Live data from Hacker News

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

johndcook.com

51–60 of 72 posts

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

#51

Earlier quoted context omitted.

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

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.

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

#52
post #8

Earlier quoted context omitted.

> brilliant one who is constantly going down rabbit holes unnecessarily Ha, sounds like an oxymoron

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,…

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.

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

#53
post #9
post #4

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…

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.

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

#54

Earlier quoted context omitted.

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…

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

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

#55
post #10

Earlier quoted context omitted.

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…

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.

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

#56

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

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.

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

#57
post #11

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.

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.

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

#58
post #5

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.

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

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

#59
post #35

Earlier quoted context omitted.

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 p…

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.

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

#60

Earlier quoted context omitted.

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

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.

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.
Post reply on HN