The way I approach Other People’s Code
If a new project performs a specific set of tasks, I will think to myself how would I implement those tasks, what classes would I decompose the problem domain down into? This gives me a mental outline of the project, a roadmap which I can then superimpose against the new code. So even if it is ugly and unreadable, there’s still a chance I can walk in and debug it straightaway.
I have inherited genuinely bad code — poorly designed and poorly coded — which invariably prompts a rewrite. Although I try to avoid rewrites.
I’m very proud of the code I write, and I’m always a bit mortified when other people dig into it. And that’s a good thing — keeps me from getting sloppy when I know it will be critiqued.