Pay Your Programmers $200/hour

2011 December 30 05:42 PM

Update: more comments on reddit and hacker news.

If you are hiring programmers, you should pay them $200/hr. This breaks through otherwise impenetrable psychological barriers, helps solve the agency problem, and ensures you are only hiring programmers when you really need them.


$200/hr is an open declaration of your expectations. It states that you are expecting to hire both a professional and an expert in the field.

As a programmer, I treat contracts that pay me $200/hr differently from jobs/contracts that pay me $65/hr equivalent salary in two key ways. First, I treat issues and requests with far greater urgency. I’ve been on vacation when a call comes in, the customer requesting a new feature. I will go back to my hotel room immediately and build it; the high rate means its easy to justify this to my spouse - in fact, she totally supports it. I would simply never consider behaving this way under normal job conditions, because its not worth it. The worst that might happen is I lose my job, but there are a glut of $65/hr jobs available.

Second, and really this is a huge benefit to the employer, I generally do not charge for what I consider to be “learning” time. If you pay me $200/hr, I will only charge for the amount of hours that I believe an expert in the field might charge. I expect, with some variation in degrees, most programmers will behave this way. For example, I was given a project that involved coding a ton of low level C. I hadn’t coded any C in a decade. I spent two 16 hour days getting my c legs back, but I did not charge the client at all for this. I also did not charge for any bugs that I felt an experienced systems programmer would not have made. Overall, this had the effect of roughly halving the number of hours I billed.


But guess what? I didn’t resent the client at all. In fact, I was delighted and so were they. I got to ramp up on some rusty skills and know they value my work, and they got a product that met all their needs, on-time and on-budget.

And the next time my client needs something? They shoot right to the top of my priority list. And they benefit from an even faster and higher quality turn around, because I only need to brush up on C once, I don’t repeat the same mistakes, and I learn more about their business and the types of features they need but may not know to ask for.

You also never need to worry about the programmer leaving you. If you have a ton of work to send their way, they will do it and pocket huge surpluses on their labor. If you can only send them a few hours per week, they will still be able to live comfortably and enjoy their free time. Its win-win for contractor and client.

On a political note, high pay correlating with high expertise is more true among programmers than other professions, like lawyers and doctors, because the only reason other professions routinely charge higher rates is because they have artificially constricted supply through licensure requirements - you are effectively coerced into paying a high rate. But when you pay a programmer a high rate, there is no element of coercion whatsoever. This recognition of value is big loyalty booster all by itself.


For the employer, trust is less of a problem when you pay a high rate on contract. If the programmer doesn’t deliver, fire them. If they deliver low quality goods and don’t fix it, fire them. If you are unhappy for any reason at all, fire them.

With a lower paid programmer, its much harder to justify rapid firing. You might be tempted to do a cost/benefit analysis - maybe you suspect that programmer is slacking, but you still feel you get a good bit of work out of them. This is a fatal error. First, there is no other market on the planet where the information asymmetry between vendor and client is greater. The programmer can spin any tale they want, and you will have absolutely no way to dispute their claims. Second, ineffective or disaffected programmers are not just zeros, they are are negatives. Really big negatives that damage your business.

Optimal Resource Allocation

If you cannot afford $200/hr, you should not be hiring programmers because you are working on a problem that addresses an insufficiently large market.

Which situation would your rather be in: risking $100,000 investment for a $200,000 return, or risking $1,000,000 investment for a $50,000,000 return? This might seem like a self-answering question, but virtually all programming hires fall into the first category. Nearly every IT department and most businesses are focused on the wrong class of problems. And the problem is that this is a gross misallocation of resources, because there are tons of opportunities in the second category.

When you focus on a problem in the second category, a lot of silly business problems go away. Super tight controls on payroll and expenses are no longer needed. Schedule slips are less of a problem and less likely to occur. Morale improves from working on a big, important problem.

On the other hand, when you are in situation where paying a programmer $75 instead of $65 would destroy the economic justification for the hire, you are in an extremely fragile state. All the problems above are exacerbated and you are one micro-economic shift away from bankruptcy or irrelevance.

blog comments powered by Disqus