The subject of this post may be the number one reason for a good programmer to stop being an employee and to start being an independent business person.
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.
And if you can't stop being an employee, at least stop being a "programmer". You can still program, just make sure you're doing it in the service of something which provably makes the company a lot of money. Mention this every time you aggressively negotiate for compensation.
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.
Yup, to all the underpaid programmers out there, if you're smart enough to program you're smart enough to read the quarterlies or the monthly sales reports. Find a big number and figure out a way to attach your name to it, then get a % of that number.
I don't think you're wrong, but it's certainly not as "natural" (oh how I hate that word) for a smart programmer to start scheming to get a higher salary. Cunning is a skill too, and while intelligence will help out a lot, it's not like things that require cunning will feel as "natural" as programming to a programmer.
Can you explain further the value you add that developers of equivalent skill don't add? Just curious. If the developers are equally skilled, they should be able to provide the same value in terms of code; perhaps you're including some business consulting that you throw in, or something like that?
On a recent engagement I prototyped a scalable content generation backend. Technically, it is an extension of the Rails build-a-blog project that everyone does in a tutorial, and it is trivially within the reach of every other Rails developer with 4 years of experience. The value I add above and beyond being able to implement a scalable content generation backend is a) knowing why you'd want to do it in the first place, b) creativity in applying it to whatever business is under discussion, c) being able to describe in detail what process one would need to use to use it in production, and d) being able to convince the relevant people that a + b + c = money.
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.
See, that's the kicker. You're able to see what the client needs, determine value and offer the best solution. As an independent business, you saw the benefit of that right away. You got PAID! That being said, does that really mean you're 10x better programmer than the next guy? The entrepreneurial & analytical mind may have made you just as valuable in the lumber business (yes, I know that's quite a stretch).
The shortcoming of many companies in evaluating programmer performance is that Engineering/Development Managers are often making value judgements based on factors besides what you potentially bring to the company. They're looking at how easy you make their job, how much they like you (seriously, I haven't even seen a manager completely detach their liking of someone and do an objective evaluation).
So, it boils down to, do you pay politics well, how smart do others "think" you are, and how well do you "sell" the value you bring to the company. In some of the larger corporations, most of that doesn't matter all that much anyways.
If you're entrepreneurial, nothing will highlight your value quite like your own business!
I didn't implement the ERP system. I enhanced the existing system to provide the benefits that the customer sought from the ERP systems.
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
These are classic problems normally attacked with ERP software. But their people were already doing the best the could with the tools at hand: old software and Excel. The project had me work with their people on their problems, not on the software. The solutions we proposed usually required more/better software, but not always. Sometimes it was just a different policy or procedure (or a bi-lingual count sheet).
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.
Just to add to the conversation:
Customization is 90% of the hard work of doing enterprise software. Often enterprise software requires teams of folks to do the above, because what is required 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 had picked them up pretty much in the standard way as a referral from a friend to do maintenance programming on their legacy system. They had me share an office with the Big 5 consultant who was interviewing ERP vendors. I knew immediately that he had no idea what he was doing and would ultimately waste a lot of good people's time and money. I had a lot of respect and loyalty to this customer and didn't want to see them taken advantage of.
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.
This is one more example proving "No guts, no glory". IMHO it takes real courage and conviction to go to a C-level executive and state the obvious. Which is why it doesn't happen more.
I see these sorts of "just do it" comments all the time on HN, but short of becoming some cold calling Glengarry Glen Ross-type, it's not at all clear to me how one goes from being an employee programmer to a one-man, bespoke software shop.
Start consulting on the evenings or weekends. Even if it's just setting up Shopify stores or making someone a portfolio site.
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.
I understand the downvotes, but I think there is some truth in 'put the coffee down'. A lot of people think about the how to, but sometimes you just have to put the coffee down and act.
When you feel the step is to big to take at once, just take babysteps. Start in the evening (try not to work for yourself at your dayjob). (see the post of jarin)
"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.)"
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.
The real reason programmers are not paid in proportion to their productivity:
They don't demand it.
I had the privilege of working with some extremely talented and productive people. Sadly, many of them were making market salary (or less).
Contrary to popular belief, many companies are quite capable of noticing and trying to keep productive people. But rarely by throwing money at them.
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.."
It's just a negotiation tactic.
Most HR people are playing a game that most applicants aren't prepared for and/or interested in. The offer, the dancing around, even the bit about looking for "top people". It's all just trying to dress up the game to their advantage [1].
[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.
How is it bad faith? They are called HR, Human Resources, to any company who employs such a department you are indistinguishable from coal. The goal is to get the coal at the lowest price, if you have to buy it sodas and tell it what a wonderful employee it is to get it to accept low salaries then so be it.
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.
Human Resources, to any company who employs such a department you are indistinguishable from coal.
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.
The function of HR in a business is to keep employee costs down.
I imagine that a lot of HR do think this, but I think it's an oversimplification of their duty that compromises the interests of the company. I wouldn't go so far as to say that HR's overall mission is fiduciary.
They are called HR, Human Resources, to any company who employs such a department you are indistinguishable from coal
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".
Fresh hardware? Are you kidding? If you make a decent salary you can buy your own hardware whenever you feel like it. A $2K MacBook Pro is a drop in the bucket compared to paying a 6 digit salary.
Fresh hardware is a test. It should be a drop in the bucket and a no-brainer but its very often not. When it goes bad, its a huge red flag. If you get even the slightest bit of "well we can't really approve something like that without this or that managers sign-off and then the 30 day procurement process from an approved vendor..." head for the door.
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.
I worked for a very large enterprise software company for a while. They gave everyone their stock computers with stock keyboards and mice (the basic ones that came with the HP systems). I spent about a month trying to get them to buy me a new keyboard which I felt was necessary for ergonomics and because I had (informally) demonstrated a higher typing speed on it.
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.
Hardware, and other expenses such as conference trips, is indeed a very small expense compared to salaries. It's a cheap way of showing employees that you care.
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.
In Australia at least, if you pay for hardware, software or education which you use directly for work purposes or for self-education directly related to your current occupation, it is tax-deductible.
That's what I do. I work at most 2 months a year. But draw salary for the rest of the year. The company doesn't mind too. They are happy to keep me on board as insurance against sinking projects.
Try for something like Google's 20% time? You work for four days a week on what they say, then work the other day on whatever you want. Or three and two. It works out well for everyone if they want you to do interesting things, and if they don't you still get to do what you think is most important or fun some of the time.
I worked at a large enterprise software company and it was actually fairly easy to tell. The reason is that management had implemented a Scrum system with two-week sprints. What this meant is that we planned out what we could do for the next two weeks on the first day of the sprint, including doing estimates of the tasks. Then at the end of the week we would look back and double check that we got everything done and try to figure out why we were off if were (but they never figured it out).
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.
I'll ask again: What is the objective and repeatable metric of programmer productivity? One of the reasons I avoid writing about productivity is that I have no idea how to quantify it.
But if someone can show me how to measure it, I'm confident I can show him how to get paid by it.
Delivering a quality product within time and budget constraints, consistently. Oh, but that's a team effort, you say? Well, that's the working environment, isn't it? Projects are an awfully coarse measurement, you say? Well, that's the only deliverable that matters.
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.
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.
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.
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?
I'm coming to dislike the citing of "correlation does not equal causation" when there's no way to determine causation at all
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.
Sure, in general. In this case managers were fairly familiar with her and the teams and posited that the success was due to what she added to team discussions. I think they were probably correct.
OTOH, having a project success divining rod could have its own value.
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.)
So ask her if she's willing to be on this project! Seriously though, ask your developer why there is a correlation between them and project success - if they can tell you, even if it shows they should be a business analyst, you're on to something very useful and valuable.
"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."
Fair point, but what would you pay for knowing in advance what projects are going to succeed and by inference which may fail...
And how would you measure Intuition then? Maybe she had terrible intuition but is just a fantastically productive programmer.
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.
"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."
She was the Shane Battier of software.
(I happen to be reading a book on basketball right now.)
Interesting you should mention it. Shane Battier gets traded to Memphis, and for the first time in their history, they have a playoff win and are well within the sight of a series win over the top ranked Spurs.
There is none. In fact this whole good programmers are 10x-100x more productive then average programmers is treated as gospel around here, but I don't trust that either as a first principal or obvious assumption.
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.
Not just here, but industry-wide. The x10 figure comes from studies. Brooks talks about them (mythical man-month), and I think Peopleware mentions some. The question then turns to what these studies are actually measuring...
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).
The only objective and repeatable metric of programmer productivity is if a single programmer is assigned the task of delivering a tool or component, from scratch, by himself. His productivity is the inverse of the time to delivery.
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.
Fortunately in the real world such situations never arise except at a few exceptional companies. At most companies the difference between the top and bottom developers is very noticeable.
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.
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.
I think this is true up to a certain point, then stops mattering. Once someone is at the 'pleasant enough to be around' level, I'd much prefer he/she be more intelligent or skilled than more fun if we're working together. This is partly because lower key, quieter, more intelligent people can often turn out to be more interesting and fun in the long run than people who have great social skills and confidence but less depth in their thinking and personalities.
If we extend "fun to work with" to include "quieter, more intelligent" people, I think palish's definition may work rather well. That group definitely falls into "people I want to work with."
Weirdly enough, I just finished reading about how NBA players overwhelmingly wanted to play with Bill Russell over Wilt Chamberlain, as part of an argument that Russell was the better player.
All (but not only) people with good people skills and zero productivity would be motivated to say this.
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.
That might be true in the very short term, but in the medium- or long-term, no one actually enjoys working with "fun" people who have zero or negative productivity.
In which case you join me in disagreeing with the statement that 'the only real-world metric that matters is "how much other people want to work with you'."
Okay, fair enough. I shouldn't have taken that sentence out of the original context, which said "By how fun they are." Or maybe I just totally misunderstood palish's point; actually rereading, that seems more likely than not. Apologies.
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?
In my experience, programmers' competences aren't so broad that we can take the decisions you presented. Repeatable measures are easier when there is a repeatable conventions to deliver work.
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.
In my experience, programmers' competences aren't so broad that we can take the decisions you presented.
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 my current job my boss has much control over my work, he is happy with my performance, he knows that I'm way over average, but (please, believe me on this) he's powerless to improve my situation.
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..
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.
Very true. A friend of mine, who worked for a very large company at the time, once described the perfect system for achieving recognition as a developer. Firstly, write code that's full of bugs and is hard to maintain. Secondly, once the code is shipped and starts going wrong, make sure you step up to the plate and fix all the bugs that you created. That way, you get kudos for delivering code rapidly and for all the customer support work you do. Contrast that with the guy who writes good quality code who doesn't ship as rapidly and who doesn't have half as much customer contact.
I don't have the citation on hand, but this goes along with a study I read about customer loyalty. Customers who have a problem which is promptly corrected by the company are more loyal than customers that never have any problems.
I think that makes a lot of sense - relationships build loyalty and trust (as long as they are positive in nature). Buying something and never interacting with the producer doesn't build much of a relationship - it's merely a transaction.
I think there's an awful lot of truth in that. You could make the argument that customers of Enterprise Software (that we love to deride) are not paying for the awesome quality of the software so much as for the assurance that the company will pull out all the stops to support them if anything does go wrong with the software. On a psychological level, that leads to a good relationship. On a practical level, that means that the customer is paying not for a great experience when things are going well but for a good experience when things go wrong.
Unfortunately employers (myself included) like to have different programmers working on different tasks, where it can be difficult to measure non-equivalent tasks.
I'm not sure I agree with this. Granted good design takes some extra work. But for the most part, in my experience, coders who write bad code also do it slowly (perhaps because they don't understand it), while those who write cleaning code are able to move more quickly. As a project grows, you have to refer back to your own work more often. The price for poor code starts to be paid almost as soon as the cursor leaves the page.
Productivity is a factor of efficiency and effectiveness. Efficiency being the measurement of how fast things get done, and effectiveness a measure of how well things get done (meeting the requirements, including all features, number of bugs/issues that crop up, quality of code).
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.
"This is essentially the same thing you are saying, just broken down."
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.
So much of it comes down to managers not being able to tell good code from bad. If you look at quality as a crapshoot (it's genuinely hard to tell architecture astronauts from good code) then indeterminate quality quickly beats indeterminate quality slowly.
I worked at an enterprise software company with a Scrum system that used two-week sprints. This means we would estimate all the tasks for the next two weeks in a big meeting at the beginning of the sprint, then at the end of the sprint we'd have another big meeting to close out the tasks and do any analysis on met/missed targets.
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.
A friend of mine used this successfully with groups practicing Test Driven Development:
- 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
This system could be gamed, but it would require a conspiracy consisting of a large fraction of the team, and any system could be gamed in that situation. This is the only method I know of that works when analyzed logically and has been shown to work in practice.
Which would be rewarded in your situation, building 30 really simple pages by hand or spending 1/2 that much time to code something which generated those pages automatically?
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.
Which would be rewarded in your situation, building 30 really simple pages by hand or spending 1/2 that much time to code something which generated those pages automatically?
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.
I'd be concerned that the approach you laid out is something of a proxy for lines of code delivered.
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.
My thought was that judging productivity by lines of code or by tests written (whatever the quality) is judging by what was done rather than by what should be done.
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.
That would be correct, except that the tests are peer reviewed in my proposal. You can't "code me a new minivan" in this situation, unless the test review process gets corrupted.
I'm of the opinion that programming is more an art than a science, so to me asking the objective metric of programmer productivity is like asking the objective metric of painter productivity.
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.
I understand this post is specifically about salary and money, but in my experience there is a kind of "gray" market of compensation that truly great hackers participate in.
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.
The 10x thing is an understatement..but say 10x is accurate.
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.
> 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.
Unless you're selling a tool or methodology, apparently.
Did you propose a 2x salary increase to accompany the 2x productivity increase? It could get the programmers, if not the managers, to decide your way was worth a try.
Why should anyone require a salary increase for somehow to show them how to do their job in an easier way? Unproductive programmers are unproductive because they do too many things manually and don't automate repetitive parts of their jobs.
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.
They fact that the choice is 'rsync' or 'ftp' scares the heck out of me. Doesn't everyone use a packaging system with reproducible builds, deploying these packages to staging first, testing it, then deploying the same signed package live using real configuration management (eg. Puppet) ...?
It's not scary at all, having that kind of process for a small shop would be absurd. When your developers are the only tech guys you have, and do all system administration, database administration, new programming, bug fixes, and deployment, you don't need or want red tape between yourself and yourself.
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.
Honestly, that's red tape that just isn't necessary for the vast majority of small business applications. Making a fix in dev environment, testing it, and pushing the fix live by a single developer is and should be the norm.
"Why should anyone require a salary increase for somehow to show them how to do their job in an easier way?"
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.
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.
Perhaps I forgot to mention, this is the .Net world, those versioning tools are not at all popular; doesn't mean one isn't used but versioning and publishing to production have little to do with each other.
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.
Telling a programmer they could be more productive is like telling a runner they could "run faster". Yes, they could theoretically be X times as productive but it's absolutely useless unless you can show them how to improve their technique, workflow etc., assuming they are trying at their job. Because if they knew how they would probably already be doing it.
They wouldn't talk about what might improve productivity
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's important to note that no one is paid in proportion to their productivity. In a free market, you're paid in proportion to your bargaining power. This means both that for programmer compensation to be fair we need to get better at translating productivity into bargaining power, and that there are some limits even if we got the first part exactly right (regardless of productivity, programmers will not be paid as much as CEOs, unless they are a CEO).
Actually, programmers can be paid proportionally to their productivity... they just need to run their own businesses (which has the downside of requiring the programmer to learn to be an entrepreneur... but it can be very financially rewarding). http://swombat.com/2011/4/26/productive-programmers
I find my skill as a programmer has substantially diminished the more I've had to spend energy and focus being an entrepreneur. I believe there's a myth that the hacker can do it all and do it all well. In reality I think you end up being stretched like... butter scraped over too much bread. :)
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.
Second the idea that my programming output has declined in terms of quality as I focus more on business related aspects. It forces you to look at everything in context -- better code quality gets you more maintainability, but at what cost? Every decision I now make has a trade-off; as a programmer, I can afford to throw more time to elegantly solve a problem. As an entrepreneur, I just need it to work as well as I've defined, for a specific cost.
If you run a tech business, your tech productivity will absolutely come in, though - and that's true both for services (e.g. freelancing) and products. You will need to learn other skills, for sure, but those are the skills you need to demand payment commensurate with your productivity.
Let's accept this and move on: programming is seen as a lowly profession by most business and hr people. And it isn't going to change in the foreseeable future. But you know what? They need us more than we need them, right now. PG, Spolsky, and many others agree it's preposterous to try to change society. The way out is either start your own business or join a small team with similarly talented people.
Uh, because the '10 times more productive programmer' is folklore, at best? It may be true, but there's not much hard empiricism behind the claim. See https://www.readability.com/articles/5egv0hme?legacy_bookmar.... Cook admits it's hard to tell who's more 'productive'. Well, if it's hard to tell, why take that claim for granted in the first place? I am sure Cook and everyone else likes to think they're the 10x programmer, however.
There was once a famous Smalltalker, a renowned toolmaker who took a "for now" job at a telecom. He could do all of his week's assignments in a single day or two, where his coworkers would take the whole week to accomplish less. So what did his boss do? Basically, demand that he suffer as much as his coworkers. Result: The boss lost his most productive and talented worker.
That's why you get it done and don't tell anyone else about it until the due date. People that get things done quickly are usually rewarded with more work and responsibility at the same pay.
This is not just in the programming business. Highly productive employees are generally underpaid relative to their peers. In his book, "Choosing the Right Pond", the economist Robert H. Frank attributes this to status-seeking. Short version: the highly paid employee could make more elsewhere, but then they wouldn't be the the big fish in the small pond anymore. On the flip side, the relatively low-productivity employee may be overpaid in compensation for the shame of being the worst programmer on the team.
For the people that are saying that the "10x more productive" programmer is a myth, I assure you these people exist, but you're likely not one of them (nor am I).
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.
I just read "Linked" by Albert-Laszlo Barbasi and he talked about different kinds of networks. One example is the number of inbound/outbound links you find on a highway map versus a map showing links between airports. The highway map gives rise to a normal statistical distribution with only a few towns having so many or so few roads in/out that they fall far from the mean.
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.
If that is true then I don't think you would expect to see people who are 10X more productive than the average. The tails of the normal distribution fall off very quickly. I think most people who have worked in the industry can think of at least one programmer that they have worked with who was 10X more productive than the average.
yes there are points under the curve out at 10X the mean but they are very, very rare. The normal distribution falls off a cliff. I don't have the reference in front of me but something like 99.6% of the population will fall within 2 standard deviations of the mean. This same issue comes up when people try and predict something like the daily fluctuation of the Dow Jones Industrial average using a normal curve. They think that there are random swings up and down but that large swings of 500 points are more are very unlikely. Then those large swings come along and show everybody that it isn't smart to use the normal distribution to try and model the absolute change in the closing price.
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.
I would have to disagree on two counts. The first point is pedantic, but, in the standard normal distribution, half the curve is over ten times greater than the mean. Of course, that's cheating, since the mean is zero, but it's not impossible for the relationship between the mean programmer productivity and the standard deviation to allow for large number of programmers with 10x the mean productivity.
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.
Ok, I spent way more time thinking about this than I should have :)
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 :)
So you think it's meaningful to talk about working programmers with negative productivity. But competent management would fire or re-task such workers. Perhaps negative management skill is also meaningful, then.
I've been frustrated over the years to see programmers rewarded for putting in extraordinary amounts of effort - often due to crises of their own making. The guy that designs and builds a service that's delivered on-time and works without major issues gets ignored but we'll heap praise (and money) on the guy that has to work 80 hour weeks for 2 months after the due date or the guy that works all weekend to fix a bug that he caused in the first place.
Yes! I've seen the worst team in the company get praised, wined and dined because they pulled the customers bacon out of the fire - the fire they created by bad programming.
> 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.
I think the brick-laying analogy is a lot more on target than John realises.
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 )
> most productive programmers are orders of magnitude more productive than average programmers.
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.
Salary has nothing to do with work.
Getting and keeping high salary is all about luck and cunning.
Your work does not have to be extremely useful or valuable.
I don't know where this idea that world is fair comes from.
Here are my random thoughts about the reasons (not in a specific order):
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."
A lot of the discussion seems to assume that a given developer has a constant level of productivity and hence, can be salaried according to that level.
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? :)
I see quite a few comments addressing the fact that there's no way to directly measure 'productivity' of a programmer. And there's also the questioning of whether the 10x figure is made up or not (Its not. There's research that attempts to measure productivity, but its always by some proxy measure, usually time to complete a task. There was a post not too long ago that collected various articles on the origin on the 10x number).
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.
To complain that programmers are not paid in proportion to their productivity is to imply that other professions are paid in proportion to their productivity. That is very rarely the case. Sales, perhaps, is the only area where there is a clearly defined performance metric that drives compensation. In any other role, there are people making roughly the same salary with substantially different levels of performance.
Sales is hardly perfect in this respect. It's harder to game sales stats, but I have yet to see a sales ranking/commission system that wasn't gameable somehow.
For the most part I think what the user edw519 tells is perfectly correct. If you sure of your competency and confident that you can actually be 10x or 100x more productive than other than you must work for somebody who pays you 'per unit of work done' rather than somebody who pays you lump sum.
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.
One option I haven't seen anyone mention is freelance development, especially at the higher end. This:
--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)
I have worked with someone who was 10x more productive than the rest of the team. His contribution was acknowledged, he had a fancy job title and he was paid more. There were 2 issues with this guy:
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!
This is the animated TED talk that I referenced before on motivations. I'm sure you've seen this before, but still interesting in this context: http://www.youtube.com/watch?v=u6XAPnuFjJc
Huh. My first thought was "Maybe the reason we don't pay some programmers 10x what we pay others is that the ones who get paid less would quickly find out and then get resentful".
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?
As 83457 put it - HR should never be tasked to hire a programmer. Same with recruiters. You can give them a set of criteria to weed out people by (they shouldn't be sending you .net resumes if you are a PHP shop) but the end task of choosing a developer should be vetted by someone who can determine if the candidate is good. Either a technical director (with actual knowledge) or by peer review from your current programmers.
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 :)
The problem with this entire article is the very first sentence. "The most productive programmers are orders of magnitude more productive than average programmers."
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?
Your startup is your new resume. Extremely productive programmers are being paid $1M a head in a talent acquisition plus salary with a 4 year lock in. That means that highly productive programmers are work $350k a year.
All you have to do is build your startup and get acquired to get that salary. :)
Am I the only one to think that it's time some asked the question, 'why are mediocre/sub-standard (and even non-programming) developers still being paid a good programmer's salary?'
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.