Haseman on Mobile

Many column inches have been devoted to defining the ‘good’ programmer.  We programmers read such stuff because we’re all paranoid that we fall under the ‘bad’ or ’stupid’ programmer.  We all, if we read up on the art of making software, like to think of ourselves as members of the elite few.  I have a news flash for you: you’re probably not. (but then, neither am I)

You cannot define what a ‘good’ programmer is without first examining the environment in which this programmer will be producing code.

Just as different martial arts have advantages and disadvantages based on the battlefield, programmers, given a set of skills and abilities, will have an environment in which they will excel.  The art of finding ‘rockstar’ programmers is less about tricky math problems (above a certain point) and more about matching their particular quirks (we all have them) with an environment that allows them produce.

For the sake of expediency, I’ll break down programmers into Cooks and Bakers.  This is absolutely an arbitrary distinction.  There are more interesting ways to bisect the programming world, but this one makes for a quick explanation.

Cooks are the creative ones.  They enjoy the big pictures, they like putting things together (especially in the early stages).  They struggle to remember small minute details like thread timing and tend towards simple, crippling, off-by-one-type errors.  Give them a blank page and they’re make you a mural…just don’t expect every building to be exactly to scale.  In the later stages of a project, they make for amazing problem solvers but will often cause more bugs on the way to a solution.  Cooks, sadly, are the most common type of programmer out there. (I say ’sadly’ because I’m a cook more than a baker)

Bakers, on the other hand, revel in the details.  Give them a comprehensive specification and they’ll be a hog in a manure farm.  They often miss the big picture, frequently say ‘but that’s not in the spec’ and often struggle with the blank page.  They hardly ever make mistakes of omission but the mistakes that they do make tend to be large in scale an very difficult to fix.  Hard core bakers are rare, which is good as they often fight with each-other.  But at any successful company you’ll always find one.

You wouldn’t wear Japanese samurai armor to fight trench warfare.  In the same way,  you shouldn’t ask engineers to work exclusively with what they’re bad at.

There’s more than style to consider.  If you’re a contractor and you’re working on a project you won’t have to maintain, there’s no incentive to write clean ledge-able, extensible code.  On the flip side, if you’re on salary, you work on long lived libraries or applications you better be or work with a baker.

With this in mind, I would offer the following hypothesis:

A ‘good’ programmer has two traits, which, interestingly enough, haven’t anything to do with the ability to bang out code:

1) They can communicate.  They build trust, hit their deadlines (or give you plenty of warning when one will be missed) and don’t hide their shortcomings.

2) They are adaptable.  They may have a preferred working style and project type, but they’re willing to work outside their comfort zone.  They know the rules, but, when the situation calls for it, they abandon them with alacrity.

That’s it.  If, in defining what makes a great programmer, you list a series of programming habits and skills, you’re only defining a programmer who works well in a particular environment.  I’ve seen programmers blow a simple linked list reversal in an interview and then turn around upon being hired and blow my mind.

Building a good team is less about complex logic problems and obscure programming knowledge and more about building a group of people that complement each other.  When you interview your next potential teammate, make them write some code, and then take the time to figure out how they work.