Why programmers are not paid in proportion to their productivity
johndcook.com
johndcook.com
2 of my own examples (I have many more, as many of you do too):
As a one man IT department, in 15 months I reduced my annual budget from $2.3 million to $600K, cleared up 500 old tickets, and implemented 4 mission critical applications. My reward? A 4% salary increase. (I gave my notice during that review.)
As a contractor, I maintained all the software for a $100 million company that was shopping for an ERP package. They were stunned by the 6 & 7 figure price tags and 2 year project timelines. I proposed a project that would add everything they needed from these ERP packages to their current system in 90 days. I hit the target and got paid $225K.
If you're a programmer who is 10x to 100x more productive than your peers, the last place you should be is as an employee without equity. Get out there and find someone who needs what you can do. You'll both be much happier.
This works for consultants, too. You'll never hear me describe my job as writing Rails code or Ruby scripts. I do that, sometimes, but I'm well aware that I add value faster than equivalently skilled developers and I charge a premium to match.
Consulting engagements also have a number of risks associated with them. Providing the perception of diminished risk is worth value to the client. Many developers could implement A/B testing, for example. (And they should, because it potentially prints money for the right clients.) There are a variety of ways a hypothetical developer could cause a client to believe that an A/B testing engagement with them is less risky than it could be. One is to have written a widely used A/B testing framework.
What I really did was help the customer identify and attack their real problems without worrying about the technology at all. They had business problems that they thought could only be solved with "bigger better software". They were wrong (as many people are).
Some of their problems:
- inventory was inaccurate
- product info (and bills of material) was inaccurate
- too much inventory
- too many late shipments to customers
- shipping costs were too high
- production was not efficient enough
The exercise in attacking the problems at hand generated the software requirements that helped the customer solve those problems. Mostly new forms, reports, database tables, and a few optimization workbenches and dashboards. (One of my favorite programs was a simple tool that enabled a dispatcher to drag and drop loads into trucks, drap and drop trucks onto routes, and generate reports. He "played" with this toy until he was satisfied with the best result.)
Hacking the customer's business was tricky. Writing the software was trivial.
This goes back to one of OP's points: it's not about how many lines of code or how fast you can write them. It's about providing value to help the customer solve their problem. That's where the real money is.
a) knowing the problems b) knowing how to solve them (ie, coding/configuration) c) being able to sell this to decision-makers
Those three roles often take more than one person to realize. Some folks are good at one of those, and they get paid well. Folks who do two or more well are rare/in-demand.
I remember sitting up all night wondering what to do. I decided to go to the CFO. I told her that her Big 5 vendor didn't know what he was doing and gave her plenty of good examples. I explained that after working with her software and her people for 3 months, I could come up with a more effective way of solving their problems in 10% of the time for 10% of the cost.
I half expected to be thrown out of her office, but instead, she got up, closed the door, and said, "Funny, I was thinking the same thing but didn't know what to do about it." Together we laid out the plan and strategy for the project.
Ever since, I have never been bashful. Even though proficiency and experience can carry you a long way, your biggest advancements often come when you go out on a limb to provide real value for a customer.
Another lesson: you never know what a gig can turn into, so just do your best and keep pushing that envelope.
People.
ideas
technologyYou are a business value-adder. You just happen to use technology.
I wish more people would be aware that there's a distinction.
You are a resource. You just happen to be human.
I wish more corporate assets would be aware that there's a distinction.
Wow, that's pretty horrifying. I certainly agree with your point. But...
"As a contractor [...] I proposed a project that would add everything they needed from these ERP packages to their current system in 90 days. I hit the target and got paid $225K."
The big ERP vendor may well be grotesquely inefficient, or their software may provide a lot more than your client needed, or both. Congrats for saving your client so much money. But complaining that you "only" made $225k for a 90-day project, working by yourself, seems a little hubristic.
If you don't have any leads, skip Craigslist and Rent-a-Coder and start going to tech/business meetups, asking friends and family if they know anyone who needs anything, and talking to random strangers at the bar. I've gotten ridiculously profitable clients at the bar.
Oh, and never do anything for free. In fact, always get a deposit, even if it's for a friend.
They don't demand it.
Related anecdote: I have meet a few startups lately that started the conversation with:
"We are looking for extremely talented and productive people".
And finished with:
"Compensation ? Well, we checked online, the average pay for your experience is.."
"We want top people."
"We want to pay average."
For smaller companies/startups I also prefer to receive fresh hardware (macbook,mini,etc.) at signing.
For me, starting off with a brand new MBP with all the trimmings (incidentally, ~4-5K) translates directly into productivity.
Besides, if I was paying it'd probably be running Plan 9 and have an FPGA duct taped to the back...
I've seen companies burn 100 hours of $150/hour employee labor in order to save $50 on a mouse. You don't want to work there.
Eventually I just bought one for myself. It was $50. Managers made all sorts of excuses, then IT said they wouldn't buy non-standard hardware, and there were particularly a lot of excuses in the vein of, "but then we'd have to buy keyboards for everyone." That they wouldn't consider buying their $100k/yr employees a $50 keyboard every few years was just another symptom of their dysfunctional environment.
Just as a recent example, it took an email to my manager and 10 minutes later a keyboard for $150 was approved. Say it lasts for 5 years - the feeling of appreciation by easily getting what I need approved and bought is worth so much more, compared to what $150 spread out over 5 years of salary would buy them (disregarding that the raise would also cost a more considering taxes and such).
I'd be interested to know going in what a startup's policy on conferences would be.
While I expect most trips to be ultimately grounded in business development (and with good reason), is the company purely focused on talking up a product, or will they accommodate my technical/social interests as well?
Giving a pitch can be fun, as long as I have Plenty of time to chat with other programmers, attend panels, learn something, etc.
[1] Your ability to negotiate effectively is helped/hampered by your knowledge of their field of candidates. Ergo, they inevitably say 'top people', to skew your perception of your competitors to their advantage.
Sure, but that's what makes them scum. It's bad-faith negotiating.
What usually wakes HR up is a detailed spreadsheet of the value you add to the business and that you will be going elsewhere unless you are properly compensated, as well as when they bring other people into it saying "Ok, lets get them in here and get their salary up too" or "fire them if you need extra money, your lack of money to pay me is not my problem, this is a business, I am not your bank, if you need a loan call them."
Grow a pair and walk out on the spot, if you can't then save so next time you can. Thats how you negotiate by putting the business in a position where it is fucked if they don't do what you want, just like a business plays its min wage employees. Letting people put themselves into stupid positions is a two way street.
It's bad faith to contend that a programmer is nothing more than an inert substance. I'm not talking about emotions or morale or anything woo-woo like that, just that programmers do more than coal. You can't burn a person and get code as a result.
HR workers who follow your logic do a disservice to themselves and the company, because when a programmer is performing under expectations, HR is not going to say, "well, they're a piece of coal, what do you expect?"
No, programmers are only coal at the beginning, and then the script flips after they're hired. That's textbook bad faith, and "walking out on the spot" always involves having wasted time at least going through the interview process. Charming.
Not disputing that but seriously: what sort of people call other people "resources"? Did they think that's who they were going to grow up to be, when they were kids?
They even know it's wrong because they don't call themselves "spreadsheet resources", they're "HR professionals".
I certainly do not know if i'm more productive than average or not :)
When doing group estimates, it's not hard to start to see who is struggling to finish their tasks at the end of the week and who is finishing with time to spare. You can also tell who is giving QA headaches with all their bugs and who is saving QA time. A lot of the people didn't realize they were doing it, but you could tell QA would base their estimates partially on who was going to be on the coding portion, and it was very easy to get a sense of who was able to get tasks done faster than you thought you would be able to and who was slower.
The worst was the programmers that needed the other programmers to help them out almost every sprint. Management liked it. They said it was a good sign because it showed what a team we were.
But if someone can show me how to measure it, I'm confident I can show him how to get paid by it.
And that doesn't take into account maintenance.
This is essentially the same thing you are saying, just broken down. Still, it's difficult (not impossible) to measure one programmer against the next in terms of productivity. Using these metrics it is quite possible to measure a programmer against himself over time.
The problem is that measuring the necessary factors affects the level of productivity being measured.
Actually, I took his meaning as productivity being only a measure of how fast the work gets done, your efficiency, and not of how well the code is written, your effectiveness.
His comment: "And that doesn't take into account maintenance.", implies to me that code quality is not a factor.
Unfortunately, this is the measure that seems to predominate, especially with non-technical managers. If it takes twice as long to do it right, all the non-technical manager sees is that it took twice as long. The subsequent reduction in maintenance time and cost from doing it right doesn't seem to get noticed.
Of course, the ideal is to get the job done fast and right.
This excellent insight takes us to a place where productivity is even harder to measure: How does one measure the value of a piece of software? Software that has subtle bugs flying under the rader of our test suite has some kind of negative value. Software that lowers the "productivity" (however we measure it) of future programmers who need to extend or change it has negative value associated with it. How do we measure that?
Imagine the exact same formally specified requirements handed to four different programmers:
The first programmer, "Ned," does the job in a straightforward fashion, and delivers working code passing all tests.
"Fred" does the job using uncommon techniques (parser combinators, for example) in less time and produces less code.
"Ed" proposes that if some of the requirements are relaxed, there is an open source solution that can do the job with trivial integration.
The last programmer, "Jed," sees some commonality with some existing code and proposes that the scope be expanded to produce a new piece of infrastructure (message queues, web services, SOAP, &c) solving a more general problem.
How do we judge Ned, Ed, Fred, and Jed?
As people.
I'm convinced the only real-world metric that matters is "how much other people want to work with you". Being an easygoing, fun person facilitates that dramatically.
Edit: I think I might have misunderstood what palish meant by "By how fun they are." to exclude productivity and focus entirely on personality. My mistake, if so.
We can't judge them in a vacuum. What is the rest of the team like? Are they all of the same mindset as Ned? Can they understand Fred's code? Which requirements did Ed relax and what is the quality of the open source code? Does what Jed suggested make sense?
Does this imply that programmer "productivity" cannot be judged in a vacuum, no matter how rigorously we attempt to specify the task?
IOW, either I'm supervised by someone that should know relative merits, or I'm judged by the final results. In either case, I'm not paid more, because I believe that the real value is more on errors I prevent than in lines I write.
Are you suggesting that in your experience, programmers never use unusual techniques, never push back on requirements, and never engage in refactoring or infrastructure construction?
Repeatable measures are easier when there is a repeatable conventions to deliver work.
If wishes were horses, beggars would ride. Sure it's easier when there are repeated conventions. But are there actually repeated conventions? You could create an environment with repeated conventions by firing Fred, Ed, and Jed. Now you can measure everything with ease. Are you better off?
In other jobs I've been much more autonomous, performed much better than now, but there was nobody that noticed it, because there wasn't anyone to compare to, bosses didn't really understand what I was doing (just that it worked) and specially because they didn't know what could have gone wrong and I made right.
Time ago I was in a different environment. I was in an intermediate situation. My autonomy was limited, but not so much. Bosses were very experienced and knew how difficult my work was. I got raises and a promotion. Then I was better off, and I'd say so was the company..
Ned would have to help Jim with his work because Jim is really not qualified to be employed as a developer, but he eventually accomplishes the bare minimum by using a lot of other people's time. There are probably a couple Jims and a few more people who accomplish the bare minimum if given enough time. Then you have Bob who, every sees as some kind of hero because he works 10 hours every day and "finishes" a lot of work. Unfortunately most of Bob's work requires constant maintenance, often by Bob. Somehow this makes Bob seem like more of a hero.
Most developers are aware of who on their team is more productive even if they cannot quantify it.
Which is the elephant in the development room. IMO, maintainability is exactly what good programmers should be judged on. Any programming project of any meaningful size and usefulness will spend at least an order of magnitude more time in maintenance and enhancements than in initial development. For the largest projects (Google, Facebook), maintainability becomes 1000 or more times more important than the original development time.
Problem is, you can't quantify maintainability. What a good programmer contributes to maintainability and enhanceability is the absence of certain problems or classes of problems. Everything from choosing an exotic languange that nobody else can maintain, to the choice and organization of source control. We take that sort of thing for granted in HN type projects, but problems like "nobody knows how to compile that" are a really big problem at corporate enterprise scales, especially companies that are not fundamentally technologists, say finance or medical or shipping. An individual programmer is more likely to incur reward if he looks like he's playing the hero in a bad platform and ecosystem ("only this guy has the wizardry to manage that!") than if he built a good understandable platform in the first place.
- First, institute "Test First" development
- Randomly pick some fraction of new tests to be reviewed
(Demand a minimum quality level.)
- Measure productivity in terms of new passing tests completed
with some multiplier for the quality score
Once again, the best programers write as little code as possible which allows them to focus on quality over quantity. It's easy to turn 10 lines of code into 20 classes and gain nothing, it's much harder to see those 10 lines of code once someone has written the 20 classes.
This method doesn't have web pages in mind. More along the lines of something like domain models for something like energy trading.
Writing tests for 20 shallow, repetitive classes would result in 20 shallow looking test classes, and that programmer would be called on it.
Web pages are really a narrow area of programming.
Once again, the best programers write as little code as possible which allows them to focus on quality over quantity.
How many functional specs are they accomplishing while they are doing this? I've known programmers who've created "entire new functional sections" in their app with 25 lines of code. Your issue is addressed by paying attention to functional specs.
Take an existing project find all the places that link to each section of code and you have some idea how reusable things are. Tell people your doing this ahead of time and you promote spaghetti code. Ask people how difficult an objective is and you get a wide range of biases based on how you use the information etc.
The secret is not how to get the most reliable data, it's how to get the best outcomes including they way people try to game the system.
Look, now it's obvious you didn't carefully read the original comment! (Left as exercise.)
My most productive days are the ones where I've removed huge blocks of unnecessary code.
Absolutely incorrect. Did you actually read my proposal? If the tests are of high quality, then the code passing them will be substantive. Also, in new development, what matters is functional specs delivered, and in a properly run TDD project, these two are strongly related.
An extreme example of this sort of thing would be a programmer who looks at what needs to be done and says: "We don't need to write ANY code there's an open source app/library for doing exactly what we need here."
By making that suggestion it's quite possible that they've saved their company months of work (versus implementing everything themselves). However, in a purely Number of Tests written * Quality of tests metric they're a miserable failure.
I think TDD and tests are a solid way to write software, but I don't think they're a great way to judge programmer productivity.
I recall reading years ago (in Peopleware or one of its contemporaries) about a company's evaluation of one of its coders. She was definitely mediocre by every measure they had. But someone noticed that every project she was on succeeded, over many projects and many years. Though she wasn't a monster at the keyboard, something she brought to the team engendered success. How productive was she? Would you want to hire her and have her on your team?
You must measure what you actually care about. Measuring things that you think are factors is fine and noble, but if you're not measuring the actual "product" of "productivity" then you'll never know how well your factors correlate with the real goal.
Correlation does not equal causation. Another possible explanation: She was a monster at predicting project success and worked her way onto projects that were going to succeed with or without her.
OTOH, having a project success divining rod could have its own value.
Sure, but if causation is effectively impossible to rigorously determine, it can end up being all you've got. If you've got the choice between going with someone whose presence correlates with success on the project and one who does not, my inability to be rigorously sure about causation isn't going to make me lose much sleep at night when I chose the correlative one.
I'm coming to dislike the citing of "correlation does not equal causation" when there's no way to determine causation at all, and when scientific certainty isn't the question at hand. At that point it's an excessively-powerful criticism, one that can't be discharged, so is it really a useful criticism at all if so?
This is perfectly understandable, however this particular discussion is one where the difference between correlation and causation is appropriate. We are talking specifically about paying programmers by their "productivity." If you want to say that "productivity" is defined as the correlation between a person and project success regardless of whether there is a causal relationship or not, and regardless of whether they engage in programming activities, project management activities, picking good project activities, discussion activities, or even just making everyone else espresso so they can produce working code, that's fine.
But what we're saying in that case is that we can't measure the productivity of a programmer, we can't establish a relationship between programming activities on the scale of a single person. I agree that the correlations you can observe are perfectly useful for management and that one can deliver great (or working, or valuable) software without an objective metric of programmer productivity. I agree that this elusive metric may not be necessary. It may not even be useful, as I tried to demonstrate elsewhere when I discussed Ned, Fred, Ed, and Jed.
But that really underscores my point: We can't tie compensation to programmer productivity because we can't measure it. Your point seems to be that we don't have to tie compensation to programmer productivity, that we can tie it to correlation with project success, for example.
Fine with me, I'd say we're in violent agreement and that our stances are compatible.
Fair point, but what would you pay for knowing in advance what projects are going to succeed and by inference which may fail...
Correlation not implying causation is a big deal because it's possible to draw (probably exponentially) many alternative causal chains than the one that you're discovering correlation along.
If the above isn't the case, and it's at least theoretically possible to design experiments like that, then correlation does[1] equal causation.
[1] Sort of. See pretty much anything written by Judea Pearl.
Even if she was just a monster at predicting project success, I'd still want her on my team. Can you imagine how useful it would be to have someone able to consistently predict project success working with you?
(Interestingly, there's a less flattering interpretation of the data as well. Given a large enough organization that promiscuously shuffles people onto new projects, some of which randomly succeed, someone is going to have randomly ended up on all the successful projects. We'd then look at them and say "Look how awesome they are!", when really they just got lucky over and over again and we're looking because they got lucky. This requires that the organization size be large relative to the number of possible combinations of projects, though, which becomes increasingly unlikely over time. It's like the people who look at Warren Buffett and proclaim "he just got lucky for 40 years in a row", then do out the math and realize that the chance of someone being that consistently lucky is several million to one.)
She was the Shane Battier of software.
(I happen to be reading a book on basketball right now.)
In my experience, there are good programmers and bad programmers, just like good project managers, bad project managers, good people managers, bad people managers, etc.
A bad employee is bad for your company period.
But that's just for programming. When you get into the application of software - unmet needs - you can easily get x100 or far far higher. This is because the value of software is more closely related to the need it meets (that exists in users) rather than any quality of the software (that exists in code).
Tasks tended to get separated so there wasn't too much direct collaboration between coders within a sprint, and the estimations were mostly a group effort, but the person who was getting assigned a task had final say to tweak the numbers. In this environment, it was fairly easy to see who was the more productive programmers. Some people got their tasks done quickly and could easily take parts of other features, and other people were usually late and needed others to help them finish their features. If you were a programmer there, you could easily rank the programmers based on productivity. I bet QA could do the same if they tried.
However, management focused on it being a team effort. As long as we finished everything up by the end of the week they did their best to reward everyone and fire no one.
In my experience, if you're technical you just kind of know if a programmer is good or not. If you're not technical, you find a technical person you trust and ask them.
This usually (but not always) means that the person has a lot of latitude to work on what they want to, they can work with the technologies they want to work with, can work the hours they want to work, have the luxury to not always have to report on progress or have a lot of management oversight.
The degree with which someone like this can participate in these "happiness perks" usually is commensurate with how good they are. There is a great TED talk on intrinsic vs extrinsic rewards in terms of motivation. I think the market "works" in the sense that great hackers aren't actually as interested in making gobs of money (they don't want to get screwed either) but are usually more interested in these other more intangible kinds of incentives (like freedom, autonomy and mastery).
The most talented engineer / programmer I've ever known was only paid at the top end of the "average" pay scale in the research lab I worked at. On the other hand, he was left pretty much alone to work on whatever he wanted to work on. He created amazing things and was genuinely happy, even though in pure monetary compensation, he was radically underpaid.
Take an average programmer, and try to convince him that he could be two times more productive..a junior programmer might buy it, but any average programmer with "experience" isn't going to believe it. Forget about telling him that he could be 4 times of 5 times more productive.
Now move up to the manager and tell him that his team could be 2x more productive. No way will your average manager believe it if for no other reason than it makes them seem pretty incompetent.
I've tried the experiment before. An example...A small team was complaining about their workload and kept saying they needed to double the team size. Management agreed and was trying to get budget. This dragged on for a while (along with the complaining). I asked why, instead of doubling the team size, they simply didn't double the productivity. The concept of even thinking about being more productive was completely foreign to them. They wouldn't talk about what might improve productivity - there was no point because clearly the hard working team couldn't work any harder...working smarter? Nonsense..they were experienced developers.
The point? Everyone thinks they are better than average. Admitting that you could be 2x (forget about 5x) more productive is like admitting (in people's minds) that they are slacking off. This works at the individual, management and company level.
More productive programmers aren't paid more because, while everyone knows some programmers are 10x more productive, every employee thinks he/she has little room to grow, and every manager believes his team is awesome.
I know programmers who still, after years and being told to use rsync and automate the pushing of their code to production, still manually open up an ftp client and one by one upload just the files they know they changed. Dudes could save probably a few hours a week easily and do less work but the fear of... learning something prevents them from doing it.
Perhaps because making some parts of a job easier doesn't make the job as a whole easier. It is quite conceivable that by eliminating all of the repetitive work, they would be forced to spend more time on difficult problems rather than trivial ones.
Personally, I think that's a great result, but people who don't like learning new things probably won't appreciate it.
A serious discussion merits at least the use of a source code versioning tool, like SVN or Mercurial or GIT.
And now for a more serious answer: How do you know that the lack of productivity is caused by lack of skill when it could be just because of lack of perceived proper compensation?
Some of these guys could be working at home creating software that can make your company obsolete.
Very very rare. Orders of magnitude more will have e.g. families that they like better than computers. Of the remaining, few will have business-killing ideas in the first place.
I agree that morale can play a part in the amount of effort and/or sophistication a given employee will put into their job.
As for SCMs, there are plenty of companies in the middle. I've seen companies whose deployment process consists of running "svn up" on the production server.
Can you use a pull from version control to do an automated build and deploy it, sure, but that's an unnecessary hassle for a small team. It's more productive to simply build on your machine and push up the new version. An automated rsync deploy is more than sufficient.
That kind of process works for large teams where different people are doing those jobs and need to collaborate effectively without finger pointing; but it's not for a small cowboy team at all. You simply can't maintain that kind of formality and process when you're doing everything.
> Now move up to the manager and tell him that his team
> could be 2x more productive. No way will your average
> manager believe it if for no other reason than it makes
> them seem pretty incompetent.
They being management, or the devs themselves? Because anyone will have a shopping list of how they could be more productive. I'm currently badgering my manager for an upgraded PC (from 4G to 32G RAM) for everyone in my team so we can run entire virtualized environments, for example. This will be a massive boost to use because we'll no longer need to rely on another team to do provisioning for us, and we'll no longer tread on each other's toes in the existing environment we have, requiring work to be re-done. She's smart so she'll probably go for it.
> 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."
It may be a cop-out but now I'm looking for "top people" to hire, but what I usually mean is someone who can have the programming focus I don't have anymore. I'm looking for "me 6 years ago" the hacker who loves products and wants to build a business who's at the beginning of the entrepreneur track. Damn damn hard to find.
Great Baggins reference as well.
Of course, if you turn back the clock far enough, there may be one or two folks out there who would say the same about me.
Don't waste your life in a rat race.
The 1968 Sackman, Erikson & Grant paper is available as a scanned PDF, btw:
The most impressive hacker I've ever known worked with me in the advanced research lab in a ginormous tech behemoth company. Let's call him "Bob". He was so good that people in the team would sometimes call him "Super Bob".
There are lots of stories I could tell about him, but he (working alone) was often able to hack out stable, working code in months, solving problems that had proven too difficult for entire software engineering organizations and multi-year projects. This happened more than once.
"Super Bob" got paid at the top end of the "average" pay scale, but was genuinely happy. He could work when he wanted, and on what he wanted, had his own lab, and no one messed with him. I tried to recruit him into my first startup when I left the company but I came to realize he wasn't interested in making tons of money, especially if it meant taking risk, sacrificing the access to huge resources (and toys), freedom and autonomy that he'd developed.
The airport map is a different story. There are many airports with just a few connecting flights and there are just a few airports with a large number of connections. When you make a plot that shows number of connections on the x-axis and the number of airports having that many connections on the y-axis it shows a power law. The graph is very high near the y-axis and drops off as you move to the right. Finally you get to the large airports like LAX, Chicago, and New York.
I bring this up here because I think the issue of programmer pay and productivity has similar properties. The salaries are distributed normally with a mean and the vast majority earning within 2 standard deviations. If you could measure productivity of each programmer and make a graph that showed the productivity level on the x-axis and the number of programmers working at that level on the y-axis then I don't think the graph would look like a normal distribution. Rather I think it would follow the power law just like the graph of airport hubs.
I know this is somewhat speculative on my part but I think it could also be that the top programmers are so productive because they are highly connected in terms of programming concepts and techniques. The article mentions their ability to come up with alternative solutions. I think they get like that by working on different projects over time. This is also how the power law networks (also called 'scale free' networks) are thought to form in other areas according to the book.
The main point here is that programmers who are 10X more productive than the average coder seem to be not so rare. Many people have stories about having worked with guys like this. Therefore I don't think you should use the normal distribution to model the distribution of productivity in programmers. I think there are many guys at the low end of the scale and it drops off slowly as you move into the higher productivity. And NO you can't include the negative x-axis to get a symmetric, "normal-like" distribution. In this model the negative values on the x-axis don't mean anything.
The catch is that any normal distribution which allows for large numbers of 10x programmers requires large numbers of programmers with negative productivity. However, I disagree that those values are meaningless. Rather, it simply indicates a programmer who makes code worse. I would readily argue that, for every 10x programmer, there's at least two who create more bugs than they solve.
When we measure human attributes they are almost always normal distributions, I see no reason that programming ability is any different. But, maybe tools allow good programmers to magnify their ability more than poor programmers. If that's the case then we'll have a lopsided normal curve, and that sounds plausible. But, I'm highly skeptical of the idea of "productivity" being a simple metric and that 10x means much of anything.
However, I'm quite certain it's not a power law :)
> I think the weakest way to solve a problem is just to solve it; that's what they teach in elementary school. In some math and science courses they often teach you it's better to change the problem. I think it's much better to change the context in which the problem is being stated. http://www.ecotopia.com/webpress/futures.htm
I've often changed a problem so the difficulty disappears; but it's usually after I've worked on the problem a bit. I must admit it is kinda disappointing when I have to sack all my clever and complicated ideas, that I've become attached to.
A lot of the below average programmers go out and start slapping down bricks at a great rate of knots. Planning? "Ha! You ain't gonna need it" they say. Design? "Pffftt, is this the bad old days of the PDP-11?" they scoff. "I do automated unit testing, why would I fire up the site in an actual browser? That's so 90s!"
The problem is that a lot of the time the bricks they are laying get torn down and rebuilt, and torn down and rebuilt, over and over and over. This gives the appearance of productivity, but gets you nowhere in the long run. Even if you could run at 50mph for hours on end you wouldn't win a marathon by running in the same small circle over and over again.
Examples of ways the bricks can go wrong:
Not building the right thing (they asked for a gazebo, you built a garage)
Not accounting for edge cases (the walls should meet)
Not doing proper testing, or leaving the testing until very late in the process
Not making the design flexible enough to account for likely changes during the project (no real world equivalent springs to mind)
Not building solidly enough (doesn't provide load bearing support in the right places) (closely related to the "catching exceptions is for wussies" school of thought)
Leaving odd holes and gaps in the brick wall (security issues)
etc. (Feel free to add your own, fun for the whole family! :D )
This seems to be so generally accepted that it's stated in the article as fact, without anything to back it up. As raganwald mentioned, we really have no metric for productivity. So, while your gut may tell you that you (or someone you know) is multiples more productive that you are, all you really have is your gut.
I don't know where this idea that world is fair comes from.
1. they are not part of a software company, say, not generating revenue directly, so they are not high on the payroll list
2. the pay is based on the overall performance of the whole development team, so the great programmers' productivity got mitigated by the worse ones'
3. high productivity may mean technologically superior products, however, superior products don't necessarily lead to market success
4. if there is a function: profit = f (productivity), it may be more likely a logarithmic one, rather than linear, e.g., there is a diminishing return on productivity
5. even if it's linear, the owners won't pay accordingly, because of the law of supply and demand
5a. own yourself when you have a chance, if you think you're great hackers
I think about myth #1 when this subject comes up - "Part of the issue is that I’m underpaid a little; a bigger part of the issue is the other guy is overpaid a lot."
Edit: Just saw there was a discussion on this article about 90 days ago: http://news.ycombinator.com/item?id=2131550
I'd say a developer's productivity can vary according to motivation; who they're working with; how interesting the work is; whether they're well managed or not...
So, while salary is a linear measure, it makes no sense to me to assume that productivity can be measured the same way.
I'm fairly sure my own productivity can vary by as much as an order of magnitude according to circumstances. Wonder what I should be getting paid? :)
So far I haven't seen anyone point out that there are lots of abstract concepts that we measure and rank without having a specific measurable quantity. Art is the first thing that comes to mind. What makes someone a 'good' artist? Even in things people might normally consider numbers based like college football rankings aren't purely objective.
The to deciding some ranking and relative comparisons is to ask people familiar with the subject to compare to instances of the set. In this particular case I could see having the team rank each other member or assign some numeric score representing their opinion. Giving this and some brief written reasoning for the scoring it seems like management would be able to get a clear picture of who the most 'productive' programmers are. There'd be obvious chances for pitfalls and politics in such a system, but if it were applied with some sanity it seems like it could work.
Unfortunately unless you make people pay for services they don't recognize your worth. Back here in India, like every where else good hackers don't get noticed until they make some noise. On the other hand even below average programmers who hop jobs often are paid real good packages. The way companies think of it is, that in any project if there say a x people. x-80% people work well, and are expected to compensated for the work of x-20% people. At the project level when the productivity data is measured, it turns out productive people have averaged out the unproductive data of the other crowd. So on a company wide policy basis a uniform hike applies, since data suggests productive was around industry average. The actual work of productive guys never gets displayed at all. This is just day light fraud, and a very scandalous way of rewarding people.
--isolates the effort/product of one person, allowing for easier measurement
--puts the burden of estimating productivity on the programmer, who, if he is as experienced as he says, is probably best equipped to judge his own productivity (as manifest by what he charges)
Programmers are fact base thinkers,unfortunately this skill makes us poor negotiators.
1) Since he had privileged treatment his colleagues did not like him! 2) He did write code a lot faster than anyone else, but his code was not optimized. Since he was the 'head of development' (or something like that) pointing out that his code was not optimized did not have any effect (he was really stubborn). So we shipped the code fast, usually we would get a complaint by the customer, re-evaluated the code, optimized it and send it back.
I would say that his code writing productivity did not seriously effect the overall development cycle of the project. As many of you said, there is no systematic way of measuring productivity!
I don't find the "paying proportionally doesn't happen because sometimes the best way to program is to not write much code" argument very convincing; what about the times when the best way to program is to write a lot of new and correct code?
If you don't have any programmers and are making a first hire, ask for code samples and have someone you know that is a developer review them. If you don't have any programmer friends then you need to spend some more time on HN or at local meetups :)
Many of the comments here conclude that it's difficult, if not impossible, to quantify programmer productivity.
So, if productivity is essentially unmeasurable, how can the initial sentence of the article be true?
All you have to do is build your startup and get acquired to get that salary. :)
So it's hardly surprising that we don't pay in accordance with something we still don't know how to measure...
Am I wrong in thinking this way?