All Programmers are NOT Created Equal

All programmers are not created equal. There. I have said it. It is our equivalent to saying, "The emperor has no clothes."

There is much evidence that, indeed, all programmers are created equal. My exhibit for this: hundreds of thousands of spreadsheets built by project managers. Okay, maybe I will count that as hundreds of thousands of exhibits. I have even contributed at least several hundred of them myself. It doesn't make it true, no matter much it makes the spreadsheet easier to use.

Okay, so it may not be true that all programmers are equal. But it is it approximately right? In my experience (many, many years) on real projects with real delivery deadlines, there is an order of magnitude difference between programmers (that is, 10x difference). Even after throwing out the incompetent programmers (who produce zero), the really good programmers are ten times better than the really mediocre programmers. So even in approximate terms, all programmers are not equal.

Ask a programmer you know about this. (You may be a programmer yourself.) Do they know a really good programmer? How good is she/he? You will likely hear of legendary feats, impossible tasks done in a weekend, feats of heroism worthy of superhero status.

So as a project manager, you should seek these resources out. The "one" on your spreadsheet can become a virtual "ten". That is contingency, risk management, and a cheap insurance policy, all rolled up into "one".

How do you find these programmers for you project? Sorry, more bad news here for the project manager: These resources don't automatically correlate to most of your company metrics.

• Some correlation with experience: Look for years programming; discount years of being an architect or any other non-programming role that doesn't involve personally writing code.
• Negative correlation with years since directly writing code for the job.
• Slight correlation with title/level: Does your organization have tiers of programmers (Dev 1, Dev 2, ...)? Higher levels are more likely to be stronger programmers. If your company has a true meritocracy (versus pure seniority system), a top-tier programmer must have been good at some point to be promoted. So there is a bit better chance that it is still true. Caveat: Negative correlation with years since directly writing code for the job.
• Negative correlation with non-programmer titles: Speciality titles are signs that (1) the skill is now gone, or (2) "Those that can't program, [fill in your favorite job title]". Be wary of architects, particularly if they come with adjectives (web-services architect). Designer titles are a little less risky, but have the same flaws. Ask the key question, "Do you write code?" Run away from any answer like, "I am past that" or "I leverage others".
• Some correlation with salary: The better programmers are probably paid more. Someone has recognized that they are worth holding onto. Most organizations are not as dumb as we think about matters of survival.

So, if all these indicators are not so good, how do I as a project manager know I am getting at least my fair share of these super-programmers? Easy. Ask the programmers. You may not recognize their legendary feats, but they know about them. You may need to prod them a bit; you may need to tolerate some geek-speak. Nod knowingly, and listen for the names. Another way to prod: Ask them, "If you were marooned on a island with the natives that are cannibals, and you had to program your way off the island, who whould you want to be there to help you?"

How many of these super programmers do you need? As many as you can get. What happens if you don't have them? Well, that is a topic for another day.

[This is part of the People thread of this blog. See The 3 P's of Agile: Process, People, and Pods for the overview.]