Typically, a code review is a tool used to create consistency and prevent foreseeable issues that might arise with the code. It’s usually conducted by, or includes, someone with relevant experience or insight.
However, it’s important to understand that no one is perfect, and no one has a great day every single day. You might leave a comment, and the developer may push back. This can actually be a good and healthy thing. While it certainly depends on the root cause, pushback is generally a positive sign.
In my experience, there can be a couple of reasons for this pushback:
- The developer disagrees with the validity of your feedback.
- The developer thinks that your feedback is too nitpicky or unnecessarily strict.
- The feedback might be perceived as condescending or toxic.
- Some developers are anxious about criticism, which can lead to preemptive pushback or avoidance.
- The developer might be biased due to having more experience on the subject.
- It could be due to demographic factors.
- Some developers might be in a rush for a release and believe that last-minute code is not subject to review.
- Developer toxicity or narcissism.
1. Validity of Your Feedback
This is the most common reason for pushback. The disagreement usually stems from one of two things: either your comment is no longer valid, or it is valid and the developer didn’t understand your point.
Before you do anything else, review your own comment one more time. A second look might reveal something you missed, proving the comment invalid. If so, you can simply resolve the issue.
If you still believe your feedback is valid after a second look, it’s time to engage. We are all human; you don’t have to be a superhero with x-ray vision. The key is to ask engaging questions and awaken curiosity.
Try asking questions like:
- “Why do you think this approach works better?”
- “Maybe I’m missing an edge case here. Could you please show me why…?”
Try to genuinely understand the root cause of the disagreement. You can also back your feedback with objective evidence such as links to documentation, benchmarks, or team coding standards. Don’t rely on personal preference!
If the pushback continues after this point, you should involve a third pair of eyes, preferably someone you both respect on the team.
The ultimate goal should be turning pushback into a learning opportunity. Strive to create a team culture that reduces ego involvement and focuses on shared goals. Remember that team trust and code strength are the true objectives of code reviews. I know this takes time and requires proactive promotion of a good code review culture, but it’s a worthwhile effort.
2. Time Pressure or Desire to Ship Fast
When there’s a release tomorrow and a developer is pushing a fix today, reviewing that code can be tricky. This is a time-bound review, and you must understand the consequences of your suggestions. This is not the time to be nitpicky or to suggest major architectural changes unless you are certain the current approach will introduce a critical bug.
You might hear justifications like, “this code will work 98% of the time,” and that the remaining edge cases rarely, if ever, occur in production.
In these scenarios, you need to be thorough and have a system for tracking what’s being deferred. These last-minute pull requests often introduce technical debt. Here’s how to manage it:
- For minor issues: Ask the developer to add
TODOcomments in the code to ensure they are addressed later. I’ve never seen a developer oppose this suggestion. - For more significant concerns: Document them where the whole team can see. This could be a wiki page titled “Mid-Term Technical Improvements,” a “Refactoring Wishlist,” or a dedicated ticket in your project management tool.
The most important principle is this: time pressure should not force your team to ship bad code. If a piece of code isn’t understandable or maintainable, the team must still put in its best effort, considering all possible trade-offs. The goal is to evaluate the risks and make a good-faith decision together.
3. Feedback Feels Personal, Condescending, or Toxic
This doesn’t happen to me since I have a system. However over the time, I’ve seen people making comments like “This is a bad code” with no suggestion or reasoning at all. Please read my other post, if you haven’t read, it is about the language of the code review. Trust me, this can prevent a lot of unwanted situations.
4. Developer Toxicity
We’ve all probably faced this, or surely will at some point.
Toxicity in a developer can manifest as hostile responses, sarcasm, or a pattern of dismissing feedback aggressively (or passive-aggressively). This causes pushback because the individual views code reviews as threats to their authority or competence, turning a collaborative process into a conflict zone.
In my experience, this behavior often comes from two common profiles:
- The Arrogant Expert: This is someone who is genuinely experienced, has read extensively, and knows methodologies far beyond the team’s average. However, they may only respect their own past experience, making it nearly impossible to get through to them with team conventions or a culture of openness.
- The Insecure Actor: This is someone who thinks they know a lot, but whose knowledge is actually limited. They use pushback to try and gain respect, perhaps because someone told them that being highly opinionated is the key to success in this business.
The Narcissistic Root
The common thread for both types is often rooted in narcissistic traits. They typically have an inflated sense of self-importance and an extreme difficulty accepting criticism. They often lack empathy. This leads to pushback where they defend their code no matter what, viewing any suggestion as a personal attack. This behavior results in prolonged, pointless debates and a refusal to iterate, all driven by the need to maintain an image of infallibility.
In my experience, people who project this type of behavior are often not very happy themselves. It’s as simple as that.
Strategies for Handling Toxicity
Unfortunately, the solutions here are limited. You can try bringing in a third party whom the individual respects, or you might have to let the issue go and address it through a different channel later. Remember, perfectionism is the enemy in these situations.
Ultimately, learning how to disengage from these individuals will do the most to preserve your own energy. Especially if the root cause of the pushback is narcissism, the best strategy is often to create professional distance and avoid getting drawn into their conflicts.
Stay the F away!
A Note on Toxic Teams
It’s also worth noting that toxicity isn’t always individual; the entire team culture can be toxic. I’ve witnessed teams that push back on good ideas simply because they are stuck in their old ways. We should avoid environments like this, as toxic teams can create and perpetuate toxic individual behavior.
Conclusion
Pushback in code reviews is not just a technical event; it’s a deeply human one. It sits at the intersection of our code, our egos, our deadlines, and our ability to communicate. While it can be frustrating, viewing pushback not as a roadblock but as an opportunity.
Most disagreements can be resolved productively by approaching them with curiosity, using objective evidence, and focusing on the shared goal of building better software.
However, it’s just as crucial to recognize the situations that can’t be fixed through good faith and communication. When faced with persistent toxicity or narcissistic behavior, the goal shifts from collaboration to self-preservation. Learning to identify these patterns and disengage is not a failure, it’s a rather critical skill for a healthy career in tech.
TL;DR
- Pushback is Normal: Treat pushback as a signal to seek understanding, not as an attack. It’s often a sign of a healthy, engaged team.
- If They Disagree on Validity: First, double-check your own comment. If you’re still sure, ask clarifying questions instead of making statements. Use documentation and standards, not just opinion, as evidence.
- Under Time Pressure: Be pragmatic. Don’t argue over minor nitpicks before a release. Use TODOs or small issues and create tickets/docs for larger tech debt. The goal is to make a conscious trade-off, not to ship bad code blindly.
- Mind Your Language: How you phrase feedback is critical. Vague or harsh comments like “This is bad code” will always create friction. Be constructive
- When It’s Toxicity: Recognize that some individuals will not engage in good faith. If you identify narcissistic or consistently toxic behavior, your best strategy is to involve a respected third party or, more importantly, disengage to protect your own energy and well-being.
