I have found that, for better or worse, those companies that are not headed by technical people themselves tend to think of programmers as cogs - maybe some are better than others, maybe some are more expensive, but at the end of the day, a programmer is a programmer is a programmer. Even inside the technical world, there is only a slightly more sophisticated sort of measurement - a programmer Alice is good at A and programmer Bob is average at B and programmer Carla is great at C. But very little time is spent on actually thinking of programmers in terms of type or temperament. But temperament has as much effect on the success of a project than on skills in many cases.Over the years, I have found many different reasons for why people chose to become programmers - because the money is good, because they liked tinkering with stuff as kids, because they like math, they fell into because they were the most computer savvy person at some job, etc. etc. The truth is, the practice of programming tends to attract a wealth of personality types, which in turn means you get a of different people doing wildly different things under the name of “programmer.”The types of programmer I have identified over the years:
- Larval - junior programmers - curious maybe, confused often. Not sure what type of programmer, if any, they will eventually morph into.
- Diggers - The guys that are great at hunting down bugs. They seem to have an infinite ability to pour through log files, read configurations, run countless GREPs across prior versions of the code, etc. Often, these guys aren’t actually true programmers - they often can be testers, sysadmins, etc. But the title doesn’t matter - what these guys do is dig.
- Housekeepers- The guy who seems to remember all the crazy legacy reasons for things, who knows in intricate detail how people use the system, and can usually tell you, almost instantly, what it will take to perform each particular enhancement or bug fix. Oddly, these guys tend to be less good at actually producing code (though this is more due to mindset than ability).
- Directors - Much better at telling people how to produce code than actually able to produce code themselves. Directors often become Business Analysts.
- Builders - these guys produce code. It doesn’t really matter what they are working on - they write it, no matter how large.
- Artists - These are the guys who don’t seem to be producing anything, and then disappear away for a 48 hour programming jag that produces a brilliant, elegant piece of software. And then they disappear for a few more days, hopefully to sleep.
- Editors - These guys are oddly bad at producing code, but terrific at optimizing, debugging, and tweaking existing code.
- Duct-Tapers - A duct-tapers main goal is to get things working. They are willing to, and often do, accept a less than elegant solution today in lieu of a perfect design tomorrow. Great at emergencies, hot-fixes and the like.
Where all of this becomes important is in the staffing of a project. Different projects will require different staffing models. Most staffing plans tend to think of staffing programmers by skillset (e.g. database programmer, VB guy, JMS expert) and/or experience level. However, specific skills can most often be taught or brought in much more easily than mindsets can be changed. A digger will always be a digger - even if he started out as a Database programmer and ended up a U/I guy. So a successful staffing plan must take temperament into account as much as skill-set.
- Green field projects, especially small ones, are better staffed with Diggers, Artists and Duct-Tapers. Artists lay down the big bigs, duct-tapers pull it together, and diggers smooth the rough ends. Oddly, Builders are less useful here - simply because inspiration and innovation can often trump perspiration in the early going of a project. Directors and Editors are to be avoided and Housekeepers will be bored.
- Young projects (something is up and running, but not “complete”): Diggers and Builders. Artists and Duct-Tapers will start to get bored - Directors will start to appear
- Refactoring, re-writes: Great for Housekeepers, Directors and Diggers.
- Maintenance: Housekeepers, Builders. A Duct-Taper is good here for small bits of continuous improvements.
- Integrations: Duct-Tapers with the help of a Housekeeper or Director. Diggers are useful if the integration is big.
I have seen projects fail for reason I think can be directly attributed to the temperament of the people involved - a major application rewrite that fell apart because there were no diggers or housekeepers (”they built the first one wrong, why would we let them at the second?”), a new application that was delivered two years late because everyone on the project was a Director or Builder (the Builders just wanted to be told what to make and the Directors could only say what was wrong), and a product expansion loaded completely with Directors (ever seen a program where the same for loop is rewritten 28 times?).At this point, its probably obvious that of all of the programmer types, a duct-taper and diggers are the most useful (though, for full disclosure, my career has mostly been green field and early phase stuff. Assume biases per your discretion). I tend to try to find work that has attracted duct-tapers and has kept at least one or two around.