The author has not ever worked with the truly 10x more productive programmers. Most people do not get the chance to work with these programmers. They do get paid in proportion to their productivity. There are so many horrible programmers that you can be mediocre and be 10x more productive than the guy next to you. Thus you think you're in the 10x crew. But you really aren't. It's not because you're really that good. It's because the guy next to you is really that bad.
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 think this comparison is a bit unfair. The guy who made Winamp had significant experience in creating audio related programs. Winamp had a lot of audio tweaking/editing-like features also. By taking his investment of knowledge about audio programming, he saved a significant amount of time in recreating something similar with his pro tools v0.0.1. I wouldn't be surprised if he copied a good chunk of code from winamp too.
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."
Justin Frankel is the doubly rare combination of being extremely skilled at programming and being able to leverage those skills to make tons of money. Most uber-programmers aren't so rich.
It might be true that you are only 10 times better than the guy sitting next to you because he is 10 times worse than you, but this is something of a red herring. There are plenty of terrible programmers out there who are 10 times worse than me. Do I get paid 10x more than them? Not even close. This article is more about why a 10x productivity increase does not equate to a 10x pay increase than it is about the possible existence of programmers who are 100s, 1000s, or 10,000s times better than the worst possible programmer.
"There are so many horrible programmers that you can be mediocre and be 10x more productive than the guy next to you. Thus you think you're in the 10x crew. But you really aren't. It's not because you're really that good. It's because the guy next to you is really that bad."
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?
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.
My proudest moments as a programmer are those where I manage to develop some functionality in a week or two that took another team of programmers months or years to do by using a novel approach or stitching together preexisting code. Every line of code I write is another I will have to maintain. Sooner or later it will be a burden. For this reason, I strive to write as few as possible. The programmers I respect most seem to follow the same pattern.
i might be proud at first, but then i would be sad to think that others have failed so terribly and with so little guidance or wisdom. i would be saddened by my pitiful pride at a product so limited by its single creator.
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.
(Though with the obvious caveat that code golf for the sake of code golf is not a good idea either. Readability is important, and sometimes, writing the naive code that is easy to explain and understand is better than the slightly more performant code)
Really it comes down to the simple fact that for the most part programmers happily sign a contract saying they will work X hours for Y money. If they are 'productive' they then can move up in the company and be a manager, but still for X and Y++. Sales guys are paid in a completely different way, same with the stock holders (founders etc). It doesn't matter how productive you are, even if you complete the task in 1 hour and have the rest of the week to do nothing, you agreed to work 40 so your boss will give you something new to do.
Being super-productive isn't always wise for the black belt coder. In the traditional world of commercial programming if you solve the problem in a couple of hours and then just spend the rest of the day fooling around, reading scholarpedia or working on your own pet projects managers often don't look upon this kind of behavior favourably - they think you're not being productive, when in fact the opposite is the case.
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.
I'd disagree with your description of "super-productive", that sounds like normal-productive with time to fool around. Do something productive with the extra time (either more coding or, better, something else business related like running the finished app past someone who might have to use it) and there might be a chance of hitting "super-productive". (fast + time wasted = normal speed)
> 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.
Not necessarily. There's plenty of horrible, horrible code that doesn't get changed because it currently works, and it would be too much of a hassle to try and de-tangle it. There's also really awesome code that gets replaced because the requirements have changed and it needs to do something completely different.
I wrote a crappy Python script one afternoon about eight years ago to address a client requirement discovered very close to implementation time. I think it's still running in a production environment -- at least I was told so as of a couple years ago. Was it great code? Nope. It split one file into four based on a particular column's value in a CSV.
It is because true productivity is very hard to identify, specially when you factor in quality, mainteinability, efficiency and timeliness. That is why managers should be as qualified as the people they manage.
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.
I'm young enough that I can still change my career easily, and I often worry that I'm not one of the super productive programmers, and that I'm wasting my time and that I should choosing a different career.
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?
I have found that uber-productivity is domain specific. I might be uber-productive in a particular domain (Java programming), however put me in an environment that does Groovy programming and I will stink as much as the next newbie. However good programmers develop techniques for meta-uber-productivity. They know what it takes to get uber-productive in another domain in a short time and what works for them.
My way to try and me more productive in any environment is to get my hands dirty, start soon and make changes often. Practice makes perfect.
As an individual you can be uber productive, just practice more of what you want to be productive at. Want to be productive at running a business, start your own and practice it. Want to be uber productive at programming, write code lots of it, and so on and so forth.
> Is uber-productivity significantly enhanced by choosing the right development methodology (e.g. test-driven development)?
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.
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.
Honest questionn--did the productivity study where the oft-quoted 10x number comes from count lines of code as the productivity measure? If so, lines of code avoided would move a developer into the "less productive" bucket. Anyone have a link to a source for this number?
Dr. Greg Wilson (editor of the Beautiful Code book that spawned Beautiful Architecture later) is working on a new book that talks about exactly this kind of thing.
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.
I'm starting to get a little burned out about trying to maximize my productivity. It's not a easy-to-understand, linear thing in most professions. No one really knows how to accurately measure it, and once you come up with something, you can game that system to produce false results if it benefits you.
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.
I think management uses salary to keep people at the company rather than to motivate them to be more productive. And if you're a manager, you want to keep people who have a lot of knowledge of the code that isn't either well captured in automated tests/documentation or easily figured out from looking at their code, ie. crappy programmers. Good programmers are able to write simpler, better tested and documented code so it's less work for others to maintain it if they leave. Paradoxically, if you're working at a 9-5 programming job, you have more incentive to be mediocre than great.
The last time I was employed I got frustrated with this having deployed 5 applications to customers in a few months on my own, and simply negotiated a contracting role. We came up with a fixed price for each job, bugs included, and I tried to make as much per hour as possible. My hourly rate ended up being >250$/hr, and the application is still in production now 7 years after deploying.
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.
Productivity based compensation for thought-workers isn't a panacea. Expenses based on time, income habituation, success or blame attribution, and differences of opinion on what is productive can actually make it a pretty horrible experience -- even for people who are well above the average.
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 started responding to disagree with you, but now I'm not sure what you're saying so I'll just chime in with my views. :)
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.
it's too bad we can't have a little roll reversal. most programmers wouldn't last a month in the advertising industry, it's far more brutal and under-paid than most development gigs unless you're founder/cto in an early-stage startup...
Always remember the classic story about "where to put the X"...
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.
Never meaningfully demonstrated? Have you tried to verify the claim?
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.
I think that part of the problem is unqualified programmers are part of the equation. The amount of "developers" out there who have no idea what they're doing is shocking. The dot-com implosion helped cut some of the excess weight, but there are still a lot of people working in software who have no excuse being there.
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.
[+] [-] rdouble|16 years ago|reply
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.
[+] [-] elai|16 years ago|reply
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."
[+] [-] jey|16 years ago|reply
[+] [-] jxcole|16 years ago|reply
[+] [-] walkon|16 years ago|reply
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?
[+] [-] joe_the_user|16 years ago|reply
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.
[+] [-] n-named|16 years ago|reply
[1] http://en.wikipedia.org/wiki/Winamp#Winamp_2
[+] [-] mattm|16 years ago|reply
[+] [-] umjames|16 years ago|reply
[+] [-] tdavis|16 years ago|reply
[+] [-] ballpark|16 years ago|reply
[+] [-] diN0bot|16 years ago|reply
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.
[+] [-] litewulf|16 years ago|reply
[+] [-] icefox|16 years ago|reply
[+] [-] raganwald|16 years ago|reply
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...
[+] [-] DenisM|16 years ago|reply
[+] [-] samuel|16 years ago|reply
[+] [-] motters|16 years ago|reply
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.
[+] [-] DougBTX|16 years ago|reply
[+] [-] RyanMcGreal|16 years ago|reply
> 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.
[+] [-] pyre|16 years ago|reply
[+] [-] ShabbyDoo|16 years ago|reply
[+] [-] clueless123|16 years ago|reply
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
[+] [-] Tamerlin|16 years ago|reply
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.
[+] [-] meunierc|16 years ago|reply
> 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.
[+] [-] DougBTX|16 years ago|reply
[+] [-] zackattack|16 years ago|reply
[+] [-] tigerthink|16 years ago|reply
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?
[+] [-] maddalab|16 years ago|reply
[+] [-] Deestan|16 years ago|reply
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.
[+] [-] abdulhaq|16 years ago|reply
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.
[+] [-] boredguy8|16 years ago|reply
[+] [-] ericb|16 years ago|reply
[+] [-] smokinn|16 years ago|reply
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.
[+] [-] martincmartin|16 years ago|reply
[+] [-] Zev|16 years ago|reply
Beyond that, I can't really answer the rest of your questions; I haven't managed to sit down and read it yet.
[+] [-] umjames|16 years ago|reply
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.
[+] [-] clofresh|16 years ago|reply
[+] [-] trapper|16 years ago|reply
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 :)
[+] [-] dusklight|16 years ago|reply
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.
[+] [-] ggruschow|16 years ago|reply
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.
[+] [-] Poiesis|16 years ago|reply
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.
[+] [-] nick007|16 years ago|reply
[+] [-] stevedekorte|16 years ago|reply
http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...
[+] [-] pxlpshr|16 years ago|reply
[+] [-] kingkongreveng_|16 years ago|reply
This is often repeated, never meaningfully demonstrated. I doubt it is true if we are excluding unqualified programmers.
[+] [-] DarkShikari|16 years ago|reply
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.
[+] [-] btilly|16 years ago|reply
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.
[+] [-] icey|16 years ago|reply
[+] [-] nikolayav|16 years ago|reply
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...