Why programmers are not paid in proportion to their productivity

The most productive programmers are orders of magnitude more productive than average programmers. But salaries usually fall within a fairly small range in any company. Even across the entire profession, salaries don’t vary that much. If some programmers are 10x more productive than others, why aren’t they paid 10x as much?

Joel Spolsky gave a couple answers to this question in his most recent podcast. First, programmer productivity varies tremendously across the profession, but it may not vary so much within a given company. Someone who is 10x more productive than his colleagues is likely to leave, either to work with other very talented programmers or to start his own business. Second, extreme productivity may not be obvious. This post elaborates on this second reason.

How can someone be 10x more productive than his peers without being noticed? In some professions such a difference would be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. Sales are easy to measure, and some salesmen make orders of magnitude more money than others. If a bricklayer were 10x more productive than his peers this would be obvious too, but it doesn’t happen: the best bricklayers cannot lay 10x as much brick as average bricklayers. Software output cannot be measured as easily as dollars or bricks. The best programmers do not write 10x as many lines of code and they certainly do not work 10x longer hours.

Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on.  It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.

The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”

Related posts:

Writes large correct programs
Experienced programmers and lines of code

136 thoughts on “Why programmers are not paid in proportion to their productivity

  1. @ARaybould – thanks for reminding us of an irrational, but all too real condition. Sometimes at work I ask if anyone can explain to me why my company pays a contractor to make mistakes and then pays me to fix them.

  2. @Grant: As to why a company might hire outsiders to make mistakes, you might want to read this article about cargo-cult consulting. It’s a tale of a consulting company telling a client what they want to hear even though it looks like a billion dollar mistake.

  3. This is a great article. I couldnt agree more. As others have pointed out, programmer productivity is very hard to measure. Specially in the current, fast paced environment where people change jobs when projects are done.

    Since programmer productivity is hard to measure, and companies impose a forced bell-curve evaluation, followed by a rank and yank system, a lot of top skilled programmers start spending less time on being productive and more time on being “visible”, schmoozing etc. Those that cannot do this, or are uncomfortable doing it, will become discouraged and not spend the effort if they are not getting recognition. Or, they will try to move into management thinking that they will get better rewards, with the result that the company loses a good programmer and gets a potentially bad manager.

    Compounding the problem are frontline managers who themselves are fighting for their jobs everyday that they cannot spend time evaluating how their directs are doing their jobs. In most companies, a managed doing an excellent job as a people manager is not rewarded for it, unless he also “manages up”, or does his own side projects to show the “extra mile” that he accomplished.

  4. Quoting Gates, “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

    That said, lines of code do have some relevance: they’re a good tool for weeding out exceptionally low productivity people. “Someone who is 10x more productive than his colleagues is likely to leave,” so it behooves your company to deal with the programmers that write 1/5th the lines of code, or end up having to write the same piece of code 5x, or write code that is 5x longer than necessary. Too much, too frequently, or too little, it takes a coder to know what the hell a coder is really doing.

  5. How do you define productivity for programmers? What metric or formula is used? How do you compare productivity between programmers in the same organization when they are often working on completely different projects.

  6. No sympathy! A good programmer can be paid well if he uses his/her brain to find a better paying client/employer. If your job is to be a programmer on a project for 12 months at a fixed rate, that position will have certain expectations. If you exceed those expectations I’m sure you’ll be shouted a few beers, get attention from girls in the office, and a nice farewell after the contract is up. Reputation boost, perhaps you even learnt something new. Want a medal to go with that? What do you want? A suitcase full of cash? Comment 52 is right, it’s not a linear thing.

  7. So the 10x productive programmer can serve 10 clients in the same amount of time as the 1x “rat race” programmer.

    Or write code for 5 clients, then rework the code for 5 new products to sell B2B.

  8. The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”

    Awesome post. 100% agree. Thanks.

  9. Your description of how difficult it is to measure programming productivity reminds me of the problem those of us with impostor syndrome face. Keeping in mind that a great programmer thinks, “Hmm, I’ve seen this before,” will increase my confidence in what I do.

  10. You’ve got the points, Programmers are most effective when they avoid writing code. Bosses just don’t understand.

  11. Interesting theory, but I suspect it has more to do with economics and psychology.

    In most fields the pay spread is not very far apart for salary employees. There’s a reason for this. If the spread is large, the folks at the lower edge of the spectrum get discouraged and productivity lowers more. The folks at the top become more and more expensive partially due to the disparity.

    As a result, it’s more cost effective to only single out the poor performers and view the rest as equals.

    Sure you’ll loose 1 or 2 of your top performers every so often. But reality is people who perform that well tend to get bored and move on quickly regardless. They won’t stick around no matter how much you pay them.

    As a result, money doesn’t get you what you’d want, so why pay?

  12. This is one fine post. Easy to read and so insightful. I work almost daily with programmers and I had times when I thought, “how is it possible these guys more easily find problems than solutions?”. It’s good to see that the real good ones process their tasks in the exact oposite way. I’m using part of it for a blog post myself (with proper linkage, of course)

  13. I once knew a programmer who must have, at one time, been paid by the number of lines he wrote. His code always had the same style:

    int checkvar;

    checkvar = val;

    if (checkvar == 0)

    {

    // do something

    }

    else if (checkvar == 1)

    {

    /// do same thing as 0

    }

    you get the idea… (if this doesn’t show blank lines, imagine there are at least 3 blank lines between each statement)

  14. It may be “hard to define” a productive programmer, but many of us know it when we see it. One difficulty, is that those who possess a lower level of talent and technical insight are sometimes unable to correctly evaluate the relative productivity, or value, of the highest performers. As Sir Arthur Conan Doyle put it: “Mediocrity knows nothing higher than itself. Talent instantly recognizes genius.”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>