Don't get stuck maintaining legacy stuff.

If you move to new, preferably greenfield dev every so often then you'll naturally keep with the times (at least if you're working in a vaguely decent team.) If you stick in one place too long and get stuck maintaining legacy crap, then that will be your focus, and that will be where your knowledge sticks.

Understand and respect legacy, but don't live in it.

@yowhatthefuck

I think the key to achieve that balance is being brave enough to delete things.

When you ask clients or product managers what they want, they always ask you to ADD a feature.

They'll never say: "Yeah I rarely use that button, feel free to remove it". Behind that unused button is often an unused route, an unused swath of backend code, maybe even unused database tables.

So it's very important as a company to have people pushing for functionality reduction.

Monitor which parts aren't used, and have the balls to just nuke them out of your product. Have tooling to detect dead code, and delete it. Git will have a backup if you ever need it again.

Less is more.

@yowhatthefuck You can read it as "How do you avoid stagnating as a dev", or "What do you do to make sure you keep your skills sharp as a dev".

When I talk about just "maintaining" legacy code, I mean just making bugfixes and maybe minor feature enhancements to the same 10+ year old software, day in day out. In short, you're just patching and bodging stuff in old code because no-one wants to touch it. You're not meaningfully improving it, there's no plan to do anything with it, you're just employed to keep the thing running, whatever it takes.

Moving a legacy application bit by bit, or gradually improving it / bringing it up to date is a whole different ball game - that's actually one of the *best* things to do in my book, as you're gaining an understanding and appreciation of the old system while having free reign to use whatever modern features, frameworks & practices you choose to re-implement it.