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.