Anyway: What makes the difference for me: taking the time to think about proper solutions. Let some problems rest for a day and reevaluate the things I made the day before, before review, merge or deployments.

I agree, I do this when I am designing some new module. I tend to write detailed design documents, covering as much behaviour as possible. I then get it reviewed by someone who might have a good understanding of the business process related to the change. This is not very feasible for legacy code because often there is no proper documentation or comments. What I’d prefer in such cases is to implement new modules in a manner where it lies somewhere outside the legacy body of code (different package or module) and expose functions to hook into the legacy code. This way at least the new enhancements follow best practices and don’t become just another patchwork to the increasingly unmaintainable legacy code.

Back to your original problem: legacy code like that is probably hard for everyone but it makes a difference in what pace (or patience!) you are doing your work. I think medication can help you with that :)

True. I have been thinking of resuming medication myself.

Until you have to fix some bug some dude introduced seven years ago and is no longer working at the company.