What is a Software Engineer — Uses industry standards and best practices

I sat there dumbfounded.  I was absolutely sure that my friend was pulling my leg and would soon start laughing.  I waited.  No laugh, heck, not even a smirk.  Instead a wave of disbelief and disappointment crossed his face.

My friend was working on the new version of some internal website.  As we met for lunch, he detailed to me a meeting he’d just gotten out of.  They were trying to figure out how to localize the website.  They were a multi-national company, and although English was the accepted business language, the IT department wanted to be able to provide workers in non-English speaking countries the opportunity to view the website in their native tongue.

What he described next was nothing short of amazing.  I don’t remember all the details, but I remember it involved no less than 6 database tables as well as a couple of input boxes, and possibly a hidden field on a web form.

Apparently, a singled developer in charge of the translation component had concocted this entire scheme.  The site would all be written in English and then through several joins of multiple tables, it would be able to be refreshed into a different language via a drop-down in the upper right.

I remember thinking “There’s got to be a better way.”

As we ate our lunch, I listened as my friend vented about how he thought it was going to be overly-complicated to implement, and be a maintenance nightmare.  The one (rhetorical) question I remember asking him was “Do you think this is how Amazon does it?”

Software engineering has a relatively low cost of entry.  This can be a double edge sword.  On the one hand, you don’t have to go to 13 years of school, followed by 4 years of college, followed by another 2-4 years of graduate and post-graduate studies to be able to write code.  On the other hand, it makes it easy for people to spend their entire career writing software and never challenge their assumptions, never examine if what they’re doing is the best way.

Although the software industry is not as mature as the civil engineering industry, it does not mean that there are not already established patterns and practices.  If you want to retrieve data from a relational database, you can use transactions and SQL to ensure you get what you want.

The same holds true for specific practices as well.  If you want to monitor an event, look at the Observable Pattern and implement that.  When writing OOP code, check out the Single Responsibility Principle.  Consider the idea of separation of concerns when designing systems.

Just as my friend’s website wasn’t the first to desire to be multi-lingual (this was in 2008), chances are, you aren’t the first person to implement something.  You might the be the first to implement it in your domain, or in your specific case, but you can still learn lessons from those who went before you.

Someone who won’t follow accepted principles is too much of a liability to be considered a good software engineer.  Not only is there more risk that her code will break, but there is also the risk that she’ll leave the company and someone else will have to sort out the pile of junk that was her attempt at a translation service.