Much of what keeps programmer salaries from going up as fast as they should is that managers know that, even if you're a genuine "10x" or even 100x engineer, you don't stay a 10x-er unless you get interesting projects, which tend to be rare in most companies. Since they control the allocation of interesting work, there's often an implied either/or: you can get interesting work and a cost-of-living bump or you can get a 20% raise.
For some examples: (1) frequent job hops can improve your salary, but they reduce your ability to stick with a long project and become good at anything; (2) if you're looking to make the case for a move into management, you do better to take on an ugly-but-necessary project where you'll delegate most of the work, than to stick with the technically interesting stuff and get a reputation of someone who only wants to work on the "fun" stuff; (3) Haskell engineers make about 40% less than Java engineers at the same level of engineering ability. (The difference in medians is only a few percent, but the median Haskell engineer is equivalent to ~95th percentile in Java.) That's because Java engineers can set up multilateral bidding wars every 2 years and get huge pay bumps; in Haskell, that's nearly impossible because it's a small community.
Personally, I tend to go for interesting work. That's because I think, in the long term, it'll play out better for me to have spent my 30s well than to have ratcheted up my salary but not really know anything.
If we want to see engineers paid what they're worth, though, we've got to get political enough that we can actually run companies (let's be honest; 98+ percent of VC-funded startups are run by Guys With Connections Who Therefore Call Shots, not engineers) and take control of the work allocation processes as well.
> That's because I think, in the long term, it'll play out better for me to have spent my 30s well than to have ratcheted up my salary but not really know anything.
Maybe, but it's far from an obvious conclusion. From a purely economic/financial perspective, it's much preferable to increase your salary as early as possible. Since in most organizations pay raises have a ceiling expressed as a percentage of comp (eg, 10%--either implicit or explicit), the base level of your salary early on in your career has a huge effect on your total lifetime earnings--similar in effect to investing a sum of money at age 35 vs 25. Sometimes having a high salary history/requirement can even give you instant credibility ("a person making $400k must know what they're doing")--some people can bluff through their entire careers that way.
That said, it's probably best to balance pure financial opportunism with "soft" concerns like actually enjoying your day to day work and growing as a person/professional.
> frequent job hops can improve your salary, but they reduce your ability to stick with a long project and become good at anything
This is a major reason why I went into platform engineering and devops. Projects are very accelerated (usually because you end up starting too late, relative to the best time to change a dev team, its culture, and its practices) and you really can learn quickly and get better at a rapid pace. It helps, too, that the state of the art is changing quickly enough that effectively nobody is an expert at everything.
> Java engineers can set up multilateral bidding wars every 2 years and get huge pay bumps
...and this is the other reason. Best of both worlds, in my view.
This is a major reason why I went into platform engineering and devops.
I can see the appeal of that. It also makes you less exposed to changes in window dressing and to political changes.
..and this is the other reason.
Sure, but it's also bad for the world that "market signals" are encouraging engineers to use bad languages for reasons having nothing to do with productivity. We know the real reason why there's so much Java in the software world: middle managers want headcount (they'd rather manage a team of 50 mediocrities than 5 elite engineers doing just enough work) and Java is such a low-productivity language that it forces teams to be big if anything is to be accomplished.
If an engineer who'd be nothing special in the Haskell community can take home $400k per year slinging Java, then what is a half-decent Haskell engineer (who, most likely, makes a lot less than $400k) really worth? $700k? $3 million?
> If an engineer who'd be nothing special in the Haskell community can take home $400k per year slinging Java, then what is a half-decent Haskell engineer (who, most likely, makes a lot less than $400k) really worth? $700k? $3 million?
The actual language isn't worth anything. Knowing the language that my business application is written in, is what counts. COBOL is the best known example - outdated, hard to use language with no features. Yet COBOL programmers are probably, on average, the best paid programmers out there, because they work on systems that the businesses care about.
The reason a 'nothing special Java dev' is worth $400k is because there are systems that make businesses crap-tons of money out there, written in Java. Not because Java is a good/bad language.
Is Haskell really that much more productive for a team? What are some large-scale projects written in it? It may make recruiting harder and take new joiners longer to get up to speed. You may not have easy access to as many libraries. A lot of "PL enthusiast" types would rather show off how clever they are than solve real problems. There are many valid concerns a manager could have that aren't headcount-related.
Sorry - I meant that in devops roles, those bidding wars exist too and I don't use Java. (Scala for web stuff, Ruby for plumbing.) Everyone needs devops, especially the people who don't know what it is. =)
> That's because Java engineers can set up multilateral bidding wars every 2 years and get huge pay bumps; in Haskell, that's nearly impossible because it's a small community.
That's why you do more than Haskell. If you are such a great programmer, you can get people from Haskell and Java land (etc) to bid on you.
(I prefer Haskell myself, and have worked with it professionally for most of my short career.)
For some examples: (1) frequent job hops can improve your salary, but they reduce your ability to stick with a long project and become good at anything; (2) if you're looking to make the case for a move into management, you do better to take on an ugly-but-necessary project where you'll delegate most of the work, than to stick with the technically interesting stuff and get a reputation of someone who only wants to work on the "fun" stuff; (3) Haskell engineers make about 40% less than Java engineers at the same level of engineering ability. (The difference in medians is only a few percent, but the median Haskell engineer is equivalent to ~95th percentile in Java.) That's because Java engineers can set up multilateral bidding wars every 2 years and get huge pay bumps; in Haskell, that's nearly impossible because it's a small community.
Personally, I tend to go for interesting work. That's because I think, in the long term, it'll play out better for me to have spent my 30s well than to have ratcheted up my salary but not really know anything.
If we want to see engineers paid what they're worth, though, we've got to get political enough that we can actually run companies (let's be honest; 98+ percent of VC-funded startups are run by Guys With Connections Who Therefore Call Shots, not engineers) and take control of the work allocation processes as well.