If you are on a legacy project, it's hard to know what to prioritise in terms of improving code. However, getting requests to take somewhere within an order of magnitude of how long people think it should take is usually my guide. I never tell people I'm going to refactor something. I just do it. Then after the fact I say, "Remember when this used to take a week? Now it takes an hour". Once you do that a couple of times, management gets the point (usually). The only problem I've come across is when you get on a team where they actively discourage code churn. On a legacy project, that's death, so it's best to find another job in that case.
I really enjoy working on legacy code. Usually everybody else leaves me alone because nobody wants to touch that code. I get a tonne of freedom. As long as I don't break things (requires a fair amount of experience) I can quietly improve things under the hood -- targeting areas where we get a lot of requests. Legacy code is also great because usually nobody wants new features just for the hell of it. You almost always get real requests from real users that have real pain points. The biggest downside (as you imply) is that it's hard to shine because the best you can do is make things acceptable. It's difficult to hype the legacy project so you don't get a lot of recognition for your work.
I liked reading this! I'm glad you found happiness doing this sort of work!
One thing I'd say is that it's awfully tough to do this sort of work as a contractor when there's a (direct) hourly cost for your time. It's tough when you're on salary working on an internal project... but doubly tough (not impossible) when you're a contractor! Theoretically, it would be in clients' best interests to improve efficiencies, but it's really hard to get a client to sign off on hundreds or many thousands of dollars of work for a future gain that's hard for them to grasp.
(Getting them to grasp it is part of our job, of course)
Then after the fact I say, "Remember when this used to take a week? Now it takes an hour". Once you do that a couple of times, management gets the point (usually)
This is great advice. It's all about those metrics and demonstrating the value of your work!
It's definitely a daunting task, and I've been in that position once and I think it was a pivotal role in my career. I was hired as the only android engineer on a project that had churned 3 devs already, each with their own code style, and they all built layers on top of one another. It's hard to be in the position where a full re-write would be simpler technically, but impossible politically. My strategy was to basically refactor layer by layer, bringing the codebase back to a mostly working state in between modules. Over the course of 6 months I basically re-wrote the whole app and reduced the LOC by 50% while taking our crash rate from ~10 percent to < 1 percent. It was painful, but I'm no longer overwhelmed or overly annoyed by legacy code filled with cruft. It really is possible to chip away at it piece by piece and end up in a great position, and knowing how to pull that off is what separates the good from the great. Theres no perfect codebase, and having the skills to continually refactor and improve while delivering features is key.
I really enjoy working on legacy code. Usually everybody else leaves me alone because nobody wants to touch that code. I get a tonne of freedom. As long as I don't break things (requires a fair amount of experience) I can quietly improve things under the hood -- targeting areas where we get a lot of requests. Legacy code is also great because usually nobody wants new features just for the hell of it. You almost always get real requests from real users that have real pain points. The biggest downside (as you imply) is that it's hard to shine because the best you can do is make things acceptable. It's difficult to hype the legacy project so you don't get a lot of recognition for your work.