A guest post for Handshake 2.0 by Ryan Hagan.
In Mobile App Programming vs. Mobile App Engineering, Dr. Balci emphasizes engineering in software development. I prefer the term "craftsman," but "engineer" will do for the purposes of this post.
Programming is easy.* Delivering working software that solves the customer's problem is much harder. I'm going to generalize quite a bit here, and some people will be upset by that, but too bad. I've been around long enough to have learned that most of the people that will take umbrage at my categorizations are generally the very people I'm talking about.
When most businesses say to themselves, "I have a problem and I need a programmer," what they're truly saying is "I have a problem, and I think I need a custom software solution to solve that problem." Now those businesses have two problems.** A "programmer" is going to have a tough time pulling the requirements from the client and delivering what the client actually wants. Clients aren't software developers and software developers are rarely domain experts in the business of the client. The fact that those two are coming at the same problem from very different viewpoints and are generally using very different language makes requirement gathering difficult. A programmer will rarely spend the time needed to understand the client's problem, and will begin writing software with only a superficial understanding of what the client really needs.
Programmers have a tendency to rush into the act of programming without designing a system. Programmers tend to release code without testing. Programmers rarely consider fault-tolerance in their systems. Programmers release code that hasn't been put under the stresses of the production environment.
Engineers, on the other hand, tend to take a much more holistic view when creating a solution. Engineers tend to seek to understand the problem and design an appropriate solution. Engineers tend to release code with executable tests. Engineers understand that systems fail, and program for that eventuality. Engineers release working and maintainable code.
So…how does one distinguish between a programmer and engineer? Their résumés? It's almost impossible to get any worthwhile information from a résumé. An interview? I can do that, but I do it for a living. Most clients have no idea what questions to ask. Their degrees? I know high school dropouts that have skills I could only dream of, and I know Ph.D.s that can't code their way out of a wet, paper sack. Their portfolios? Unfortunately, portfolios can be misleading.
The best way I can figure is to ask for references. Engineers worth their salt will easily be able to produce references for their last three or four jobs. Call those references, ask them questions about the technology as well as the interaction with the developer. Find out if the person was willing and able to work closely with others and to deliver an appropriate solution. Once you find and hire someone you work well with, hang onto that person (or team) for dear life.
*Programming is not easy.
**I'm not that clever. This is simply a modification of a well-known quote from Jamie Zawinski, a Netscape engineer in 1997. The original quote is "Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems."
Ryan Hagan has kindly written guest posts for Handshake 2.0. Previous posts include The Really Interesting Conversations in the Technology Sector and Creating Peer Groups for Technology Industry Specialties.