7 ms·

Why programmers are not paid in proportion to their productivity

114 points by imgabe 17y ago

tdavis 17y ago
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.
- diN0bot 17y ago
  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.
  - tdavis 17y ago
    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.
    - alnayyir 17y ago
      >I wasn't aware there was a "pitiful" tier. I don't know, I recall an (unnecessarily) hard-coded HTML form in a Django project with extremely poor input validation that somebody I knew wrote. It was a single field, single button form too, I might add. I refactored it with extreme prejudice.
      - tdavis 17y ago
        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.
- ballpark 17y ago
  I feel best when I'm deleting other's code, and accomplishing the same thing with much less code.
  - rpledge 17y ago
    100% agree with this, less code = less maintenance. Very few people truly understand this and why it's important.
    - SapphireSun 17y ago
      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.
    - alnayyir 17y ago
      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.
- litewulf 17y ago
  (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)
icefox 17y ago
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.
raganwald 17y ago
Show me how to measure productivity and I'll find a way for the 10x more productive programmer to earn 10x the compensation. I agree with the OP that the problem here is that it is not easy to measure productivity. http://github.com/raganwald/homoiconic/blob/master/2009-02-12/a_question.md http://github.com/raganwald/homoiconic/blob/master/2009-02-1...
- samuel 17y ago
  It's worse than that. There is a standard way of assesing programmers productivity and is the worst it could be: kLOC's.
  - raganwald 17y ago
    > 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.
  - wgj 17y ago
    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.
    - TeHCrAzY 17y ago
      We use stats like this to help us gauge the project as a whole, but its considerly likely to be useless for measuring individuals productivity etc.
  - nostrademons 17y ago
    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).
- 17y ago
kingkongreveng_ 17y ago
> The most productive programmers orders of magnitude more productive than average programmers This is often repeated, never meaningfully demonstrated. I doubt it is true if we are excluding unqualified programmers.
- DarkShikari 17y ago
  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.
  - btilly 17y ago
    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 http://answers.google.com/answers/threadview?id=183998 cites several other variations for comparison.
  - gruseom 17y ago
    It's a legend that's often told about Tesla as well: http://answers.google.com/answers/threadview?id=183998 http://answers.google.com/answers/threadview?id=183998 http://www.snopes.com/business/genius/where.asp http://www.snopes.com/business/genius/where.asp There's a really similar story about Picasso asked by a lady in a restaurant to draw a simple sketch on a napkin. He does and hands it to her saying, "That will be [X] thousand dollars". Shocked, she says: "But that only took you 30 seconds!" "Madam", says Picasso, "It took me thirty years."
RyanMcGreal 17y ago
From the comments: > I’d love to see some metrics on the average life expectancy of a line of code for different programmers. I know that some of my best code was written and has sat there with minimal changes ever since. Now that's an interesting idea.
- pyre 17y ago
  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.
  - patio11 17y ago
    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.
  - Periodic 17y ago
    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. There are plenty of enterprise systems like this.
- ShabbyDoo 17y ago
  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.
  - alnayyir 17y ago
    Buddy of mine just got done writing a CSV parser at work. Don't really know why though, I remember there being CSV parsers for C#/.NET out there.
ericb 17y ago
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?
- Zev 17y ago
  The number is from The Mythical Man Month by Fred Brooks, based on his experiences when developing IBM's OS/360. Beyond that, I can't really answer the rest of your questions; I haven't managed to sit down and read it yet.
- smokinn 17y ago
  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. http://pyre.third-bit.com/blog/archives/2910.html http://pyre.third-bit.com/blog/archives/2910.html Basically, he says that professional understanding of software is still in the lore stage where we gossip about what works and doesn't rather than empirical studies based on evidence. About this specific number though (the programmers are X times more productive) that's often repeated: To date, these studies have mostly been confined to academia. Most professional developers are vaguely aware of some of the results, but often get the details wrong. For example, hundreds of books, blog posts, and presentations claim that the best programmers are forty times better than the worst—or fifteen, or a hundred, or some other number. Almost none of the people repeating that claim realize that it originally came from a very small study (twelve people) run for a very short time (one afternoon) in an era of batch processing and punch cards.
  - dgabriel 17y ago
    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.
  - btilly 17y ago
    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.
ggruschow 17y ago
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.
- Poiesis 17y ago
  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.
  - Psyonic 17y ago
rdouble 17y ago
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.
- jey 17y ago
  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.
- n-named 17y ago
  Nullsoft was bought by AOL in June 1999 for US$80 million. [1] [1] http://en.wikipedia.org/wiki/Winamp#Winamp_2 http://en.wikipedia.org/wiki/Winamp#Winamp_2
  - sfk 17y ago
    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.
- mattm 17y ago
  How did he get that good?
  - nostrademons 17y ago
    One guess: practice?
clueless123 17y ago
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
- Tamerlin 17y ago
  That's completely true. 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.
motters 17y ago
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.
- DougBTX 17y ago
  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)
  - hvasishth 17y ago
    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.
    - oujheush 17y ago
      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.
boredguy8 17y ago
The bare truth is that productivity isn't defined, so it's not measured, so it's not rewarded algorithmically.
dusklight 17y ago
I think 10x is really not the right number. 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.
- Psyonic 17y ago
  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.
nick007 17y ago
what kind of salaried professionals do get paid based on productivity?
- DenisM 17y ago
  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.
  - mr_luc 17y ago
    Or any analogue of being paid for piece-work. I guess some salesmen would fall into this category, as it´s easy to measure their productivity.
  - Imprecate 17y ago
    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.
    - DenisM 17y ago
      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.
      - Imprecate 17y ago
        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.
meunierc 17y ago
From the article: > 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.
- zackattack 17y ago
  And this kind of hostility is why I left corporate america.
- DougBTX 17y ago
  I guess the magic happens when you found that company :-)
pxlpshr 17y ago
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...
umjames 17y ago
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.
tigerthink 17y ago
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?
- maddalab 17y ago
  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.
  - ahlatimer 17y ago
    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."
clofresh 17y ago
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.
trapper 17y ago
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 :)
stevedekorte 17y ago
Seems to be a retelling of The Parable of the Two Programmers: http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...

114 points by imgabe 17y ago

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.

diN0bot 17y ago
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.
- tdavis 17y ago
  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.
  - alnayyir 17y ago
    >I wasn't aware there was a "pitiful" tier. I don't know, I recall an (unnecessarily) hard-coded HTML form in a Django project with extremely poor input validation that somebody I knew wrote. It was a single field, single button form too, I might add. I refactored it with extreme prejudice.
    - tdavis 17y ago
      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.
ballpark 17y ago
I feel best when I'm deleting other's code, and accomplishing the same thing with much less code.
- rpledge 17y ago
  100% agree with this, less code = less maintenance. Very few people truly understand this and why it's important.
  - SapphireSun 17y ago
    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.
  - alnayyir 17y ago
    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.
litewulf 17y ago
(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)

icefox 17y ago

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.

raganwald 17y ago

Show me how to measure productivity and I'll find a way for the 10x more productive programmer to earn 10x the compensation. I agree with the OP that the problem here is that it is not easy to measure productivity. http://github.com/raganwald/homoiconic/blob/master/2009-02-12/a_question.md http://github.com/raganwald/homoiconic/blob/master/2009-02-1...

samuel 17y ago
It's worse than that. There is a standard way of assesing programmers productivity and is the worst it could be: kLOC's.
- raganwald 17y ago
  > 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.
- wgj 17y ago
  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.
  - TeHCrAzY 17y ago
    We use stats like this to help us gauge the project as a whole, but its considerly likely to be useless for measuring individuals productivity etc.
- nostrademons 17y ago
  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).
17y ago

kingkongreveng_ 17y ago

> The most productive programmers orders of magnitude more productive than average programmers This is often repeated, never meaningfully demonstrated. I doubt it is true if we are excluding unqualified programmers.

DarkShikari 17y ago
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.
- btilly 17y ago
  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 http://answers.google.com/answers/threadview?id=183998 cites several other variations for comparison.
- gruseom 17y ago
  It's a legend that's often told about Tesla as well: http://answers.google.com/answers/threadview?id=183998 http://answers.google.com/answers/threadview?id=183998 http://www.snopes.com/business/genius/where.asp http://www.snopes.com/business/genius/where.asp There's a really similar story about Picasso asked by a lady in a restaurant to draw a simple sketch on a napkin. He does and hands it to her saying, "That will be [X] thousand dollars". Shocked, she says: "But that only took you 30 seconds!" "Madam", says Picasso, "It took me thirty years."

RyanMcGreal 17y ago

From the comments: > I’d love to see some metrics on the average life expectancy of a line of code for different programmers. I know that some of my best code was written and has sat there with minimal changes ever since. Now that's an interesting idea.

pyre 17y ago
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.
- patio11 17y ago
  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.
- Periodic 17y ago
  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. There are plenty of enterprise systems like this.
ShabbyDoo 17y ago
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.
- alnayyir 17y ago
  Buddy of mine just got done writing a CSV parser at work. Don't really know why though, I remember there being CSV parsers for C#/.NET out there.

ericb 17y ago

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?

Zev 17y ago
The number is from The Mythical Man Month by Fred Brooks, based on his experiences when developing IBM's OS/360. Beyond that, I can't really answer the rest of your questions; I haven't managed to sit down and read it yet.
smokinn 17y ago
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. http://pyre.third-bit.com/blog/archives/2910.html http://pyre.third-bit.com/blog/archives/2910.html Basically, he says that professional understanding of software is still in the lore stage where we gossip about what works and doesn't rather than empirical studies based on evidence. About this specific number though (the programmers are X times more productive) that's often repeated: To date, these studies have mostly been confined to academia. Most professional developers are vaguely aware of some of the results, but often get the details wrong. For example, hundreds of books, blog posts, and presentations claim that the best programmers are forty times better than the worst—or fifteen, or a hundred, or some other number. Almost none of the people repeating that claim realize that it originally came from a very small study (twelve people) run for a very short time (one afternoon) in an era of batch processing and punch cards.
- dgabriel 17y ago
  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.
- btilly 17y ago
  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.

ggruschow 17y ago

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.

Poiesis 17y ago
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.
- Psyonic 17y ago

rdouble 17y ago

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.

jey 17y ago
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.
n-named 17y ago
Nullsoft was bought by AOL in June 1999 for US$80 million. [1] [1] http://en.wikipedia.org/wiki/Winamp#Winamp_2 http://en.wikipedia.org/wiki/Winamp#Winamp_2
- sfk 17y ago
  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.
mattm 17y ago
How did he get that good?
- nostrademons 17y ago
  One guess: practice?

clueless123 17y ago

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

Tamerlin 17y ago
That's completely true. 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.

motters 17y ago

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.

DougBTX 17y ago
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)
- hvasishth 17y ago
  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.
  - oujheush 17y ago
    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.

boredguy8 17y ago

The bare truth is that productivity isn't defined, so it's not measured, so it's not rewarded algorithmically.

dusklight 17y ago

I think 10x is really not the right number. 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.

Psyonic 17y ago
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.

nick007 17y ago

what kind of salaried professionals do get paid based on productivity?

DenisM 17y ago
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.
- mr_luc 17y ago
  Or any analogue of being paid for piece-work. I guess some salesmen would fall into this category, as it´s easy to measure their productivity.
- Imprecate 17y ago
  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.
  - DenisM 17y ago
    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.
    - Imprecate 17y ago
      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.

meunierc 17y ago

From the article: > 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.

zackattack 17y ago
And this kind of hostility is why I left corporate america.
DougBTX 17y ago
I guess the magic happens when you found that company :-)

pxlpshr 17y ago

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...

umjames 17y ago

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.

tigerthink 17y ago

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?

maddalab 17y ago
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.
- ahlatimer 17y ago
  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."

clofresh 17y ago

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.

trapper 17y ago

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 :)

stevedekorte 17y ago

Seems to be a retelling of The Parable of the Two Programmers: http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...