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.

Comments

[Michael Hamilton]

Tom:

Another thought, I find myself requiring approximately 15-30 minutes to fully re-immerse myself in a typical problem domain if it is written well. If not, it might be an hour or longer throughout the day as you need to reference new pieces. The amount of time it takes you to re-immerse yourself I believe is directly proportional to the cleanliness of your code.

Let me recommend looking into the book Clean Code by Robert C. Martin. It would make for an excellent gift to any programmers who are "good" but would like to become "great". The tidiness of a problem will save REAMS of development time and is in itself a great springboard into faster turnaround and better results with more maintainable code.

I would consider myself an advanced programmer and I found the book very difficult to read, not because the subject was difficult, but because it forced me to re-evaluate the way I write code. Given to a newer programmer I imagine it wouldn't be as difficult for them to get into, but they might not see -why- things are suggested because a lot of the concepts require experience to really digest.

That said, it would definitely help steer them in the right direction, give it a look.

[Michael Hamilton]

Tom:

I understand extraordinary circumstances call for extraordinary effort. I guess what I was getting at is that it shouldn't be that ridiculous hours have much to do with the separation of great from merely good. I will admit that I've spent 24 and sometimes even 32 hour stretches though rarely longer than that on last minute school projects that I had been working on regularly up until that point.

Presently I'm the sole developer responsible for (and indeed, the creator of) the CMS software my company uses in many client sites. It's a small company with two other programmers who rely on my code daily so it's a bit easier to manage than some multi-dozen man company. I know that some days require longer hours, you can't leave for the day and have broken the pipeline. Personally I haven't put in more than 12 hours in a sitting but that's pretty rare. 72 would be counter-productive without at least having naps to rejuvenate you... But as I said earlier, best to avoid that type of situation when possible.

When I was at a very large game studio for a workterm I got during university I got a great glimpse at the games industry and what I saw was that crunch times like the one you described are being addressed as the industry matures. Right now managing programmers is such a new type of requirement that many companies just don't have it right yet and so you see deadline creep, crunch times, and stress.

Things like that are getting better year after year and I suppose it depends on where you work and what kind of clients you cater to, but in general good scheduling should avoid the marathons you've described.

In any case, the rest of your article I found myself nodding to. I suppose it's old now, but it is still pretty relevant. I was just searching for "Programmer Worth" in google to see if I could find something on the topic your blog discusses.

[Tom Evslin]

Micheal:

I worked 72 hours on rare occassions - not because I had only 72 hours until a deadline but because I was at a stage in a problem when the overhead of putting it down and picking it up was greater than the pain of staying awake (I was young, of course, or I couldn't have done it).

Eating shut down after about 36 hours. It took more than a day to recover - but less than a week.

But I think the same task may have taken more than three elapsed weeks if I tried to break it into eight hour segments.

[Michael Hamilton]

No sane person works more than 24 hours. There is a very quick drop off of productivity, ability to concentrate, and general attentiveness with extended sleep cycles which has been demonstrated in several medical tests.

As a manager who might see a programmer has spent 24 hours at his desk you better damn well be telling them to go home and get some sleep. Product cycles usually involve a "crunch" time, but this is neither desired nor required. If you are experiencing a significant deadline "crunch" it is usually due to lack of proper design and management and should not be considered "normal".

Putting the pro into programming is what separates that top 5% from everyone else and those who fit in that category should be greatly valued. Part of valuing your employees is making sure work and personal life are in balance. Sleep is a part of that. You're looking at a future burnout if they are running 72 hour shifts, and I am not talking years, I'm saying a few months.

[Erica]

OK, I would like to comment on this as someone who has considered herself a great programmer. This sounds arrogant, I know, but for the particular gig I am thinking of I was the top paid developer, I created two systems basically from scratch (this place didn't believe in requirements) and when I left they hired several people immediately to replace me.

I worked long hours but not 72 at a stretch. I think throwing that in confuses the issue because any boss would like to hire someone who works 3x the hours of anyone else. The real difference lies elsewhere as I discovered.

I left to start my own company, and like the post I of course wanted a superstar too -- I didn't want to code everything myself. What I ultimately discovered, and this was a painful process, is that management plays an important role here. If you have the right systems in place for designing and communicating interfaces and requirements, a lot of merely good programmers can become excellent ones. It is not easy to do, but it will allow your project to scale, to hire from a pool of people who want to see their families occasionally, and save you when the superstar quits in two years to do something more interesting.

You do need a great architect, as an earlier poster mentioned, and here I confess I've basically had to take over. But going through the other steps has made our development team stronger and allowed us to tackle larger problems. While I generally recommend hiring the smartest people you can get, if you are dependent on a superstar I would take a hard look at your process. Great managers are important too.

[Zeno Davatz]

This is a great post and I totally agree with what you are saying about how 1 programmer can be as good as fifty. But one thing does not seem right to me:

> A superstar prefers to work in at least twenty-four > if not forty-eight or even seventy-two hour spurts.

The best athletes, musicians, entrepreneurs are those that have gentle and regular Rhythm. Sniper-Style-No-Sleep will do lots of damage in the long run.

Also for me: A great programmer gets greater as he grows older.

[timb]

"Hopefully, someone’ll answer in a comment but, if not, I’ll post the answer some day." ... well played.

[Joseph Bruno]

1. The computer is deterministic.

2. So its next state depends on its current state and on nothing else.

3. And a given current state can only ever turn into one "next" state.

[you can't disprove this with an "up and down" counter: when it is counting up the state is {n,UP} and when it is counting down the state is {n,DOWN}, which are two different states - so the total is N+1 bits of state, N in the counter and 1 in the "UP/DOWN" setting].

4. So the longest program is the one that goes through the most states, once each.

5. N bits of memory can have 2**N possible states.

6. So the longest program cannot have more than 2**N possible states.

7. A counter can have 2**N possible states.

8. So no program can take longer than the simple N-bit counter.

Each byte of program code subtracts 8 bits from the space available for the counter. So each byte of program reduces the running time by a factor of 256, which makes programmatic cleverness very unlikely to be useful.

Using the registers would be useful if you can do this in less than 4 bytes of code (less than 8 bytes, for a 64-bit computer). For instance,
XXX: INC AX
JNZ XXX
takes only 3 bytes but lengthens the effective "counter" by 4 bytes.

[Charlie Crystle]

Wow, Tom. Great post, and congrats on the attention. I passed it on to my dev team...

[Eighty]

If you throw together the size of the program's own "stack" (for a Turing machine it holds the position of the writing head and the position in the code) and the size of the memory into N, sure, you get an upper bound for the running time of 2^(N-code).

I think it will be hard to attain that upper bound though. The stack would have to run through all its permutations an equal number of times, and that puts more restrictions on the problem (for example, if the stack is stored in binary and each counter in separate bytes, the size of the program and the size of the memory have to be powers of 2).

But for "any digital computer" you don't have the luxury of deciding how much space you want to use for the program, its stack, and the memory. If you're only given the size of the memory, and a maximum size for the program and the stack, the problem becomes much more difficult.

[CS Prof]

Counting is the answer.

With no outside influences our program must be deterministic. Given some state A, such an algorithm will always proceed to the same next state B in the deterministic order. If we only have the bits in memory to represent such states, and if there are N such bits available, then only 2^N states can be uniquely represented. Thus, a deterministic algorithm could only take at most 2^N steps. A counting algorithm is likely the simplest way to visit each of these 2^N unique states.

Aside: If you assume that you also have extra bits elsewhere in the computer to help represent states then that merely adds to the value of N. Practically, some number of bits must be set aside to form your algorithm code. Yet, a simple counter starting with all other "data" bits as 0's and adding 1 until it has all data bits as 1's will likely take the fewest number of program bits to represent.

Finally, the problem with using StupidSort or "counting up, then down" is that you have to assume that you have enough bits in memory to represent each state that you're visiting. For example, assume that you have a counting algorithm that goes through all possible combinations of the N available bits and thus through all available state representations. If you want to count up and then back down to double the running time, then you need an extra program bit to determine if you're currently counting up, or down. Removing this data bit decreases the number of states you can represent by half. So, no gain in longevity was achieved. For more information, see computer science complexity results, such as those relating space complexity classes to time complexity classes. (i.e. P <= NP <= PSPACE)

[Doctor]

So, let's throw some Kolmogoroff complexity in the mix: the size of the program is also significant. Basically, you age given n bits of memory. You can program your machine to interpret the memory as code or data. The solution is to make the machine go through every possible state of those data bits for 2^(n -code) steps. Making code bigger makes data smaller for no net win.

[UJ]

I wonder how all the great programmer has enough time to read and debate on worth of good and great programmer when they have to put 72 hrs a week to meet the deadlines.
Meeting deadlines with quality and manageable code is justifies success.
I would say good programmer are as good as great programmer as long as they finish their work in given deadline.
If a programmer can bring more reusability and better performing code, he may qualify for better programmer but nothing more.

[Eighty]

As stated before, a counting program is not the answer. If you make the program larger you can run through all permutations of the memory many times (consider a Turing machine with one memory cell and a program of 100 instructions).

There can't be an algorithm; an algorithm has a certain size, and for a long-running program you want a long program (compare with the Busy Beaver problem).

[auriga]

Well the purpose of the software industry is to make money, not invent solutions to academic problems. So a great programmer would ask: Why do you want to solve that problem? It might turn out that you do not actually need a solution to that problem, but to another one.

[biff]

void main(void)
{
int x;
looooooooooooooooooonnng int y = infinity;

for (x=1; x<=y-1; x++);
}

[Vince P.]

Solution in C#:

using System;

namespace ConsoleApplication1
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
while(true)
{
Console.WriteLine("Hi there!");
}
}
}
}

There you go.

I can hear you now. "But.. but that's infinite!" you say.

Really? Prove it.

Stupid question really.

[Dennis]

To everyone who thinks they can make the longest-running program simply by counting up to a number consisting of all the bits of RAM set to 1...I can double your running time by making the program slightly larger and counting back down to zero.

You're not cycling through all possible running states if there's a separate program in there doing the cycling.

[Rintoul]

How can someone with a blog which cannot be printed easily comment about "great programmers"?

[w durden]

I agree there is some uncertainty in the problem statement. What is finite for instance when the problem also says that it will run for as long as it takes... For instance, zero all of the ram and randomly flip one bit and check for all 1's. The probability of eventually hitting all ones in a finite size memory is 1 if we have an infinity of time to wait. (If you reduce it to some meaningful small amount of ram we pragmatically know this is true. While folks might argue, were do you doubt it is pragmatically true? Will it happen with two bits in finite time? Four bits? How many bits of ram do I have to have for practical experience to say it really might never hit all 1's.) Its a limit problem. If we have infinity to wait the probability = 1. If this doesn't violate the infinity aspect of the problem, then randomly flipping bits and checking has a probability of being longer than any count based approach, but it is not GUARANTEED to take longer than a count based solution, and it is only GUARANTEED to finish at infinity limit though pragmatically with a finite memory store it must finish. If this violates the problem then you have to fall back on iterations through all of the machine states ...

[Casey Marshall]

Doesn't "longest running" and "infinite" kind of eventually both end up at the same place? Maybe I don't understand the wording of your question or what you're looking for.

To burn a lot of cycles I would probably do a Towers of Hanoi with 64 rings. I have heard that takes a good long while. Of course, you can beat me by adding another ring, but I am sure the hardware will fail first :)

So here is a counter-question, which maybe will enhance my understanding of the problem. Can you describe a non-infinite program that cannot be made longer-running by increasing some factor of N, whether than N is the number of bits in a counter, bits in a keyspace to brute-force, or rings on a post, etc, and is still longer than all of these, for any aribitrary size N?

If you can, my intuition tells me that solution would be infinite. If that is not the case, I am prepared to be enlightened.

[w durden]

There is a mixture of roland and nigel's answers that would work better. Use a bitindex of the ram to keep track of your position therein. Count (flip the bits of the ram below the index) to every bit state below the index the number of times the bits above the bitindex can be counted (i.e. create every machine state below the index repeated by the number of machine states above the bit index), then increment the bit index one bit. This runs longer than Rolands because it creates every possible state lower than the rammax multiple times. Unfortunately my brain was/is warped with imperative language thought patterns, so give me a bit before I post something in pseudocode.. All this of course divides out the program memory space from theoretical RAM space. Our digital computer is part finite machine RAM and some other part that can set those states. Reality intrudes and makes us carve out part of one for the other....

Back to the problem, so for instance, say we have eight bits of ram. When our index is at bit three we can count to 4 below the index and 32 above (2 to the 2nd and 2 to the 5th). We end up setting up all the states below multiple times. Here reality is our friend if we assume the binary value of our digital machine is much larger than the maximum counter we might have in some "other register". We are using the ram as both machine state and counter....

[Jimbob]

I've met those programmers that work in 72 hour stints. They produce garbage. After the first 12 hours, they can't think clearly enough to produce coherent code. I've been the person to clean up their mess more than once, and let me tell you, I could've done a better job working 8 hour days for 3 days than they did in the 72 hours straight.

[A. E.]

This is not the same as the Busy Beaver problem. The counting algorithm is the correct answer.

The program will run infinitely if the memory state repeats itself. Hence we want to go through the maximum amount of states without repeating, which is easily achieved by a minimal counting program. Just wipe all the memory and start counting. It's probably not good to count using the registers, unless the code takes less than 32 bits (or whatever the register size is) per register.

I don't know if knowing this proves that you are a great programmer though. A mathematician would probably be able to figure out the same thing without knowing a single programming language.

[Dean]

I don't believe you. There is no such thing as a "great" programmer that's worth 50 "good" programmers. Even Michael Jordan was not worth 50 good NBA players.

While I agree that one person doing a project alone saves a lot of time by not having to communicate with anyone else, I don't think that's meaningful, except in the smallest of projects.

Also, the "great" programmers in your example appear to be only designing and coding. This is unrealistic. There is so much more to a programming project than that. You have to talk to users about requirements, you have to test, you have to document. What about usability? If you're building a UI, what about making it good-looking? You have to "interface" with a lot other people for all these things. At least I do. In other words, your "great" programmer has not finished your hypothetical project for you.

And your example of a "great" coder sounds like a real cowboy to me. I wouldn't trust the work of anyone who worked in a "seventy-two hour spurt", or even a "forty-eight hour" one. But even if someone could produce excellent code that way, so what? Why is that better than someone producing excellent code in eight hours a day? Working seventy-two hours straight does not make you a faster coder. All you've done is compress eight days into three--the coding takes the same number of hours. I don't agree that there is an "interface" problem for a single coder stopping work for the night. When you're deeply involved with a project, it stays in your head even if you take the time to go home, eat, shower and sleep.

I think it's a disservice to tell employers they should try to get "great" programmers who do the work of 50 "good" programmers. Because, like Santa Claus and the Easter Bunny, they don't exist.