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.
Try time the clerks in your local supermarket, I am sure you can find one which is twice as fast as the slowest, should he or she get twice the salary?
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.
"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?
A small sample size would just imply greater deviation. There's no reason to assume the programmers outside your sample would be x10 better than those in your sample.
That only works when you can assume your sample is representative of the global population. Since people are not evenly distributed according to their abilities, that assumption will not hold.
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.
I used Gnutella too. It was horribly buggy and slow. However, remember that they wrote it in a weekend, and what it was attempting to do really was pretty revolutionary.
Even brilliant programmers can only accomplish so much in a weekend.
Interesting information. This was the time when the bubble was expanding rapidly. Anything got sold for $80 million in those days.
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.
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.
I'm skeptical. What evidence do you have for this? Maybe some people who have a better start (those who are "naturally" talented) receive better instruction, or are more inclined to practice more often.
Programming ability is more like athletic ability than most people want to admit. Some guys just get better, faster. Some guys can't ever break certain plateaus, no matter how hard they try. In golf, it's probably possible for anyone to go from a duffer to a scratch golfer. But it might take 20 years of work for someone who isn't set up with the right natural gifts. Quality and amount of instruction and practice will determine some of the pace. But some people will just get it faster than others. And even "elite" golfers simply won't be as good as Tiger Woods, ever.
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 think it may be more that there are certain mental blocks that can hold you back completely, but once you get over them, your skills improve rapidly. Some people are fortunate enough to start with the "right" way of thinking about those, and so they just sail over the blocks with ease. Others need a mental shift in perspective before they can understand the fundamentals, and so they're "stuck" for a long time with virtually no progress.
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.
I'm actually skeptical of "natural ability," and I find it... a cop-out to ascribe learning rates to it. I think presence of mind matters. All practice is good, but some practice is better than others. People who are continually conscious of their performance, and who actively try to figure out how to improve will probably learn faster than someone who practices passively and hopes to improve "by accident."
No one's figured out a grand unified theory of Physics either but they still have a lot more useful conclusions and solid research than we do on ability.
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.
In my latest app, I've noticed that I get the greatest highs when I write one specific function, and then rewrite it to be generic enough to handle four different elements. Great fun.
This is why I've never been impressed with people who are supposedly 10x programmers, but are actually people who just hammer out tons of code in response to any given problem.
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 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.
You seem to have a very strict requirement for pride; I wasn't aware there was a "pitiful" tier. I feel like life would be pretty depressing if I needed to create something greater than me for the social good that had a purpose just to feel proud of my accomplishment. You can only save the whales once.
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.
Your example only makes sense if that somebody was very proud of their hard-coded HTML form with poor validation. And even then, if it was better than they'd done before, they could still be proud.
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.
(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.
But it is not a measure of the productivity of a programmer. It may be a measure of the productivity of an entrepreneur, but that is not what this article is about.
Therein lies a subtle indicator as to what is the value-add in the modern economy. Any other measure of productivity is prediction of the this one (at best) or cargo-cult metric (aka vanity metric) at worst.
It's measuring the amount someone is willing to pay you for your work. By an economist's definition, that's your output. If you divide your output by number of hours worked, that's your productivity, again by economist's definition.
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".)
You make good points. However... if we accept the economist's definition of productivity, then the article becomes a NOOP: We measure the marketplace, we discover that given a set of programmers with roughly the same conditions, there isn't a 10x disparity in output divided by hours worked, therefore no programmer is 10x more productive.
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 is easily a 10x disparity in output divided by hours worked. Why did the Etherpads just make 8 figures over the past 3 years, while I made only 6 figures? They certainly didn't work 100x more. By the economist's definition, they were easily 100x more productive.
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.
This is one of the best posts I've read in a long time. It is easy to forget that, with regard to creating wealth, there are lot more factors at work than raw programming skill.
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.
I'm surprised this has been voted up. Generally I've found anything that suggests you aren't fully in charge of your own destiny, and that hard and smart work necessarily translates to success, to be somewhat taboo round here. (Which makes sense given the audience but often strikes me as a bit cargo-culty)
In the real world the amount someone is willing to pay for your work is greatly influenced by how it is marketed and sold. I known some great programmers whom I suspect would fall flat on their face if forced to start their own company, but when placed in a team where they can focus on their strength can produce great things. So while it might be good way to measure the productivity of companies it isn't a great way to measure the productivity of individuals.
As someone who's been on both sides of the fence, this is untrue. You pay people more or less what is sufficient to keep them happy (within reason). When you're hiring a new employee, you tend to pay them their current salary + some percentage raise. So the biggest determining factor of your salary will be how much you made at your last 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.
I understand that an economist would say that exchanging intellectual property for money is the only way to measure productivity. It satisfies me about as much as measuring productivity by lines of code, and for much the same reason.
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.
That's not actually true, economists are willing to measure things in non monetary terms because economists study people not money. EX: If you turn down job X that pays 20% more than job Y then clearly you are getting something of value out of that choice.
That reminds me that interesting graph http://royal.pingdom.com/2009/05/14/congratulations-google-s... about revenues per employee in big tech comp. See the differences... Interesting enough, when you dig down subpart of the companies, you find areas with very different revenue per head also.
> Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
--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.
Basically every programmer I've worked with agrees that kLOC is a terrible way of assessing productivity. I think it's only "standard" in the stupid section of the industry (which, alas, is much bigger than it should be).
Actually, I've always seen kLOC as a divisor: defects/kLOC, branches/kLOC, etc. Even metrics like functions/kLOC are useful, if you believe in small functions.
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)
While I agree with fast + time wasted = normal speed, in reality it is not the wasted time that plays the role. In most companies developers don't have a fixed 8 hour job and most of them work more than 8 hours a day on a routine basis. I have seen managers who valued the total time spent working more than the actual work accomplished. So a developer who works about 8 hours a day was ranked below someone who spent 10-12 hours a day working even though it was the former who was accomplishing more tasks.
It's often hard for a manager to judge how productive a developer is being. Often they're insufficiently qualified to judge the standard of the code being produced or whether one solution is more elegant/reusable than another, and instead are just using heuristics which work for other types of employment, such as estimating how much overall time and effort was put in.
What about someone who works 10-12 hours and accomplishes the most tasks? I think you have to understand the corporate mindset without abandoning your black-belt coder-fu. Yes, you have to emphasize how difficult what you did was. You have to point out what you've accomplished. And tie yourself in directly with producing specific pieces of revenue wherever possible.
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.
Let me re-phrase that. If you... solve the problem in a couple of hours and then spend the rest of the day fooling around ... then you are as productive as the guy who spent the whole day on it, not super-productive. (The other guy probably spent half the day reading Hacker News anyway.)
> 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 throw out about 50% of all code written for A/B tests within, typically, a week or two. If it weren't for all the business value added by it, I guess I would suck as a programmer.
In fact, the particularly horrible code might not be replaced for a long time precisely because it is hard to understand but it works and changing it could cause problems elsewhere.
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.
I've found that most of the competent developers I've met haven't had a whole lot more difficulty switching languages than the significantly better developers. There's a lot of synergy between modern programming languages.
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."
> 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 don't realize his "fact" for the simple reason that he is wrong.
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.
This is a great piece of information, thanks. I always wonder at the shifting X, and am often perplexed that programmers who will take almost NOTHING for granted accept this as gospel truth without any corroborating sources.
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.
50x? Really? That means they achieve in a week what the 1x programmers achieve in a year. I'd say its more likely they are infinitely more productive (as in produce things the 1x programmers could never produce), but those kinds of projects are rather uncommon.
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.
I've done performance based pay for programmers both at the individual and group level. It adds a lot of non-obvious problems. I don't believe it improves happiness, retention, or productivity in the long run†.
Most companies theoretically already do performance based pay, but just at two levels:
Level 1 pay: $salary
Level 2 pay: $severance
There's usually a lot of room for improvement. If they can't get it right for 2 levels, they shouldn't look to fix it by adding more.
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.
That's one big problem I see with performance based pay, even if an accurate personal metric were available. Time spent helping/mentoring others would have a negative impact on a senior programmers bottom line, even though a company generally wants to encourage this.
You can't be accurate when you need to hit multiple different targets with one shot. It's exceptionally difficult to get people to agree on what's valuable, and how valuable it is.. and the problem gets worse with scale.
The only people who get paid according to their productivity are the ones that own their own business, individually or collectively (in a partnership). Everyone else is paid "market rate" which is the lowest rate someone else is willing to accept to do the same job, and is able to deliver. These are completely different compensation models.
Untrue, many salaried finance types eat what they kill in bonus comp, even some developers (front office developers or quants) if they're responsible for driving P&L and not just a cost center.
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.
Good point. Having never seen one of those people I have forgot about their existence when writing this post.
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.
If you own the business, why would any rational market participant buy your product or service without expecting it to create more value for them than they paid? Same thing, really.
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.
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.
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."
There are so many variations of that story floating around that someone may have heard it, but not recognize any detail of the version you gave. http://answers.google.com/answers/threadview?id=183998 cites several other variations for comparison.
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 thought the Peopleware claim was that some teams are 10x more productive than other teams. I could easily buy this, because it's very easy to generate more internal communication work than it produces, i.e. be negatively productive.
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.
No, Peopleware's research was on the productivity of individuals at different organizations. To be precise what they did is arranged a series of "coding wars" where multiple organizations would each select 2 individuals and all would code up solutions to the same problem in the language of their choice. People were asked to keep a log of what they did, and describe various things about their environment.
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.
Well, I just googled the peopleware citation and it seems the study backing this often repeated claim is from the 1960s and people have plenty of questions about its methodology.
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.
If you view computer programmers as mental ditch diggers, then the idea that one could be so much more productive than another seems crazy. But when you see it as a creative endeavor, it's completely rational that some could be orders of magnitude more productive, even infinitely so.
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.
Slight nitpick: Infinite developer As will not solve the problem unless you assume that each developer can solve a finite part of the problem. If Developer A simply can't solve the problem none of them will help.
I don't know what you found through Google, but it was a bad description of the research cited in Peopleware. For a start the research they discuss was done in the 1980s, not the 1960s, and the methodology of their study was quite carefully done.
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.)
I've experienced a 10x difference firsthand - and not against bad coders, but against average ones (they were former game developers, so they're quite possibly above average vs. the rest of the software industry). And you can slice the productivity along a bunch of different axes - systems designed and built, loc (not a great metric), complexity, features, etc - and the metrics still hold up.
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. :)
Unacknowledged differences of that magnitude would imply a massive arbitrage opportunity that has persisted for many years.
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 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.
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.