5 exercises — practice rephrasing informal, blunt, or offensive code review comments into professional English that is specific, constructive, and respectful.
Informal expressions you'll rephrase in this set
"This code is a dumpster fire." → significant issues to address before merging
"WTF is this?" → requesting explanation of the approach
"You broke everything." → regressions appear to have been introduced
"Just YOLO it to prod." → direct-to-production if the team is confident
"This is spaghetti code." → complex control flow, suggestion to refactor
0 / 5 completed
1 / 5
A developer leaves this comment on a pull request: "This code is a dumpster fire."
How would you rephrase this professionally in a code review?
"This implementation has significant issues that should be addressed before merging."
The informal "dumpster fire" is a colourful insult that describes something as chaotic, broken, and beyond saving — like rubbish on fire. While it might be used humorously between close colleagues, it attacks the code (and implicitly the author) without providing any constructive information.
Why the formal version is better:
It describes the situation without judgment: "significant issues"
It specifies when action is needed: "before merging"
It invites discussion and fixes rather than closing it down
It doesn't make the author feel personally attacked
The options and why they fail:
Option A: "Directness is valued" — true, but directness means being specific and clear, not insulting
Option C: "Terrible code" — still a subjective judgment with no actionable detail
Option D: Refusing to review is unhelpful and unprofessional unless there is a genuine reason (e.g., conflict of interest)
Rule of thumb: Critique the code, not the coder. "This function is hard to follow" not "you wrote confusing code."
2 / 5
A reviewer writes on a PR: "WTF is this?"
What is the professional equivalent of this comment?
"Could you explain the reasoning behind this approach?"
"WTF" (What The F***) expresses shock or confusion but gives the author nothing to work with. The professional version does two things: it acknowledges confusion, and it invites explanation rather than implying the code is wrong.
Why explanation requests are valuable in code review: Sometimes code that looks strange has a good reason behind it:
A workaround for a known browser bug
A performance optimisation that is not obvious from the code
A constraint imposed by a third-party API
An intentional trade-off that was discussed in a separate Slack thread
Asking "why" before assuming error makes you a better reviewer and creates space for the author to add explanatory comments or documentation.
Other professional ways to ask "WTF":
"I'm not familiar with this pattern — could you add a comment explaining the intent?"
"Could you help me understand the rationale here?"
"This isn't immediately clear to me — is there documentation for this approach?"
3 / 5
After a deployment, someone comments on the PR: "You broke everything."
Which is the most professional and constructive alternative?
"This change appears to have introduced regressions — could we discuss what changed?"
"You broke everything" is accusatory and vague — it assigns blame without providing any actionable information about what is actually broken.
Breaking down the professional version:
"appears to have introduced regressions" → tentative language ("appears") acknowledges uncertainty; "regressions" is a precise technical term for behaviour that worked before but no longer does
"could we discuss" → invites collaboration rather than assigning blame
"what changed" → focuses on information-gathering, which is the first step to fixing the problem
Why "appears to" matters: In high-pressure post-deployment situations, it's easy to assume causation before confirming it. Another PR, an environment issue, or a dependency update might be responsible. Professional language reflects this uncertainty.
The other options and why they're weaker:
Option A: "I'll revert immediately" — unilateral action without discussion
Option C: "You are responsible" — accurate perhaps, but adversarial and unhelpful in the moment
Option D: Contains a reprimand ("do not merge untested changes") that may be appropriate but escalates rather than problem-solves
4 / 5
A developer writes in Slack before a release: "Just YOLO it to prod."
How would you express this formally in a release decision meeting?
"We can deploy this directly to production if the team is confident in the change."
YOLO (You Only Live Once) in a deployment context means deploying without a full review, staging validation, or safety net — relying on confidence (or recklessness) rather than process.
The professional version captures the intent without the bravado:
It makes the team's confidence a condition ("if the team is confident") — so it's not unilateral
It frames it as a deployment decision, not an act of recklessness
It leaves room for someone to object: "actually, I'm not confident" is a valid response
Why the other options fail:
Option A: "Skip testing" sounds like deliberately bypassing process — too explicit about what's being ignored
Option C: "Without a staging environment validation" — technically accurate but still sounds like advocating for bad practice
Option D: "No time for review" — this is what is implied, but stating it bluntly invites pushback and creates a paper trail of the bad decision
When direct-to-production is actually reasonable: Small, low-risk changes (typo fixes, config changes) may not need staging — but the decision should be explicit and consensual, not casual.
5 / 5
A reviewer comments: "This is spaghetti code."
What is the most professional and actionable equivalent?
"The control flow here is complex — breaking this into smaller functions might improve readability."
"Spaghetti code" is a technical metaphor for code with tangled, hard-to-follow control flow — like a plate of spaghetti with no clear structure. While developers understand the term, it is a criticism without a clear improvement path.
The professional version is better because it:
Identifies the specific problem: "complex control flow" — not just "messy"
Offers a concrete suggestion: "breaking into smaller functions"
Frames it as a suggestion, not a demand: "might improve" — it's a recommendation, not a rejection
Focuses on a measurable quality: "readability" — something the author can act on and verify
The other options and why they're weaker:
Option A: "Does not meet standards" — vague and authoritative without being specific
Option C: "I can't review this" — the reviewer is blocking without helping; this puts the problem back on the author without guidance
Option D: "Complete rewrite" — may be true but is demoralising if given without specific reasons
The art of constructive feedback: Good code review feedback is specific (what exactly is the issue?), actionable (what should be done?), and respectful (written as a suggestion, not a verdict).