Really? I'm quite to opposite, I love to look through old code, add missing testcases and fix minor issues.
It helps me greatly to learn the ins and outs of the software.
You've been working with decent code, in that case.
The legacy stuff I come across isn't even testable without massive refactoring, even if the company allows you to do that in the first place.
Also, deprecated libraries for which there is no upgrade, which leads to further framework support issues (e.g. you can't upgrade X 'cos it doesn't support Y where swapping out X would take siginificant effort).
The worst problem I come across is spaghetti code where the business logic is ridiculously hard to follow, and it's not entirely clear if something is intentional or not, till you inevitably break it, and get an angry email from someone you didn't even know used the system.
Refactoring (for testing or not) is something you can do without the company 'allowing' it or adding 'dedicated trust work time' to the schedule. Sure, it does need buy-in from whoever reviews/signs off your commits if they bother to ask why you did that thing, and in pathological cases you'll have to keep a test suite to yourself / a local environment, but the social issues seem less of a barrier than people just throwing their hands up at perceived technical issues. I like recommending Feathers' Working Effectively With Legacy Code since it serves as a technical reference of solutions to the usual technical challenges/complaints that hang people up.
This is a general human nature thing, it's apparent everywhere in life:
"It's more attractive to create new problems than address existing ones"
In some work environments you can easily take ownership of a project, and some not.
After he left we wrote the contents of his hard drive to this stack of CDs, and they are scratchy enough to have data loss. Of course the prod executable differs from all variants of code found on the CDs.
It turns out to be a custom reporting framework for producing exactly 1 report. For extra speed, it starts 100 threads but doesnt have any synchronisation. Which turns out not to matter as they are all fighting for 1 DB connection.
You are not allowed to touch prod directly, but have to get some unix guy on the phone so far to recover logs, executable, and config. And as that guy has to support this mess, he hates your guts by association.
The more frustrating situation it needing to jump in and make a one-off fix to something that is at least notionally "modern". These can be just as impenetrable, but you have to hold your tongue much more (especially if some of the developers are still around), and there's generally a lot less kudos for sorting things out. Personal "favourite": debugging stuff that's virtually impossible to build locally "...because we've got this great CD pipeline".