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.
Why programmers are not paid in proportion to their productivity (2009)
11–20 of 72 posts
Re: Why programmers are not paid in proportion to their productivity (2009)
#12The 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.
Re: Why programmers are not paid in proportion to their productivity (2009)
#13FTA: "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.
Re: Why programmers are not paid in proportion to their productivity (2009)
#14FTA: "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
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.
Re: Why programmers are not paid in proportion to their productivity (2009)
#15Good 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? An…
When you save a company $$$, it's important to bring that up at annual review time, and definitely place it on your resume.
Re: Why programmers are not paid in proportion to their productivity (2009)
#16FTA: "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.
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.
Re: Why programmers are not paid in proportion to their productivity (2009)
#17I'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.
Re: Why programmers are not paid in proportion to their productivity (2009)
#18That'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…
Its called a hackathon ... and who knows the honest results of a war game ... better than doing nothing , but is any one (includong you) hiding a tatic??? ... For there to be true estimates there must be clear goals, something that biz and product dont seem to care for in totality. Once we get clear goals then we can compare dev abality. My experience is that you always have to be part your own project manager and dev op.
In an ideal world the project manager would tell me to jump and i would ask how high?
We need as clear instructions as the machines we pass them onto ... without the semicolon. Otherwise we are partially doing the pm job.
Re: Why programmers are not paid in proportion to their productivity (2009)
#19Earlier 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,…
'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.
Re: Why programmers are not paid in proportion to their productivity (2009)
#20I'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 can get two competent testers. :)