I think you hold off negative thoughts and make a list of what's good about the code first, and then write down your negative thoughts. The key question is, is

I think you hold off negative thoughts and make a list of what's good about the code first, and then write down your negative thoughts. The key question is, is there a good interface to it, if not, can one be built to wall around the bad code? Remember, often an overwhelming advantage in having bad code is, it's already written and it works. See it as an opportunity, rather than a burden. Each line of existing code is a potential line of code you don't need to write, rather than a potential line of code you need to re-write. On a broader scope, try to work to become an unnecessary employee in the company, rather than to become indispensable. The former attitude helps me try to see what's good about my colleagues because I'll need every strength the team has if I were to leave the company in good hands. I want the company's engineering team to stand on its own feet without my help so I can quit and feel good about the organisation I've contributed to. On the other hand, being underpaid and wanting to become more indispensable so you get paid more will lead you to keep seeing your colleague's weaknesses. (And the justification to be so "altruistic" and "loyal" is to have negotiated hard in the beginning in the first place so you're so well paid you want to do right by the company.)