Why programmers are not paid in proportion to their productivity (2009)

http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity

by ColinWright • 15 years ago

123 76 15 years ago

johndcook.com

rasur• 15 years ago

The article is from 2009.

ricefield• 15 years ago

But, still a good article.

mattmanser4• 15 years ago

It's even been on here before. This happens all the time, but be positive about it. It's obviously getting a new audience who are enjoying it.

It can be polite to add a [2009] tag, but the subject's not really time sensitive like programming or business analysis articles.

mattmanser4• 15 years ago

I think John missed one.

The other thing I've seen happen is that the more productive programmers are asked to do the more complicated things. So they'd be the ones creating a javascript drag-drop widgets framework while the less capable were stitching together CRUD apps with a bit of business logic in the backend.

This then looks like they're both delivering products, the CRUD app may even earn a lot more money for the business in the short term too.

I've even seen this kind of skill discrepancy in call centres when I temped as a student, this isn't restricted to the programming field. There's always a couple of people who knew how to fix actual problems rather than just enter payment details, they'd always be handed the troublesome clients but rarely got paid more.

I ended up as one of these myself, but none of us ever complained about being paid the same as Bob the lazy call avoider because it made our jobs far more interesting and satisfying.

In the end I guess part of being a high performer is that you know you're going to get the jobs that interest you and that in truth would just frustrate and demoralize your colleagues. It's not always about the pay.

scscsc• 15 years ago

So writing a JavaScript drag-and-drop widget framework counts as complicated?

Jach2• 15 years ago

Have you tried it? (Don't forget to make sure it works in all the browsers at decent speeds!) It's not the most difficult thing, but it's reasonably complex, it doesn't seem like a bad example. How many teams have one person working on satellite code in Common Lisp and another doing a basic e-commerce site for a client?

some1else• 15 years ago

A good manager in a software company should have a decent grasp of project complexity and output quality of his subordinates.

The examples listed seem to appear at companies that have in-house developers, but don't really think of IT as an area they should focus on. Similarly, I often found my ex ad-agency co-workers have trouble understanding why I have to browse blogs/manuals, take time to think things through, sketch graphs and sometimes just start over instead of refactoring.

Really, software managers should have no trouble noticing a 10:1 skill difference between devs.

kls• 15 years ago

Really, software managers should have no trouble noticing a 10:1 skill difference between devs.

I absolutly agree with you, and on HN many of us are in a filter bubble in which the companies we are surounded my have a good deal of people that know software and creativity. The reality out in the real word though is much different. Many companies have managers that have never worked on software in their life, there is a school of thought that management is management, and for some disciplines it is true management is transferable, those of us in technology know this to be idiotic but if you came from a traditional enterprise and have seen multiple manager move from inventory to shipping and be successful you would believe the converse to be true. Years of observation reinforce this to those individuals and create cultures in which management is management.

mgkimsal• 15 years ago

How many people are "software managers" in a company, vs "managers" who happen to have people doing software in their dept? I worked someplace where they proudly stated "we're not a software shop!". They had 100+ software engineers working on stuff that managed billions of dollars in money for the company. But "they're not a software shop". OK.

They really weren't as bad as that statement makes them seem, and I think it was more a misguided "rah rah" statement than a core mentality, but there were days when I couldn't quite tell.

dmethvin• 15 years ago

There are very few good managers, and when you think about it very few programmers work in software companies. Instead they work for trading firms, utilities, banks, government agencies, etc.

When the business of the company isn't software, there is a good chance that the manager won't be a software developer. The criteria the developer is judged by will have nothing to do with the complexity of the software or the time it takes to create. Instead, their work will be judged and compensated by the value it delivers to the organization. Even if it's crappy software.

feralchimp• 15 years ago

Love this example for two reasons, the first being the one you mentioned, and the other being the fact that the troublesome/interesting call probably isn't generating more revenue for your employer than the simple/boring call.

zura• 15 years ago

interesting/boring* doesn't always correspond to complicated/easy.

Actually, it might be even more complicated to _complete_ the extremely boring task.

* - in this particular example, js drag&drop being an interesting task is a subjective assumption, but I guess "yet another CRUD app" being boring is an objective reality :)

geebee2• 15 years ago

That's a really good point. It's worth remembering that the person picking the low hanging fruit will often fill up the baskets faster than the person who climbs up to the tall branches, But since anyone can pick the low hanging fruit, you may need to send your most talented people into lower-yield environments, since they're the only ones who can do it.

Productivity really is difficult to measure, especially in software development.

brain5ide• 15 years ago

It's not low/high hanging apples. It's apples and oranges. 1X programmer does job that is immeadiately visible and has value. 10X programmer writes code that has potential value, which is to be seen in the future, probably when some other 1X programmer implements his code. I now remembered a quote Anthony Hopkins said on 'Inside the actor studio' which he learnt while having a role as a butler: When you're in the room it has to be more empty. Same goes to great programmer and software system as is mentioned in the article.

Garbage• 15 years ago

The best part of the article:

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

Jach2• 15 years ago

Seems in line with Rich Hickey's "Hammock Driven Development" (Here if you haven't seen his talk: http://blip.tv/clojure/hammock-driven-development-4475586 )

brador• 15 years ago

Programming at the level of HN readers isn't a science, it's a creative art. You buy artwork based on it's value to you as a finished product. Very few people commission art from artists other than those who are very well known.

Conclusion - sell finished works of art, not your time. Effectively, SHIP A PRODUCT PEOPLE WANT.

roel_v4• 15 years ago

"Programming at the level of HN readers isn't a science, it's a creative art."

Can we please stop circle jerking like this? I have no reason to believe that there aren't a bunch of idiots on here, just as most anywhere else.

Cushman3• 15 years ago

Can we please stop using the phrase "circle jerk" to demean people we disagree with? Just because there may be "a bunch of idiots on here" doesn't make it Reddit.

alphamale30002• 15 years ago

Finally! Even in hacker forums, many people talk louder than they can deliver.

tsunamifury• 15 years ago

Software development is not an art, it is craftsmanship to make a tool. That isn't meant to demean development -- it just isn't the case that your code is making a statement on humanity or causing a user to ponder the meaning of existence.

Eliezer• 15 years ago

Of course it's art inside, it's just that people don't buy it for the elegance.

lhnz• 15 years ago

That's not the definition of 'art' that they are using.

yuhong• 15 years ago

Yea, programmers are not dumb automatons that should be motivated by fear.

discreteevent• 15 years ago

A corollary of this article is that experience is also undervalued. It is experience and the ability to reflect on it intelligently that prevents people from making a mess. Its that mess that is killing productivity in most shops.

eftpotrm• 15 years ago

Maybe, but if you paid the juniors appropriately on that scale they'd never get into the industry and if you paid the seniors on that scale the business couldn't afford them.

joelthelion• 15 years ago

Because no one has found a good way to improve the quality of information in the job market for programmers (yet).

It's still very hard for an employer to detect skill, and for a job seeker to select good potential employers.

Could be an idea for a very useful startup :)

WeWin• 15 years ago

Isn't the obvious, uncomfortable answer, that management wants to maximize profitability? It's almost the definition of their job to find these 100x productivity programmers and pay them the 1x salary. Also, note that when you have an entire team of 100x programmers, and you are only paying them 2x or 3x the salary of the 1x programmer, the manager has succeeded well in their goal - not only has the pay-me-more-for-my-skill argument disappeared (they are all the same 100x skill level) but you are extracting the massive amount of excess productivity into profitability. bottom line is that if you really are a 100x programmer, it is difficult to fully capitalize on that skill

freemarketteddy3• 15 years ago

>if you really are a 100x programmer, it is difficult to fully capitalize on that skill

Only if you work at xyz corp!

phzbOx• 15 years ago

Why programmers are not paid in proportion to their productivity? Because they procrastinate the other 50% of the time! (Obviously, it is a joke. But ironically, we're discussing that on HN...)

wayathrow• 15 years ago

Or they procrastinate and take it easy because there is an upper limit to compensation per unit of time & effort. If I am truly 10x more productive, that means I should be able to keep a steady paycheck rolling in with 4 hours a week!

freemarketteddy3• 15 years ago

I worked for about 45 minutes today and finished all the work that was assigned to me for today and tomorrow.(I am not a genius,I just used a few modules from github!).

If I work more than that I will not get more money.All I will get is more work and stricter deadlines."You are smart.Why dont you work during the weekend and finish this.We have a demo!" has happened to me numerous times.And everytime I have ended up changing teams!

The best strategy at xyz corp is to pretend that you are slightly dumber than average!

yzhengyu• 15 years ago

Well, my answer to that is the same as the others here. At most of the corporate places where the programmer is treated just like any peon, he/she will just get assigned more work.

The running jokes amongst my peers is that the project manager sees the programmer as a battery. Not far from the truth.

My only advice to fellow programmers who find themselves working in such an environment - quickly get out. Or else you will find yourself sliding into mediocrity and feeling miserable for yourself.

araneae• 15 years ago

I disagree with all the reasons he listed... because this is true of all careers, not just programming. I think it has more to do with our ideas about pay more than anything else.

Quite simply put, in almost all professions you're paid for being there for 9-5. If you show up and do your work poorly or not at all, you might get fired. If you do well, you will get a small raise. So to a small extent productivity is correlated. But the salaries aren't proportional to productivity; the biggest predictor of salary is if you're fulltime. You're getting paid for your time, not what you're producing.

shawndumas• 15 years ago

http://www.readability.com/articles/uuek7ysi

daxxad• 15 years ago

I think we should address 2 questions first before we can answer this. Why do some programmers think they are 10x or 100x more productive than others? Is it a myth or is it for real? Give some concrete examples of 10x productivity for a start.

wes-exp• 15 years ago

The 10:1 productivity gap is well established in the academic literature for software engineering.

There are not many concrete quantitative statements one can make about the profession, but this is one of them.

brider• 15 years ago

Do you have any references for this, my good man? I don't mean to question your comment; I want to learn more about how this has been established and the nature of it.

randomdata• 15 years ago

I have worked with people who needed to see the whole picture before they could implement anything. Whereas I can seem to be able to jump in and start building even while lacking information. I have some weird ability (or perhaps not so weird, it is probably just a result of experience) to infer what is not yet there; the whole picture only becomes clear to me when I am done.

In those cases, I was seeing at least a 10x productivity increase because while they were sitting around thinking about the problem, I was already writing code, working on the parts that I did understand, while gaining a greater understanding of the rest during that process. Once we all reached the point of understanding, those gains became negligible, and our productivity was probably closer to par.

If you're writing the same old boilerplate code day in, day out, it is probably hard to realize increased productivity between individuals. However, if you're venturing into new problems constantly, I believe different developers can be quite a bit more productive over others.

freemarketteddy3• 15 years ago

10 times is actually an understatement....For example Marco Arment made instapaper himself...try asking a 100 person team at xyz corp to make something like that!

alphamale30002• 15 years ago

There are many concrete examples where the productivity of a programmer may be positive or negative.

For example: How many more tasks did you complete on average? How much time did you require the assistance of your colleagues? How many times per day do you interrupt other developers and prevent them from doing their job?

So the productivity multiplier is either over 1x or under 1x. When you multiply it up together for all the members of your team, and you normalize so that the lowest multiplier is 1x, you might realize that in fact some co-workers can be 100x more productive than others.

mvzink2• 15 years ago

If you have two programmers, and one is "10x more productive" than the other in that he knows when to reuse or adapt other code, but there is a problem that actually does require writing code, which one will put out a more correct, reliable solution faster? I would guess that it would be the 10x more productive programmer, because he/she doesn't just know when to reuse or adapt other code, but also when to reuse or adapt algorithms, architectures, etc. or "solutions" generally.

I'm annoyed that Cook is still undervaluing these programmers in this article by not explicitly mentioning solutions in general, but only "reusing code", which is just a special case of reusing solutions.

esrauch2• 15 years ago

The '10x more productive' in this article was referring to people who reuse and adapt, you seem to have it backwards. You are infinitely more productive if you realize the problem is already solved. Not only is it faster, but it also isn't as likely to suffer from bugs.

But I also think you are assigning to him a slightly different opinion than I understood it. It's not just 'This would be a good time to use Excel!" or "This would be a good time to use Library X!", it's "This codebase already has something that is slightly different; we can probably generalize that slightly and save a lot of headaches". He is talking about people who write code every day, but people who are better able to apply existing frameworks to the new problem instead of banging out something from scratch.

Also with regards to your "still", this article is not new.

mvzink2• 15 years ago

No, I don't have it backwards and that is indeed the kind of programmer he was talking about. I am only saying that the "This codebase already has something that is slightly different; we can probably generalize that slightly and save a lot of headaches" situation is just a special case of better, more adaptive problem solving that doesn't necessarily rely on the "codebase already [having] something that is slightly different".

And I know the article is not new, the point of "still" is that the article seeks to address the undervaluation of these programmers, yet doesn't give them their full due. This is because most (if not all) of the same programmers who practice that special case of efficient problem solving also are capable of more generalized forms of efficient problem solving, and Cook doesn't mention this.

achompas• 15 years ago

Why haven't I seen the following comment here?

    patio11  10 minutes ago  |  link

    Programmers are paid in proportion to the value they create. 
    If you want to make more money, work on stuff that makes money, 
    then ask for that raise.

Is there really any other explanation? Think about this like patio11 or Greenspun: work on stuff that makes money/value for the business, go talk to your managers, point to the thing you created and say "this generated $X in revenue for us. I'd like to partake in some of that revenue."

Then head out to dinner or happy hour and enjoy your raise, or jump ship if the company laughs at you.

Isn't this how the labor market for programmers works? If not, why aren't we making this happen?

aiscott• 15 years ago

I agree. I've struggled with highlighting my accomplishments in the past, "tooting my own horn" so to speak. I guess to me it can feel like bragging or boasting, but that is something to get over.

I have found that where I work, if I don't explicitly tell my manager(s) what I've been working on and spotlighting the important things I've gotten done, they simply won't know about it.

It gives them ammunition to "fight" for you, to justify raises etc...

synnik• 15 years ago

That isn't exactly how it works --

It is a valid argument for raises, especially early in your career. But at some point, you are no longer selling your personal value to your boss - you are competing with other programmers who are willing to give the same value for a lower salary.

To get past that point, you need to have specialized business knowledge so that outside programmers cannot compete with you.

The trick to getting very high salaries is to decrease the pool of competitors for work, by increasing specialized knowledge above and beyond your coding skills.

growingconcern• 15 years ago

If he can't say that it's easy to measure whether someone is 10x more productive than the average programmer then how can he say they are 10x more effective? Also I work at 200 person game company and there is no programmer that even performs close to that level. Maybe 2 to 3x the average for absolutely exceptional programmers. But your average would have to be pretty fucking crappy to get anything more than that (and even very talented programmers aren't more than 2x the average).

onemoreact2• 15 years ago

Productivity in the shortest time scales is hard to measure.

But, when someone spends a few days and makes an optimization that literally prevents well over 1 million dollars of new hardware from being purchased that's real value. (This actually happened.) Create that type of value a few times in 5 years and yes someone can really create 10x the value of the average programmer.

PS: Not a programming example but http://en.wikipedia.org/wiki/Polymerase_chain_reaction is one of the more extreme examples. Kary Mullis literally created billions of dollars of value paying him 10x what the average researcher makes for 40 years and it's still a net win.

agoder• 15 years ago

I think there's a simple explanation for this: asymmetry of information. While the programmer knows that they are a 10x programmer, the company hiring them does not. Interviews, resumes, and referrals only provide a limited set of information, and surely not enough to boost the company's perception of you up to the 10x range. So that's why salaries are much more compressed than skill.

The standard economic solution for these types of markets is to offer a "warranty", the idea being that the better product will be able to outcompete on "warranty". For programmers that might mean agreeing to a contract where you get paid, say, $300k, but if after X time you aren't performing well enough then you have to pay back most of it. Actually this is sort of what happens already with equity.

Zak• 15 years ago

This article and general theme are based on an invalid premise. Many of the most productive programmers are, in fact paid in proportion to their productivity.

Such people are likely to found startups or join at an early stage or they're likely to work at places like Google that issue large stock grants to many of their most productive programmers. Those who don't are more interested in stability than money.

Large non-software companies and governments fail to compensate their most productive programmers proportionally because they have difficulty identifying the benefits they're getting or simply don't value them all that highly. Most of us consider it obvious that such organizations aren't the most desirable work environment for programmers.

elspoono• 15 years ago

Dead on.

What makes a good programmer good isn't the code they write, it's the code they don't.

porfirio• 15 years ago

I noticed something similar, though not as a programmer.

I tested videogames one summer, where it was my job to locate and report bugs. It was soon apparent that there was huge variation in productivity: some people submitted more and better bugs, in better written reports, than others.

Most people were hired as independent contractors through an outside company. A select few would be hired by the actual game company, and kept on through the season. Was it the most productive who were kept on? No. It was the people who put in the most overtime hours, and made themselves available when the company asked.

Call me an ignorant youth, but it seemed like, if they wanted to, they could raise salaries, fire the bottom X%, and hire some more talented QA testers, and still come out ahead.

Cook's explanation doesn't really explain this scenario, but I have a feeling the answer is similar, for both the QA tester and the programmer.

My theory: management simply doesn't care, and doesn't need to. If you were to walk out, they could easily get someone else at the exact same pay-grade. It's only when your value to the company is crystal clear, and you are clearly better than the competition, and that there's a viable threat that you will leave somewhere else and actually get better pay, that a company will pay you accordingly.

After all, economics doesn't say you get paid what you're worth. It says you get paid the market clearing wage. You might be creating $200 of value per hour for your employer, but if there are tons of people ready to work for $10 an hour and are just as productive, then you will get paid $10 an hour.

This is more conjecture, but I think for things to change, for people to be paid according to their productivity, two critical pieces of information are essential:

1. Exactly how productive you are, relative to your peers. 2. Exactly how much people of varying abilities make.

The problem is, for #1, the metrics are bad if at all existent. For #2, there's a huge taboo against telling people what you make, which ultimately helps employers keep wages lower.

I think my QA testing situation would have been different if say, the men in charge took some pride in it, and only hired great testers. They didn't, they were just filling slots, so the QA on the QA testers themselves was pretty shoddy.

greenyoda• 15 years ago

"Call me an ignorant youth, but it seemed like, if they wanted to, they could raise salaries, fire the bottom X%, and hire some more talented QA testers, and still come out ahead."

Not ignorant at all; this is a very insightful observation. I've seen the same thing from the programming side. Unfortunately, an unskilled programmer can create more and longer-lasting damage than an unskilled QA tester -- some code sticks around for decades and has layers and layers of new code built on top of it. Thus, bad programmers can drag down other programmers' productivity long after they've left the project. So the advantage of replacing a lot of bad programmers with a handful of good ones who are better paid could be even greater.

Not to mention that a smaller group has much less communication overhead than a larger group (as described in The Mythical Man Month).

ericHosick• 15 years ago

The most productive programmers are the ones who can solve the problem without writing any code at all.

Why programmers are not paid in proportion to their productivity (2009)

Related Stories