How do senior engineers balance legacy system maintenance with adopting new tech to avoid long-term career stagnation?

Posted by BizAlly@reddit | learnprogramming | View on Reddit | 5 comments

Hey everyone,

I've been working as a software engineer for 11 years, and I'm facing a real dilemma that I think many senior engineers deal with:

The Conflict:

On one hand, I spend 6-8 hours daily maintaining legacy code (5-6 year old Java system with zero documentation, constant bug fixes, and it works, don't touch it mentality)
On the other hand, I'm terrified of career stagnation if I don't learn new tech (cloud, AI tools, modern frameworks) in the next 2-3 years, will I become obsolete in the job market?

What's happening in my day-to-day:

Legacy system maintenance eats up all my energy by end of day
No mental bandwidth left for learning new tech after work
Company says focus on legacy, it's critical business but that's not helping my resume
Watching juniors pick up new stacks faster while I'm stuck in the same tech for years

My question for senior engineers (10+ years experience):

Time allocation: How do you split your time between legacy maintenance vs learning new tech? Daily 1-2 hours? Weekends? Or something else?
Modernization strategy: Do you try to push for incremental modernization at work (microservices, API wrappers, cloud migration) or do you keep learning separately on side projects?
Career anxiety: How do you handle the fear of becoming that senior engineer who only knows old tech? What non-coding skills or new tech have been most valuable for you?
Company politics: How do you convince management to let you work on new tech when legacy is what pays the bills right now?

Looking for real experiences, not generic advice. Don't want to hear just study hard or make time Want to know what actually works in practice.

[-]

huuaaang@reddit

5-6 years old? Legacy? LOL. Man, that's new.

But, I mean, Java is a legacy language. If you want to avoid legacy systems Java in general is not the place to be.

Trying to learn everything outside work after already spending all day inside difficult legacy systems is usually unsustainable long term. A more realistic strategy is often attaching learning directly to practical work problems. For example, introducing monitoring, improving deployment pipelines, automating repetitive maintenance, adding better testing, or gradually adopting cloud tooling inside existing operational workflows. That creates both business value and skill growth simultaneously.

mlugo02@reddit

New tech? I still program in C at home while my manager threatens to move from C++ to Rust via AI

Fexelein@reddit

It’s easy. You innovate and stop making your job suck. If you cannot manage that during your day job, simply work less and make time. These seem excuses to me and I have heard them over and over. 20+ years of professional experience and still work new software, maintain existing software, migrate legacy code and co-lead a large group of engineers (45). Working for an enterprise financial institution as a Lead Cloud Solution architect and developer. Current innovation projects are related to generative AI and agentic systems. Before this is was cloud and before that Dotnet migrations and Blazer.

Developers have always been required to manage and allocate their own time and invest more time into learning their ambition. Simply crunching on what your PO tells you never leads to satisfaction. Oh and sometimes a no is also a good signal. If no doesn’t work find a new job, should be easy with 10 years of experience.

StillAnxious2493@reddit

stuck in this too tbh. the only thing that worked was carving out 3–5 hours a week of “learning” as part of work and framing it as risk reduction for the legacy system. if they won’t give you even that, quietly prep to bail. nobody values legacy skills when hiring and finding anything decent now is a slog in this market