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

The company downfall is always hiring the first "manager". After that managers will just keep inventing excuses to expand their dominion, until the company is 50% management, there's more people than actual work that needs being done, yet all work grinds to almost complete halt.

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.

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.

Hierarchies make people optimize for raising in the hierarchy, and accumulating power, at the expense of actually doing what the group needs.

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.

At the corporate size there is practically no actual owner/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're going to see 1:1 with every corporation you've ever worked in.

Seems more to me that managers just don't want to fork over higher salaries and engineering is looked at as a cost center to be minimized.

My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on stackoverflow, that's not considered productive programming. That'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.

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't worry about. THAT is productive programming in my world.

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.

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'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.

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.

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've been programming over 30 years, so my daily productivity may be something like 1/1000 of what I'd be capable of if I had something like JARVIS in the Iron Man movies.

That's a total humblebrag and I'm no Tony Stark, I'm not saying that. Just that I'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.

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't have to. Like how doctors move to small towns to help people instead of landing large salaries at major hospitals. I'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.

Not only that, it is also very subjective. What is valuable to one person might be a liability to another.

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.

So the success of this person would largely depend on the manager he has. For example, how much the manager values simplicity.

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't afraid to write original software) would be lavishly rewarded beyond most of our imaginations. Their output doesn't even have to be high quality.

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't shed a tear.

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.

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.

I often feel like I'm pretty slow in terms of my output, but I generally wade into really tough problems after other devs/teams have flailed at them for weeks and I manage to solve the problem. Does that make me a "10x programmer"? I don't tend to greenfield anywhere near as fast as that so I can'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.

This is usually a function of experience, but not necessarily. Productive developers are constantly mapping each development requirement into a larger context of the 'system processes' at large, cross-referencing their (usually deeper) understanding of the technical, business, and political issues involved (all involving some acquisition or expenditure of 'energy' 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's the main reason senior development is so difficult to hire for..

And how do you balance your urge to say "this feature is not what brings us the most value" in a team setting where the business/ product decisions should be evaluated by the product owners?

I'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't always change his mind, but I know that he was always listening and never made me feel like insubordinate little child.

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 "not a team player". 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 "autonomous" 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.

I had to work too many times on a "super urgent, hundred million dollar feature" and "non-negotiable legal requirements" that still hide behind a feature toggle.

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'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).

That is, first you bet, then you could win, or lose.

This is totally different lifestyle and different style of thinking.

And that'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%.

And this also consider much different knowledge set and skillset, than typical programmer think.

For real business much more important than abstract loc, how good you know business (and/or lifestyle) of your client, and how good your code fill his needs.

Separate important problem, what people say they need, does not really equals to what they really need.

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'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.

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.

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.

To be honest, in usual developed country it's worth it. In developing country, successful programmers paid comparable to big bosses and to media stars.

This snippet is at the heart of it for me. The best analogy I give is a drawing of Pablo Picasso's horse. After many years of understanding your craft, a developer knows how to provide the most value with the least complexity required. It's not because the developer doesn't want to write code. It'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.

It's easy to say "Well, just quit and join a different company" 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't need to be efficient to stay afloat and they usually aren't... And usually companies which are already earning a lot of money don't care about anything other than merely staying afloat - Everyone is just coasting along thanks to their market monopolies.

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'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.

Talent and skills don't attract such financial opportunities in this industry; it's all about luck. It's not even about social connections because people in this industry have an obsession with 'warm introduction' and this creates a huge amount of friction - It's literally impossible to socially network your way to a good opportunity; if you don't try hard enough, you won'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're terrified to do anything differently than their peers, it doesn't matter how rich they are. They have FU money but they're terrified to say FU. It makes 0 sense to me.

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.

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.

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.

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:

- 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.

- It makes you compete with your colleagues for buds and that creates a really hostile work environment that probably drastically decreases workout pace efficiency

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.

E.g. if someone really believes they can make 10x more they should quit and start their own company to do that.

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.

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.

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.

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).

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.

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.

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.

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 "ownership". Maybe 25% of work that needs to be done meets this criteria.

It's hard to get promoted for "product excellence". They tried to do a push a few years ago, when I was there. You won'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.

I don't think so? I've heard that some top-tier talent makes $500k annually while most beginners make $50k annually. Isn't that a 10x difference which would be in line with 1x beginners vs. 10x pros?

The way to get maximum return on your above-average output is to go into business for yourself.

Plus, for some of my work - it might seem even to a "fair" lay-person that I'm doing practically nothing except wasting my time for a year, then do a year'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...

Compare that to joining a "all-star" team, where there's much less variance. You'd get paid less - because the distance between best and worst programmer is much smaller?

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.

I'm not sure how we get to collectively recognizing this inefficiency, but something to try would be "more liability (some liability? like any liability at all?) for bad/harmful software.

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.

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.

I understand the sentiment, but there's weak evidence to measure effectiveness by offloading work to others.

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's shifting the load to others.

Investment in more sales gives almost immediate gratification while investment in engineering takes longer and carrying bigger risk.

Thus majority of senior execs never like conversation about more investment into engineering

Code is a vehicle for delivering value to customers.

Developers are not the only one contributing to creation of product.

In cases where you 'can' establish direct correlation between more/better code = more margin, then you can flex your leverage.

https://www.youtube.com/watch?v=kHI7RTKhlz0

Please let's not.