I think that a big part of it is the quality of work you get. If you work on business apps that aren't very well appreciated and most of your time is spent maintaining projects where the decisions were already made, you're never going to get to that level. A couple scut projects early in your career can teach you things about maintenance and just why code quality is so important, but eventually, you need to graduate beyond that sort of thing and move to projects where you can learn from your own decisions.

Working with software is like poker. If you aren't playing with real money, it gets boring quickly. Programming is fun if you have "skin in the game"-- a decision where you want to see if it was the right one, a problem you want to solve-- and it's mind-numbingly boring if not.

You need, somehow, to ensure a reliable stream of high-quality work. You need to become that guy who moves from machine learning to self-driving cars to new language development while the unlucky saps are trying to swing from an HR app led by a Manager II to an HR app led by Manager III.

I don't want to trivialize this, because getting high-quality work is really fucking hard. There just isn't much of a budget for it, and usually getting the best work involves manipulating the politics, especially when you're young and not "obviously" qualified for it yet. Good work tends to be R&D stuff where up-or-out business people who will be promoted or gone in 4 years can't see the payoff. You often have to take a mercenary attitude toward transfers and job changes and, if your boss isn't personally interested in your career growth, balance out the universe by stealing an education. Most people learned how to program by doing something other than what they were supposed to do. This doesn't change when you become a professional programmer. Good programmers tend to put their own development over business goals-- "optimizing for learning"-- because otherwise, they wouldn't have become any good.

People talk about "5:01 developers", but I've started to think of myself as a "1/21 developer". I expect to grow the value of my programming skill set (and indirectly, my earning potential) by 1% every 21 days. It doesn't have to be coding only. Improving social skills or business knowledge can easily account for such an improvement. I make that rate of growth (more as metaphor and guideline than hard lower bound, because it's impossible to measure such a quantity precisely) an almost inflexible primary constraint, as important as (a) getting done what I'm told to do, (b) showing up on time, and (c) not being offensive at work. None of these get slack except in extreme circumstances, so why should my learning rate?

1 percent every 21 days might not seem like much-- it's incremental change as opposed to get-rich-quick bullshit-- but that's a doubling every 4 years, or a factor of 32 in two decades.

What I think is getting much harder is consistently putting yourself forward as a person who deserves the best projects. As the number of frameworks and languages increases, we're getting curse-of-dimensionality problems. Being seen as a good programmer (which is increasingly different from being one) is an artifact of terrain knowledge, these days, more than general competence. This makes political battles around tooling a lot nastier, because the stakes are so high.

I think the way out is, for now, to establish a credibility in something other than engineering-- statistics, business, design. Hence the X-Who-Programs vs. Just-A-Programmer phenomenon: http://michaelochurch.wordpress.com/2012/08/26/xwp-vs-jap/ . If you're a software engineer and nothing else, your place in the pecking order is unsafe because of tool-sensitivity, so you need to diversify into other areas of knowledge.