How to Disagree Professionally in Code Reviews

Code reviews are one of the most frequent sites of professional disagreement in software engineering. You disagree with an approach, a naming choice, an architectural pattern, or a security decision. How you express that disagreement determines whether the conversation leads to a better outcome — or to defensiveness, conflict, and damaged working relationships. This guide covers the language tools you need to disagree professionally and constructively.

---

Why Language Matters in Code Reviews

Code reviews are written, asynchronous, and often lack the softening effect of tone and body language. A comment that sounds neutral in your head can read as harsh or dismissive on screen. Engineers — especially non-native English speakers — often default to direct or blunt phrasing that works in spoken conversation but feels abrasive in text.

The goal is not to be less honest. It is to be more effective. A comment that is phrased respectfully is more likely to be heard, considered, and acted on.

---

Expressing Concern Without Accusation

The difference between “this is wrong” and “I’m concerned this might cause problems” is not just tone — it changes the conversational dynamic from confrontational to collaborative.

Instead of:

“This won’t work under concurrent load.”

Try:

“I’m concerned this might not behave as expected under concurrent load — if two requests arrive simultaneously, could there be a race condition on the shared state?”

The second version:

• Expresses concern, not accusation
• Asks a question, inviting dialogue
• Specifies the scenario you are worried about

---

Useful Phrases for Respectful Disagreement

Wondering / Exploring

These phrases signal curiosity rather than criticism:

“I wonder if we could handle this at the middleware level instead — it might simplify the controller logic.” “I’m wondering whether we need to persist this at all, or whether it could be derived on the fly.”

Suggesting Alternatives

Offering an alternative is more constructive than simply objecting:

“Have you considered using a factory pattern here? It might make it easier to swap implementations in tests.” “One alternative would be to use an enum for these values — it would prevent the string comparison issues I’m seeing in a few places.”

Flagging a Concern

When you have a specific concern but are not certain:

“One concern I have is that this introduces a circular dependency between the auth module and the user module. Could we break that cycle?” “I’m not sure about the memory implications here — allocating a new buffer per request could be expensive at scale. Worth benchmarking?”

Asking for Clarification Before Disagreeing

Sometimes the author has a reason for the choice that is not visible in the diff:

“Could you help me understand the reasoning behind this approach? I want to make sure I’m not missing context before raising a concern.” “Is there a particular reason we’re not reusing the existing validateInput utility here?”

Acknowledging the Approach, Then Raising a Point

The “yes, and” structure acknowledges the author’s work before introducing a concern:

“This is a clean solution for the happy path. My concern is around error handling — what happens if the third-party API returns a 429 while we’re mid-transaction?”

---

Nonviolent Communication (NVC) in Code Reviews

Nonviolent Communication (NVC) is a framework developed by Marshall Rosenberg that encourages expressing observations, feelings, needs, and requests without blame or judgement. In code reviews, a simplified version is useful:

1. Observe — describe what you see, not what you judge
2. Express concern — explain what you are worried about
3. Request — ask for a specific change or discussion

Poor (judgement-based):

“This code is spaghetti. Nobody will be able to maintain this.”

Better (NVC-informed):

“I’m finding it difficult to follow the control flow in this function — there are five exit points across four different conditions. Could we discuss whether we could simplify this with an early-return pattern or by extracting some of the condition logic?”

---

Distinguishing Blocking Concerns from Preferences

Not all disagreements are equal. Be explicit about whether your comment is a hard requirement or a personal preference. Many teams use labels like:

• nit: — minor, non-blocking (e.g., formatting, naming preference)
• suggestion: — optional improvement worth considering
• concern: — potential problem worth discussing
• blocking: — must be addressed before approval

“nit: I’d name this calculateTotalPrice rather than getTotalPrice since it’s doing computation, not retrieval — but this is just a preference, happy to defer.” “concern: This appears to log the raw request body, which could include payment card numbers. I’d want us to redact sensitive fields before merging.”

---

Receiving Pushback Gracefully

Professionalism in code reviews goes both ways. If the author disagrees with your comment:

“That’s a fair point — I hadn’t considered the caching behaviour there. Happy to defer on this one.” “I still have a concern about the thread-safety issue, but I can see the tradeoff you’re making. Could we at least add a comment explaining why this is safe in the current usage?”

---

Disagreeing professionally in code reviews is a skill that improves with practice and deliberate attention to language. The phrases in this guide will help you express concerns clearly, invite dialogue, and reach better outcomes — without creating unnecessary friction or damaging working relationships.

Navigating Nuance: English for Disagreement in Reviews

Disagreement is inevitable in code reviews. It’s not about “winning” or being right; it’s fundamentally a collaborative process of improving the codebase. However, expressing disagreement effectively, especially when your first language isn’t English, can feel daunting. Many developers find themselves defaulting to blunt statements that risk escalating tension and hindering productive discussion. The key is shifting from simply saying you disagree to articulating your concerns constructively – using what we call Non-Verbal Communication (NVC) in tech. This involves framing your feedback around the impact of a change, rather than directly criticizing the code itself.

Think about a scenario where a colleague suggests adding a complex logging statement within a critical performance function. A direct response like “That’s terrible! Logging here will slow everything down” is likely to be perceived as dismissive and confrontational. Instead, you could say something like, “I wonder if we could explore alternative approaches for monitoring this function’s performance? Adding detailed logging might introduce latency that impacts the user experience. Have you considered profiling the function first to identify specific bottlenecks before adding logging?” Notice how this phrasing focuses on potential consequences and opens a dialogue about finding a better solution. It’s about shifting the focus from “your code is wrong” to “this approach might have unintended effects.”

Another common situation arises when reviewing a Pull Request description. A developer might simply state, “Fixed bug X.” While technically accurate, it offers no context for reviewers. A more professional phrasing would be: “This PR addresses bug X by [briefly explaining the fix – e.g., modifying the validation logic in the user authentication module]. I’ve also added some tests to ensure this issue doesn’t reappear and to maintain code clarity.” Using phrases like “addresses,” “modifying,” and “ensuring” demonstrates a clear understanding of the change and its purpose, reducing ambiguity and fostering smoother reviews. Remember, clear communication minimizes misunderstandings and promotes mutual respect.

Finally, when responding to a comment that you disagree with, it’s crucial to acknowledge the reviewer’s perspective first. A simple “I understand your concern about…” demonstrates empathy and validates their viewpoint before presenting your alternative. This can de-escalate potential conflict. For example, if someone suggests refactoring a small piece of code for readability, you could reply: “I appreciate you highlighting the potential for improved readability here. I was aiming for maximum efficiency in this particular area, but I’m open to discussing trade-offs and exploring ways to balance performance with maintainability.” This approach signals willingness to collaborate and find common ground.