I'm pretty sure this is false. Hackers such as Guido van Rossum or Linus Torvalds or Bill Joy are many orders of magnitude more productive than average programmers. Some of the old IBM studies cited in Peopleware show the average programmer writing 3 lines of code a day! PG mentioned that Trevor Blackwell rewrote their entire system in smalltalk in two weeks, which was everything that he and rtm wrote in 6 weeks. That's like an order of magnitude difference.. He and RTM were themselves probably an order of magnitude more productive than their competitors, with fourteen times the number of programmers and a worse product. And since those competitors were actually shipping products, they were probably an order of magnitude more productive than the average programmer working on internal tools at some BigCo, ekeing out 3 lines of buggy, ineffective code per day.
I'm not sure that's a valid measure of productivity. In a commercial setting most of the code is actually pretty straightforward, but it might take a day of meetings to agree with everyone that (for example) this is how interest should be calculated on this particular financial instrument. Been there, done that.
Also 3 lines of APL are a very different beast to 3 (or even 300) lines of COBOL...
Although I'd agree with the second part (that PG and RTM were exceptionally more productive than the Joe Schmoe the programmer), I don't think the Trevor Blackwell example is a good one.
I think it's routine for me, and most anyone, to write a first version of a system over a week or two and keep noticing ways the design could be improved. Over time cruft accumulates--and you continue to notice new problems you didn't anticipate when you first designed--and almost always it is much quicker to rewrite a second version than the first.
The 3 lines of code per day metric seems fishy to me, but it seems to be based on systems level projects (lets build a new operating system) rather than making a new PHP photoalbum for Grandma. It would be very interesting to see numbers which broke down LOC/day for different subsets of programming jobs.
What you wrote does not disagree with the author. He comes to the same conclusion: some developers are much more, even an order of magnitude more, productive than others.
He doesn't get to his real question until the last few paragraphs, which is why don't we see the same pay disparity with developers that we do with other professions? His answer is that measuring who's better is difficult and unreliable.
I admit I was confused, too; since he spends so much time on the issue of are some programmers orders of magnitude better than others, I thought that's what he was questioning. He doesn't get to his real question until the end, and then his answer is weak.
The author suggests that programmers vary in talent by reliability, buglessness, extensibility and maintainability. He goes on to suggest that these are hard to measure.
"It's not that good developers can churn out 10 times as many features as the bad ones. It's rather that good developers write code that have less bugs, more extensible and more maintainable. These are the things that you can't measure by statistics or figures."
I've given a few examples of good developers making systems that are orders of magnitude harder to complete, in the same time. In many cases it's not within the current talents of most programmers to write those systems at all. Another good example is the Quake engines. Additionally, in programming contests or student assignments there are many examples of people completing the same task in vastly different amounts of time. Finally, he states that reliability, buglessness, maintainability and extensibility are things you can measure with statistics, but many people have quantified uptime, maintenance, density-of-bugs, and extension time, to moderate success.
Measuring things this way is completely wrong. All lines are not created equal. Finding a bug in 10 million lines of legacy code might take me a week to do a 2 line fix, whereas I have days where I can bang out 2-3k of mindless interface code. Sometimes I spend 2 weeks doing research to write a few hundred lines of code.
I find this sort of rhetoric honestly reeks of inexperience. Lines is a horrible metric for measuring productivity. Speed for finishing something isn't a particularly good metric either, since I've met a lot of hackers that can go on a coding binge (myself included) and accomplish as much in a weekend as they could in a couple of normal reasonably productive weeks.
IIRC, one of the major results of the Ericcson language studies (see for example http://www.erlang.se/publications/Ulf_Wiger.pdf) was that the lines of code metric was more or less constant over projects and across languages.
"Comparisons between Ericsson-internal development projects indicate similar line/hour productivity, including all phases of software development, rather independently of which language (Erlang, PLEX, C, C++ or Java) was used. What differentiates the different languages then becomes source code volume."
Do you have a better metric? How about skill in solving tough algorithmic problems which haven't been before solved? Often on, for example, TopCoder, the top competitor can solve a set of three problems in 15 - 30 minutes. The median competitor, even in the upper division, solves zero. Some of the problems at only the 'medium-level' in those sets are in fact so difficult that they are given as two-week assignments in university courses, and only a fraction of students can complete it. This doesn't seem like a difference in reliability and bug count, it seems like a difference in kind in both algorithmic ability and productivity.
They're trying to prove a very different point in that study; notably that for developers working on distributed architectures that it's faster to solve most problems with Erlang than C++. That's a very different sort of conclusion than saying that the best programmers write the most code.
I think the only reasonable metric is someone's portfolio. You wouldn't pick an architect by how many nails they'd used or a musician by how many notes they'd written. You have to look at what they've actually done.
And in fact, that's pretty close to what good hiring is about. You then see if real performance matches up to what's in the portfolio.
A vaguely tangential story, I was on-call during Y2K and I got called, but it wasn't urgent, and I stopped by the office on my way home from the party and fixed it.
For being on call at that time, I got a week's time in lieu and #500. For getting called, I got the same again. The fix was 10 lines of code, and the day after that I took it out and replaced it with a change to the original line.
I believe the studies you are referring to measured 3 lines of shipping code produced per programmer-day. This doesn't mean that Joe the Hacker went to his terminal and only typed three lines; it means that other people re-wrote code, or he spent a lot of time debugging something that was a short fix, or that a lot of programmer time was devoted to projects that were never shipped.
I'm not trying to defend mediocre programmers here, but I think you've misinterpreted a study that intentionally combines individual productivity with organizational productivity.
* Unfortunately, I wasn't able to find the actual study report. If someone can locate it I'd appreciate it.
PG mentioned that Trevor Blackwell rewrote their entire system in smalltalk in two weeks, which was everything that he and rtm wrote in 6 weeks. That's like an order of magnitude difference..
I don't know about that situation, but in general, rewriting a system is much easier than writing it in the first place.
Either managers can tell who is better or not. He says both:
It is not that the managers don't know that good developers are 10 times more productive than a bad one. Managers do know; some of them are developers or former developers.
and
It's not that good developers can churn out 10 times as many features as the bad ones. It's rather that good developers write code that have less bugs, more extensible and more maintainable. These are the things that you can't measure by statistics or figures.
I think his point is that while managers know that good developers do "exist", it's difficult to be able to label a specific individual as a good programmer.
Why do you think that re-writeability matters? People who write code that is difficult to maintain should make more money by virtue of being harder to eliminate. I don't think effective programmers document everything either, but maybe this is an unpopular opinion.
What sets really productive people apart in my experience is architecture and domain vision. This is certainly the lesson in the Viaweb example. Without good architecture innovation consists of "feature creep". You've got a good thing when you find yourself with changes that simplify a code base or system while increasing its power.
I suspect this is why people who develop their own tools are often seen by others are great programmers, and why Eric Raymond's definition of a hacker is someone who builds their own tools. I'm a worse programmer than a lot of people, but am orders upon orders of magnitude faster than anyone else in my niche domain by virtue of knowing how to do things and leverage existing assets. I assume really good programmers are leveraging their expertise in other areas too.
If this is true, I'd argue that what keeps the good people from earning higher multiples is that architecture and vision don't matter in a lot of cases. Companies that innovate less have less need for development characterized by rapid innovation. Systems get developed by spec and implemented by indifferent teams. You budget for the features you want, not the flexibility you need. Innovation matters more to smaller companies, but even there non-technical individuals rarely see the architecture through the interface. Flexibility becomes conspicuous mostly by its absence, as development gets "over budget and behind schedule everywhere".
I've found that with freelancing you can at least get closer to something resembling an efficient market value much more quickly, you just need to build up a reputation of being awesome. ("This guy is expensive but he's totally worth the money." style referrals)
A crap developer doing say inhouse software for a non-tech company might make £20k/year. A top-tier contractor developing for an investment bank or hedge fund could be making £250k+/year.
Yes, but his key skill isn't his C++ but his knowledge of financial instruments. Even tho' a Quant spends most of his time programming he's not considered a member of the IT staff.
I'm not talking quants, I'm talking senior architects & technical specialists. Domain knowledge is important in those roles - but domain knowledge is an integral part of being a developer. The standard contract rate for senior front office devs seems to be between 500-800/day, specialized knowledge/skills can easily push that upto 1000-1300/day.
Those numbers actually seem a bit low. Even mediocre programmers bill out at $100+/hr ($800+/day). It isn't unusual for someone great to charge 5x that amount ...
Because there's a disconnect between the value created by good developers and where the value gets realized. It's the same reason why people don't invest in energy efficiency. Without a holistic view, you can't see all of the benefits that get created so you can't weigh it correctly against the costs (which are clear).
It's really very simple:
- Bad developers won't work for less than a certain amount.
- Good developers cost about the same.
- Distinguishing one from the other before hiring is nearly impossible.
If you were one of these magical 10x producitity guys, would YOU hold out for the job offer with 10x the normal salary? Are you sitting at home, right now, by the phone?
The author doesn't get it. It's not about measuring results. Great programmers don't get compensated in proportion to their contributions for the same reason that mediocre CEOs are far over-compensated for theirs.
Programmers have no power over the people who set pay rates while CEOs have a great deal of power.
Being in management gives you leverage. Being in a union gives you leverage. Being a replaceable widget -- even a gold-plated widget that is x10 better than the other widgets -- gives you no leverage.
I hope I've cleared things up for you. Now go out, throw away any Ayn Rand books that you own, and download something by Machiavelli. You'll learn a lot more about the way that capitalism really works.
Programmers have no power over the people who set pay rates while CEOs have a great deal of power.
Being in management gives you leverage. Being in a union gives you leverage.
I hadn't thought of this. Personally, I see programmers as workers that should be in small, elite groups, like surgeon wards. OTOH, surgeons have a cartel that programmers do not.
Quite right about doctors and lawyers. In fact I was going to mention their professional organizations as an example. Requiring certifications, all for the public good of course, is one of the best ways to inflate wages.
Johnnie Cochrane and celebrity plastic surgeons don't earn 30× as much as other doctors and lawyers because their compensation is set by a guild; if anything, guilds tend to assign scale and frown on those who charge more (and prosecute those who charge less). They earn 30× as much because people are willing to pay 30× as much for their services.
I think the relative value they charge relates to what other people are charging. A hair dresser might charge 50x what other hairdressers charge, but in the back of peoples heads they compare the price to other hair dressers and not doctors. If your 10x as good you can charge 5 - 50x as much, but not 50,000x as much without a lot of brand advertising.
"Without a lot of brand advertising"? How many ads do you think Tom Cruise buys to promote his personal "brand"? I think the relevant thing is the reputation, not the advertising that might or might not create a better reputation. The reputation is why Tom Cruise makes 50 000× as much as the actor in the community-theater play down the street from you. (Assuming they're even getting paid.)
When a producer is negotiating a contract with Tom Cruise, I don't think it enters his mind how much unknown actors in community theater make. I think he's thinking about how many people bought tickets to see the last Tom Cruise movie and his estimate of how many of them went because of Tom Cruise.
I don't know enough about hairdressers to know whether the same thing applies to them. It does apply to fashion designers, and in some cases it seems to apply to programmers.
After sarah paulin chose her glasses that brand become unusually popular. I don't think the idea it was "Free" advertising really matters the effect is the same. Tom Cruise has a long history of exposure which is part of why he is paid that much. But, you could also consider he the idea he is worth 50,000x as much because he increases the movies revenue and he helps the movie get financed.
In most cases I suspect "brand" acts like a multiplyer so Apple's HDD might be worth 1.25 times as much as another just because of the reputation. IBM might be 30% better and have 2x the brand so they charge 2.6x what other consultant companies charge etc. Clearly major movies have great hairdressers but they don't get to charge 50,000x as much because a lower increase in value and a lower level of brand recognition.
PS: This get's confusing when considering something like breitling watches where a lot of the value comes from the price tag and not the physical watch. When someone knows you spent 250,000 on your watch they know you have money even if they can't see your car / house etc.
What would the union be, though? 99% of programmers would not be overly ecstatic at 10x payments for stars. Are you suggesting a Rockstar Programmer Union, MENSA qualification required to join?
Perhaps what Rockstar Programmers need are Agents.
There is a Rockstar Programmer Union already. It basically consists of the programmers who network, are excited about their craft, and start or join companies that do innovative things with software. Wages for programmers in that group are significantly higher than for those who just join any old software development group that they find through Monster.com, and then never talk to anyone outside the company.
I met someone at a fencing club that was a programmer for a health care software company. He was my age, graduated a year earlier, and his salary was half what mine was (we were both on our first jobs out of college). I didn't know programmer salaries could go so low, for college grads. And his skillset was completely ghettoized - the company used a proprietary programming language and involved lots of domain specific knowledge. I suspect the difference was that I got my job through a friend of a friend that I'd met on the C2 Wiki, while he took the first available job he could find upon graduation, probably through Craigslist or Monster.
An exceptionally brilliant programmer I know was working at a telecom. Since he was so good, he could complete his week's assignments in one day, so he'd go home until the weekly status meeting. His boss was dead set against him -- it was "only fair" that he should suffer as much as everyone else.
I'd bet money the conversation went a lot closer to, "Uhm, no. You're paid to work 40 hours a week."
Any line of reasoning that begins with "since I'm so good" and ends with "being here is suffering" sounds like there's probably some jackassery going on.
Honestly, a manager who was ok with him going home after one day would be stupid. Then he's giving them no additional benefit for his fabled skills, and their best developer wouldn't be there most of the time and the rest of the team would probably resent it.
Honestly, a manager who was ok with him going home after one day would be stupid. Then he's giving them no additional benefit for his fabled skills, and their best developer wouldn't be there most of the time and the rest of the team would probably resent it.
Instead of the manager forcing him to sit at his desk for 40 hours a week, he should be giving this guy more autonomy. You don't keep good developers by squelching their abilities or freedom, they'll get fed up and leave.
That missed the point though. He wasn't asking for more autonomy, apparently. He was asking to work less. A good developer that's not getting any more done than the other developers doesn't add value.
Was he really asking to work less? He was getting equivalent results and asking for less useless ass-in-0seat time. I know for a fact that a guy like that reacts well to more autonomy. Doesn't matter so much what the developer asks for in this case. It's how the manager reacts when discovering talent like that. In this case, it was an epic fail for management.
A devious manager would praise this guy, raise his pay 25%, but quietly give him double the work. A really devious one would find some way to document the resulting increase in productivity and take the credit.
But the really insightful one would let this guy try to find ways to make the whole group more productive or reduce its bug rate.
Uh, he didn't use "suffering" in his conversations. That is just a description of the manager's philosophy. The most relevant factor wasn't the work accomplished and the quality. It was serving time.
Why does this require a solution though? Why is it a problem? If as the manager you're focused on productivity and not time spent, there's nothing wrong with him working 1/5th the time so long as his productivity rivals his colleagues. Maybe he doesn't want to work 5 days a week? Maybe his priorities aren't 40 hour work weeks. If you are unable to replace him with someone who'll perform better, then why make it in an issue?
And why should his colleagues be any more jealous of him then they are of the CEO who makes tons more, or anyone else who gets paid more or works less for that matter?
There are 2 problems:
1) Having a clear way to measure productivity.
2) Stodgy ideas most manager's have about time spent, instead of production.
Why does this require a solution though? Why is it a problem?
It's a problem because the company culture (probably) won't tolerate it, but instead will act to preserve itself at all costs, including the cost of reduced productivity. So when I said "obvious solution" I should perhaps have added "within the parameters of the existing culture".
I sympathize with your values, but the idea that you can change a corporate culture to make it recognize productivity in a more rational way is a fantasy. It's actually a harmful fantasy because it deceives many creative people into spending their time and energy on environments that will never fully recognize them.
To paraphrase what Max Born said about science, new models are accepted in the market not because companies change, but because old companies die.
Edit: Having a clear way to measure productivity wouldn't change a thing. If maximizing productivity were the value driving behavior, things would already be different even without a measure.
Programmers have no power over the people who set pay rates while CEOs have a great deal of power.
Actually they do: they can turn down an offer to work at any existing company and start their own instead. And many do.
(That's how capitalism really works.)
I get what you're saying, but thras's point still stands. You're just using the word "programmer" in two slightly different senses.
thras was using it to refer to a role - a non-management role - and in that sense a programmer does have a lot less ability to influence the people who set pay rates.
You're using it to refer to an actual person who can try to change the role he occupies, in your example by starting a company.
Sort of. It's not about who sets the pay rates - otherwise, actors and sports figures wouldn't get their $multimillion salaries, since it's the movie execs and team owners that set the pay. It is about negotiating leverage.
When a company hires a CEO, they usually decide who they want first, and then they negotiate over price. There are few substitutes for their choice - usually, a company will find only a handful of candidates that are suitable for the position. This gives the CEO enormous leverage. There's only one of them, yet there are probably a couple companies that want to have them as CEO, so the price goes up.
Similarly, brand-name actors can drive moviegoers to theaters just by their name alone. There is only one Brad Pitt, but there are several movies that would love to have Brad Pitt star in them. Dakota Fanning gets like $4M/movie, because her name alone ensures the movie would get more attention than it otherwise would. David Beckham got a $250M contract, even though he's kinda washed up, because his reputation means people will watch.
An average programmer is filling a role, however. If they ask for too much money, the company just goes out and gets a different programmer. At hiring time, they don't know who'll be 10x more productive, unless that programmer already has a strong brand behind them.
I'm very curious to know how much "brand name" programmers like Peter Norvig or Guido van Rossum get paid. There are many Python programmers, but there is only one Guido, and many places that want him. I'm guessing I'll never find out, though.
BTW, this is behind a lot of the career advice that Internet celebrities give. Seth Godin's "you should throw away your resume" really means "your personal brand should be strong enough that employers want you and aren't just filling a position." Paul Graham's "work hard at things that excite you" is because if you do so, people will notice (eventually), and then they'll want you for what you've done and not just any old programmer. Marc Andreesen says "set the controls for the heart of sun" because that's the work that people notice, and that'll make you stand out from the crowd.
"For his part, Torvalds has been amply rewarded for his role, but he's no Bill Gates billionaire. OSDL pays him a salary of nearly $200,000. In addition, he sold initial public offering shares that he got as gifts from a couple of Linux companies, including VA Linux Systems. That helped him afford his house and put money away for his daughters' educations."
I'm very curious to know how much "brand name" programmers like Peter Norvig or Guido van Rossum get paid. There are many Python programmers, but there is only one Guido, and many places that want him. I'm guessing I'll never find out, though.
Anders Hejlsberg got a $3 million signing bonus from Microsoft when he left Borland.
Programmers have no power over the people who set pay rates while CEOs have a great deal of power.
Yup, I think that around about covers it. I would have phrased it a little differently though. Basically, in just about any endeavour, you only get the really big reward if you sell your product directly to the people that use your product. So, music artists sell directly to the people that listen to the music (well, they earn a percentage share of direct sales). Startup founders also sell their products directly to the end user.
But as soon as you become an employee, earning a salary, you aren't selling directly to the end user, you are selling your skills to your company, which then produces a product that is used by the end user. Or worse still, you are selling your skills to a company that produces a tool that is sold to another company that is finally used to do something deemed useful by the end user. The longer that chain is, the less likely you are to get paid what you are worth if you are above average. Why? Because the entity that is buying your product doesn't actually care about the product, so if you have made it three times better than it would have been without you, don't care - just as long as it meets the minimum specification necessary to be able to sell it to the next person in the chain. On the other hand, if you are selling directly to the end user, they certainly appreciate the product that goes above and beyond minimum spec - insert Apple/Ferrari story here...
I can think of only one special case exception to this rule, and that is sports stars - and they are a special case because they are the only market where you actually have to beat the competition to be considered as performing. That means that there is a massive advantage in having someone on your team's payroll that is just slightly better than the other guy - you only have to be slightly better to win, and winner takes all.
Wages are not effected by leverage or productivity. Productivity only matters when figuring out how many laborers you should hire. Leverage is just a weird way of masking the fact that higher paid workers are in low supply and high demand. Leveraging can only exist in instances where supply is low and demand is high!
1) The supply and demand of labor determines wages.
2) The factors that determine where you might lie on the demand curve for labor are: skill level, education, experience, reputation, etc.
3) The higher up the Demand curve, these factors become in shorter supply because it is hard to level up in real life. (MMO reference, sorry.)
4) The higher the demand of skills, experience, reputation, education, etc. >>> the lower the supply of labor will be >>> the higher wages will be.
Being a Brazilian, I have some ideas for a fair comparison between soccer stars and software engineers. I just submitted the article here: http://news.ycombinator.com/item?id=386910
One explanation for extremely large pay packages is that they are the result of a bidding war. If programmers don't get the oversized pay they feel they deserve it's because they haven't manipulated the job market properly or they don't really have the power to manipulate the market. The "top-rank" developers sabotage each other by working for lower pay than they collectively deserve. How could programmers construct a bidding war for their services? One way that borrows from the sports analogy is to work in an industry where there is a winner-take-all payoff structure. While one 10x programmer may be only slightly better than any other 10x programmer, in a winner-take-all business it's worth the trouble to bid higher than one's competitors for such people.
The 10:1 ratio is an oversimplification. In some problem domains and with some languages, it's 25+:1 (or infinity:1); for others, it's only 1.5-2:1. Also, though a project can be accomplished 10x faster and better if given to the right person, it's not the same people who are 10x more productive on every project. Finally, one's position on the scale improves (at least within a given field) with experience, so that the first 3 months in a new area are often less than 25% as useful as the next 3.
Mediocre developers are short-term money losers, but some of them (the ones with curiosity and intelligence, whose mediocrity is a result of inexperience) will become great hackers, and thus, money-makers who, if treated well, will stick around for a salary much less than their value to their operation. Mediocre programmers are "overpaid" because this "call option" exists.
What also has to be taken into consideration is the HR department, and their company policies that do not allow for any deviation from the policy. Set pay ranges for a title, inability to promote a person more than once per year, inability to provide an increase in pay greater than 15%, so on and so forth.
You could describe YCombinator as a means for rectifying this imbalance.
I think the author glances over too lightly the idea of good developers working for equity. A core part of the YC philosophy is that it is much easier to take a great hacker and teach them the business skills they need to succeed, than to take someone with business skills and make them a great hacker. (I'm basing this on something from one of pg's essays, sorry, can't remember which one at the moment.)
Based on the kind of output that the average YC team puts out during the program, a 10x multiple over the average corporate programmer's output during the same time is a reasonable estimate. Part of this is because, even if you have a corporate programmer capable of 10x more productivity than his peers, the processes surrounding him likely make it impossible for him to get that much work deployed in that amount of time.
And I think that is another important thing to consider. Corporations do not pay developers who are 10x as productive 10x as much because the way they develop and deploy software makes it impossible for them to realize a 10x productivity improvement, in any case.
EDIT: Just thought of a possible rebuttal I would like to address. You might compare this to the sports star, and point out that the star is not taking on the risk associated with getting paid in equity. However, an athlete's career is also an extremely high risk endeavor. Just as most startups fail, obviously the vast majority of athletes fail to make a lucrative career out of their athletic prowess. I would venture that the selectivity for an athlete looking for a lucrative contract is much higher than the selectivity for a hacker managing to start a lucrative business.
I think it was another pg essay (possibly http://www.paulgraham.com/opensource.html) which suggests that workplaces have office hours because they can't accurately measure an employee's productivity. So they aren't likely to know where the productivity is really coming from anyway.
Even if they know you're 10x as productive as the other developers, they may not reward you so as not to make the other developers jealous or resentful.
Pay is not proportional to personal performance. For a sporting example, try sprinting: the fastest runners are only 2 or 3 times faster than I am, but might be paid millions.
Musicians are not paid proportionately to some independent measure of ability, but to sales.
So neither of those example support the contention.
The article says the difference is not that good devs produce 10 times as many features. But that contradicts the original research reference, ie. productivity.
Think about a real rock star (not a rock star programmer). They play/sell their music to millions of paying fans. Now think about the difference to a band that only plays out in local clubs and might sell a few CDs. That rock star who plays to millions of people might not be as "good" as the local band but they are generating a lot more value. Now think about the programmer who is 10x better than a "not so good" programmer... is the end result of the 10x better programing worth 10x more value in the end? Even if they are generating 10x more value - I think that the value generated by real rock star is 100s or 1000s of times more than the local band. So do "rockstar" programmers create a 100x or 1000x more value than a "not as good programmer" does for a company - great rockstars do, great sport players do, great actors do...
Measuring developer quality is indeed a hard problem, but I predict it will be solved before too long. Good programmers are a massively undervalued resource. A company that could effectively measure developer value would be able to pay strong developers more while paying weaker developers less. This would allow them get much more value from their salary costs and would give them a huge advantage over the competition. I think a lot of people realize this, so it's only a matter of time before we start seeing solutions.
I've read this a bunch of times, and I'm starting to think that the "10x more productive" meme may be damaging the reputation of top programmers. Not because it's bad to be ten, twenty, or a hundred times more productive, but because it shifts focus away from the real value a top developer can bring, which is creativity. The 10X thing implies that top developers produce the same thing as crappy developers, just faster and to a higher quality standard.
Imagine a writer is contracted by Rolling Stone for 2,000 words on a rock band (ie., the plot for Almost Famous, vaguely autobiographical for Cameron Crowe). By the "10x more productive" argument, we'd be most impressed with a young journalist who comes back with a high quality story in less time and at a lower cost.
The real issue here, though, isn't the productivity - it's that if you give this assignment to 100 different writers, you'll end up with 100 different stories. Some will be great, some will be fine, some will be boring, some will be incomplete. But while deadlines are important, that's more of a baseline: you need to finish in time, and you need to write competently. Beyond that, as a publisher I'd worry a lot less about the writer's "productivity" and a lot more about the product itself.
So a top developer can be someone who gets a well defined project done much more quickly to a high standard, or a top developer can be someone who takes vague notions and emerges with incredible software within a reasonable timeframe and budget. While there's probably some overlap, one isn't necessarily good at the other (in fact, I'd guess there's a negative correlation, mainly because people who would be happy working under one set of circumstances would generally be very unhappy in the other).
You have a good point here, and I hadn't thought of it that way before.
Somewhat related, it does seem like a major factor in the importance of people's software accomplishments (measured economically or however) is the importance of the problem they were trying to solve. Build an easy-to-use web site builder for Microsoft Windows in 1994? Sell to AOL, retire to Switzerland at 35, spend your spare time mentoring the young, designing prosthetic limbs, writing new operating systems in Python, or whatever floats your boat. (Incidentally, to me, that seems like getting paid 10× as much as the average COBOL cubicle drone who retires at 65.) Build it for NeXTStep instead? Nobody will remember.
Hamming's "You and Your Research" makes this point about scientific accomplishments: working on great problems is a sine qua non of scientific greatness.
To tie back to your point, when someone has some vague notions about what they need done, the first thing you have to do to make incredible software for them is to figure out what they would think was "incredible" — that is, figure out which problems to solve, and which to postpone. Because if you get that wrong, all the rest of your work is more or less wasted.
As Hamming points out, it's not enough for the solution of a problem to be desirable; it also has to be feasible. That clearly involves some risk.
Part of the problem is that people rarely hire someone to be creative. They hire because they have a distinct need. I think it was 37Signals that referred to this as "the tyranny of the client."
I've always performed better when I had wide latitude, but this is difficult to pull off in "the real world." In college and especially grad school, I could get out of all kinds of exams and assignments by suggesting a different project to a professor. They'd get interested and say "sure, do that instead."
Thing is, it really didn't cost them anything. Giving a student an "A" even though he didn't do the assigned homework is, of course, very different from cutting a programmer a check even though he didn't complete the assigned project.
In general, I'd figure employers are looking for the 10X productivity, whereas investors are looking for the creativity.
You have to live an edgier life to get to be creative. The closest thing I've heard in the corporate world is Google's 20% thing. There are other avenues as well: I worked a while at Sun, and I managed to get a couple of projects accepted well enough that they became my full time job.
It is interesting how the trade-offs between the following two desires come into play:
[1] "more extensible and more maintainable" (long term)
[2] "meets a date with sufficient functionality" (short term)
In either case, intolererable bugs make the contribution invalid.
The stuff has to "work" for the cheque-writer's definition of "work".
A manager setting pay rates has less latitude than people might think.
The perception of bean-counters and other upper-management is that programming talent is a commodity that does not vary as much as it truly does.
Even if they were to pay a superstar (defined however you like) what they were worth (in term of the bottom line), then they get nervous about having too many of their eggs in one basket.
e.g. "Uhhhmm ... how about you get me 4 mediocre programmers instead of that superstar so that if one leaves or gets sick I am still covered".
I can tell you that most managers are driven by item [2] above with mostly just lip-service being paid to [1].
The peers of developers are much more slanted to [1].
This is why open source can kick so much butt. Developers actually get to do the right long-term thing.
So, in practice, a superstar "date meeter" trumps a "extensibility maven" in a managers (i.e. his bosses) eyes nearly every time.
I always thought programmers were more prestige- or interest-oriented than money-oriented. This would help explain why pay is not as proportional as in other industries.
J. Random programmer who works at Do-No-Evil Geek-owned Company works on software that millions of normal people will use, but gets paid 40k, is much better off than J. Random programmer who works for Enterprise Software Factory who gets paid 40k and has to wear a tie and work in a cubicle on software 20 people may really give a crap about.
You will see the same skewed numbers at work in the video games industry, where employers know they can pay you barely anything for the right to wear whatever you want to work and work on something cool that people care about.
I believe Gresham's Law, i.e. the principle that bad money drives out the good, is also applicable here. Employers aren't knowledgeable enough to evaluate the difference between a good and a bad programmer. Consequently, they pay only an average with a small variance.
One of the characteristics of a bad programmers is that they will say they are "done" when in fact they aren't or the quality is so poor that the schedule will ultimately slip. Employers are bad at judging internal code quality or correlating bugs with bad programmers.
In fact, at my old company, they actually gave bonuses to people who fixed the most bugs -- usally their own. They ended up rewarding programmers who made lots of bugs versus people who had solid code. Fortunately, such a reverse incentive program ended.
Maybe 10x good developers don't get 10x pay because it takes teams to build high impact software, and the probability of anyone getting a team of all 10x good developers in the same room working on the same thing is low. (Assume something like 10x good developers at frequency 1:100 or 1:1000 in the population of all developers.)
It's hard for a company to realize the value from a 10x good developer, because their work is averaged with that of their 1x, 2x, 0.5x good teammates. Therefore the 10x good developer isn't worth much more than their more conventionally stellar 2x good colleagues; all he's doing is bumping up the average somewhat. The salary difference he commands is the the amount he bumps up the average.
Startups are more easily able to increase the concentration of 10x good developers, and that's where developers can make 10x+ money.
97 comments
[ 3.5 ms ] story [ 145 ms ] threadAlso 3 lines of APL are a very different beast to 3 (or even 300) lines of COBOL...
I think it's routine for me, and most anyone, to write a first version of a system over a week or two and keep noticing ways the design could be improved. Over time cruft accumulates--and you continue to notice new problems you didn't anticipate when you first designed--and almost always it is much quicker to rewrite a second version than the first.
The 3 lines of code per day metric seems fishy to me, but it seems to be based on systems level projects (lets build a new operating system) rather than making a new PHP photoalbum for Grandma. It would be very interesting to see numbers which broke down LOC/day for different subsets of programming jobs.
A "Complete rewrite" sounds hard, and like a big task, but usually it's a simple operation of copying existing functionality.
In my experience it's completely possible to spend 6 months writing version 1, and then completely rewrite it in a week.
I'll bet Netscape wished you worked for them in 1997.
He doesn't get to his real question until the last few paragraphs, which is why don't we see the same pay disparity with developers that we do with other professions? His answer is that measuring who's better is difficult and unreliable.
I admit I was confused, too; since he spends so much time on the issue of are some programmers orders of magnitude better than others, I thought that's what he was questioning. He doesn't get to his real question until the end, and then his answer is weak.
"It's not that good developers can churn out 10 times as many features as the bad ones. It's rather that good developers write code that have less bugs, more extensible and more maintainable. These are the things that you can't measure by statistics or figures."
I've given a few examples of good developers making systems that are orders of magnitude harder to complete, in the same time. In many cases it's not within the current talents of most programmers to write those systems at all. Another good example is the Quake engines. Additionally, in programming contests or student assignments there are many examples of people completing the same task in vastly different amounts of time. Finally, he states that reliability, buglessness, maintainability and extensibility are things you can measure with statistics, but many people have quantified uptime, maintenance, density-of-bugs, and extension time, to moderate success.
I find this sort of rhetoric honestly reeks of inexperience. Lines is a horrible metric for measuring productivity. Speed for finishing something isn't a particularly good metric either, since I've met a lot of hackers that can go on a coding binge (myself included) and accomplish as much in a weekend as they could in a couple of normal reasonably productive weeks.
"Comparisons between Ericsson-internal development projects indicate similar line/hour productivity, including all phases of software development, rather independently of which language (Erlang, PLEX, C, C++ or Java) was used. What differentiates the different languages then becomes source code volume."
Do you have a better metric? How about skill in solving tough algorithmic problems which haven't been before solved? Often on, for example, TopCoder, the top competitor can solve a set of three problems in 15 - 30 minutes. The median competitor, even in the upper division, solves zero. Some of the problems at only the 'medium-level' in those sets are in fact so difficult that they are given as two-week assignments in university courses, and only a fraction of students can complete it. This doesn't seem like a difference in reliability and bug count, it seems like a difference in kind in both algorithmic ability and productivity.
I think the only reasonable metric is someone's portfolio. You wouldn't pick an architect by how many nails they'd used or a musician by how many notes they'd written. You have to look at what they've actually done.
And in fact, that's pretty close to what good hiring is about. You then see if real performance matches up to what's in the portfolio.
For being on call at that time, I got a week's time in lieu and #500. For getting called, I got the same again. The fix was 10 lines of code, and the day after that I took it out and replaced it with a change to the original line.
Knowing what line of code: priceless :-)
I'm not trying to defend mediocre programmers here, but I think you've misinterpreted a study that intentionally combines individual productivity with organizational productivity.
* Unfortunately, I wasn't able to find the actual study report. If someone can locate it I'd appreciate it.
I don't know about that situation, but in general, rewriting a system is much easier than writing it in the first place.
It is not that the managers don't know that good developers are 10 times more productive than a bad one. Managers do know; some of them are developers or former developers.
and
It's not that good developers can churn out 10 times as many features as the bad ones. It's rather that good developers write code that have less bugs, more extensible and more maintainable. These are the things that you can't measure by statistics or figures.
What sets really productive people apart in my experience is architecture and domain vision. This is certainly the lesson in the Viaweb example. Without good architecture innovation consists of "feature creep". You've got a good thing when you find yourself with changes that simplify a code base or system while increasing its power.
I suspect this is why people who develop their own tools are often seen by others are great programmers, and why Eric Raymond's definition of a hacker is someone who builds their own tools. I'm a worse programmer than a lot of people, but am orders upon orders of magnitude faster than anyone else in my niche domain by virtue of knowing how to do things and leverage existing assets. I assume really good programmers are leveraging their expertise in other areas too.
If this is true, I'd argue that what keeps the good people from earning higher multiples is that architecture and vision don't matter in a lot of cases. Companies that innovate less have less need for development characterized by rapid innovation. Systems get developed by spec and implemented by indifferent teams. You budget for the features you want, not the flexibility you need. Innovation matters more to smaller companies, but even there non-technical individuals rarely see the architecture through the interface. Flexibility becomes conspicuous mostly by its absence, as development gets "over budget and behind schedule everywhere".
If you were one of these magical 10x producitity guys, would YOU hold out for the job offer with 10x the normal salary? Are you sitting at home, right now, by the phone?
Programmers have no power over the people who set pay rates while CEOs have a great deal of power.
Being in management gives you leverage. Being in a union gives you leverage. Being a replaceable widget -- even a gold-plated widget that is x10 better than the other widgets -- gives you no leverage.
I hope I've cleared things up for you. Now go out, throw away any Ayn Rand books that you own, and download something by Machiavelli. You'll learn a lot more about the way that capitalism really works.
Being in management gives you leverage. Being in a union gives you leverage.
I hadn't thought of this. Personally, I see programmers as workers that should be in small, elite groups, like surgeon wards. OTOH, surgeons have a cartel that programmers do not.
When a producer is negotiating a contract with Tom Cruise, I don't think it enters his mind how much unknown actors in community theater make. I think he's thinking about how many people bought tickets to see the last Tom Cruise movie and his estimate of how many of them went because of Tom Cruise.
I don't know enough about hairdressers to know whether the same thing applies to them. It does apply to fashion designers, and in some cases it seems to apply to programmers.
In most cases I suspect "brand" acts like a multiplyer so Apple's HDD might be worth 1.25 times as much as another just because of the reputation. IBM might be 30% better and have 2x the brand so they charge 2.6x what other consultant companies charge etc. Clearly major movies have great hairdressers but they don't get to charge 50,000x as much because a lower increase in value and a lower level of brand recognition.
PS: This get's confusing when considering something like breitling watches where a lot of the value comes from the price tag and not the physical watch. When someone knows you spent 250,000 on your watch they know you have money even if they can't see your car / house etc.
Perhaps what Rockstar Programmers need are Agents.
I met someone at a fencing club that was a programmer for a health care software company. He was my age, graduated a year earlier, and his salary was half what mine was (we were both on our first jobs out of college). I didn't know programmer salaries could go so low, for college grads. And his skillset was completely ghettoized - the company used a proprietary programming language and involved lots of domain specific knowledge. I suspect the difference was that I got my job through a friend of a friend that I'd met on the C2 Wiki, while he took the first available job he could find upon graduation, probably through Craigslist or Monster.
FogBugz developer?
Any line of reasoning that begins with "since I'm so good" and ends with "being here is suffering" sounds like there's probably some jackassery going on.
Honestly, a manager who was ok with him going home after one day would be stupid. Then he's giving them no additional benefit for his fabled skills, and their best developer wouldn't be there most of the time and the rest of the team would probably resent it.
Instead of the manager forcing him to sit at his desk for 40 hours a week, he should be giving this guy more autonomy. You don't keep good developers by squelching their abilities or freedom, they'll get fed up and leave.
But the really insightful one would let this guy try to find ways to make the whole group more productive or reduce its bug rate.
And why should his colleagues be any more jealous of him then they are of the CEO who makes tons more, or anyone else who gets paid more or works less for that matter?
There are 2 problems: 1) Having a clear way to measure productivity. 2) Stodgy ideas most manager's have about time spent, instead of production.
It's a problem because the company culture (probably) won't tolerate it, but instead will act to preserve itself at all costs, including the cost of reduced productivity. So when I said "obvious solution" I should perhaps have added "within the parameters of the existing culture".
I sympathize with your values, but the idea that you can change a corporate culture to make it recognize productivity in a more rational way is a fantasy. It's actually a harmful fantasy because it deceives many creative people into spending their time and energy on environments that will never fully recognize them.
To paraphrase what Max Born said about science, new models are accepted in the market not because companies change, but because old companies die.
Edit: Having a clear way to measure productivity wouldn't change a thing. If maximizing productivity were the value driving behavior, things would already be different even without a measure.
Actually they do: they can turn down an offer to work at any existing company and start their own instead. And many do. (That's how capitalism really works.)
thras was using it to refer to a role - a non-management role - and in that sense a programmer does have a lot less ability to influence the people who set pay rates.
You're using it to refer to an actual person who can try to change the role he occupies, in your example by starting a company.
When a company hires a CEO, they usually decide who they want first, and then they negotiate over price. There are few substitutes for their choice - usually, a company will find only a handful of candidates that are suitable for the position. This gives the CEO enormous leverage. There's only one of them, yet there are probably a couple companies that want to have them as CEO, so the price goes up.
Similarly, brand-name actors can drive moviegoers to theaters just by their name alone. There is only one Brad Pitt, but there are several movies that would love to have Brad Pitt star in them. Dakota Fanning gets like $4M/movie, because her name alone ensures the movie would get more attention than it otherwise would. David Beckham got a $250M contract, even though he's kinda washed up, because his reputation means people will watch.
An average programmer is filling a role, however. If they ask for too much money, the company just goes out and gets a different programmer. At hiring time, they don't know who'll be 10x more productive, unless that programmer already has a strong brand behind them.
I'm very curious to know how much "brand name" programmers like Peter Norvig or Guido van Rossum get paid. There are many Python programmers, but there is only one Guido, and many places that want him. I'm guessing I'll never find out, though.
BTW, this is behind a lot of the career advice that Internet celebrities give. Seth Godin's "you should throw away your resume" really means "your personal brand should be strong enough that employers want you and aren't just filling a position." Paul Graham's "work hard at things that excite you" is because if you do so, people will notice (eventually), and then they'll want you for what you've done and not just any old programmer. Marc Andreesen says "set the controls for the heart of sun" because that's the work that people notice, and that'll make you stand out from the crowd.
http://www.businessweek.com/magazine/content/05_05/b3918001_...
"For his part, Torvalds has been amply rewarded for his role, but he's no Bill Gates billionaire. OSDL pays him a salary of nearly $200,000. In addition, he sold initial public offering shares that he got as gifts from a couple of Linux companies, including VA Linux Systems. That helped him afford his house and put money away for his daughters' educations."
Anders Hejlsberg got a $3 million signing bonus from Microsoft when he left Borland.
http://delphi.about.com/od/delphifornet/a/conspiracydnet_2.h...
But as soon as you become an employee, earning a salary, you aren't selling directly to the end user, you are selling your skills to your company, which then produces a product that is used by the end user. Or worse still, you are selling your skills to a company that produces a tool that is sold to another company that is finally used to do something deemed useful by the end user. The longer that chain is, the less likely you are to get paid what you are worth if you are above average. Why? Because the entity that is buying your product doesn't actually care about the product, so if you have made it three times better than it would have been without you, don't care - just as long as it meets the minimum specification necessary to be able to sell it to the next person in the chain. On the other hand, if you are selling directly to the end user, they certainly appreciate the product that goes above and beyond minimum spec - insert Apple/Ferrari story here...
I can think of only one special case exception to this rule, and that is sports stars - and they are a special case because they are the only market where you actually have to beat the competition to be considered as performing. That means that there is a massive advantage in having someone on your team's payroll that is just slightly better than the other guy - you only have to be slightly better to win, and winner takes all.
Ditto for CEOs.
They treat the CEO well because he's their buddy.
1) The supply and demand of labor determines wages.
2) The factors that determine where you might lie on the demand curve for labor are: skill level, education, experience, reputation, etc.
3) The higher up the Demand curve, these factors become in shorter supply because it is hard to level up in real life. (MMO reference, sorry.)
4) The higher the demand of skills, experience, reputation, education, etc. >>> the lower the supply of labor will be >>> the higher wages will be.
Mediocre developers are short-term money losers, but some of them (the ones with curiosity and intelligence, whose mediocrity is a result of inexperience) will become great hackers, and thus, money-makers who, if treated well, will stick around for a salary much less than their value to their operation. Mediocre programmers are "overpaid" because this "call option" exists.
I think the author glances over too lightly the idea of good developers working for equity. A core part of the YC philosophy is that it is much easier to take a great hacker and teach them the business skills they need to succeed, than to take someone with business skills and make them a great hacker. (I'm basing this on something from one of pg's essays, sorry, can't remember which one at the moment.)
Based on the kind of output that the average YC team puts out during the program, a 10x multiple over the average corporate programmer's output during the same time is a reasonable estimate. Part of this is because, even if you have a corporate programmer capable of 10x more productivity than his peers, the processes surrounding him likely make it impossible for him to get that much work deployed in that amount of time.
And I think that is another important thing to consider. Corporations do not pay developers who are 10x as productive 10x as much because the way they develop and deploy software makes it impossible for them to realize a 10x productivity improvement, in any case.
EDIT: Just thought of a possible rebuttal I would like to address. You might compare this to the sports star, and point out that the star is not taking on the risk associated with getting paid in equity. However, an athlete's career is also an extremely high risk endeavor. Just as most startups fail, obviously the vast majority of athletes fail to make a lucrative career out of their athletic prowess. I would venture that the selectivity for an athlete looking for a lucrative contract is much higher than the selectivity for a hacker managing to start a lucrative business.
Even if they know you're 10x as productive as the other developers, they may not reward you so as not to make the other developers jealous or resentful.
1) Large companies don't yield the flexibility for top developers to produce 10X the value of the average.
2) Startups don't have the cash to pay 10X. However, I'll bet there are 10X equity differences.
Musicians are not paid proportionately to some independent measure of ability, but to sales.
So neither of those example support the contention.
The article says the difference is not that good devs produce 10 times as many features. But that contradicts the original research reference, ie. productivity.
Imagine a writer is contracted by Rolling Stone for 2,000 words on a rock band (ie., the plot for Almost Famous, vaguely autobiographical for Cameron Crowe). By the "10x more productive" argument, we'd be most impressed with a young journalist who comes back with a high quality story in less time and at a lower cost.
The real issue here, though, isn't the productivity - it's that if you give this assignment to 100 different writers, you'll end up with 100 different stories. Some will be great, some will be fine, some will be boring, some will be incomplete. But while deadlines are important, that's more of a baseline: you need to finish in time, and you need to write competently. Beyond that, as a publisher I'd worry a lot less about the writer's "productivity" and a lot more about the product itself.
So a top developer can be someone who gets a well defined project done much more quickly to a high standard, or a top developer can be someone who takes vague notions and emerges with incredible software within a reasonable timeframe and budget. While there's probably some overlap, one isn't necessarily good at the other (in fact, I'd guess there's a negative correlation, mainly because people who would be happy working under one set of circumstances would generally be very unhappy in the other).
Somewhat related, it does seem like a major factor in the importance of people's software accomplishments (measured economically or however) is the importance of the problem they were trying to solve. Build an easy-to-use web site builder for Microsoft Windows in 1994? Sell to AOL, retire to Switzerland at 35, spend your spare time mentoring the young, designing prosthetic limbs, writing new operating systems in Python, or whatever floats your boat. (Incidentally, to me, that seems like getting paid 10× as much as the average COBOL cubicle drone who retires at 65.) Build it for NeXTStep instead? Nobody will remember.
Hamming's "You and Your Research" makes this point about scientific accomplishments: working on great problems is a sine qua non of scientific greatness.
To tie back to your point, when someone has some vague notions about what they need done, the first thing you have to do to make incredible software for them is to figure out what they would think was "incredible" — that is, figure out which problems to solve, and which to postpone. Because if you get that wrong, all the rest of your work is more or less wasted.
As Hamming points out, it's not enough for the solution of a problem to be desirable; it also has to be feasible. That clearly involves some risk.
I've always performed better when I had wide latitude, but this is difficult to pull off in "the real world." In college and especially grad school, I could get out of all kinds of exams and assignments by suggesting a different project to a professor. They'd get interested and say "sure, do that instead."
Thing is, it really didn't cost them anything. Giving a student an "A" even though he didn't do the assigned homework is, of course, very different from cutting a programmer a check even though he didn't complete the assigned project.
In general, I'd figure employers are looking for the 10X productivity, whereas investors are looking for the creativity.
You have to live an edgier life to get to be creative. The closest thing I've heard in the corporate world is Google's 20% thing. There are other avenues as well: I worked a while at Sun, and I managed to get a couple of projects accepted well enough that they became my full time job.
[1] "more extensible and more maintainable" (long term) [2] "meets a date with sufficient functionality" (short term)
In either case, intolererable bugs make the contribution invalid. The stuff has to "work" for the cheque-writer's definition of "work".
A manager setting pay rates has less latitude than people might think. The perception of bean-counters and other upper-management is that programming talent is a commodity that does not vary as much as it truly does. Even if they were to pay a superstar (defined however you like) what they were worth (in term of the bottom line), then they get nervous about having too many of their eggs in one basket. e.g. "Uhhhmm ... how about you get me 4 mediocre programmers instead of that superstar so that if one leaves or gets sick I am still covered".
I can tell you that most managers are driven by item [2] above with mostly just lip-service being paid to [1].
The peers of developers are much more slanted to [1]. This is why open source can kick so much butt. Developers actually get to do the right long-term thing.
So, in practice, a superstar "date meeter" trumps a "extensibility maven" in a managers (i.e. his bosses) eyes nearly every time.
J. Random programmer who works at Do-No-Evil Geek-owned Company works on software that millions of normal people will use, but gets paid 40k, is much better off than J. Random programmer who works for Enterprise Software Factory who gets paid 40k and has to wear a tie and work in a cubicle on software 20 people may really give a crap about.
You will see the same skewed numbers at work in the video games industry, where employers know they can pay you barely anything for the right to wear whatever you want to work and work on something cool that people care about.
One of the characteristics of a bad programmers is that they will say they are "done" when in fact they aren't or the quality is so poor that the schedule will ultimately slip. Employers are bad at judging internal code quality or correlating bugs with bad programmers.
In fact, at my old company, they actually gave bonuses to people who fixed the most bugs -- usally their own. They ended up rewarding programmers who made lots of bugs versus people who had solid code. Fortunately, such a reverse incentive program ended.
http://en.wikipedia.org/wiki/Gresham%27s_law
It's hard for a company to realize the value from a 10x good developer, because their work is averaged with that of their 1x, 2x, 0.5x good teammates. Therefore the 10x good developer isn't worth much more than their more conventionally stellar 2x good colleagues; all he's doing is bumping up the average somewhat. The salary difference he commands is the the amount he bumps up the average.
Startups are more easily able to increase the concentration of 10x good developers, and that's where developers can make 10x+ money.