To answer one of your questions: Age doesn't matter.
To answer one of your questions: Age doesn't matter.
You come to understand that software development methodologies are just fleeting trends. Unlike with many other fields, the returns that you earn from investing in yourself as a software developer/engineer don't compound; they start to depreciate as soon as you stop trying to keep up with the trends.
The subskills that actually compound in value are things like understanding project lifecycles, building teams/culture, understanding good coding standards, CI, deployment, testing, quality assurance, etc.. These 'management' skills never go out of fashion.
Are you at this stage now, or theory crafting?
I've been coding for 2 decades and I don't find it predictable or tedious.
Life is an event stream of lessons. Things you learn from previous events don't automatically become useless just because there's a new tech trend in town.
For example, when I was writing PHP code in 2000, I still apply the lessons I learned then to code I write today in non-PHP languages. Those lessons I've learned are what makes me a better programmer today than I was 20 years ago.
Move out of your comfort zone and take on some projects outside of your established expertise.
> Unlike many other fields, the returns that you make from investing in yourself as a software developer/engineer don't compound; they start to depreciate as soon as you stop trying to keep up.
This is only true if you invest in frameworks/libraries/languages/etc. If you invest in understanding problems faced within industries and how to solve them with software, that's not something that depreciates.
Just so that doesn't sound like something abstract, take for example an e-commerce marketplace. Knowing that you need to create two objects, one for the order and another as an invoice for each seller within that order, isn't knowledge that will depreciate with time.
On top of that, there is general knowledge of algorithms and a thousand other things that are sufficiently generalized that they can be applied at any time.
Virtually every project that I take on is in a new space and I learn constantly, keeping things interesting. For reference, since we're talking about age, I'm 37.
However, at the end of the day where the rubber meets the road you can't ignore frameworks/libraries/languages. You have to learn what the job/market demands. This gets tiring because not only do these tend to be the same thing rehashed over and over again by some new young developer who doesn't have the experience, but they also ignore a lot of the lessons you have learned throughout your career.
Constantly learning can keep things interesting. After several years of re-learning front end frameworks or even back end frameworks with the same result gets tedious and boring.
Well yeah, if you are still “coding” after two decades you will probably find it tedious.
You can move into “engineering” and “architecting” however, which involve entirely different challenges, both in type and scale.
I do like coding, and will definitely continue working on my side projects. Although programming pays quite well, I'm not sure of the long term payoffs of continuing as a programmer (unless you are one of the Linus Torvalds, or in a similar league - which I am no where close to).
Longer term: I do want to get to a point in my career where I would like to influence product strategy (focus on the whys) a s a VP of Product Management vs. VP of Engineering.
If you have a complete different outlook to this, please let me know.