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

Related posts:

144 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. Pingback: CodeBlab » Blog Archive » To Win Befor You Code
  10. 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.

  11. @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?

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

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

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

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

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

  17. 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!

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

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

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

  21. Pingback: Michael Alan Miller » Gramming
  22. 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.

  23. Pingback: links for 2009-12-25 at DeStructUred Blog
  24. 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?

  25. @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).

  26. Pingback: ClipperHouse | Programmers and “productivity”
  27. 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.

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

  29. Pingback: Weekly Link Post 125 « Rhonda Tipton’s WebLog
  30. 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.

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

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

  33. Pingback: almost effortless » Weekly Digest, 1-6-09
  34. 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,
    A vegan food & hospitality blog

  35. Pingback: Recruiting smart people « Using Excel.com | Excel Learning
  36. Pingback: The Bangus Ultimatum » Bookmarks for February 26th from 18:30 to 19:53
  37. 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.

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

  39. Pingback: Let’s Be Independent Together | Code Anthem
  40. @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.

Leave a Reply

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