If you’re like me, you experience a small sense of elation when you spot a bug during a code review. Or maybe when you find a way to trigger a bug in some software a colleague wrote.

I recently heard a professional tester say “I love finding bugs!”

I do, too! Well, as long as they don’t get in the way of accomplishing a task or playing a game (I’m looking at you, Bethesda!)

But is this really a healthy attitude?

I once had a new joiner tell me “I’m looking forward to the day when I pass one of your code reviews on the first try!”

This got me thinking.

I never saw code review as a stage to “pass”. Clearly some do. And I don’t think that’s a good thing.

There are many reasons for code review, but I think we can roughly summarize in: Code review exists to improve the quality of the product we produce.

“Gatekeeping” (via code review or QA testing) may appear to serve this purpose in the short term, but it also poses the significant risk of pitting reviewee against reviewer, or developer against tester. Such rivalaries invariably undermine product quality, by encouraging the producer of the work to hide defects, or take fewer risks.

Now far be it from me to chide you for experiencing joy from finding a needle in a haystack. I get that. Finding a bug can feel a bit like finding Waldo!

But maybe we can channel that energy in a more productive direction.

Rather than allowing a sense of Schadenfreude when we find fault, let’s celebrate the opportunity to improve the product’s quality.