Advice from someone who regularly got thrown on "new tech stacks" and finally has fallen into the "boring" work of a popular language and very defined set of well known standards:
You might think you are "unimportant" and maybe at your company that's true. Looking at it less cynically you could also be reliable, capable of parsing and improving code, and more familiar with a wide variety of code styles. These suit you well to this job and being a janitor often pays really well. Often times as I advanced in the ranks I spent more time modifying other people's code than starting something from scratch.
You don't want to be learning new tech stacks all the time. If that's your personal hobby - great. But these stacks come and go and collecting N number of tech stacks to throw on your resume won't make you any more desirable to a new position down the road that requires senior X or staff Y and you've spent so much time in varying tech stacks you're not at that level. At the end of the day people WANT "boring" engineers. They're reliable, predictable, and knowledgeable.
When I was a kid, maybe 5th or 6th grade, my family was driving out in the country and came upon a burning farmer's field.
We stopped to help, and my older brother and I were charged with keeping an eye on the smoking remains of a field that had already burned out. The adults, and my younger siblings, went to fight the actual fire.
By the time it was all over, my brother and I were both feeling slighted and sidelined. But as we got back to the car, my mother, may she rest in peace, told us how much responsibility we had been given, to be set such an important job, with no adult supervision, the farmer must have thought we were older than we really are.
Two points, I suppose. First, one doesn't always appreciate one's salient qualities. Second, 45+ years later, that episode still stands out in my memory for how rewarding it felt.
This brings to light the importance of managements messaging to the "legacy" and "Greenfield" teams.
Frequently the Greenfield project is purely political, or just a punt.. and has a 50-50 chance of successfully launching in a way that ever replaces legacy.
People lose sight of the fact that until the Greenfield thing launches, 100% of the revenue keeping the lights on comes from the legacy system. Keeping legacy alive and thriving is critically important both to the firm and also to give the Greenfield team runway to build the new solution. Even beyond the launch date, a sliding % of the revenue will continue to go through legacy, often the majority, and often for years.
The reality is you could fire the entire Greenfield team and continue as a going concern for 5 years. If your legacy system fails, your firm might miss payroll within a few months.
Most often I find management slaps unrealistic optimistic timelines on the Greenfield project, and continues to stick with them as the new thing fails to deliver. This both stresses out the Greenfield team to build a more corner cut solution.. while also causing mass attrition on the legacy team out of job risk concerns.
OP doesn't want to learn new stacks all the time, they simply want a change for a while. One new stack maybe. But that's what happens when you're too good at what you're doing. No I'm not suggesting they should suddenly suck, but the managers will mostly think at the products - do I want somebody less capable taking over this legacy life-saving component? The only way out is to teach somebody else in the intricacies of those old parts, while getting a chance at some new stuff. This needs management commitment and one must make a solid case in front of them. If they realize that you might be thinking to change jobs out of frustration (no threats please), I'm sure they will make the mix possible.
Yeah, I think that's a very good point. It can be brain-damage inducing to constantly learn new frameworks, new infrastructure, and new ways of doing things.
And while it may seem companies are throwing the "new" stuff at important engineers, it may actually be the opposite. Since the new stuff isn't mission critical yet, they may actually be throwing that work at the less senior engineers. After all, it isn't keeping the lights on right now.
You might think you are "unimportant" and maybe at your company that's true. Looking at it less cynically you could also be reliable, capable of parsing and improving code, and more familiar with a wide variety of code styles. These suit you well to this job and being a janitor often pays really well. Often times as I advanced in the ranks I spent more time modifying other people's code than starting something from scratch.
You don't want to be learning new tech stacks all the time. If that's your personal hobby - great. But these stacks come and go and collecting N number of tech stacks to throw on your resume won't make you any more desirable to a new position down the road that requires senior X or staff Y and you've spent so much time in varying tech stacks you're not at that level. At the end of the day people WANT "boring" engineers. They're reliable, predictable, and knowledgeable.