5 exercises on the language of respectful, effective code review — the phrases that keep feedback constructive, focused and collaborative.
Key patterns
be constructive → critique the code, not the coder
assume good intent → give the benefit of the doubt
blocking vs non-blocking → signal severity clearly
take it offline → move a long thread to a call
defer to the author / agree to disagree; watch for scope creep
0 / 5 completed
1 / 5
A team's review guidelines say feedback should focus on the code, stay specific, and offer a path forward rather than just criticising. What adjective best captures this principle?
Be constructive — the core etiquette principle:
Constructive feedback identifies a problem and points toward a solution, focusing on the code rather than the person.
"Constructive criticism includes the why and a possible fix."
Related etiquette collocations:
be specific — point to lines, give examples.
be respectful / kind — assume the author did their best.
critique the code, not the coder — a common maxim.
offer alternatives rather than only objecting.
Why not the others: "blunt" and "brutal" prize harshness over helpfulness and erode psychological safety; "vague" feedback can't be acted on. The widely cited standard — in Google's and many companies' review guides — is to be constructive.
2 / 5
A reviewer reads code that looks odd and is tempted to assume the author was careless. Good etiquette says to do the opposite. Which phrase names that principle?
Assume good intent — the trust-building principle:
To assume good intent (or assume positive intent) means starting from the belief that the author had sensible reasons, then asking rather than accusing.
"Assuming good intent — is there a reason this runs synchronously?"
"Let's assume good faith and ask before judging."
"Give the benefit of the doubt when something looks off."
How it shows up in comments:
Ask questions: "What's the thinking behind X?" instead of "This is wrong."
Use "we" not "you": "Could we handle the null case here?"
Acknowledge constraints: "I know this was urgent…"
Why this matters: assuming good intent keeps reviews collaborative and lowers defensiveness. The distractors — "assume the worst", "assume control" — describe exactly the adversarial stance healthy teams avoid. This phrase appears in most engineering culture docs and code-of-conduct guidelines.
3 / 5
A reviewer dislikes a variable name but it does not actually prevent merging, versus a security bug that absolutely must be fixed first. Which pair of labels distinguishes these correctly?
Blocking vs non-blocking — the severity distinction:
A blocking comment must be resolved before the PR can merge; a non-blocking comment is a suggestion the author may take or leave.
"This is blocking — the token is logged in plaintext."
"Non-blocking, but I'd rename this for clarity."
"Two nits (both non-blocking) and one blocker."
The severity ladder:
nit / non-blocking — optional, cosmetic.
suggestion — recommended, usually non-blocking.
blocking / must-fix — has to be addressed before merge.
Why label clearly: stating "blocking" or "non-blocking" tells the author exactly what they must do, preventing wasted back-and-forth. While "optional vs mandatory" is close in spirit, the established review vocabulary is blocking vs non-blocking, mirrored by GitHub/GitLab conventions and review bots.
4 / 5
A comment thread is turning into a long debate that would be faster to settle in a call. The reviewer suggests moving the discussion elsewhere. Which idiom fits?
Take it offline — moving a discussion out of the thread:
"Take it offline" means continue a discussion privately or synchronously (a call, DM, or in person) instead of in the public comment thread — useful when a thread gets long or heated.
"This is getting deep — let's take it offline."
"We took it offline and agreed on the approach; summarising here."
"Happy to discuss this offline if that's easier."
Good practice: after taking something offline, post a summary back in the thread so the decision is recorded for others.
Related phrases:sync (up), hop on a call, pair on it, circle back. The distractors twist the idiom: "put it online" reverses it, while "take it overboard/apart" are entirely different expressions. "Offline" here is figurative — it doesn't mean disconnected from the internet.
5 / 5
A PR meant to fix one bug keeps growing as the author adds unrelated improvements. The reviewer also notes that, on one stylistic point, they will let the author decide. Which two terms fit?
Scope creep & defer to the author — boundaries and trust:
Scope creep is the gradual expansion of a change beyond its original purpose; reviewers flag it to keep PRs small and focused.
"This is scope creep — let's split the refactor into its own PR."
"Keep the PR focused; park the extras for a follow-up."
To defer to the author means to let the author make the final call on a judgement point.
"It's your module — I'll defer to you on the naming."
"Non-blocking; I'll defer to the author here."
When you can't align: sometimes reviewers and authors agree to disagree on a stylistic point and move on, especially if it's non-blocking.
Why these terms: "scope creep" is the established project-management/engineering term (not "feature drift" or "code bloat"), and "defer to" — not "overrule" or "yield to" — is the precise verb for ceding a decision respectfully.