I have been quite lucky that throughout most of my career I have ended up mostly working on Greenfield code bases that I had a major role in shaping. As a result I don' think I have trained the muscle of working in legacy codebases well.
I have recently joined a new team/org and Im finding it a bit of struggle contributing to messy codebases where there have been many people hacking away at it over the years. The result is nothing is very consistent and there is rarely a clean way to do anything.
Any change I want to introduce feels like I am adding to the mess and this is something I really struggle with. I either end up in 1 of 2 failure modes.
I spend too long hunting for a nice clean solution that slots in.
I think oh, well if I just refactor this a bit then it will all fit together nicely, only to realise my change is quite big given what I set out to do.
I feel like a lot of my other colleagues are a lot more biased to action than me and was wondering if there is some mindset or behavioural shift I can make to be more ok with shipping 'less than ideal' code
Ugh. I know the feeling. A particular codebase I was working on was basically just an iteratively vibe coded jumbo slop mess. Unfortunately it is much harder to stay calm and focused in messy codebases.
Something that helped me mentally was not letting the codebase chaos get to me. This takes some getting used to but the mental strain of the legacy codebase will get less and less over time. This also means that you are not adding to the mess. You're trying to make the codebase better one diff at a time.
Instead of shooting for perfection, why not just shoot for a little better? For example, if there are bunch of nested conditionals, simply collapsing the crazy logic is a major win in readability. This way, you also don't spend 4x the time you originally budgeted for a task.
Can you try blocking out time to attempt a few refactors? Knowing how deep the rabbit hole is and how you'd approach it will better set you up for understanding how effectively you can refactor & how deep/shallow you're able to cut based on the context.
I believe you already know at this point that Meta rewards impact not the clean code. You would be able to refactor and the work would be in a better engineering category which depends on the org, may or may not be rewarded properly.
Get it to work (with the best approach at the time) then make it better when you can would be my strategy here. There is no such thing as a perfect code anyway.