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 necessarily 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.”

More programming posts

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

  1. Me and my workmates have talked about this issue a lot of times and always have reached the same conclussion : We all should had obtained another degree, instead one IT-based.

    Regardless the company you look at, you’ll find that other professionals are more appreciated and best paid that the ones at IT, so I won’t loose my faith in trying to find a completely different job …

  2. The framing of the question “why aren’t programmers who are 10x more productive paid 10x more?” seems to imply that the expectation is there should be a linear relationship. Why is that expectation even there? When a waitress is 10x better do you leave a 100% or 150% tip? Probably not. Maybe you bump the tip up to 25%? I think there is a logarithm involved somewhere in the relationship.

  3. I believe that it’s all about supply and demand. Someone who produces 10x as many hamburgers even though there is only a market for 2 hamburgers is still only going to sell 2 hamburgers. The best he can do is just surf the web for the other 8/10 of his day or spend it learning something new and fun. I completely believe that the rare individual can be 10x more productive, but those individuals are far and between; though most programmers see themselves as special they fail to recognize the mediocrity of their existence.

  4. How to recognize Uber-coders is easy:

    They make programs that are safer, faster, smaller and more reliable than any other similar program made in the past.
    And, there is a price to pay for this: as their peers will notice the feat before managers or end-users, the Uber-coder will be the target of politics and be promptly fired.

    As a result, Uber-coders end as solitary creatures (in their field) and become even more Uber as they choose what they are working on.

    Now the interesting part starts: the return of the Uber-coder might simply disqualify the work of many of its (so willing to compromize with facts) peers simply because WE ALL BECOME WHAT WE DO.

    Cheat and you will become a decent cheater.
    Code like if your live depends on it and you will become rather good at doing it.

  5. This is the same issue many sysadmin faces.

    A good sysadmin makes it look easy, no on notices the changes.
    Everyone keeps on going as tho nothing has changed.

    I feel the pain…

  6. I think you highlight the most important aspect here which is that we cannot measure productivity. That said, I think there is always a general feeling of who is contributing more, and how that contribution is made. Doesn’t it then become a question of quality versus quantity? How much quality has a developer added not just to the product itself, but to the entire process of making it?

  7. Somebody commented that being good in avoiding unnecessary work isn’t rewarded. That’s not true. I consider myself quite good at writing as little code as possible, and at the company where I worked I had respect of senior developers and I was also given a complete freedom when to work and even when and whether to show up at work at all. I usually worked less than 40 hrs a week, sometimes much less, and kept the quality of work. That was a great reward in itself, and I was still getting (slightly) above average salary increases.

    To put it differently, with good management the reward may be not money but time.

  8. JB, thank you very much. I’m clumsy with words, your link to sums it up nicely. And I agree: There’s always a gut feeling who is more important, not just among developers, but across the whole organization. But you can’t really answer that in a single line (which is covered in the linked article as well).

  9. Code I wrote in ’92 and maintained for fifteen years is still being used around the world. One key is keeping the original authors around because new programmers will always insist on re-invention.

  10. @Ryan/11 Thanks for posting the links — but how closely have you read those studies? Sackman et al is very small N (a dozen people), very short T (an afternoon), and undefined metrics; Curtis’s is larger N but shorter T (not much more than an hour, if I recall correctly), and so on. The only two that would pass muster today are Valett & McGarry and DeMarco & Lister (and even the latter would probably be bounced if submitted today).

    @John/29 I agree that there are very large differences in productivity among professional programmers, but I don’t agree that when anecdotal evidence is strong enough you don’t need studies — my late aunt’s faith in crystal healing is just one example :-) I’m also not (necessarily) arguing in favor of randomized double-blind trials: lots of other techniques can be used (see recent ICSE proceedings for a sampling).

    @Everyone else: yeah, the biggest problem is that we just don’t know how to measure the productivity of programmers. Health authorities have the same problem with doctors, and friends of mine who are still engineers complain about this as well. So let’s turn it around: does anyone know of a knowledge-based profession that does have good measures of productivity?

  11. Well, conventional wisdom…

    My personal experience as a software engineer:
    1. Pay varies all over the place. There is not a narrow range. (But it doesn’t necessarily vary by skill or ability)
    2. Productivity? Is an engineer who routinely writes undocumented, uncommented non-reusable highly-coupled code more productive than one who engineers a quality product that solves the same problem and takes longer?
    3. I have yet to see a good measure of productivity. I do know some engineers who are frequently consulted by others with tough problems, time which does not fit into most accounting systems, and slows them down.
    4. I’m sorry. I think that we would all like to believe that we are “10x more productive” and not adequately compensated. That is human nature. How many, however, do you find that say “now X, he’s 10 times as productive as I am… But how many times do you think “this was really thrown together in a hurry…”
    5. I always enjoyed the movie “How To Succeed in Business Without Really Trying”. Our craft is like so many others and not like any other. I have met many poorly trained, poorly equipped developers trying as hard as they could, and many knowledgeable well-equipped coasting along with the minimum possible effort.
    6. I love this. I love being able to do this as a job. I make terrible mistakes, and I find elegant solutions. I can accept almost anything in coworkers other than the arrogance that is unwilling to help the less adept. I think a basic skill is the ability to help coworkers become better and more productive engineers. I guess this is why I find the “10 times as productive” discussion disappointing. I do believe in continuous profession improvement. (<- I think this may be what a process joke looks like)

  12. I don’t think taking advantage of reuse (whether your code or someone else’s) is an example of a developer being 10x more productive that average. Ditto with recognizing a pattern and reusing a solution. I consider that to be average development productivity. It is when there is a difficult problem, that is not easily solved by such reuse, is solved 10x quicker by a dev (in a sustainable and quality manner) that I would say this person is 10x more productive – yes, even if it is just one line of code (the task and and solution is the goal, not lines of code). In my experience, even when I have worked with some particularly bright devs (much brighter than me – I consider myself average or slightly above), I don’t see such productivity that often – although it is not rare either.

    Those more productive devs do make more than I do and rightly so. A major part of why they make more is that they can show on their resume (and with references) that they can solve the problems that employers have better and faster than I can. I aspire to be more productive every day, in part by learning technology that is in demand, in part by improving my problem solving skills.

    Unfortunately I have encountered too many examples of devs ignoring reuse (both reusing and creating reusable code), ignoring the need to write sustainable code, the need to write quality code. I see way too much cut and paste code. I see this code from devs that are ’10x more productive’, from average devs, and especially from below average devs. The really tough part is when your boss does it; how do you tell your boss that you have seen better code from a first year intern??!

    Which brings me to value – if your lead/manager/etc. doesn’t know how to create value, doesn’t know value when he/she sees it, how can they evaluate your contribution? Generally they can’t – then you are in trouble.

    As for why devs make more than someone who cleans toilets; well, anybody off the street can clean a toilet, not everyone can write a scalable server process. It is all about supply and demand.

  13. The reason is because they can. Its ONLY about free market economics. Businesses want to get the most value for the least price… just like everyone else. Salespeople have to get big margins because that’s what keeps them happy and provides an incentive to find more customers. Sales is also the only department that actually *makes* money for the business. IT depts DO add value, but direct incoming cash flow is the most important thing for any business.

    IT an especially programmers seem to overthink this too much. The business does not think about it that much and just does what the market forces drive it to do.

  14. Brian, I agree that ultimately this is about market economics, and a lot of programmers focus on technical matters to the exclusion of economics. But I also think that businesses don’t necessarily act in their own best interests. They would do well to improve their ability to evaluate talent.

  15. If the business would be paying based on the number of defects found (less=more money, or pay a fine for each defect), then the whole business would drastically transform itself. It’s nice to be able to crunch out so-so code that does it’s job so-so, and then polish it a bit, and then later come back in to fix things, all paid by the hour. This makes it easy for an hourly based worker, and the manager doesn’t understand anyway what is going on. The defect are seen as an accepted part of the job, because it happens everywhere. Read Clean Code by Robert C. Martin. It is enlightening. And of course we should then also reject faulty specifications to start with. “I want it to be social” is just not specific enough. Otherwise how can you say it’s defective at all?

  16. That “10x more productive” person has numerous distinguishing characteristics — “think more, code less”, for instance, and many benefits are gained from that.

    S/he may also incrementally improve application architecture, so that future development gets a permanent cost savings. (Or even make new functionality feasible where it wasn’t.) Because it’s done incrementally, the effort is unlikely to get recognized except maybe by one’s peers. I wish a little more attention were given to these accomplishments.

    It’s very hard for some geeks to spend the time to document and quantify each improvement; it’s time you’re not coding!

  17. I was three times more productive than my peers, and caused about two times as many problems in terms of bugs.
    Because of the increase in bugs, I was singled out as a problem and got a bad review. After working late every night to 9pm.

    Life is sometimes insane.

  18. Anyone know how I can take myself OFF the email notification list for this blog. (No offense, great comments, it’s just flooding my email a bit too much).

  19. @Philip Andrew: I hope you’re joking. If not, try to think about the meaning of “productivity”. Sorry if I got you wrong.

    @Davi Minor: Try the link at the bottom of this page to “manage your subscriptions”.

    I feel the discussion moves in the direction of “why am I better than …” and “how to build better software”, which diverges from the original question.

  20. howtolearneverything

    But how do you compare productivity for a programmer :) And his reward is long term: his probability to get fired is lower.

    And economically that isn’t just possible to get paid ten times more than other.

  21. This all underscores the difference between getting a job done and expending effort: programming is an activity where the former is far from equaling the latter, and why a concept like ‘productivity’, is so hard to measure when applied to programming (though you probably know it when you see it)…
    Are mediocre programmers to great programmers as a person cutting marble is to a fine marble sculptor?

  22. @howtolearneverything

    Of course it’s economically possible to get paid 10 times more, if you’re 10 times more productive you add 10 times more value to a company. If the productive person is not getting paid 10 times more then someone else is getting rich by squeezing a talented person. But because people do not understand this value or cannot measure it, it doesn’t work out. Compare it with artists: a concert ticket for Michael Jackson, Madonna could easily be 10 times what you pay for a performance of Band X. The customers understand the value and pay for it (no need to measure it by the way).

  23. Face it, you’re never going to get rich (or anywhere close) working for someone else. If you want to get paid for your true value, then do consulting work. Make sure you NEVER BILL BY THE HOUR!.

    Clients buy results and value, not your time. Read more on how to do this over at my blog series on Value-Based Fees in IT Consulting.

  24. As a (non-software) engineer managing (and coding for) a software development project and working with what I have come to regard as a great programmer, I’d like to add that the benefits of great programming are not immediately obvious and are therefore hard to measure. Many are not visible until (if) management becomes more code-savvy, or months down the line when you want an edit and it’s completed incredibly quickly because flexibility was planned in. We have robust (ha!) discussions on what the ‘client’ actually wants, but in the end it’s worth it.

    Also, programmers are frequently not mercenary, self-promoting, manager-managing types who can handle discussions about pay. I fight for raises, while the programmer appears indifferent, motivated more by recognition of the quality of his code than actual cash. So the simplest answer for why great programmers are not payed more is They Don’t Ask. This could be driven by some sort of ascetic pride, but luckily for the coder I’m a mercenary bsd who believes that companies must put their money where their mouth is when recognising excellence.

  25. Wow, great comments. They’ve inspired the following questions in my own head:

    If workers are paid their marginal productivity, and the release date of software is as late as the longest development trail, then of what worth is that productive programmer, except to his own schedule?

    If a productive programmer derives utility from the work per-se, then is this not sufficient to answer the original question? He’s paid less because he demands less to do the same work, while the less-efficient guy who hates coding demands as much to do less.

  26. Google is a programmer’s best friend (or any of the other search engines out there).

    Productive programmers plagiarize. If it has been done before, why rebuild/recreate it again.

  27. Good developers can make more. They get more repeat business. Peers recognize them and recommend them for positions. The have less bench time. It may not show up in the check as making [x] more dollars a month but over time it pays off.

  28. Thanks for sharing! I plan on passing this along to my sweetie, a programmer who struggles with the “productivity” question at his firm. He’s definitely one who needs to become more at ease taking pause in his work.

    Maybe programmers just need more code-inspired cupcakes? http://cracktheplates.com/?p=337

    Much peace,
    adrienne
    http://cracktheplates.com
    A vegan food & hospitality blog

  29. But the best bricklayers are 10x more productive than the average–or at least 5x. They might not lay 10x as many bricks, but they’ll do a good job a lot quicker.

    With programmers, the “most productive” don’t write the most lines of code, why would you measure productivity for brick layers in number of bricks stacked?

    In fact, your top programmer won’t be the first one done either. He’ll take a little time to understand the problem, plan out the best method to achieve it, and then create his elegant solution in a relatively small amount of time, but then take a little extra time to go through and test some unforeseen scenarios. The result is a quality product in 1/10th the time it would take an average programmer to do a comparable job. — It’s getting that last 10% that’s the real hard part, and the part that he makes achievable that cuts his overall delivery time.

    It’s the same for almost anything. While it’s true that physical labor is a larger part of the bricklayers job, something that can’t be automated or created as quickly as code, the analogy still stands.

    The analogy holds further in that the best bricklayers are usually working for themselves, or with other top notch craftsmen on more challenging tasks, though not necessarily for 10x the money.

    Another point is that until recently, there was a shortage of “average” programmers because until recently their was a lack of understanding of the field, and thus teachability, while bricklaying is a very old and well understood profession with a shorter ramp up time to achieve average performance.

  30. “hose, very rare, programmers think and feel that his job is so much fun, and think that are UNETHICAL charge too much for their work.

    So, many talented programmers are exploited by companies and business clever guys.”

    That is delusional. The only people who feel it is unethical to charge too much for their work are those people who believe their work is not worth much, period. It has to do with self-esteem and nothing to do with productivity.

    Confident programmers who are passionate for what they do and produce great work KNOW it’s value and are not afraid to charge what it’s worth. (Not counting those who actually are) We’re not in charity, folks. This is business and anyone acting like it’s not is just being silly.

  31. @Aaron: There is a problem with any attempt to claim that the best programmers are N times more productive than the worst: the worst have zero or even negative productivity. This is because the mess they create steals more time from other team members than it contributes to the project’s progress.

  32. @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.

  33. @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.

  34. The question asked on the Stackoverflow podcast was turned into a Stackoverflow question. That question inspired a blog post of mine to go into more detail on the subject. Thanks to the <CodeAnthem site for bringing the subject up again.

  35. 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.

  36. 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.

  37. 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.

  38. 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.

  39. 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.

  40. 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.

  41. 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.

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

  43. 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?

  44. Roberto Estreitinho

    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)

  45. 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)

Comments are closed.