Why a Great Programmer is Worth Fifty Good Ones

Great programmers are orders of magnitude more productive than merely good programmers.  It’s like basketball players.  Michael Jordan isn’t just 20% or 50% or 100% better and more useful to his team than you or I would be; he’s simply in another league (or was).

The best thing you can do to make your technology-based company succeed is hire (or outsource to) a great programmer.  Second best thing (Mary might disagree) is get a great marketing person but that’s another topic for another day.  Today’s post is about the person who will build the better mouse trap for you.

Question came up when I was consulting to a development manager at a tech company.  He told me that the CEO, his boss, wouldn’t give him the salary and option freedom he needed to close a great programmer he’d found.  Salary would have been 20% above what he had approval to offer; and, thanks to the new accounting standards for stock options, he didn’t have the authority to offer options.  He lost the potential new hire and had to settle for someone merely “good”.  Ironic thing is that he had several open positions so, once he gets through hiring several people, he’ll end up paying more in the aggregate than he would have paid for the superstar – and probably won’t get as much productivity.

I suggested that he make a deal with his boss:  put a cap on total budget but not individual salary.  Let him, the manager, decide whether to put his budget into one or more superstars or a gaggle of good players.  Alternatively, promise to produce more with the same budget if only he can have freedom from salary caps.  He promised to take my advice but too soon to know if it’ll work out.

But why is a great programmer worth fifty good ones?  It all has to do with the interfaces.

If one person can do a whole project, there is a whole layer of complexity, documented interfaces, and misunderstandings that is eliminated compared to having two or more people working on the project.  Meetings don’t have to happen; schedules don’t have to be synched; joint-testing and finger pointing over faults doesn’t happen.  No personality conflicts, either.  The actual amount of work required to do the project is much less when it is being done by one person.  Also management time is reduced.

So, suppose your typical project (I know there’s no such thing) needs to get done in a month.  If you have programmers who, working alone, could do this project in two months and the deadline is real, my guess is that you’ll have to assign four of them plus a manager to get done in a month.  Such is the inefficiency of multiperson projects.

But, if you have a superstar who can do the whole thing in a month, you only have to assign the superstar.  You also get better odds of actually finishing on time AND get better, more maintainable code.  Now how much more is the superstar worth than the merely “good” programmer?

But there is more to the productivity gap than just avoiding multiperson projects, as important as that avoidance is.  A great programmer, working alone, is usually orders of magnitude faster than a good programmer also working alone.

If you’ve ever had a superstar working for you, you’re probably used to leaving him or her behind in the office when you go home – if you’re the CEO of a startup you don’t go home that early – and finding him or her in the office when you arrive.  If it’s a him, the stubble’s a giveaway; women cover up a little better.  A superstar prefers to work in at least twenty-four if not forty-eight or even seventy-two hour spurts.

Again, it’s the interfaces: it’s very expensive to put something down, go home, sleep, wake-up, and then recover all the loose ends. The first half of writing a program creates almost all loose ends; the second half is tying them back up.  Like surgery. If a programmer has the skill and physical stamina for marathon gulps of creativity, then there are many fewer times when the non-productive work of putting stuff away neatly (mentally) and picking it up again has to happen.  For similar reasons, one-person debugging is best done when you can crawl inside the code and stay there until you’re done.

Now, unfortunately, this kind of endurance is a young person’s game.  Michael Jordan isn’t in the NBA anymore.  I can’t stay up seventy-two hours anymore, not even forty-eight.  And I can’t program nearly as well as I used to.

Older programmers can be craftier, though, just like older athletes.  Remember, productivity isn’t measured in lines of code, far from it.  Too many lines of code is the hallmark of an unskilled journeyman.  Productivity is measured in terms of how little time it takes to create how many great things that actually work.  So the third reason that superstar programmers are superstars – after the ability to do huge project alone and at a single bound – is a canny knack for the smallest solution.

I posted about super debuggers here and posted a phrase- book of programmer-speak. How programmers can manage their non-technical CEOs is here; managing technical CEOs is here.  The character Dom Montain in my novel hackoff.com: an historic murder mystery set in the Internet bubble and rubble (hackoff.com is an anti-hacker software company) is a super hacker which is, of course, a sub-breed of super programmer.  He won the freshman robotics contest at Caltech before dropping out to write video games.  You can read or listen to the novel free at www.hackoff.com.

Here’s a puzzle for superstar programmer types:

What’s the general algorithm for the longest running, non-infinite program on any digital computer?  Obviously, no I-O of any kind is allowed nor may a clock be queried. You can assume that the computer will continue to function for as long as necessary and you can ignore quantum uncertainty (I know that was worrying you). Hopefully, someone’ll answer in a comment but, if not, I’ll post the answer some day.