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.
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.
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.
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.
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 :)
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?
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.
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...
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
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.”
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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).
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.
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...)
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!
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.
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!
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.
"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).
[+] [-] mattmanser|14 years ago|reply
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.
[+] [-] geebee|14 years ago|reply
Productivity really is difficult to measure, especially in software development.
[+] [-] some1else|14 years ago|reply
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.
[+] [-] feralchimp|14 years ago|reply
[+] [-] scscsc|14 years ago|reply
[+] [-] zura|14 years ago|reply
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 :)
[+] [-] achompas|14 years ago|reply
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?
[+] [-] synnik|14 years ago|reply
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.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] aiscott|14 years ago|reply
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...
[+] [-] WeWin|14 years ago|reply
[+] [-] freemarketteddy|14 years ago|reply
Only if you work at xyz corp!
[+] [-] Garbage|14 years ago|reply
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.”
[+] [-] Jach|14 years ago|reply
[+] [-] araneae|14 years ago|reply
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.
[+] [-] brador|14 years ago|reply
Conclusion - sell finished works of art, not your time. Effectively, SHIP A PRODUCT PEOPLE WANT.
[+] [-] roel_v|14 years ago|reply
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.
[+] [-] agoder|14 years ago|reply
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.
[+] [-] mvzink|14 years ago|reply
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.
[+] [-] esrauch|14 years ago|reply
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.
[+] [-] discreteevent|14 years ago|reply
[+] [-] eftpotrm|14 years ago|reply
[+] [-] daxxad|14 years ago|reply
[+] [-] wes-exp|14 years ago|reply
There are not many concrete quantitative statements one can make about the profession, but this is one of them.
[+] [-] randomdata|14 years ago|reply
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.
[+] [-] alphamale3000|14 years ago|reply
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.
[+] [-] freemarketteddy|14 years ago|reply
[+] [-] Zak|14 years ago|reply
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.
[+] [-] joelthelion|14 years ago|reply
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 :)
[+] [-] growingconcern|14 years ago|reply
[+] [-] onemoreact|14 years ago|reply
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.
[+] [-] phzbOx|14 years ago|reply
[+] [-] wayathrow|14 years ago|reply
[+] [-] yzhengyu|14 years ago|reply
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.
[+] [-] freemarketteddy|14 years ago|reply
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!
[+] [-] ericHosick|14 years ago|reply
[+] [-] shawndumas|14 years ago|reply
[+] [-] elspoono|14 years ago|reply
What makes a good programmer good isn't the code they write, it's the code they don't.
[+] [-] rasur|14 years ago|reply
[+] [-] ricefield|14 years ago|reply
[+] [-] mattmanser|14 years ago|reply
It can be polite to add a [2009] tag, but the subject's not really time sensitive like programming or business analysis articles.
[+] [-] porfirio|14 years ago|reply
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|14 years ago|reply
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).