Why programmers are not paid in proportion to their productivity (2009)

The actual real reason is that most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company.<p>The company downfall is always hiring the first &quot;manager&quot;. After that managers will just keep inventing excuses to expand their dominion, until the company is 50% management, there&#x27;s more people than actual work that needs being done, yet all work grinds to almost complete halt.<p>Even if a given individual is not a self-serving moron, they are overpowered by the dynamics of the group and they either comply and play the game, or they are out.<p>The bigger the group, the easier it is to hide in a corner with incompetence, stupidity, politics, optimize for your personal gain, and the harder it is to actually competently judge the performance and contributions of each member.<p>Hierarchies make people optimize for raising in the hierarchy, and accumulating power, at the expense of actually doing what the group needs.<p>The way human groups organize in practice is pretty much always complete dysfunction without motivated, benevolent and competent leaders at the very top. Our own self-interest combined with natural bias and blind spots in aggregate always win. And the dysfunction grows more than linear with the size of the group.<p>At the corporate size there is practically no actual owner&#x2F;leader overseeing things (even the board is just bunch of self-serving assholes), so you effectively get a smaller and private replica of a communist state. If you read anything about communist state politics and management you&#x27;re going to see 1:1 with every corporation you&#x27;ve ever worked in.

At one company I worked at, after I quit, they had to hire 19 engineers to rebuild the piece of software I built on my own. What took me 9 months took them a year. I quit because they wouldn&#x27;t give me a raise. Even the CTO recognized to me that I was the most skilled programmer there. I don&#x27;t think talent is that hard to spot and while I agree measuring programming productivity in a concrete manner is difficult, knowing who&#x27;s above average isn&#x27;t hard.<p>Seems more to me that managers just don&#x27;t want to fork over higher salaries and engineering is looked at as a cost center to be minimized.

BTW: The linked article is from 2009.<p>My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on stackoverflow, that&#x27;s not considered productive programming. That&#x27;s usually a sign of incompetence. Also, pulling in huge frameworks to solve some simple acute problem is also not considered productive programming. It may solve the problem at hand (poorly, usually) but it will create huge future costs for maintaining the dependencies, applying patches, and following changes.<p>In my world, productive programming means solving an actual problem quickly and effectively, and in a way that minimized legacy costs in the following years. The code you leave behind is easy to follow, has few side effects or even none, is not just correct but obviously correct. And where it is not correct, it is easy to fix. You leave behind code that has documentation and good unit test coverage. Code that you needn&#x27;t worry about. THAT is productive programming in my world.<p>That said, I have personally witnessed 10x productivity differences under these definitions, too. My observation is that poor programmers get stymied by frameworks and environments they hardly grasp, and are either deathly afraid to touch anything or they try something and it breaks in horrendous unanticipated ways so they get paralyzed.<p>A 10x programmer will not be paralyzed by fear but they will approach systematically. First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you&#x27;ll know if you broke something because your unit tests will fail. Then you can start ripping out chunks of legacy code that is not actually needed anymore or was there to solve some hypothetical future problem that never materialized.<p>To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit.<p>The measure of good programming is not whether you solve that problem (that is a given) but by how much future headache your solution causes. Leave the world better than you found it.

I feel that programming ability rises by roughly an order of magnitude every decade, as one learns more approaches to problem solving.<p>I&#x27;ve been programming over 30 years, so my daily productivity may be something like 1&#x2F;1000 of what I&#x27;d be capable of if I had something like JARVIS in the Iron Man movies.<p>That&#x27;s a total humblebrag and I&#x27;m no Tony Stark, I&#x27;m not saying that. Just that I&#x27;m concerned that if we view programmer aptitude through the lens of productivity instead of the complexity of problem that can be solved, then programmers will eventually find themselves underemployed.<p>For my mental health, I had to let my ego die and begin to look beyond my personal contribution (which will always pale in comparison to my dreams). I view programmers now as enabling larger groups of people to work and support their families. In a very real sense, we sacrifice our human potential on minutia so that others don&#x27;t have to. Like how doctors move to small towns to help people instead of landing large salaries at major hospitals. I&#x27;m sad that people who win the internet lottery are often spared ego death, so hoard their wealth and never wake up to a greater understanding of how they could pay it forward outside of models built on the profit motive.

Developer productivity specifically and knowledge work in general is extremely hard to measure.<p>Not only that, it is also very subjective. What is valuable to one person might be a liability to another.<p>Just the other day I looked at results from a developer who spun a huge mess of AWS infrastructure, microservices, lambdas and so on all to solve a very simple problem. He probably congratulated himself for a job well done.<p>So the success of this person would largely depend on the manager he has. For example, how much the manager values simplicity.

<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Pareto_principle" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Pareto_principle</a><p>If programmers were paid in proportion to their productivity most (maybe 80%) would starve to death. They would be better off providing data entry for minimum wage. On the other hand, those that are productive (aren&#x27;t afraid to write original software) would be lavishly rewarded beyond most of our imaginations. Their output doesn&#x27;t even have to be high quality.<p>This would resoundingly benefit everybody. People doing a job just to put an unqualified body in a seat are an economic drag. Their contributions are often a net negative purely existing to qualify their own existence. For example, does the user actually want 10mb of JS executing for 10 seconds on every page load just to put a few lines of text on the screen? Does the user care that it took a large team of software engineers to pull that off and waste their time without which those software engineers would have to do something else? No, the user won&#x27;t shed a tear.<p>Yes, there are 10x developers. Yes, most software developers have no idea what a 10x developer is and are absolutely incapable of recognizing one even when working adjacent to one.<p>The only valid question is why the industry tolerates, and even infantilizes, hiring people not qualified to do this work at their own expense. The simple answer, also economically valid, is because it takes them less effort to make a knowingly bad decision than confront the risk of defining what comprises valid selection criteria.

How do you measure the productivity of someone that can wade into a horribly buggy 10 year old piece of code that has terrible edge conditions and is integrated with other 10 year old pieces of code that you can&#x27;t break, and you need to work out how to fix it and test it?<p>I often feel like I&#x27;m pretty slow in terms of my output, but I generally wade into really tough problems after other devs&#x2F;teams have flailed at them for weeks and I manage to solve the problem. Does that make me a &quot;10x programmer&quot;? I don&#x27;t tend to greenfield anywhere near as fast as that so I can&#x27;t claim to have written some 40,000 line program from scratch in a month. I can write some 100 line patch in 2 weeks that nobody else could come up with though and keep some 10 year old 40,000 line production critical codebase still running.

true.. adequate programmers code exactly what you tell them to..and even then it may not be great. Great engineers step back and ask &#x27;why are you asking me to do this?&#x27;..(probably silently).. which inevitably leads to a more refined solution, or none at all when they realize you don&#x27;t actually understand the actual problem, more likely just a symptom of it. Nobody remembers what didn&#x27;t happen and they certainly don&#x27;t pay you more for that.<p>This is usually a function of experience, but not necessarily. Productive developers are constantly mapping each development requirement into a larger context of the &#x27;system processes&#x27; at large, cross-referencing their (usually deeper) understanding of the technical, business, and political issues involved (all involving some acquisition or expenditure of &#x27;energy&#x27; in the general sense). Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets. It&#x27;s the main reason senior development is so difficult to hire for..

The most productive programmers are the ones that make other programmers more productive. Making a tool or library or other piece of reusable infrastructure that increases the productivity of 100 engineers by 10% is 10x productivity.

&gt; Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for.<p>And how do you balance your urge to say &quot;this feature is not what brings us the most value&quot; in a team setting where the business&#x2F; product decisions should be evaluated by the product owners?<p>I&#x27;ve only worked with one product owner who actually appreciated the engineers challenging product decisions and was capable of actually changing priorities based on our feedback. He didn&#x27;t always change his mind, but I know that he was always listening and never made me feel like insubordinate little child.<p>Most business and product people may let you share your thoughts, they smile and nod, and ignore everything you said. Do it a couple of times, you will be labelled as &quot;not a team player&quot;. Do you want to know how our similar features performed in the past? You want to challenge whether some SAFe ceremony actually works for your &quot;autonomous&quot; team? You want to recommend hiring an analyst because the whole product flies blind without proper data? Want to take a step back and think about whether a project that takes many man-years to complete is bringing the business or the users any value? Too bad, shut up and code.<p>I had to work too many times on a &quot;super urgent, hundred million dollar feature&quot; and &quot;non-negotiable legal requirements&quot; that still hide behind a feature toggle.<p>In practice, you can figure out in a couple of months whether the person in charge of product vision is capable of listening or not. If they are not, you&#x27;ll either learn how to keep your skepticism to yourself and do as you are told, or you start looking for a new position (or going solo).

Because programmer usually is not businessman.<p>That is, first you bet, then you could win, or lose.<p>This is totally different lifestyle and different style of thinking.<p>And that&#x27;s not all. In reality typical win means, you just got much more than typical bank deposit give. For example bank give 10%, but you got 20%.<p>And this also consider much different knowledge set and skillset, than typical programmer think.<p>For real business much more important than abstract loc, how good you know business (and&#x2F;or lifestyle) of your client, and how good your code fill his needs.<p>Separate important problem, what people say they need, does not really equals to what they really need.<p>And one also very important part of this puzzle, sometimes you must become salesman and convince your client to buy your solution, which client don&#x27;t understand, but you sure, it is what he need, and may be more important to you, to what you invested your time and money.<p>And for salesman it is very typical, to have ZERO permanent part of compensation, live only from percents of sales. And to be honest, sales are not 100% depend on salesman skills, but have few peaks on few famous parts of year, and also have huge known decline periods.<p>So, if programmer want to be paid in proportion to his VALUE, he will deal with all things I mentioned. And yes, in many cases, this means, to become much more salesman and much less programmer.<p>To be honest, in usual developed country it&#x27;s worth it. In developing country, successful programmers paid comparable to big bosses and to media stars.

&gt; Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem.<p>This snippet is at the heart of it for me. The best analogy I give is a drawing of Pablo Picasso&#x27;s horse. After many years of understanding your craft, a developer knows how to provide the most value with the least complexity required. It&#x27;s not because the developer doesn&#x27;t want to write code. It&#x27;s more that they understand how to maximize the tools available for the system they work in. Reduction of complexity is better than the addition of it over the long term.

I&#x27;m so glad to see this article on the HN front page. It&#x27;s spot on and it&#x27;s what makes coding such a difficult career and why it feels so non-meritocratic. It&#x27;s happened to me a couple of times that I had to work under the leadership of someone who was far less skilled than me. It&#x27;s a painful experience and it can take over a year for non-technical directors to figure it out; also, by the time they start to suspect something is wrong, they may have become friends and don&#x27;t want to admit to themselves that their chief engineer is simply not good.<p>It&#x27;s easy to say &quot;Well, just quit and join a different company&quot; but this trivializes how incredibly widespread this problem is across all companies including very financially successful ones. They have a huge amount of money; they can throw thousands of engineers at any problem; they don&#x27;t need to be efficient to stay afloat and they usually aren&#x27;t... And usually companies which are already earning a lot of money don&#x27;t care about anything other than merely staying afloat - Everyone is just coasting along thanks to their market monopolies.<p>In my last role, I was presented with what could have been a once-in-a-lifetime opportunity. It could have worked out really well but it worked out terribly because the top engineer was not qualified for the job and neither were the founders. It&#x27;s not like I can just turn around an find another opportunity like that the next day; it took 10 years and a lot of things had to line up exactly right to get that opportunity. This was the best financial opportunity I had come across in over a decade. I still think it could have worked out very differently.<p>Talent and skills don&#x27;t attract such financial opportunities in this industry; it&#x27;s all about luck. It&#x27;s not even about social connections because people in this industry have an obsession with &#x27;warm introduction&#x27; and this creates a huge amount of friction - It&#x27;s literally impossible to socially network your way to a good opportunity; if you don&#x27;t try hard enough, you won&#x27;t get any opportunities. If you try too hard, investors or founders will feel threatened by you - It will make them uncomfortable. This industry is full of sheep; they&#x27;re terrified to do anything differently than their peers, it doesn&#x27;t matter how rich they are. They have FU money but they&#x27;re terrified to say FU. It makes 0 sense to me.<p>For the average person who is or aspires to be above average, the tech industry is a kafkaesque nightmare. You have to be content with being average and rolling the dice. This means you have to content yourself with mediocrity and work on your people skills instead.

The nature of labour and productivity has been understood by classical economists for hundreds of years now. You are not paid in proportion to the excess value you produce, or else you would be an owner of the company.

I have given the problem of how to correctly compensate according to productivity some thought, and one idea I keep revisiting are auctions.<p>Assuming that you have a fairly good idea of what needs to be done and how to divide it up into reasonable chunks, I could imagine an auction where you just create a list of things and programmers in your company freely bid on them with how much money they’ll be paid for completing each task.<p>The system doesn’t have to be complete. Imagine auctioning off the top x% most urgent bugs to be fixed every sprint, reviewing PRs, etc as extra work.<p>There are some very big flaws with this approach, namely that requirement specifications are basically impossible to get right and review and that incentive structures are not well aligned:<p>- If I bid $5000 to fix a bug, but introduce $10,000 of technical debt into the codebase, then I just made money by externalising the cost.<p>- It makes you compete with your colleagues for buds and that creates a really hostile work environment that probably drastically decreases workout pace efficiency<p>So it’s just been an idea that’s been floating around my head, but maybe an econ grad student can work something out from this.

It’s because productivity is a function of the environment wherein one is practicing.<p>E.g. if someone really believes they can make 10x more they should quit and start their own company to do that.<p>I’m in an organization where I am considered super productive, but I know that is a quirk of how I interface efficiently with this particular organizational structure. If I was off on my own, I wouldn’t be nearly as productive.

I think the other thing that goes on these days is that, for better or for worse, DEI initiatives have flattened pay bands for everyone. I&#x27;m not making <i>any</i> comment about whether certain subgroups are over or under paid, but it should be quite obvious that the incentives mean that hiring managers are now terrified of overpaying certain groups and equally terrified of underpaying others.<p>When, as this article points out, outcomes are extremely difficult to measure for any individual programmer, this results in less variation of pay yet still with wide variation in real underlying productivity.

I&#x27;ve been thinking about this myself. I&#x27;m highly productive and always avoid unnecessary complexity. My most common question is: Can we not do it?<p>However, when I worked for a company I did get bigger promotions but that it was in the 10-20% range. I was literally 2-3 times more productive than people who got paid 30-40% less.<p>If you take a big picture look, you will see things get more obvious when you give it enough time. In 10 years the difference will be big enough (I think).

There is little semblance of meritocracy, especially in larger companies where salaries are not even determined on an individual basis, but more as a function of years worked and meeting the minimum bar to sustain good yearly ratings.<p>The structure itself is preset, and no matter how effective you are in your role, companies generally recognize that competing for talent has a narrow value range. Companies are hurting for sound product ideas and good business plans more than they are for talented people to implement them. As long as all of their corporate peers are generally in the same boat, turnover is merely a statistic. Talent comes and goes, and you only need to acquire at equal rates to your talent losses.<p>Hiring is just as hit or miss, and article after article here demonstrates that corporate America has given up trying to innovate on that process. If companies could bureaucratically recognize talent internally, then maybe they could hire better candidates. But that’s expensive, and like I said before, the value proposition is limited. If they hire a 10x person, it’s a risky investment anyway, because they’ll leave a 10x hole to fill. It’s just easier to hire 10x people, which has better statistical stability in turnover.

Cause no one is, that would be called participating employees into company&#x27;s profit.

Here&#x27;s what I&#x27;ve noticed in my career so far. It&#x27;s difficult if not impossible to assign an actual concrete value to programmer productivity. This makes it difficult to compare programmers side by side and assign a true value to each of them. Some companies rank developers but it&#x27;s done subjectively. This fuzziness allows businesses to not pay fairly for extreme productivity (and conversely, forces them to pay too much for crappy productivity). Usually at any company there are one or more 10x programmers who do most of the work and a ton of mediocre developers.

I have found that the most effective programmers are diplomats, they consider consequences and don’t dive into making unconsidered fixes. They understand that the code they write is not only for themselves and that nothing, especially not people, works in isolation. My preference is for clarity and comprehension over breakneck, manic late-night cola-fueled, pizza-box programming sessions. This isn’t The Matrix…

Past comments: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1012381" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1012381</a>, <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2485098" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2485098</a>

Programmers are paid the market rate for their field, level, geographic area. It&#x27;s just supply and demand.

Besides this being an extremely utilitarian way to view of humans that obfuscates inherent value of human beings, it is a general problem with wage labour under capitalism, where only capital earns proportional to its “value”.<p>I think we should focus our energy more on the question how we can provide everyone according to their needs than how utilizable they are, if we want to live in a more healthy and thriving society than we currently do! At the end there is really no need to give some people 10 times more just because they are productive in a certain way. And this calculation already fails as soon as we add more dimension to it, e.g. someone might not be producing 10 times more productive code but maybe they do offer a lot of social skills that make everyone in the team have a better time during work hours.

Sometimes to make a project work you need all types of work, not only high visibility, high impact work that gets management attention and raises.<p>Good example is promo process at a particular large tech company - you win promo by picking a project that is high visiblity, appears difficult, standalone piece with &quot;ownership&quot;. Maybe 25% of work that needs to be done meets this criteria.<p>It&#x27;s hard to get promoted for &quot;product excellence&quot;. They tried to do a push a few years ago, when I was there. You won&#x27;t get promoted for fixing an issue that annoys millions of users or maintaining a succesfull product, unless you really build a case around that with data, case studies, etc. You would spend more than half of your effort on proving that your work is valuable.

&quot;salaries usually fall within a fairly small range in any company&quot;<p>I don&#x27;t think so? I&#x27;ve heard that some top-tier talent makes $500k annually while most beginners make $50k annually. Isn&#x27;t that a 10x difference which would be in line with 1x beginners vs. 10x pros?

no one gets paid on proportion to their productivity. artists do not, actors do not, managers do not, politicians certainly do not. you get paid according to your perceived market value unless you contract per well defined project(not per hr)

The incentive structure for an above average programmer is usually somewhat broken, though stock options can theoretically patch this up some.<p>The way to get maximum return on your above-average output is to go into business for yourself.

I am (among other things) a programmer, I absolutely do not management to have yet another string to pull me by, routinely adjusting my pay according to whatever social-engineering game they choose to decide &quot;productivity&quot; by.<p>Plus, for some of my work - it might seem even to a &quot;fair&quot; lay-person that I&#x27;m doing practically nothing except wasting my time for a year, then do a year&#x27;s work in a couple of weeks. At other times, my contribution might be _preventing_ the introduction of poorly-designed or faulty code; so, in a sense, negative productivity...

If compensation was simply measured by productivity relative to your co-workers - and let us assume this is not a zero-sum game, and that your compensation independent from company revenue - wouldn&#x27;t the most proficient and productive programmers seek to work with much less productive co-workers? Simply because they&#x27;d come out at the top, and get most compensation.<p>Compare that to joining a &quot;all-star&quot; team, where there&#x27;s much less variance. You&#x27;d get paid less - because the distance between best and worst programmer is much smaller?

&quot;Programmers are most effective when they avoid writing code&quot; is the crux of this article, and stated like a fact. IMO this is not as obvious as the author believes, and needs a solid defense.

This touches on the very very obvious tension here that I think needs to be understood and stated more clearly:<p>Software, in theory, is frictionlessly infinitely reproducible. We now know that there are quite a few 10x, 100x, 1000x programmers out there, and yet a lot of people still getting paid to write code, which is probably a massive waste of time.<p>I&#x27;m not sure how we get to collectively recognizing this inefficiency, but something to try would be &quot;more liability (some liability? like any liability at all?) for bad&#x2F;harmful software.

Um, they are paid in terms of their productivity. However, it&#x27;s not how productive they are as a programmer, but how their work translates into business value.<p>While measuring programmer productivity is not trivial, measuring the value of the average programmer on the revenue generated is much easier. For this reason, an average programmer at Facebook will be earning a lot more money than a great programmer at a small regional bank.

Define productivity.<p>A previous colleague at my company rushed out a load of new code in 3 months, then left the company. What a steaming pile of crap he left us. After nearly a year and a half we have had our first week without support requests related to this. This guy wrote order of magnitude more code than the others on the team, but we have spent many more hours cleaning up the crap he left.

&gt; Programmers are most effective when they avoid writing code.<p>I understand the sentiment, but there&#x27;s weak evidence to measure effectiveness by offloading work to others.<p>Not writing code for non-core purposes is not the same as avoiding it. Nor is avoiding policy-mandated code (things like tests and build scripts) making someone more effective, when it&#x27;s shifting the load to others.

It&#x27;s because they&#x27;re milking inventions they didn&#x27;t invent for salaries that don&#x27;t reflect their intrinsic value.

Because engineering is considered as &quot;liability&quot; while sales are &quot;assets&quot;.<p>Investment in more sales gives almost immediate gratification while investment in engineering takes longer and carrying bigger risk.<p>Thus majority of senior execs never like conversation about more investment into engineering

Because compensation should be proportional to investment and both the 1X and 10X programmers invest the same thing, eight hours of their time each working day. In practice things are more complicated as this creates undesirable incentives but I think the general point stands.

In most cases, end customers don&#x27;t eat or use code.<p>Code is a vehicle for delivering value to customers.<p>Developers are not the only one contributing to creation of product.<p>In cases where you &#x27;can&#x27; establish direct correlation between more&#x2F;better code = more margin, then you can flex your leverage.

For some reason this thread makes me think of this Steve Balmer on KLOCs rant.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=kHI7RTKhlz0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=kHI7RTKhlz0</a>

I don&#x27;t understand, how is a company supposed to make money at all if the worker is paid proportionally to their productivity?

I find a lot of my productivity boils down to knowing what work not to bother with. This can be hard to value.

In short, Programmers are not great Negotiators. Thus, they get &quot;the business&quot; from The Business.

You can&#x27;t just guess at which 25 percent of your employees not to pay.

Because that would be a stupid, factory floor mentality?

Oh God, are we <i>still</i> discussing 10x programmers?<p>Please let&#x27;s not.

10x engineers don&#x27;t exist, or if they do, they are less than .1% of engineers. 2x engineers, sure, 2.5-3x even, but 10x? A fantasy, a pure invention with no data to back it up. Factor that into your analysis.