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 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.”
Related posts:
Writes large correct programs
Experienced programmers and lines of code
{ 16 trackbacks }
{ 88 comments… read them below or add one }
Omar Gómez 12.23.09 at 08:45
That reminds me why Larry Wall say laziness is one of the most important virtues a programmer must have http://fwd4.me/9I6
Martijn Verburg 12.23.09 at 08:50
Great post, the last paragraph sums it up so well!
Lucas 12.23.09 at 08:58
The qualities of a good programmer also sounds like those of a good mathematician.
Colin Howe 12.23.09 at 08:59
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
Mario Arias 12.23.09 at 09:36
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.
Mark Richman 12.23.09 at 10:21
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.
Ville Laurikari 12.23.09 at 10:56
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.
Daniel Lemire 12.23.09 at 11:26
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.)
Greg Wilson 12.23.09 at 11:38
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.
Daniel Haran 12.23.09 at 11:48
@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.
Ryan Mentzer 12.23.09 at 12:06
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.
Mario Arias 12.23.09 at 12:13
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
Bri 12.23.09 at 12:22
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.
Starhawk Laughingsun 12.23.09 at 12:24
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.
Virgil Dupras 12.23.09 at 12:39
You should make your “Good Idea!” part into an hyperlink to http://xkcd.com/664/
azraiyl 12.23.09 at 13:25
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”.
Ryan Heath 12.23.09 at 13:51
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.
KristofU 12.23.09 at 14:22
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?
graffic 12.23.09 at 14:27
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.
hln 12.23.09 at 14:47
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.
Till Salzer 12.23.09 at 15:01
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.
l a 12.23.09 at 15:13
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.
Hans Moleman 12.23.09 at 15:23
Managers prefer to measure effort.
Measuring the complexity of the task and the achieved results is just too much effort for them.
Hans Moleman 12.23.09 at 15:25
Managers prefer to measure effort.
Measuring the complexity of the task, and the achieved results is just too much effort.
Roxie 12.23.09 at 15:43
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.
Daniel Davis 12.23.09 at 15:46
They’re not factories, they’re artists. We’re using the wrong model.
Channing Walton 12.23.09 at 15:47
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!
Gary 12.23.09 at 15:47
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.
John 12.23.09 at 16:01
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.
Maurice 12.23.09 at 16:02
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
Pavel Zaitsev 12.23.09 at 16:06
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.
Mike 12.23.09 at 16:14
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.
John 12.23.09 at 16:20
Mike, I agree that there’s more to productivity than just coding. As you said, testing, maintenance, etc. I make a similar argument here.
Bob Carpenter 12.23.09 at 16:34
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.
Mark Richman 12.23.09 at 16:39
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.
dave9 12.23.09 at 16:44
“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?
Steve 12.23.09 at 17:54
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.
Tom Warner 12.23.09 at 17:56
Think smarter, don’t work harder
Jurg 12.23.09 at 18:33
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.
peter john 12.23.09 at 18:34
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.
Mike 12.23.09 at 18:41
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.
Till Salzer 12.23.09 at 19:35
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.
ARaybould 12.23.09 at 19:36
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.
Mohan 12.23.09 at 20:52
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.
Michael Langford 12.23.09 at 22:09
This is why freelancing can be great
D
If you’re a 100x programmer, you can make 5x what you do as a normal office drone with 1/10th the work.
David J Anderson 12.23.09 at 23:28
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.
David Minor 12.23.09 at 23:45
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!
Zach 12.24.09 at 00:17
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.
Dom 12.24.09 at 00:47
Fix the first sentence of the article…. How does that happen?
FireStorm69 12.24.09 at 00:53
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.
M Beltrán 12.24.09 at 01:27
Me and my workmates have talked about this issue a lot of times and always have reached the same conclussion : We all should had obtained another degree, instead one IT-based.
Regardless the company you look at, you’ll find that other professionals are more appreciated and best paid that the ones at IT, so I won’t loose my faith in trying to find a completely different job …
Peter Michaux 12.24.09 at 02:17
The framing of the question “why aren’t programmers who are 10x more productive paid 10x more?” seems to imply that the expectation is there should be a linear relationship. Why is that expectation even there? When a waitress is 10x better do you leave a 100% or 150% tip? Probably not. Maybe you bump the tip up to 25%? I think there is a logarithm involved somewhere in the relationship.
dude 12.24.09 at 03:02
I believe that it’s all about supply and demand. Someone who produces 10x as many hamburgers even though there is only a market for 2 hamburgers is still only going to sell 2 hamburgers. The best he can do is just surf the web for the other 8/10 of his day or spend it learning something new and fun. I completely believe that the rare individual can be 10x more productive, but those individuals are far and between; though most programmers see themselves as special they fail to recognize the mediocrity of their existence.
Pierre 12.24.09 at 03:27
How to recognize Uber-coders is easy:
They make programs that are safer, faster, smaller and more reliable than any other similar program made in the past.
And, there is a price to pay for this: as their peers will notice the feat before managers or end-users, the Uber-coder will be the target of politics and be promptly fired.
As a result, Uber-coders end as solitary creatures (in their field) and become even more Uber as they choose what they are working on.
Now the interesting part starts: the return of the Uber-coder might simply disqualify the work of many of its (so willing to compromize with facts) peers simply because WE ALL BECOME WHAT WE DO.
Cheat and you will become a decent cheater.
Code like if your live depends on it and you will become rather good at doing it.
Jonathan 12.24.09 at 03:43
This is the same issue many sysadmin faces.
A good sysadmin makes it look easy, no on notices the changes.
Everyone keeps on going as tho nothing has changed.
I feel the pain…
JB 12.24.09 at 04:37
I think you highlight the most important aspect here which is that we cannot measure productivity. That said, I think there is always a general feeling of who is contributing more, and how that contribution is made. Doesn’t it then become a question of quality versus quantity? How much quality has a developer added not just to the product itself, but to the entire process of making it?
Davor Magdic 12.24.09 at 05:00
Somebody commented that being good in avoiding unnecessary work isn’t rewarded. That’s not true. I consider myself quite good at writing as little code as possible, and at the company where I worked I had respect of senior developers and I was also given a complete freedom when to work and even when and whether to show up at work at all. I usually worked less than 40 hrs a week, sometimes much less, and kept the quality of work. That was a great reward in itself, and I was still getting (slightly) above average salary increases.
To put it differently, with good management the reward may be not money but time.
Till Salzer 12.24.09 at 05:33
JB, thank you very much. I’m clumsy with words, your link to sums it up nicely. And I agree: There’s always a gut feeling who is more important, not just among developers, but across the whole organization. But you can’t really answer that in a single line (which is covered in the linked article as well).
Rick 12.24.09 at 11:02
Code I wrote in ‘92 and maintained for fifteen years is still being used around the world. One key is keeping the original authors around because new programmers will always insist on re-invention.
Greg Wilson 12.24.09 at 11:09
@Ryan/11 Thanks for posting the links — but how closely have you read those studies? Sackman et al is very small N (a dozen people), very short T (an afternoon), and undefined metrics; Curtis’s is larger N but shorter T (not much more than an hour, if I recall correctly), and so on. The only two that would pass muster today are Valett & McGarry and DeMarco & Lister (and even the latter would probably be bounced if submitted today).
@John/29 I agree that there are very large differences in productivity among professional programmers, but I don’t agree that when anecdotal evidence is strong enough you don’t need studies — my late aunt’s faith in crystal healing is just one example
I’m also not (necessarily) arguing in favor of randomized double-blind trials: lots of other techniques can be used (see recent ICSE proceedings for a sampling).
@Everyone else: yeah, the biggest problem is that we just don’t know how to measure the productivity of programmers. Health authorities have the same problem with doctors, and friends of mine who are still engineers complain about this as well. So let’s turn it around: does anyone know of a knowledge-based profession that does have good measures of productivity?
cvsdave 12.24.09 at 11:16
Well, conventional wisdom…
My personal experience as a software engineer:
1. Pay varies all over the place. There is not a narrow range. (But it doesn’t necessarily vary by skill or ability)
2. Productivity? Is an engineer who routinely writes undocumented, uncommented non-reusable highly-coupled code more productive than one who engineers a quality product that solves the same problem and takes longer?
3. I have yet to see a good measure of productivity. I do know some engineers who are frequently consulted by others with tough problems, time which does not fit into most accounting systems, and slows them down.
4. I’m sorry. I think that we would all like to believe that we are “10x more productive” and not adequately compensated. That is human nature. How many, however, do you find that say “now X, he’s 10 times as productive as I am… But how many times do you think “this was really thrown together in a hurry…”
5. I always enjoyed the movie “How To Succeed in Business Without Really Trying”. Our craft is like so many others and not like any other. I have met many poorly trained, poorly equipped developers trying as hard as they could, and many knowledgeable well-equipped coasting along with the minimum possible effort.
6. I love this. I love being able to do this as a job. I make terrible mistakes, and I find elegant solutions. I can accept almost anything in coworkers other than the arrogance that is unwilling to help the less adept. I think a basic skill is the ability to help coworkers become better and more productive engineers. I guess this is why I find the “10 times as productive” discussion disappointing. I do believe in continuous profession improvement. (<- I think this may be what a process joke looks like)
the heretic 12.24.09 at 11:45
I don’t think taking advantage of reuse (whether your code or someone else’s) is an example of a developer being 10x more productive that average. Ditto with recognizing a pattern and reusing a solution. I consider that to be average development productivity. It is when there is a difficult problem, that is not easily solved by such reuse, is solved 10x quicker by a dev (in a sustainable and quality manner) that I would say this person is 10x more productive – yes, even if it is just one line of code (the task and and solution is the goal, not lines of code). In my experience, even when I have worked with some particularly bright devs (much brighter than me – I consider myself average or slightly above), I don’t see such productivity that often – although it is not rare either.
Those more productive devs do make more than I do and rightly so. A major part of why they make more is that they can show on their resume (and with references) that they can solve the problems that employers have better and faster than I can. I aspire to be more productive every day, in part by learning technology that is in demand, in part by improving my problem solving skills.
Unfortunately I have encountered too many examples of devs ignoring reuse (both reusing and creating reusable code), ignoring the need to write sustainable code, the need to write quality code. I see way too much cut and paste code. I see this code from devs that are ‘10x more productive’, from average devs, and especially from below average devs. The really tough part is when your boss does it; how do you tell your boss that you have seen better code from a first year intern??!
Which brings me to value – if your lead/manager/etc. doesn’t know how to create value, doesn’t know value when he/she sees it, how can they evaluate your contribution? Generally they can’t – then you are in trouble.
As for why devs make more than someone who cleans toilets; well, anybody off the street can clean a toilet, not everyone can write a scalable server process. It is all about supply and demand.
Kerem 12.24.09 at 12:21
Laziness is the way to go!
brian 12.24.09 at 12:34
The reason is because they can. Its ONLY about free market economics. Businesses want to get the most value for the least price… just like everyone else. Salespeople have to get big margins because that’s what keeps them happy and provides an incentive to find more customers. Sales is also the only department that actually *makes* money for the business. IT depts DO add value, but direct incoming cash flow is the most important thing for any business.
IT an especially programmers seem to overthink this too much. The business does not think about it that much and just does what the market forces drive it to do.
John 12.24.09 at 12:43
Brian, I agree that ultimately this is about market economics, and a lot of programmers focus on technical matters to the exclusion of economics. But I also think that businesses don’t necessarily act in their own best interests. They would do well to improve their ability to evaluate talent.
Michiel van der Blonk 12.24.09 at 13:39
If the business would be paying based on the number of defects found (less=more money, or pay a fine for each defect), then the whole business would drastically transform itself. It’s nice to be able to crunch out so-so code that does it’s job so-so, and then polish it a bit, and then later come back in to fix things, all paid by the hour. This makes it easy for an hourly based worker, and the manager doesn’t understand anyway what is going on. The defect are seen as an accepted part of the job, because it happens everywhere. Read Clean Code by Robert C. Martin. It is enlightening. And of course we should then also reject faulty specifications to start with. “I want it to be social” is just not specific enough. Otherwise how can you say it’s defective at all?
Grant 12.24.09 at 14:02
I want to marry this article.
Grant 12.24.09 at 14:23
That “10x more productive” person has numerous distinguishing characteristics — “think more, code less”, for instance, and many benefits are gained from that.
S/he may also incrementally improve application architecture, so that future development gets a permanent cost savings. (Or even make new functionality feasible where it wasn’t.) Because it’s done incrementally, the effort is unlikely to get recognized except maybe by one’s peers. I wish a little more attention were given to these accomplishments.
It’s very hard for some geeks to spend the time to document and quantify each improvement; it’s time you’re not coding!
philip andrew 12.24.09 at 21:31
I was three times more productive than my peers, and caused about two times as many problems in terms of bugs.
Because of the increase in bugs, I was singled out as a problem and got a bad review. After working late every night to 9pm.
Life is sometimes insane.
SMiGL 12.25.09 at 02:29
Good article! Thanks!
David Minor 12.25.09 at 02:42
Anyone know how I can take myself OFF the email notification list for this blog. (No offense, great comments, it’s just flooding my email a bit too much).
Till Salzer 12.25.09 at 05:39
@Philip Andrew: I hope you’re joking. If not, try to think about the meaning of “productivity”. Sorry if I got you wrong.
@Davi Minor: Try the link at the bottom of this page to “manage your subscriptions”.
I feel the discussion moves in the direction of “why am I better than …” and “how to build better software”, which diverges from the original question.
howtolearneverything 12.25.09 at 17:20
But how do you compare productivity for a programmer
And his reward is long term: his probability to get fired is lower.
And economically that isn’t just possible to get paid ten times more than other.
Avatar 12.26.09 at 03:15
This all underscores the difference between getting a job done and expending effort: programming is an activity where the former is far from equaling the latter, and why a concept like ‘productivity’, is so hard to measure when applied to programming (though you probably know it when you see it)…
Are mediocre programmers to great programmers as a person cutting marble is to a fine marble sculptor?
Michiel van der Blonk 12.26.09 at 06:17
@howtolearneverything
Of course it’s economically possible to get paid 10 times more, if you’re 10 times more productive you add 10 times more value to a company. If the productive person is not getting paid 10 times more then someone else is getting rich by squeezing a talented person. But because people do not understand this value or cannot measure it, it doesn’t work out. Compare it with artists: a concert ticket for Michael Jackson, Madonna could easily be 10 times what you pay for a performance of Band X. The customers understand the value and pay for it (no need to measure it by the way).
Mark Richman 12.26.09 at 10:59
Face it, you’re never going to get rich (or anywhere close) working for someone else. If you want to get paid for your true value, then do consulting work. Make sure you NEVER BILL BY THE HOUR!.
Clients buy results and value, not your time. Read more on how to do this over at my blog series on Value-Based Fees in IT Consulting.
Doug 12.27.09 at 13:59
As a (non-software) engineer managing (and coding for) a software development project and working with what I have come to regard as a great programmer, I’d like to add that the benefits of great programming are not immediately obvious and are therefore hard to measure. Many are not visible until (if) management becomes more code-savvy, or months down the line when you want an edit and it’s completed incredibly quickly because flexibility was planned in. We have robust (ha!) discussions on what the ‘client’ actually wants, but in the end it’s worth it.
Also, programmers are frequently not mercenary, self-promoting, manager-managing types who can handle discussions about pay. I fight for raises, while the programmer appears indifferent, motivated more by recognition of the quality of his code than actual cash. So the simplest answer for why great programmers are not payed more is They Don’t Ask. This could be driven by some sort of ascetic pride, but luckily for the coder I’m a mercenary bsd who believes that companies must put their money where their mouth is when recognising excellence.
Bo Zimmerman 12.28.09 at 02:15
Wow, great comments. They’ve inspired the following questions in my own head:
If workers are paid their marginal productivity, and the release date of software is as late as the longest development trail, then of what worth is that productive programmer, except to his own schedule?
If a productive programmer derives utility from the work per-se, then is this not sufficient to answer the original question? He’s paid less because he demands less to do the same work, while the less-efficient guy who hates coding demands as much to do less.
Scott R 12.28.09 at 11:19
Google is a programmer’s best friend (or any of the other search engines out there).
Productive programmers plagiarize. If it has been done before, why rebuild/recreate it again.
sirfwalgman 12.29.09 at 16:38
Good developers can make more. They get more repeat business. Peers recognize them and recommend them for positions. The have less bench time. It may not show up in the check as making [x] more dollars a month but over time it pays off.
Adrienne Lowe 01.14.10 at 10:43
Thanks for sharing! I plan on passing this along to my sweetie, a programmer who struggles with the “productivity” question at his firm. He’s definitely one who needs to become more at ease taking pause in his work.
Maybe programmers just need more code-inspired cupcakes? http://cracktheplates.com/?p=337
Much peace,
adrienne
http://cracktheplates.com
A vegan food & hospitality blog
Aaron Evans 04.22.10 at 10:20
But the best bricklayers are 10x more productive than the average–or at least 5x. They might not lay 10x as many bricks, but they’ll do a good job a lot quicker.
With programmers, the “most productive” don’t write the most lines of code, why would you measure productivity for brick layers in number of bricks stacked?
In fact, your top programmer won’t be the first one done either. He’ll take a little time to understand the problem, plan out the best method to achieve it, and then create his elegant solution in a relatively small amount of time, but then take a little extra time to go through and test some unforeseen scenarios. The result is a quality product in 1/10th the time it would take an average programmer to do a comparable job. — It’s getting that last 10% that’s the real hard part, and the part that he makes achievable that cuts his overall delivery time.
It’s the same for almost anything. While it’s true that physical labor is a larger part of the bricklayers job, something that can’t be automated or created as quickly as code, the analogy still stands.
The analogy holds further in that the best bricklayers are usually working for themselves, or with other top notch craftsmen on more challenging tasks, though not necessarily for 10x the money.
Another point is that until recently, there was a shortage of “average” programmers because until recently their was a lack of understanding of the field, and thus teachability, while bricklaying is a very old and well understood profession with a shorter ramp up time to achieve average performance.
Amber 04.22.10 at 13:38
“hose, 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.”
That is delusional. The only people who feel it is unethical to charge too much for their work are those people who believe their work is not worth much, period. It has to do with self-esteem and nothing to do with productivity.
Confident programmers who are passionate for what they do and produce great work KNOW it’s value and are not afraid to charge what it’s worth. (Not counting those who actually are) We’re not in charity, folks. This is business and anyone acting like it’s not is just being silly.
ARaybould 04.23.10 at 04:42
@Aaron: There is a problem with any attempt to claim that the best programmers are N times more productive than the worst: the worst have zero or even negative productivity. This is because the mess they create steals more time from other team members than it contributes to the project’s progress.
Grant 04.23.10 at 06:31
@ARaybould – thanks for reminding us of an irrational, but all too real condition. Sometimes at work I ask if anyone can explain to me why my company pays a contractor to make mistakes and then pays me to fix them.
John 04.23.10 at 06:39
@Grant: As to why a company might hire outsiders to make mistakes, you might want to read this article about cargo-cult consulting. It’s a tale of a consulting company telling a client what they want to hear even though it looks like a billion dollar mistake.
Kelly French 04.24.10 at 20:37
The question asked on the Stackoverflow podcast was turned into a Stackoverflow question. That question inspired a blog post of mine to go into more detail on the subject. Thanks to the <CodeAnthem site for bringing the subject up again.
feroze daud 04.26.10 at 11:19
This is a great article. I couldnt agree more. As others have pointed out, programmer productivity is very hard to measure. Specially in the current, fast paced environment where people change jobs when projects are done.
Since programmer productivity is hard to measure, and companies impose a forced bell-curve evaluation, followed by a rank and yank system, a lot of top skilled programmers start spending less time on being productive and more time on being “visible”, schmoozing etc. Those that cannot do this, or are uncomfortable doing it, will become discouraged and not spend the effort if they are not getting recognition. Or, they will try to move into management thinking that they will get better rewards, with the result that the company loses a good programmer and gets a potentially bad manager.
Compounding the problem are frontline managers who themselves are fighting for their jobs everyday that they cannot spend time evaluating how their directs are doing their jobs. In most companies, a managed doing an excellent job as a people manager is not rewarded for it, unless he also “manages up”, or does his own side projects to show the “extra mile” that he accomplished.