The most productive programmers are orders of magnitude more productive than average programmers. But salaries usually fall within a fairly small range in any company. Even across the entire profession, salaries don’t vary that much. If some programmers are 10x more productive than others, why aren’t they paid 10x as much?
Joel Spolsky gave a couple answers to this question in his most recent podcast. First, programmer productivity varies tremendously across the profession, but it may not vary so much within a given company. Someone who is 10x more productive than his colleagues is likely to leave, either to work with other very talented programmers or to start his own business. Second, extreme productivity may not be obvious. This post elaborates on this second reason.
How can someone be 10x more productive than his peers without being noticed? In some professions such a difference would be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. Sales are easy to measure, and some salesmen make orders of magnitude more money than others. If a bricklayer were 10x more productive than his peers this would be obvious too, but it doesn’t happen: the best bricklayers cannot lay 10x as much brick as average bricklayers. Software output cannot be measured as easily as dollars or bricks. The best programmers do not necessarily write 10x as many lines of code and they certainly do not work 10x longer hours.
Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on. It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.
The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”
That reminds me why Larry Wall say laziness is one of the most important virtues a programmer must have http://fwd4.me/9I6
Great post, the last paragraph sums it up so well!
The qualities of a good programmer also sounds like those of a good mathematician.
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 :-)
Productive programmers, by general rule, are those that love his job and feel real passion for it
Those, very rare, programmers think and feel that his job is so much fun, and think that are UNETHICAL charge too much for their work.
So, many talented programmers are exploited by companies and business clever guys.
Yet another reason to NEVER bill by the hour as a consultant. I’ve read and written extensively on the topic of Value-Based Fees in IT Consulting. Please have a look at my blog or forums for more info.
It’s a good habit to keep questioning yourself when you feel you’re doing a lot of work. Are you really getting a lot done or are you working hard on the wrong things? It’s easy to believe you’re being productive when you’re writing a lot of code and doing lots of commits. This false belief of productivity has a strong correlation with Not-Invented-Here thinking.
Actually, that is the case in many fields. The most talented policeman in the USA makes what… maybe two times or three times as much as the least talented one?
In research (or mathematics), the most talented researcher does not make much more than five times the salary of a post-doc. Yet, he can be a hundred times more productive.
The reason, I suspect, is that these fields are not money-bound. You do not become a researcher or a policeman for the money. (Or a blogger, for that matter.)
The claim that good programmers are X times better than average (where X varies widely depending on how dramatic the writer wants to be) is widely repeated, but there’s surprisingly little evidence (vs. anecdote) to back it up.
@Colin: most of my code in the last year has been erased. As it should be, since I was building prototypes to validate that the product would do what the customer wanted. Life expectancy of code would work well in more mature organizations though.
There have been a number of studies that support n-fold productivity differences.
The following citations are from Steve McConnell’s article: .
Sackman, H., W.J. Erikson, and E. E. Grant. 1968. “Exploratory Experimental Studies Comparing Online and Offline Programming Performance.” Communications of the ACM 11, no. 1 (January): 3-11.
Curtis, Bill. 1981. “Substantiating Programmer Variability.” Proceedings of the IEEE 69, no. 7: 846.
Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.
DeMarco, Tom, and Timothy Lister. 1985. “Programmer Performance and the Effects of the Workplace.” Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.
Curtis, Bill, et al. 1986. “Software Psychology: The Need for an Interdisciplinary Program.” Proceedings of the IEEE 74, no. 8: 1092-1106.
Card, David N. 1987. “A Software Technology Evaluation Program.” Information and Software Technology 29, no. 6 (July/August): 291-300.
Boehm, Barry W., and Philip N. Papaccio. 1988. “Understanding and Controlling Software Costs.” IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.
Valett, J., and F. E. McGarry. 1989. “A Summary of Software Measurement Experiences in the Software Engineering Laboratory.” Journal of Systems and Software 9, no. 2 (February): 137-48.
Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.
As other people say, no exists a metric to measure productive programmers.
I think that we can have an approach, not by lines-of-code-hours-spend metrics, but “value” of your code
1) How much business value add your work to your company. (Competitive advantage, research and innovation capabilities, focus on right technologies, avoid buzzwords vendors locking. strategic decision support, new products ).
2) How much is the cost of maintain your code in the future. (Some heroic solutions will cost many bucks in the long turn, also bad code is a shoot in the foot for any business (By personal experience I saw business that go to bankrupt for BIG projects poorly executed by bad programmers))
Like this could be more examples, So I think that is possible (but not easy) measure productive programmers
Wow. Great post. Ever read “The Art of War”? Swap around a few of your nouns and this article is straight from Sun Tzu. He says that the best generals aren’t the ones who win great battles; rather they win the easy battles. They choose the times and places to fight that are most advantageous, they wait until their enemy is weak. So really, the best generals appear to do nothing at all except have an occasional easy victory.
As someone who is both a brick mason and a computer programmer i couldn’t help but notice the statement :
Actually it is possible for a really talented mason to be 10x as productive as another mason but it rather stupid of a mason to lay brick or block like that. For one thing if you are working for a masonry contractor , in my experience, you are not going to be paid anymore than any other mason. And two even if you are working for yourself throwing brick or block around like that is going to destroy your health and probably hurt you so bad you are not going to work for a couple of days after your day of heroic masonry.
You should make your “Good Idea!” part into an hyperlink to http://xkcd.com/664/
Just like to argue from another view point. I’ve a big advantage, that the job I’m doing is fun for me, and I get enough money, that I am able to live. I see no reason why anyone that is slower than me, shouldn’t get as much money, and I see no reason why a cleaner, which has an awfull job compared to mine, shouldn’t get as much money. I believe that there is not a single book out there that says: “I’ve you have enough money, you are happier if you get more money”.
Great post, and so true. I won’t claim to be the best at what I do, in fact, I’m far from it. But I do think I’m better than a lot of my co-workers. And maybe that just means I work harder in terms of never taking the easy way out, writing tests, and doing things right. It gets noticed to some extent, but not necessarily rewarded. And *that* is very, very frustrating. I don’t mind teaching on influencing people, I actually like it. But I’d like to work in a place where I’m the one learning and being influenced by those better than me. I think that’s a lot of what talented programmers move on to do bigger and better things.
I thought this was only going on at our company :)
The statement that a good programmer ( or engineer ) is one who loves his work ( @Mario Arias ) and therefore has moral objections to charging a lot for his work certainly has some truth. It applies to a lot of people in my company, to an extent that you almost feel shame for a world where these ultra productive people, the ones who generate the added value, are treated like little children when payday arrives.
And where stagnant, less-than-mediocre, byte punchers are valued almost as much as their talented counterparts. To me it’s corporate communism at its best.
But I do know of a different kind of good programmer, one that has a mean streak, and looks only after himself. Guys that want to be little kings in their own domain and as soon as they are forced to share knowledge, they start looking for other, better paid, jobs. That’s the kind of programmer that I hate to work with.
I guess everybody needs to make up his own mind about whether he thinks he earns enough for the job he is doing.
One question you need to ask yourself : do I want – not even like – to get up in the morning and go to work, or would I rather close my eyes and wish it would all go away like a bad dream?
I’d say that the best programmer is the one that chooses the right tool for the problem.
“I’ve seen this before” is as dangerous as typing “vim solution.c”. To choose the right tool is as good as to type the “magic code lines” that will make your day.
I liked most this sentence:
Programmers are most effective when they avoid writing code.
If something takes me 15 minutes to accomplish with quality and the same work takes someone else 3 hours, should we be paid the same for the work? Yes, indeed, we should. But this breaks down for a regular full-time job where the need for this kind of efficiency waxes and wanes.
This concept applies to other areas of business as well but because of both the testable nature of programming and the power of the program, it’s far more noticeable here.
The best the programmer can do is to find a relevant niche job. If you work for yourself (as I do), there’s a balance you have to find between pay rate and regular work. I have two customers – one hands me the work (nearly full time), and the other is an as-needed basis where I had to cultivate the lead into being a customer. As you might guess, customer one pays considerably less per hour than customer two.
I agree with Greg Wilson: How can you call someone more productive by factor X if you have no metrics? The whole point of “productivity by factor X” is to measure some kind of performance over time in a quantified way, so you can count “productivity points” and compare them. No metrics, no comparison, no salary raise.
I like the “pattern recgnition” approach of the last paragraph very much, though. Not for productive developers, but for good developers. No sharp definition there, either. :)
The claim that good programmers are X times better than average (where X varies widely depending on how dramatic the writer wants to be) is widely repeated, but there’s surprisingly little evidence (vs. anecdote) to back it up
I think it stands to reason that with time , comes change, and if you change with the times, you will always have plenty of work, and if you keep on top of your field, you will also know most of the hidden tools that make most uber coders quicker, and more efficient, nothing like writing a proper unit testing dll side by side with your app from the beginning, instead of after the fact. Such a small little thing that I have seen many forget until the end, and waste twice as much time writing it. Of course this comes from experience, but even in school this should be at the very least, mentioned right away instead of on the job.
Managers prefer to measure effort.
Measuring the complexity of the task and the achieved results is just too much effort for them.
Managers prefer to measure effort.
Measuring the complexity of the task, and the achieved results is just too much effort.
Personally, I think more senior or ‘productive’ programmers have additional responsibilities that should be measured beyond the standard ‘lines of code’ or ‘projects finished’ or ‘percent of code developer tested.’
A productive programer, especially one labeled as senior, should be responsible for raising the productivity of the other programmers around them. If you’re 10x as productive as those around you, you’ll provide far more value to the tripling the productivity of others on your team than you will by improving your productivity by some percentage.
From the ‘value’ perspective, it’s all about the product, which comes from the productivity of the team, rather than individual productivity.
I’ve seen many times a supposed rockstar programer using the work produced by their peers to be seen as highly productive. Not through stealing the work, but by being the one communicating about the work. Perceived productivity is often about politics, not code.
Is a corporate CEO making 100,000 times the salary of us programmers 100,000 times as productive as us? No, they’ve simply found themselves in a position of leading a large number of folk who provide a great deal of productivity.
Often, from what I’ve observed, people do find themselves in support roles. They end up doing ‘setup’ or ‘build’ work. They do some systems integration. It’s work that needs to be done and is critical to productizing a technology. However, those working on the core technology often get the credit.
It’s darn hard to judge the productivity and value of individual contributors. Darn hard.
They’re not factories, they’re artists. We’re using the wrong model.
I have observed that really talented programmers have their worked dismissed by the average as being “obviously easy, not as hard as the stuff I do”. The business/managers simply don’t notice good work because stuff that just works is under their radar. The stuff that fails spectacularly and needs lots of heroic action to fix is noticed and, bizarrely, rewarded!
Often programmers are productive/not productive in ways that have little or nothing to do with constructing software. Answer phone calls, emails, meetings. Often they have little control over their work environment (no walls, lousy chairs, etc.). Should their pay be related to their theoretical productivity? Ignore the non-construction requirements? How do you even measure such things without inordinate cost.
People based overall performance evaluations are not provably inferior to any metrics based analysis. Not to say metrics have no place, but people & communication skills are often just as important.
In reality, It is kind of like the stock market, people pay programmers based on expected future performance. Past performance is no guarantee of future performance. At least on the stock market, I have useful & reliable metrics — for programmers, good luck, it is exceedingly difficult to evaluate performance.
I believe there have been studies that quantify the “10x” figure using computer science students. But in any case, you don’t need a randomized study to tell you that some programmers are far more productive than others. I’ve seen this over and over, and I imagine so has nearly everybody with a few years experience. When anecdotal evidence is strong enough, you don’t need randomized studies. There haven’t been any randomized studies that prove that using a parachute increases your chances of survival when jumping out of an airplane.
You could argue that there are hundreds of reasons why some people produce more productive and that it’s not a matter of inborn talent. That’s plausible. But the fact remains that for whatever reasons, some people are far more productive.
You could even argue that some programmers are infinitely more productive than others. There are some projects that a great programmer can finish that a team of mediocre programmers will never finish no matter how much time they have.
Update: I wrote my comment before I saw Ryan Mentzer’s comment above. See his comment for a list of studies attempting to quantify the variation in programmer ability. These look like great studies. Still, I find the anecdotal evidence more compelling. The real world is filled with precisely the complications that controlled studies attempt to eliminate. I think it’s the ability to handle these complications that distinguish the best programmers.
Um you have missed a few points
1 90% or more of programmers are not hourly paid
2 what you pay for a given job is not some god given absolute, luck, being in the right place at the right time, having rare skills etc
one example in an early web project for BT I and another developer built a system in 28 days that another group had quoted 2 years for.
those 28 days probaly was of more value to the company that the rest of th15 years i spent working for BT
Even if companies are ran by ex-developers, it is often hard to realize what benefit to the company that 10x productivity is. Some say ‘duct-tape’ programmers are better for the industry, then those that are necessarily good at new cool technologies and are productive in some vector with them.
You view “productivity” in terms of producing a solution to the problem; but overall software costs are dominated by testing, debugging, maintenance and usability. It’s hard to know whether the “most productive” programmer actually produces code that is best on all those other criteria.
Mike, I agree that there’s more to productivity than just coding. As you said, testing, maintenance, etc. I make a similar argument here.
If anyone needs quantitative proof, check out Top Coder, which runs timed programming contests. It’s a great place to practice coding and can be awfully humbling.
The range isn’t 10 times, it’s infinite. If you look at the Level Three problems in Division II of the Top Coder algorithms contest, the winners do them in 10 minutes and most programmers couldn’t solve them even if given a week, much less in the 1.5 hours allocated to the contests.
PS Congrats on the /.-ing.
Bob, you’re missing the point. Programming skill has nothing to do with problem solving ability, which is what clients (and employers) pay for. Yes, efficiency is important too, but not as important.
“I believe that there is not a single book out there that says: “I’ve you have enough money, you are happier if you get more money”.”
Well, isn’t this the American Dream as sold to us?
A more interesting question is “Why do programmers, who are ten time more productive, willing to work for so little?”
Your question reminds me of when I used to work in academia. We had a group of programmers that constantly complained about how they could be making more in the private sector (which was true). My response to them was to go work in the private sector. Yet they never did. It seems that the perqs of working in academia (regular hours, great benefits, interesting work) were actually worth quite a bit.
I suspect that part of the reason some “super” programmers are willing to work for so little is that maybe they really are not x10 more productive every working hour of every work day. Also, going out on your own is a huge amount of work and risk. It involves dealing with customers, selling, managing, etc… It’s a lot easier to just sit back and complain how about how no one appreciates your brilliance and how much you are underpaid.
Think smarter, don’t work harder
Productivity helps in other ways. In my organization, there’s no way I’d get paid twice as much as other programmers. However, while other programmers are complaining about how much they have to do, I’m kicking back, studying new technologies, knocking out some code now and then, and still keeping everyone happy.
How? Lots of code generation and re-use. Building tools that can make things easier for me later. Keeping the code simple, elegant, and general. And lately, using Vim. Being able to turn my ideas into code quickly helps maintain the flow.
Open source. Good programmers will work for nothing but the joy of programming. That’s why good programmers aren’t paid 10x because you don’t have to.
Productivity does not matter so much in a full time salaried development job. What does it matter if it takes you 10 minutes and some other guy 3 hours if the deadline is next week and both of you make that date? Devotion to getting the work done properly given a fair timeline is what matters.
If you see IT as a service (and that’s, in my opinion, the only sane way), you come to the conclusion that you where productive if you solved a problem, and unproductive when you didn’t. (It’s a bit a hind sight thing.)
You might argue that the quality of the code might be important. Not so. Nor is the quality of your solution of any concern, as long as the problem is solved (now and in foreseeable future). *That*, however, is the hard part, as we know: Software engineers aren’t trained to use technology X or language Y, they are trained to solve problems. Or should be. (You can learn any technology or language later, and you have to the rest of your life.)
But problem solving as productivity measurement this is a qualitative approach, not a strictly quantitative. You can hardly count solved problems, and your efficiency to solve problems depends not only on general training, but on experience and specialization. Learning and adaption capabilities can help transferring experience across domains (the “pattern recognition” from the beginning I like so much), but that is qualitative, too.
Bottom line: Yes, some people are obviously more productive than others. But this is because the learn quicker, see connections, relate with co-workers, and are generally more comfortable with the problem at hand. Soft-skills, hard to measure, hard to predict. Then again, awesome good coders with or without a suitecase full of expensive certificates might be completely unproductive, because the project cannot “utilize” their skills or they got the wrong tasks assigned.
Whoever said, “you don’t get what you deserve, you get what you negotiate”, nailed it — for human life in general, not just programming.
It doesn’t help that a lot of people in software development, and in particular, project managers and self-styled software engineers, think programming is a form of manufacturing. In reality, program source code is the design for an abstract machine that can be replicated automatically and essentially effortlessly, and programmers are designers (albeit at the lowest level of abstraction), not assemblers of software.
Believing the manufacturing fallacy leads into a cascade of others: a) programming isn’t particularly skilled; b) therefore, programmers are interchangeable parts; c) the more, the faster; d) all problems can be solved through sufficiently-detailed, ‘painting-by-numbers’ procedures. Fred Brooks, amongst others, has eloquently demolished many of these fallacies, but there are none so blind as those who can’t understand what they see.
I used the term ‘self-styled’ with regard to software engineering, because the discipline seems to have adopted this fallacy as its creed. Compare it to the rigor and professionalism of electrical engineering and weep.
So, here’s an idea for smart programmers – when they are given a task, insist that the same task be given to one of their average colleagues too. Do this for a month or two. Tell the company that they will be pay for that average colleague’s salary for those two months out of their pocket. At the end of the period, measure the time taken by both to complete their respective tasks. If the smart programmer did it 5 times faster than the average guy, then demand a salary 5 times that of his colleague’s.
This is why freelancing can be great :oD
If you’re a 100x programmer, you can make 5x what you do as a normal office drone with 1/10th the work.
The low point of my career was working was an hourly paid contractor at IBM in the mid-90s leaving at 3.36pm every day because I’d finished my largely defect free work, while realizing that some bozo at the next desk was there until 9pm slaving over the debugger and earning almost 2x as much as me as a direct result of his poor initial quality. Had I not gone to Singapore and met Jeff De Luca and Peter Coad in 1997, I would have quit the industry entirely before the decade was out.
Another issue is “what kind of programming”. I’ve seen close-to-the-money IT programmers being grossly overpaid because they can whip up a GUI in Oracle in a day. The close-to-the-meta programmer who spends a month sweating out some assembly code that makes the device “beep” is unappreciated. I don’t know a solution to this problem except have managers that understand the work!
To: ARaybould
You left a great post, however, you fail to mention that your “professional” and “rigorous” electrical engineers don’t get paid shit either.
Fix the first sentence of the article…. How does that happen?
Too me, coding is an art and requires concentration. I can’t work 9 – 5, my mind doesn’t work that way. It works when it wants, and when I feel inspired I go to work and produce some of my best work that way. When I was forced to into the 9 – 5 stigma, my productivity reflected this. I would show up late often, day dream at work, doze off, take long lunches, but I would also do a lot of work at home and sometimes when I was inspired at work, which more than made up for it. I still met all my deadlines, which some were just ridiculous seeing as how I was the only coder and tester and designer all in one, plus I had other duties such as client support. Yet, I still managed to meet every single deadline and usually with a few extra perks added in by me to make the software more usable or faster or whatever. Sometimes I would be up all night coding because I just got inspired and couldn’t stop, next thing I know the sun is coming up. But my boss paid me a salary and expected me to still adhere strictly to the schedule as well as work at home if needed to meet a deadline, but he didn’t want to pay me extra when I did.
Now, I am a partner of a business, he is the face of the company and I am the brains. I am able to work when I want, where I want and all my bills are paid and I have no worries. And if I need extra money, I just have to ask for it, especially if an important client suddenly drops a ridiculous deadline on us and I somehow manage to pull it off. I make sure he knows how much it’ll affect me and the other work we have going on and he makes sure too take care of me and keep me happy. He recognizes how important my work is, and how important it is for me to be relaxed and free to do the work when my mind is most productive, not when society says I should be doing it.