Defensiveness Is Ruining Your Code Reviews (Here's How to Fix It)
A few years ago, I submitted a 450-line pull request that I was exceptionally proud of. I had spent four days refactoring our authentication pipeline to reduce latency by 40ms. I felt like a wizard.
Two hours later, a Senior Staff Engineer left a comment on line 112:
"Why are we using a custom caching strategy here instead of the standard Redis wrapper? This introduces unnecessary concurrency risk and complicates cache invalidation."
Reading those two sentences felt like an electric shock straight to my ego. My stomach tightened, my face felt warm, and my brain instantly went into combat mode. I spent the next 45 minutes typing, deleting, and re-typing a passive-aggressive essay quoting RFCs, explaining why my custom implementation was actually brilliant and why his suggestion was outdated.
We traded 18 increasingly tense comments back and forth. The PR dragged on for three days, team standups felt icy, and our engineering manager had to step in to mediate.
When the dust settled and I looked at the code objectively a week later, I realized something humiliating: He was 100% right. My custom cache did introduce a race condition under high load. My 45-minute defensive retaliation hadn't protected code quality—it had only protected my fragile ego, wasted ten hours of team time, and damaged my professional reputation.
+--------------------------------------------------------------------+
| THE DEFENSIVENESS SPIRAL |
| |
| Reviewer: "This function has a bug." |
| Internal Translation: "You are an incompetent engineer." |
| Reaction: Fight back, argue syntax, delay ship date. |
+--------------------------------------------------------------------+
That painful episode made me realize how widespread this issue is across our industry. To help developers identify their conversational blindspots, I built Defensiveness Radar, a free diagnostic tool for tracking defensiveness triggers in collaborative environments.
