I think the title is misleading – it should be “Don’t go on a witch hunt for bad code offenders”. Learning from code that either has bugs or is no longer fit-for-purpose is valuable and not done often enough. How are people supposed to learn the effect of their decisions when coding if they don’t see the outcome weeks or months later? Treat such situations as learning opportunities, much like blameless postmortems.
Agreed, but it’s not all about witch hunt. There is some good content later in the article about how to approach new code, and how to keep from driving yourself crazy with all the “problems” the original coder left for you.
I think the title is misleading – it should be “Don’t go on a witch hunt for bad code offenders”. Learning from code that either has bugs or is no longer fit-for-purpose is valuable and not done often enough. How are people supposed to learn the effect of their decisions when coding if they don’t see the outcome weeks or months later? Treat such situations as learning opportunities, much like blameless postmortems.
Agreed, but it’s not all about witch hunt. There is some good content later in the article about how to approach new code, and how to keep from driving yourself crazy with all the “problems” the original coder left for you.