I'm one of the persons who loves refactoring existing code. It's much easier to get started than writing something from scratch. I change a few bits, then I get more ideas on how the code can be further improved. I always try to consider the business value - is the a maintainability problem? Does the code need upgrades to reduce tech debt? Etc. Hard to sell this sort of work to PMs who just keep pushing for new features.

I love rehabbing legacy code. It's like furniture restoration for apps.

Depends on the project and the person I guess. The trust of your manager is tremendously important. N=1 here, but at my current client it took me several hours of staring at a huge SQL query before I understood why it wasn't fast but the client was trusting enough that it was time well spent. I've also has PMs who could barely understand the concept of refactoring at all.

I always apply Chesterton's fence when working on existing systems. You don't get to add, remove, or change things before you understand what exists. That discovery is inherently exciting to me.

Well, I'm currently trying to reverse engineer something done by an open source SaaS offering, to patch a tool written by another person which works with that part I'm trying to reverse.

I just wanted to use the tool without any effort, but I have to understand the interface and patch the tool to make it work again. I'm not complaining.

Just wanted to add a data point for the former part of your comment.