Most developers give technically accurate code review feedback.

Many of them are damaging their team relationships while doing it.

Not because they are wrong. Because being right and being useful are not the same thing in a code review — and the difference lives entirely in the words used to deliver the feedback, not the judgment behind it.

This is the phrase system that closes that gap.

How the problem starts

Code reviews happen under time pressure. A PR lands in the queue. The reviewer reads fast, spots a problem, and types the most direct path from thought to keyboard.

The most direct path is blunt.

"This approach is wrong." "Why did you do it like this?" "This won't work."

Each comment is accurate. Each comment creates friction. And over time the friction compounds — the author begins triple-checking their work before requesting review, not for quality, but for self-protection. The reviewer has changed how someone works around them without intending to and without realizing it has happened.

The root cause is the absence of a phrase system. Most developers were never given one. They improvise every review. Improvisation under pressure defaults to blunt. Blunt damages trust. Damaged trust slows teams.

A phrase system removes the improvisation requirement entirely.

The three-tier framework

Every code review comment belongs to one of three tiers. The tier determines the register — how direct, how urgent, and how much explanation is owed. Getting the tier right is the foundational skill of effective code review communication.

Tier 1 — Non-blocking notes

These are optional improvements. The PR can and should merge without addressing them.

The signal word is Nit — universally understood in engineering culture to mean optional.

Before: "This naming is bad." After: "Nit: this variable name could be more descriptive — something like userSessionToken instead of token. Not blocking, just a thought."

What the rewrite does: names the tier upfront so the author knows immediately this does not block the merge, includes a specific alternative rather than a verdict, and closes with language that removes pressure.

Delivering Tier 1 feedback as though it were Tier 3 is the most common code review mistake. It signals that the reviewer cannot distinguish between important and unimportant, which erodes trust in all their comments over time.

Additional Tier 1 phrases for reference:

"Nit: this comment is slightly out of date — worth updating to reflect the current logic when you get a chance."

"Optional: we could extract this into a helper function for reusability. Not blocking — just flagging for future cleanup."

Tier 2 — Suggestions worth addressing

These should be addressed before merge but are not hard blockers. Discussion is welcome.

The signal language is "I'd suggest" or "I'd flag" — both signal a recommendation from someone who has thought it through without delivering it as a command.

Before: "This will break." After: "I'd flag this — if the input is null here, this throws an unhandled exception in production. Here is how I'd handle it: [specific approach]."

What the rewrite does: names the specific condition that causes the problem, names the specific consequence, and offers a path forward. The author has everything they need to act without a follow-up conversation.

Additional Tier 2 phrases:

"I'd suggest moving this logic to the service layer rather than the controller — keeps the separation of concerns cleaner and makes this significantly easier to test."

"Worth revisiting: this query runs inside a loop — could cause N+1 issues at scale. A batch query would be more efficient."

Tier 3 — Blocking issues

These must be resolved before the PR can be approved. The language should be direct and unambiguous about the consequence while remaining precise and solution-oriented.

The signal language is "I can't approve this as-is" — clear on the consequence without being personal.

Before: "I'm not approving this." After: "I can't approve this as-is — the race condition on lines 84-91 will cause data corruption under concurrent writes. Here is how I'd approach it: [specific solution]."

What the rewrite does: names the specific location (lines 84-91), names the specific mechanism (race condition), names the specific consequence (data corruption under concurrent writes), and provides a starting point for resolution. The author is not left with a verdict — they are left with a problem they understand and a direction to move in.

Additional Tier 3 phrases:

"Blocking: this endpoint has no authentication check — any unauthenticated user can access this data. Must be addressed before merge."

"I can't approve without resolving this memory leak — the event listener on line 203 is never removed and will crash the service under sustained load."

The three questions every comment should answer

Regardless of tier, an effective code review comment answers three questions:

What — what specifically is the issue, including the location and the mechanism? Why — what does it cause or risk if left unaddressed? How — what is the path forward?

The blunt comment answers only What — and often incompletely, without specificity.

The effective comment answers all three — specifically, professionally, and with enough information for the author to act without a follow-up thread.

The practical implementation

Before leaving each comment in a code review, ask one question: which tier is this?

If Tier 1 — begin with Nit or Optional. Signal that the merge is not blocked. If Tier 2 — begin with I'd suggest or I'd flag. Include the specific condition and consequence. If Tier 3 — begin with I can't approve this as-is. Name the line, the mechanism, the consequence, and the path forward.

This calibration takes thirty seconds per comment. Over the course of a review it takes two minutes. Those two minutes determine whether the author experiences the review as useful or as an attack.

The reviewer who is consistently useful gets requested. The reviewer who gets requested gets noticed. The reviewer who gets noticed gets promoted.

Same technical judgment throughout. Different phrase system. Different career outcome.

Want one framework like this every Monday?

Senior Dev English delivers one practical communication upgrade for non-native software developers every week — built for standups, code reviews, salary conversations, and every high-stakes moment that moves careers.

Free to subscribe. Includes an instant download of The Senior Dev Communication Cheat Sheet.

→ Subscribe free at SeniorDevEnglish.com

This article was originally published in Senior Dev English — a weekly newsletter for non-native software developers who want to communicate with the confidence their code already deserves.

​
​