"Longevity/diversity. Elite engineers stick with projects long enough to see the consequences of their decisions"
That is what I was saying to some colleagues in the past years. Jumping from a job to the next one every 3-4 years doesn't allow you to see the consequences of your decisions... I learned a lot staying in companies for 6-9 years. I know... maybe it is too much for someone, but you don't need to plan in advance. For sure you can stop following the mantra "change your job after 3 years otherwise you'll stop learning", because that's simply not true
Interesting! It reminded me about an advice to musicians (heresay though). Try to sometimes play in a band where you would be the least skilled, sometimes being the most skilled.
"Build and maintain relationships with engineers you admire." This is one of the hardest parts i find, but also it shouldn't be I think. Maybe it's me but I sadly had never found a mentor in my career, yet.
I like the mentor approach from the idea of software craftsmanship was never able to either have one or be one for others.
I find some of this can be mitigated by building and maintaining a good "social circle" online amongst engineers, but that's harder in some industry sectors than others. For example, for the last decade-plus, I've worked with Clojure and there's a small but strong online community (Slack, Reddit, plus a few forums and mailing lists), and there are a disproportionate number of truly outstanding engineers there who are very happy to provide wisdom and guidance to others -- I've learned a lot from some of the leading lights in that community. Back when I did C++ in the '90s, Usenet was where I found such "online mentors".
Attending conferences and networking that way can also help identify potential mentors.
They don't always have to be people you work with.
Another way to the top: make sure you work on projects that are visible and understandsble by thr business. Eg, fixing the customer checkout experience will be understood and rewarded by higher ups but upgrading some middleware or refactoring some old classes is too esoteric to the business and they'll never hear about it. As much as possible you want the outcome of your efforts to be tangible to non-tech stakeholders.
"Longevity/diversity. Elite engineers stick with projects long enough to see the consequences of their decisions"
That is what I was saying to some colleagues in the past years. Jumping from a job to the next one every 3-4 years doesn't allow you to see the consequences of your decisions... I learned a lot staying in companies for 6-9 years. I know... maybe it is too much for someone, but you don't need to plan in advance. For sure you can stop following the mantra "change your job after 3 years otherwise you'll stop learning", because that's simply not true
“Elite engineers have the habit of investing the margin in personal growth.” - excellent quote
Interesting! It reminded me about an advice to musicians (heresay though). Try to sometimes play in a band where you would be the least skilled, sometimes being the most skilled.
"Build and maintain relationships with engineers you admire." This is one of the hardest parts i find, but also it shouldn't be I think. Maybe it's me but I sadly had never found a mentor in my career, yet.
I like the mentor approach from the idea of software craftsmanship was never able to either have one or be one for others.
I find some of this can be mitigated by building and maintaining a good "social circle" online amongst engineers, but that's harder in some industry sectors than others. For example, for the last decade-plus, I've worked with Clojure and there's a small but strong online community (Slack, Reddit, plus a few forums and mailing lists), and there are a disproportionate number of truly outstanding engineers there who are very happy to provide wisdom and guidance to others -- I've learned a lot from some of the leading lights in that community. Back when I did C++ in the '90s, Usenet was where I found such "online mentors".
Attending conferences and networking that way can also help identify potential mentors.
They don't always have to be people you work with.
Another way to the top: make sure you work on projects that are visible and understandsble by thr business. Eg, fixing the customer checkout experience will be understood and rewarded by higher ups but upgrading some middleware or refactoring some old classes is too esoteric to the business and they'll never hear about it. As much as possible you want the outcome of your efforts to be tangible to non-tech stakeholders.