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.
How do you quantify the 1% per 21 days improvment? There are no easy-to-get-at brain weight scales yet. I agree with your incremental change mindset, I just find it hard to measure.
An addition to your proposition that you needs make your decisions in order to improve: You also need to actively learn from your failures. Many people just go like "That sucks, it did not work out" without ever asking the Why. That's not enough to learn, and one could even learn the wrong lesson from a failure.
How do you quantify the 1% per 21 days improvment? There are no easy-to-get-at brain weight scales yet. I agree with your incremental change mindset, I just find it hard to measure.
Agreed. 21 days is a good audit point. If you can make the case to yourself that you've improved the total value of your skill set by 1 percent, then proceed normally.
This is equivalent to 19% per year. That's measurable if you pay attention to market trends. Keep in mind that if you stick with one job, you're likely to bank only half of that increment. You probably won't get 20% pay increases unless you work for yourself (in which case your expectancy might go up by 20%, but you have a lot of volatility). You'll get 6 to 10 percent per year. It might still be worth it to stay in the same job, if you feel like you're learning a lot. Part of the reason why the pay improvement is slower is that the best engineers tend to prefer more interesting work (and stability, as they get older) over aggressive salary growth.
Here's a scale for software engineering: http://michaelochurch.wordpress.com/2012/01/26/the-trajector... . Each 0.1 increment seems to be about a 26% increase in abstract business value (or a 10-fold increase per 1.0) and about an 8-15% increase in salary. You should be aiming for 0.1 every 18 months, which is hard but doable, although it usually requires pushing back at work sometimes.
An addition to your proposition that you needs make your decisions in order to improve: You also need to actively learn from your failures. Many people just go like "That sucks, it did not work out" without ever asking the Why. That's not enough to learn, and one could even learn the wrong lesson from a failure.
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.