5 exercises — practise explaining why you suggested a change, not just what to change. Link suggestions to principles and articulate trade-offs clearly.
Key phrases for explaining reasoning
"...because it would..." — always attach the benefit
"This reduces coupling / improves testability" — name the principle
"The trade-off is X, but Y" — articulate both sides honestly
"I'm not certain, but..." — calibrate your confidence
"This is a nit, not blocking" — signal the weight of the comment
0 / 5 completed
1 / 5
You suggest extracting a class. Which comment best explains your reasoning rather than just stating the change?
Good review feedback explains why, not just what. "...because it would let us test the pricing logic in isolation" gives the author a concrete benefit they can weigh. When people understand the rationale, they either agree and learn, or they push back with context you were missing — both are productive.
"Extract a class here" and "This needs a class" are bare directives. "Classes are better" is a vague generalisation with no reasoning at all. The pattern to practise: suggestion + "because" + concrete benefit. The "because" is what turns a command into a teaching moment and an invitation to discuss.
2 / 5
Which phrasing best links a suggestion to a technical principle?
Grounding a suggestion in a named principle ("it reduces coupling") makes your reasoning transferable — the author learns a concept they can apply elsewhere, not just a one-off fix. It also makes the feedback objective rather than personal preference.
"Just trust me" and "This is how I always do it" appeal to authority or habit, not reasoning. "It's a best practice" name-drops without explaining why it is best here. Naming the principle (separation of concerns, low coupling, single responsibility) and connecting it to the specific code is far more convincing and educational than asserting that something is simply "correct."
3 / 5
You are recommending a trade-off. Which comment communicates it honestly?
Real engineering decisions involve trade-offs, and saying so explicitly ("the trade-off is more memory use, but...") shows mature judgement and respects the author's ability to reason. Naming both the cost and the benefit, stating your recommendation, and inviting input ("Thoughts?") models how senior engineers discuss design.
"This way is just better, full stop" pretends there is no cost, which is rarely true and shuts down discussion. "Cache it" omits all reasoning. "Why isn't this cached already?" is a loaded question that implies the author should have known. Articulating trade-offs honestly is a hallmark of strong technical communication.
4 / 5
How do you explain a concern when you are not fully sure it is a problem?
Calibrating your confidence honestly ("I'm not certain this is an issue, but...") is more credible than overstating. It flags a real concern (a possible race condition) while acknowledging you might be wrong, and it asks the author to verify rather than asserting a defect that may not exist.
"This is broken" claims certainty you do not have — and if you turn out to be wrong, it erodes trust. "You forgot about concurrency" assumes intent and blames. "Fix the race condition" presumes the bug is confirmed. Pairing honest uncertainty with a specific, checkable concern ("could you double-check the locking?") gives the author an actionable next step.
5 / 5
The author asks "why does this matter?" about a small style suggestion. What is the most professional response?
When challenged, a professional reviewer explains the weight of their feedback and is willing to let go of minor points. Here the reviewer clarifies it is a non-blocking consistency preference, gives the actual reason (consistency with the module), and explicitly defers to the author. This distinguishes blocking issues from optional nits.
"It just does" and "Because I said so" refuse to give reasoning. "If you don't know, you shouldn't be writing code" is hostile and condescending. Being clear about which comments are must-fix versus nice-to-have — and gracefully conceding the small stuff — keeps reviews efficient and relationships healthy.