Why programmers are not paid in proportion to their productivity
johndcook.com
johndcook.com
I thought I was pretty good until I worked with the guy who made Winamp. It took me a couple weeks to make some enhancements to their add-ons site. It took him a couple weeks to write his own version of Pro Tools. I made 80 thousand dollars. He made 80 million dollars.
I'm sure that Frankel is an excellent programmer, but this in no way an example that excellent programmers are generally rewarded according to their ability.
Potential is not necessarily proportional to practice. So, what he may be able to do in a year may take you twenty, or a week.
Practice isn't the only factor where ability is concerned.
I used to be a good skateboarder. There were guys I skated with who could learn the tricks 5 times faster than I could. I don't know why. We all skated the same amount... in fact, some of the guys who were better than me skated a lot less than I did. They just had something clicking that I didn't have.
I'm a proponent of self-improvement. I think most average people can develop skills far and beyond what they give themselves credit for. I hate to be the guy who is arguing for mystical innate ability. However, it seems naive to claim that it doesn't exist.
To end this comment on a useful note, the one thing I noticed both with the good skateboarders and the good programmers I know, is that they would 'go big' when practicing. the skaters would try something hard and figure it out until they got it. They wouldn't just sit around and do the same kickflip in a parking lot over and over again.
Likewise, the good programmers I knew would always be seriously challenging themselves. For practice programs, they wouldn't just write a dumb fibonacci generator. They'd write a full blown throttling distributed network file copier, or a scheme compiler in postscript. Serious, hard projects for practice. Most programming is mundane and you can go for years without getting any better. The best guys I know are never complacent with doing the same boring shit all day - they'd always challenge themselves.
I sailed through math and physics and chemistry in high school. I suspect this is because my dad was a nuclear chemist. I didn't have to learn how to think scientifically, because it was ingrained in me from the age of 3, and it never occurred to me to think any other way. But I'm now in my late 20s, and it's the other kids in my high school class, the ones who struggled through everything, that are now finishing their chem Ph.Ds. Because they decided consciously that chemistry was something they wanted to be good at, while I decided my interests lay elsewhere and didn't bother breaking through all the other mental blocks that crop up when you do college-level hard sciences.
I think a lot of skills have this same pattern - hard skills that can take forever to learn, followed by a bunch of easy and flashy tricks that come easily once you master the basics. My violin tone improved markedly and rapidly once I learned to use "arm weight" instead of simply pressing hard on the string. When I was doing whitewater kayaking, the experienced kayakers would say "Once you learn to roll, your skills just shoot up, because you aren't afraid of trying things any more." Last Olympics, there was a video interview with the U.S. women's gymnastics team where they asked each of them "What was the hardest skill to learn?" Shawn Johnson replied, "The hardest skill for me was my kip." (For non gymnastics fans, the kip is basically a prerequisite for all bars moves, and is usually learned around age 7.) There's an Olympic champion, but if you looked at her gymnastics in elementary school, she spent well over a year on a really basic, fundamental skill that some people get in three tries!
I think this may be why a lot of software engineers ask about pointers and recursion as interview questions. Those skills themselves are rarely useful. But they are hard mental blocks that often weed out a lot of prospective programmers. And once you've got them, a bunch of other algorithms and data structures open up for you. If you understand pointers and recursion, you can learn about linked lists, balanced trees, dynamic programming, hashtables, and all those other fundamentals in short order. If you don't, you might forever be stuck using frameworks that other people put together for you.
Ask Justin?
Maybe someone here who knows him can ask him and post the reply, oeven better, ask him to post. Once of the reasons I enjoyed "Coders At work" was that this question in (at least implicitly) answered by some great programmers.
So someone who is 10x more productive then their coworker isn't actually 10x more productive because their coworker is so horrible? Isn't "10x more productive" an explicit measure of productivity relative to the guy(s) next to you?
Could there be a dark matter halo of great programmers lurking around the world's mediocre-programmer-filled corporate cubicals?
When it comes to programming there are relatively many bad programmers hired (on a base salary). Maybe the good programmers are underpaid, but definitely the bad programmers are overpaid.
Anecdotal evidence also suggests that programmers are generally bad at negotiating their own salary.
I remember using Gnutella back in the day. It was horribly buggy and slow. Maybe Frankel didn't write that one or maybe being satisfying things half-working was the secret to x100 productivity.
Even brilliant programmers can only accomplish so much in a weekend.
Also he was starting from square one. It might take me a few weeks to make enhancements to some add on website I'm unfamiliar with using clunky web tech fighting with a badly architectured framework, while it would take me a day to make the same thing with a concise and elegant API starting from scratch. Later on I might become faster in changing the website.
It's like a phd physicist talking about how that math phd clobbered him in an analytics course, when really he just had more invested.
Or as the article says: "“Hmm. I think I’ve seen something like this before."
my proudest moments are when i'm collaborating with such flow that no one knows exactly where each idea came from, and at the end we have a powerful, awesome product that none of us could have built alone, that is seemingly greater than the sum of its contributors. i can understand it, i can see some of my contributions, and yet it is greater than me. add some social good and purpose and then i'd feel me some good pride.
Anyway, as is the saying, "whatever gets you off". If I've managed to be particularly clever or efficient or solved a problem I haven't previously, I feel good about that. In 10 years doing this I've never collaborated on a project start to finish with other programmers but I imagine I'd feel good about that, too. I guess I just lack the ability to comprehend self-pity over a personal accomplishment.
I don't know, I recall an (unnecessarily) hard-coded HTML form in a Django project with extremely poor input validation that somebody I knew wrote. It was a single field, single button form too, I might add.
I refactored it with extreme prejudice.
There are "pitiful" tiers of code, relative to those who find it pitiful, but there's no such thing as pitiful pride. Essentially din0's argument is "Hey, you shouldn't feel proud about that because I have done things I consider superior! Pity yourself!" I was just trying to point out the absurd nature of that argument.
It strikes me that I'm seemingly one of the few people at my workplace who can handle abstracted functionality comfortable and make use of third party code/libraries without fear.
tl;dr, I wrote a customer service app for my company in about a week flat.
I agree with the OP that the problem here is that it is not easy to measure productivity.
http://github.com/raganwald/homoiconic/blob/master/2009-02-1...
--Bill Gates.
My favourite consequence of measuring productivity by the line is to ask how much I owe my employer when I spend a day eliminating redundancy and thus contribute negative lines of code.
I make no claims as to how useful these definitions are. There's a reason why economics is called the dismal science. But terms like output and productivity do have accepted definitions - so yeah, the true measure of an employee's productivity is almost their salary. (It's actually revenue / employee / hour, so if an employer keeps most of the money as profit, it's still productivity. That's why the grandparent suggested "start your own consultancy".)
The only way there is something to discuss is when we presume there is another measure of programmer productivity and then ask why the marketplace is so inefficient that economic productivity does not correlate with programmer productivity.
I think that there's a more interesting question in the article - why do salaries "flatten out" the productivity curve, so that programmers who would easily be making 100x more as startup founders are instead making 50% more, with the balance going to the employer? After all, if we measure by revenue generated for the employer, I'm in at least the 7 figures, within an order of magnitude. And I doubt Aaron etc. were making all that much in salary when they were Google employees either.
I suspect the answer to this has to do with risk allocation. Because technology markets tend to be winner-take-all, there's a lot of variance in productivity that's not the result of the coder's actions. In other words, it comes down to luck, being in the right market with the right product. You can work hard at the wrong thing and still produce nothing of value, despite being smart and dedicated.
When you sign on as an employee, your employer agrees to take on the risk that you'll work hard and still nothing will come of it. And in return, they get nearly all of the upside if your hard work does result in something great.
I suspect that the 10x more productive figure is a result of sample bias: when you look at what people have done, there are some folks whose projects were 10x more useful than what other people have done. All the people who worked equally hard and produced equally large amounts of code are lumped into the "not productive" category, because in hindsight, their projects weren't all that useful. If you try to predict, a priori, who the 10x coders are, I bet you'll have a much harder time. If you don't, you have a sterling future ahead of you as a venture capitalist.
Networking, for instance, can greatly increase your output if you choose an awesome cofounder. It has a benefit that is not easily defined because of how hard it is to decouple the work and effect of each individual team member.
I know of one person that is worth easily in the 8 figures range, but he got in early to the venture. This does not mean he's a better programmer than everyone else, but he does benefit from a lot of factors that sum to being more important than programming skills.
Yes. An Indian programmer could earn (say) $15k at home, 40k if she goes to Japan, and 80k in Silicon Valley. All doing the "same" job.
This does mean that you end up with employees who are clearly superior getting paid less than some of their inferior peers. Certainly when I was a mere employee the idea that I was working harder and better than someone who got paid twice my salary was galling. But there are plenty of employees who aren't as concerned about what their peers are getting paid. Most of the time, assuming your salaries are relatively generous, I've learned that employees feel they are personally being rewarded sufficiently, and that's what matters to them. For those who make it more of an issue, you try to accommodate them if they're worth it.
That said, it is really important to reward superstars to keep them really happy. Often, this means salary / bonuses, but sometimes it means type of work and the role they get to play on the project.
Is an architecture astronaut really more productive than a programmer just because there is some sort of perceived value within an "Enterprise Environment?" Is a programmer who switches jobs every few years--garnering a raise each time but needing a ramp-up period at each job--more productive than the one who values security more than money and stays in one place?
I don't think that when we use the phrase "programmer productivity" on HN we are talking about the same thing as an economist who talks about productivity.
From having spent most of my adult life in the world of software development I've noticed that it's the programmers who make a lot of noise, huff and puff, and spend all day battering a keyboard looking stressed that tend to get pay rises and eventually promotions into managerial positions. This is really just down to the limitations of human psychology. If you look like you're working hard you must be being more productive than someone who did the job without fuss, then went out to get a sandwich.
But this will all be helped if you can program well. And if you want to play office politics, it'll be useful to have the ability to accomplish someone else's job in half the time, if you really can.
> I’d love to see some metrics on the average life expectancy of a line of code for different programmers. I know that some of my best code was written and has sat there with minimal changes ever since.
Now that's an interesting idea.
There are plenty of enterprise systems like this.
Programmers do some thinking & some typing, the more you do of one, the less you do of the other. (don't remember the original author)
The lazy engineer is the best engineer.. If not for lazy people we would still be living in caves
Unfortunately, in the world of programming, most people get rewarded for putting in extra hours rather than for being good at their jobs.
My pointy-haired manager rejected a design that I developed for our current project because I think he didn't understand it... instead we went and cloned the existing bug-ridden, convoluted, user-hostile app, following its example at every opportunity, and leading to a HUGE increase in project scope... exactly what I had predicted and attempted to avoid.
In the end what should have been a six-week project for a good 4-person team turned into a 4-month crunch for a 10-person team saddled with several run-of-the-mill and a few genuinely incompetent members... and the worst of the incompetent ended up being the primary architect based on his ego and politics.
> someone who stares quietly into space for a few minutes
...and exactly here lies the problem. I've been fired from a job because according to an old retiree who never saw anyone programming before, "he spent his days scratching his beard and looking blankly at the screen". No mention about the job being done and the extra $1M my ideas saved. And certainly no apologies after they had to replace me by a whole external company.
Is uber-productivity significantly enhanced by choosing the right development methodology (e.g. test-driven development) or is it mostly something innate? Aside from stories like rdouble's (which I don't find that helpful, since it doesn't contain information on rdouble or his employer's domain expertise), what is the evidence that super-productive programmers exist?
For instance, I started with Java, then moved to Python, learned COBOL and a little bit of php and ASP around the same time, then finally switched to Ruby, where I do most of my programming now. A lot of the things I learned in Java were still relevant in Python, and the same was true with the switch from Python to Ruby. COBOL was a bit of an outlier since I wasn't using the OO version of COBOL, but I already had a grasp on logic and flow of control, so even that wasn't that much of a stretch.
I'm definitely not one of those elite programmers, even though I do seem to grasp concepts better than a lot of my classmates, so I find categorizing domain as a programming language in relation to programmer ability is flawed. Once you've achieved competency in a few languages, you should be able to switch languages without too much trouble, assuming those languages at least have a moderately similar paradigm (a notable exception might be, say, Java -> Lisp).
It's the ability to understand concepts that tend to separate the good from the mediocre, and that might have been what you meant when you referenced "domain."
Negative: you're considering changing career, seems like you don't really love hacking. It's really hard to be a great hacker if you don't love it.
Positive: You want to learn. A key ingredient to becoming a great hacker is being keen to learn new techniques, practise them, and admitting that there are better ways to do it than the way you are doing it now.
Yeees...-ish. All methodologies have their pros and cons. Therefore you should be experienced in as many of them as possible, so you know when and where they are best used.
People who only know one methodology really well tend to overdo it - they don't know when to stop shoving tests and patterns into their codebase.
Beyond that, I can't really answer the rest of your questions; I haven't managed to sit down and read it yet.
http://pyre.third-bit.com/blog/archives/2910.html
Basically, he says that professional understanding of software is still in the lore stage where we gossip about what works and doesn't rather than empirical studies based on evidence.
About this specific number though (the programmers are X times more productive) that's often repeated:
To date, these studies have mostly been confined to academia. Most professional developers are vaguely aware of some of the results, but often get the details wrong. For example, hundreds of books, blog posts, and presentations claim that the best programmers are forty times better than the worst—or fifteen, or a hundred, or some other number. Almost none of the people repeating that claim realize that it originally came from a very small study (twelve people) run for a very short time (one afternoon) in an era of batch processing and punch cards.
For example I often quote a 10x figure and cite Peopleware as a source. They draw their data from measurements taken of hundreds of different programmers working at different companies in different languages in the mid 1980s. Which is a lot more solid than the punchcard study he cites which I have honestly never heard of.
I think the best approach for anyone is to do the best you can with what you have. It's more important to get something done than to worry about if the amount you got done is greater than most others. You certainly should do whatever you feel you need to do to optimize your "productivity", but don't get distracted or depressed trying to be #1 in the world.
The other comments are correct; if you aren't willing to take any risk, then you don't deserve the benefits. If you think you are good, put your money where your mouth is :)
First off there are the net negative producing programmers, you can't say the good programmers are 10x the productivity of those guys, because that would make them 10x worse, which is incorrect.
Second off, I think the variation between programmers can be much bigger than 10x, easily 50x or more. Of course the 1x programmers really don't like this idea, because their egos cannot handle the concept of someone else being that much better than they are.
Time-based compensation and productivity-based firing can be a pretty good system for a lot of people in a lot of situations.
I was hiring for some other jobs recently, and I was surprised at how the group I was hiring from thought about their compensation. It wasn't "I deserve $X", "Chris makes $Y", or even "I think I can get them to pay $Z." They'd come to me and say "I need a job that pays $A/month because [$A ~= monthly expenses + a little extra niceties + a safety cushion in case something bad happens]". It was refreshing.
I actually think production based pay is refreshing. I've personally worked under this system (OK, so technically my wife did). It is really egalitarian. Unfortunately it is also very uneven, as production capabilities vary considerably and at times disappear complete (i.e, you're sick). Also, as you pointed out for software development it's pretty hard to find decent metrics that don't deteriorate when you optimize solely for them. In her field (medical transcription), it was more clear-cut with a payment per line and penalties for mistakes.
From the lazy, employee-based-safe perspective I can certainly agree that time-based compensation is attractive, but my sense of self worth would prefer being paid on performance. I'd certainly prefer to hire based on it.
Really the current system is probably roughly as good as you're going to get right now. There are all manner of intangible pluses and minuses to a particular person and a lot of places take this into account for compensation. It makes the process less transparent but it at least allows flexibility.
Just one example--I like to think that I'm helping out less experienced developers when I'm explaining some concept of business process or something. But I'm certainly not adding code then. And what of managers? Good managers are certainly valuable but their personal contribution is even less measurable than that of a developer.
Most companies theoretically already do performance based pay, but just at two levels:
Level 1 pay: $salary
Level 2 pay: $severance
If you've got a big productivity range and a small pay range, you don't have to address it by expanding the pay range. You can focus the productivity range instead, and get lots of side benefits. Let the people who aren't performing well find another job.
Remember there's more to comp than just wages and bonuses too. Sometimes other things can address perceived needs.
___
† I'm assuming most good employees will be around 2 years or more. If you don't expect that, that changes everything.
I guess some salesmen would fall into this category, as it´s easy to measure their productivity.
I guess you could argue that they aren't salaried since their bonus compensation is usually significant, often many multiples of their relatively low base salary.
To the point consider this - if you are my employer and you pay me performance bonus, do you have some money left for yourself? I imagine some of the value I generate as an employee gets captured by the company, otherwise they wouldn't keep me around, right? Therefore, self-employment is the only way to keep all the value you have created.
The issue posed by the original post was that great programmers are not paid proportionally to their output, not whether their employer makes a spread on them.
You're correct though that the closer you get to the money the more value you'll capture. You also take more risk. How many startups have folded where junior engineers made $100k/yr and investors and founders left the endeavor with nothing or a net loss? Depending on your life situation, being more risk-averse and taking the guaranteed paycheck isn't such a bad thing.
http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...
This is often repeated, never meaningfully demonstrated. I doubt it is true if we are excluding unqualified programmers.
Have you ever heard of Charlie Steinmetz? Legend has it that he was a prominent electrical engineer in the early twentieth century. Not long after his retirement, all of the engineers at General Electric had a problem. Although each was wise, they were unable to understand the complexity of the machinery. A call was made and Charlie Steinmetz came to the plant to offer his assistance.
Ol’ Charlie walked around the machine for a few minutes, just looking it over, not touching anything. After a few minutes, Charlie took out a piece of chalk, walked over and placed a large X on one particular part of the machine. When the other engineers disassembled the machine, they were amazed to find that it was exactly where the problem was. A few days later, the engineers received an invoice from Charlie for $10,000! This was a lot of money in those days, so they returned it to Charlie and ask that he itemize it. A few days later, they received an itemized bill which read:
Making one X mark – $1.00
Knowing where to place the X – $9999.00
Even if one tosses the idea that there are "rockstar programmers" who are 10x more productive than merely good ones, someone with the right experience and domain knowledge can be priceless. I have certainly found cases in which I could merely hear the symptoms of a very subtle bug and find it in 2 minutes, whereas a great programmer unfamiliar with the codebase, field, and my past experience might have taken a week to find it.
http://answers.google.com/answers/threadview?id=183998
http://www.snopes.com/business/genius/where.asp
There's a really similar story about Picasso asked by a lady in a restaurant to draw a simple sketch on a napkin. He does and hands it to her saying, "That will be [X] thousand dollars". Shocked, she says: "But that only took you 30 seconds!" "Madam", says Picasso, "It took me thirty years."
Go read Peopleware. You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences.
There is other research on the topic as well. For instance http://www.computer.org/portal/web/buildyourcareer/fa035?utm... cites "individual differences" research that found a 30 fold difference between mediocre programmers and the top programmers. That article is supposed to be a distillation of http://www.amazon.com/Facts-Fallacies-Software-Engineering-R... so I'd look there if you want citations into how that research was done and what exactly they found.
I'll easily buy 2X or 3X productivity difference. I'm not buying these casually tossed off claims about 10X or 30X productivity differences without the supporting research discussed in detail front and center. Unacknowledged differences of that magnitude would imply a massive arbitrage opportunity that has persisted for many years. And that's just not realistic.
Read http://javatroopers.com/Peopleware.html#Chapter_8 for a much better overview of what Peopleware actually says. Of more interest than the productivity differences measured is the discussion of what factors were part of those productivity differences. Once you've read that, you may find the result much more believable. (There is a lot of detail in the book that is left out of the summary, but that's in the nature of what summaries are.)
For example, when you have a hard problem (like a networked 3d game with physics) that is beyond the abilities of a developer A (he can't solve the problems at hand, no matter how much time given), but not developer B (a creative thinker who can solve the problems quickly), then I think you can literally say Dev B is infinitely better than dev A for those hard problems. Because it's going to take you infinitely many developers A's randomly poking at their keyboard to solve the problems. But dev B will solve them in a reason amount of time.
Now dev B isn't infinitely smarter, but for certain tasks, he's infinitely more productive. The point is the productivity differences are highly context dependent, and the greater the creative and cognitive load of the tasks, the the greater the measurable productivity differences between the highest and the average developers.
1) Knowledge is entirely linear. If there some tasks programmer A fails at and some tasks programmer B fails at, then all you have is an apples-to-oranges comparison (which is what a lot of the x10 chest-pounding comes down to).
2) Knowledge isn't shared in the group. My proudest moments have involved actually teaching my co-workers how to write a recursive descent parser, why ACID matters in databases or how to divide a multi-threaded application between worker and consumer threads. It might be true that if I'd just kept my knowledge to my self and laughed as they failed, I might have been a 10x or even a 100x programmer. But it was more pleasant and satisfying to be the guy who actually helped everyone.
That said, this order of magnitude is pretty rare (and it was against the slowest of the programmers) - but if you have a few true superstars, you can expect at least a 4x difference against the average in a group.
As far as compensation goes, at my last internet startup there was approximately a 5x difference, once you factor in bonuses. In the games industry, it was more like 2.5x.
For the worst coders, we tended to fire them after a few weeks if they somehow made it past the interview process. So there was a well-correlated difference in compensation there - we either paid them a few weeks of salary or 0$ in the latter case. :)
Only if "programmer productivity" is a primary limiting factor and one can reliably distinguish relative productivity beforehand, both of which strike me as unlikely in most situations.
I'm not sure I buy it for individuals, except in the limiting case of someone completely not knowing what they're doing and having no idea where to start.
I guess it's also possible with the economist's definition of productivity ($$$/hour), since so many projects turn out to be commercial flops. But by that definition, startups and research are some of the least productive sectors of the economy, not the most.
They found an order of 10 productivity difference that showed up under any of a number of possible measures. The also found that the best predictor of a given person's productivity was the productivity of the other person from the same organization. They also identified a number of workplace environment issues that were strongly correlated with productivity.
This overall picture comes with many caveats. Individual productivity differences were still quite significant. They didn't have any way to tell correlation versus causation. (To what extent does a better environment make programmers better, versus correlate with being able to hire and retain them?) The coding assignments were fairly small. So don't read too much into the result.
But given the size of the difference, and that it is one of the few attempts to quantify these issues, it isn't a result to take lightly either.
In one particular area of programming, competitive programming, productivity is easier to measure.
One might call Tomek Czaijka the Federer of algorithmic competitions. As of 1.5 yrs ago, he had made more than $130k off of TopCoder competitions [1]. Seeing as how he is still ranked 3rd, this figure might be outdated [2].
I can assure you the average TopCoder contestant who has competed over a comparable amount of time made way less than $130k/30 ~ $4300. Easily more than 30 times the productivity.
You can argue about how coding up toy programs compares to working on products. I suspect there is a strong correlation though.
As a point of reference, please consider Steve Newman, who co-wrote Writely which was subsequently acquired by Google and is today the word processor of Google Docs [3]. He must have made some money in the process and was also successful at topcoder.com [4].
That being said, I do knew similar people with astonishingly low "product" productivity.
1. http://www.portfolio.com/careers/job-of-the-week/2008/07/06/...
2. http://www.topcoder.com/tc?module=MemberProfile&cr=14440...
3. http://www.seattlepi.com/business/262443_googlewritely10.htm...
4. http://www.topcoder.com/tc?module=SimpleStats&c=coder_ac...