Why programmers are not paid in proportion to their productivity (2009) | Hacker News Reader

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

johndcook.com

That's the problem with being so good that you make it look easy. Everything thinks that it's actually easy, and no one gives you credit for it.

The military periodically runs war-games, in order to assess the effectiveness of various tactics/strategies/leaders. I wonder how much we would learn if the major tech companies periodically did the same thing. Come up with a complex task, spin up multiple groups to work on it in parallel, and examine what exactly each group does and how well that turns out.

The military's peace-time job is training. Companies do not have peace-time, so they don't have time to train like that. It's too expensive. (Or at least, that will be the argument.)

Google does this to a degree. They sometimes give the same project/goal to multiple groups and pick the winning one.

Unfortunately, in the long run this decreases morale because you don't know if the project you are working on will ever be used

> Google does this to a degree. They sometimes give the same project/goal to multiple groups and pick the winning one.

Yep, we've seen that with their messaging platforms.

I'm reminded of The Soul of a New Machine[0] by Tracy Kidder. Essential reading, even today.

[0] https://www.goodreads.com/book/show/7090.The_Soul_of_a_New_M...

>Everything thinks that it's actually easy, and no one gives you credit for it.

It's not clear to me what you mean by getting credit. I'm usually one of the 1-2 "go-to" people on my dev teams. I'm recognized for it constantly. I get comments like, "I wish you were on all our projects." Meaningful financial recognition is less common, but I occasionally get nice bonuses. FWIW the things I regularly get credit for have little to do with code quality. The things I get recognition for are bringing disparate teams together and leading them to solve complex problems. I can only recall having received 2 compliments for my coding ability, by other coders, in almost 20 years of professional coding.

I've heard people claim the "I bring disparate teams together..." before. I don't know the details of your particular situations but in the situations I've been involved, both times, it has been people taking credit for the work of others.

Me too. There are people at my current job who presents the work of others and get a lot of credit for it. The boss has no idea what the builders are doing even.

In the most recent case I can think of the identity management on a big bank's 16 mainframes was being changed. There were 4 technical teams including QA plus 2 outside vendors and 2 business teams representing mainframe users and identity management system support. And there were a few bad actors in the mix. About halfway through the project several of the teams started refusing to have meetings unless I was present even if the subject had nothing to do with me, "You're the only one who knows what's going on around here." None of the technical teams could understand the lingo of the other technical teams. So I had to figure that out and translate for everyone. I helped the QA team write test scripts for all the systems involved, not just mine. I helped front-end user support write up troubleshooting guides on systems that weren't mine. And I even wound up assisting one of the other dev teams debug code. While I did solve a lot of technical problems, the big thing I brought to the table for this project was helping mitigate social problems. I got major personal kudos and a bonus of about 30% of my yearly salary.

You don't pay me to solve your problems at my desk from 9-5. You pay me to do it in the shower, on a walk, when doing my dishes, etc. And I'm surely not going to be time tracking those things.

http://dilbert.com/strip/1995-09-15

> Here's my time sheet filled out in increments of fifteen minutes.

> As usual, I coded the useless hours spent in meetings as "work", whereas the time I spent in the shower designing circuits in my mind is "non-work".

FTA: "Programmers are most effective when they avoid writing code."

I'll take an average coder who only codes what is needed over a brilliant one who is constantly going down rabbit holes unnecessarily.

> brilliant one who is constantly going down rabbit holes unnecessarily

Ha, sounds like an oxymoron

I see that, but one type of really good dev is one who is super focused on the small details, and it seems to be human nature that it's hard to do that well and keep the big picture in your head at the same time.

I think these guys are totally capable of thinking big picture, but they are often just not in that 'mode' and hence the tendency to inadvertently find themselves writing code that if they took a breather and sat back and re-evaluated, probably wouldn't write.

Maybe - I think the missing component is their level of "laziness" as Bill Gates defined it. A brilliant, but "lazy", coder will find the most efficient way to compose a solution that meets the requirements.

But it's definitely not an oxymoron to say that some brilliant coders can go down rabbit holes at the expense of their own (and company's) time and productivity. They may spend lots of time reading white papers, improving a design/implementation/test-suite beyond what is required, etc. It's just these coders don't place a high value on being as efficient as possible from a PM's perspective, but might be able to solve a problem 10x as difficult as the guy who is closing his tickets within hours of assignment.

'efficient as possible' is only measurable in terms of the task at hand. Being smart educated and hardworking does not necessarily make you better at your job if you spend most of your effort tilting at windmills.

At times it really is better for everyone to just move on from a comfortable position and stretch your wings as it where.

I like to call it strategic laziness. Knowing what to do, and more importantly what not to do is key.

This reminds me of the following by General Freiherr von Hammerstein-Equord:

> "I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities.

> Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous."

I'm clever and stupid.

Or you know, writing an entire library instead of filing four PRs against an existing one, with a user base, documentation, stack overflow entries and resume appeal.

Nothing more dangerous than a smart but bored developer.

I would much rather be refactoring code from that guy... I seem to be refactoring the industrious and stupid code.

I'll second that sentiment.

The largest source of your tech debt may in fact be that brilliant one writing volumes of code destined to become the collective headache of future dev teams.

Only building what is needed is only part of avoiding writing code. I'd say that during the first half of my career, I was completely ignorant of just how powerful shell scripting was for increasing productivity and reducing the amount of code that I would need to write and then later have to maintain.

One of the best pieces of advice you can give to a young developer is to learn about the tools already available on the operating system and how to build solutions by composing them via scripts.

It was really only after being a few years into a job where the primary development environment was OpenVMS with a crusty old manager that knew DCL inside and out that I fully understood - and boy oh boy did people think I was some sort of freak 10x developer when in fact I was just writing a few hundred lines of C to fill in the gaps between what I could get for free.

I really hate developing on Windows, but PowerShell is an amazing tool (I saw an interview with the creator who said that he started trying to do a UNIX-like shell but gave up when he realized that it just doesn't fit in the Windows paradigm. So he modeled it off of VMS. If you want PowerShell to act like bash, you're doing it wrong). The pipeline is passing around full .Net objects and the feature set is amazing. If you program Windows for a living and don't learn PowerShell, you're missing out on a lot of free productivity.

Lately, I've been using Linux more and am all in on shell scripting. I am following some advice I got to explore man pages more frequently and it is paying off. I even found an old System V printed manual and sometimes flip through it, finding random commands that I had no idea existed and thinking about how I could use them.

I absolutely love the Linux philosophy. Piping outputs means programs are functions. So I can combine programs to get what I want. The only gripe I have is that bash is a pretty hard language to read and write.

I barf out intermediate state to JSON all the time now that jq is a thing.

I'd highly recommend the xonsh shell for scripting if you're familiar with python: http://xon.sh/tutorial.html

Once you do tutorial and learn the rules for going between shell and python, it's super easy to slice and dice.

I have always disliked that moment of "yes, a shell script is probably the best tool for this job" that then leads me to banging my head against bash syntax for an hour. Python libraries like `sh` are great, but still a little high overhead. Now the twice a month I have to shell script I find to be pretty fun, and I'd highly recommend xonsh.

Great PyCon 2016 talk on it here: https://www.youtube.com/watch?v=uaje5I22kgE

This is very dangerous advice. Modern Linux with systemd and mature programming languages require very little shell scripting. I saw people building deployment pipelines in shell and how ugly it was. I worked with a team doing batch processing in the shell and how many people where needed to make simple changes.

In my view this highlights an issue, which is identifying the 10x programmers, versus the -10x programmers.

That makes sense, but our experience is slightly different.

We have a 20x (not a 10x) programmer. He closes literally 20 times the number of issues that other programmers close for a given time frame. Plus, his issues are almost always fixed or completed properly without needed to be re-opened. So, his actual throughput is greater than 20x that of others.

He is good at what he does, better than almost everyone else put together. I don't care if he goes down rabbit holes, spends 90% of his time walking down the hall mumbling, or if he sits in the break room staring into space. His salary is higher than others in the same role, but not 20x. He wins and we win.

What do you see/what do you think he does differently compared to the rest of the team?

Really, I don't know. He's tried to mentor others but whatever he tells them doesn't "stick". He might be more intelligent than others, and he is intelligent. He could just make better, faster connections constantly. Maybe he just listens to the inner voice and types whatever comes out.

When you ask him, he just shrugs and says he does his job.

If you start solving highly abstract problems (including chess) before you're eight years old, that helps. Deciding you're going to become a concert pianist at eighteen doesn't work if you haven't picked up an instrument before then. You can become a pianist, but not a concert pianist.

Unless one knows that a certain path will turn out to be a rabbit hole, it is by definition not unnecessary.

Good insights. In addition, there are good reasons to think that the value that programmers produce isn't even measurable in any practical way.

A couple of years ago, I spotted a latent bug in a piece of core infrastructure software that would have caused a lengthy world-wide outage of the company when triggered. I can see that that saved the company at least $10M. But how can managers/HR/etc measure such effects? And how can you account for it in compensation, even if you wanted to?

Programmers--like many other professionals--are simply paid the least possible needed to keep them in their seats.

likewise I found a bug on a major UK website that was costing them > 500k£ per week an also early one the web as one of a two person team delivered I a month what another part of the company has quoted as a 2 year project :-(

You should have quoted them a 1-year project, at some eye-poppingly high rate to solve the problem

When you save a company $$$, it's important to bring that up at annual review time, and definitely place it on your resume.

At Google I was explicitly told not to use $ value in my perf review/promo form by multiple managers. There and at other companies i worked for i found that management cares more about revenue (more engagement, new features, releases, etc) than costs (code quality, performance, etc).

Interesting! I have had the opposite experience at smaller companies.

A cynical view might be that in larger companies, the goal setting only materializes as dollar values higher up the chain so that they can benefit from that negotiation leverage.

A less cynical view is that business-speak and goal setting naturally abstracts away from money as you try to manage larger goals down a chain of people.

Maybe its just me but everybody seems to follow this advice in resumes these days. It has gotten to the point where I become more skeptical of the candidate because I highly doubt a single person was responsible for $x million in addition revenue (even if it is true)

I wonder if the best advice now is simply put your impact in non-monetary terms in your resume.

You're right to be skeptical of any claims in a resume. I've seen an awful lot of resume padding.

Be prepared to back it up in the interview.

Unfortunately, mentioning this politically sensitive issue in such a manner would have been career suicide. (And I suspect that this is not rare for such black swans.)

A good accountant can save you hundreds of thousands by spotting misreported line items. Bugs in your accounting so to speak.

Being able to demonstrate tech cost savings in monetary value is a very powerful skill to have come negotiating time.

I'm generally baffled when companies opt to hire a junior dev for ~$110k, when an additional 30% more income can get them someone 10x more productive.

Or they spend the +30% and get someone who’s just as productive or 10x less productive. It’s not a magic price performance formula.

Have you ever worked on a team with only senior people?

Nobody wants to do any grunt work. So everything turns into an overly automated nightmare.

Or they can get two competent testers. :)

I've told my boss: You can get two junior technicians for what you're paying me, if hours of "productivity" is what you're measuring.

Source?

This also happens in practice because the super experienced 10x guy has not balanced a RB tree or some similarly 100% solved std library algo in practice for 20 years and won't even get the job. The young 1X guy just got of uni and had to do it as an assignment just a year ago so they will employ him first, as they have no repeatable way to differentiate between a resume BS artist and the real McCoy. It costs everyone but that is automation practiced on a corporate scale.

It may surprise you, but the people I worked with the last few years strongly preferred very senior developers.

So on the contrary one could argue that they are cheaper (yes ;)) but also can learn something new. Also I think that very junior people bring some kind of enthusiasm into teams. I guess the right mixture must be there.

> They may know where to find reusable or re-editable code that solves their problem. They may cheat.

I have done this since I started learning to program, which is only 4 years ago. I have been able to complete many tasks quicker than my co-worker. I always assumed I was going about it lazily and not working hard enough compared to him.

My boss believes I quite productive and gets things done efficient and correct, so I kept doing these practices and only writing code that needed to be written from scratch.

I supposed my intuition wasn't wrong - even though it felt guilty.

> The most productive programmers are orders of magnitude more productive than average programmers. But salaries usually fall within a fairly small range in any company. Even across the entire profession, salaries don’t vary that much. If some programmers are 10x more productive than others, why aren’t they paid 10x as much?

Because the 10x Programmer is a pernicious myth.

Even if you believe the original study from the '60s, it found that the best programmers were 10 times better than than the worst programmers, and only 2-3x better than the average.

Am I the only one who believe that the "10x programmer" might actually be someone who is just as good as the others, but actually work constantly and is self sufficient ?

I believe this, mostly. There are those who refuse to learn and do poorly, but compared to an average programmer instead of the worst, the real difference is ability to remain focused despite interruption (or a good mitigation strategy), a desire to improve oneself, and a willingness to continue working through a solution to either completion or determination of it being the wrong answer and finding an alternative.

Probably but I doubt you'll ever hear recruiters say: We're looking for rockstar ninjas but we'll settle for someone who's very productive by blowing off bullshit distractions.

I don't know.... I have not seen this study, but:

1> I feel I can safely say that I am more productive than the median programmer, as are probably a majority of visitors to Hacker News

2> I am aware of many famous programmers who are more productive than I am by at least an order of magnitude - probably two orders of magnitude.

Skeptical. You may be star struck and/or undervaluing yourself.

More likely I simply have a much lower estimation than you do of the productivity of the median programmer.

There were teams of 2-3 average programmers who, combined, didn't deliver what John Carmack did over his career.

What about in algorithm development or research? Could an average programmer invent quicksort, dynamic programming or information theory if transported back to the mid 20th century?

There is >10x productivity in scientists or mathematician using many kinds of metrics (papers, citations, awards etc)

"Could an average programmer invent quicksort, dynamic programming or information theory if transported back to the mid 20th century?"

I think many could have yes, had they been in the same academic environment as the people who invented those things. It's amazing what normal people can acheive when they are isolated from the noise of modern corporate work environments and given the resources to focus on a problem.

Not only can most programmers not create it, most can't implement it:

Binary search is a great example because it's so simple and yet it's so easy to implement incorrectly. In Programming Pearly, Jon Bently shares how, over the years, he asked hundreds of programmers to implement binary search after providing them with a description of the basic algorithm. He gave them a very generous two hours to write it, and even allowed them to use the high-level language of their choice (including pseudocode). Surprisingly, only about 10 percent of professional programmers implemented binary search correctly. (Beautiful Code, p. 87)

Like many “preventative” things, it can be hard to prove that problems would have occurred with less experienced/productive people because you only have one team and outcome in any situation.

And there’s a lot of easy-sounding ways to “measure” quality that actually suck (e.g. “number of bug reports” says nothing about the kinds of bugs, and might encourage people to create micro-bugs to inflate numbers or mega-reports to make them smaller, depending).

Right. When the company dies or goes down for some while, you may be able to identify the minus-ten-times employee who allowed that to happen. But he's likely long gone by then.

Measuring productivity is hard. Everywhere I've worked there were attempts and the system always became gamified and skewed. Incentive hitting a number(s) and folks will hit it.... at the expense of a lot of other things.

The way I see it... Is that most good programmers are nerds who can program. Because they have been introverts and socially awkward nerds, their entire life... Those qualities have made them useful for everyone around them so they grow up to be nothing more than handy tools for their peers.

Because of that a salesman or a manager or even a taxi driver will always be able to walk over them, and "twist their arm" in a social sense.

So do we expect introverted nerds to stand up for themselves and ask for a fair wage???

The stronger party will match the weaker’s second best offer

The code programmers write is worth $0 without the surrounding organization.

The company makes the code valuable.

Programmers are paid based on supply and demand. It's a completely different measure.

Everyone is paid based on supply/demand or rather how much leverage they have.

It would take a team of scientists and analysts to properly measure how much value each employee creates (and even then, probably wouldn’t be 100% accurate).

If you can’t even measure how much each employee’s contributions are “worth” to the final product, how the hell are you supposed to pay people based on those metrics?

The answer is, you don’t.

So if you want to get paid more, don’t worry about creating more value, worry about increasing your leverage. Form a union or guild, learn a skill very few people have, form close relationships with your customers, etc.

Reply on news.ycombinator.com