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.