The Art of Code Review: How to Critique Without Being Toxic

Code reviews are the lifeblood of a healthy engineering team. They prevent bugs, ensure consistency, and most importantly, facilitate knowledge transfer. However, they are also a common source of friction. We've all received that comment: "Why did you do it this way?" or "Fix this."

Reviewing code is a skill, distinct from writing code. Here is how to master it.

---

1. The Goal is "Better Code," Not "My Code"

The most common trap senior engineers fall into is trying to make every pull request (PR) look exactly like code they would have written.

The Golden Rule: If the code is correct, performant, readable, and follows the style guide, approve it, even if you would have approached it differently.

• Bad: "Rewrite this using a reduce function."
• Good: "This for loop works, but a reduce might be cleaner here. What do you think?"

Offering alternatives as suggestions rather than commands empowers the author to own their code.

---

2. Automate the Nitpicks

Human beings should not be arguing about whitespace, semicolons, or indentation. That is a waste of expensive salary time.

• Linting: Use ESLint/Prettier (or standard formatters for your language).
• CI Checks: If the build passes, the formatting is correct. Period.

If you find yourself commenting "Add a space here," your tooling has failed you. Invest time in your .eslintrc or GitHub Actions workflow so you never have to make a style comment again.

---

3. Categorize Your Feedback

Not all comments are equal. Explicitly labeling your comments helps the author prioritize.

• [BLOCKER]: Even if this is the only issue, I cannot approve the PR until it is fixed (e.g., security flaw, major bug).
• [NIT]: Tiny, non-blocking issue. "Fix it if you want, or ignore it."
• [QUESTION]: "I don't understand how this edge case is handled."
• [PRAISE]: "This is a really elegant solution!"

Example:

[NIT] Variable name u is a bit vague. Maybe user or currentUser?

---

4. Critique the Code, Not the Person

Language matters. Avoid "You."

• Toxic: "You broke the login page with this change."
• Constructive: "This change seems to prevent the login form from submitting."

By focusing on "This change" or "The code," you remove the personal attack. The code is an artifact we are working on together; it is not an extension of the author's self-worth.

---

5. The "Feedback Sandwich" is Okay, But Sincerity is Better

The old management advice of "Praise, Critique, Praise" can feel manipulative. Instead, just be genuinely appreciative when you see good work.

If you are reviewing a massive, complex PR that clearly took days of effort, start with: "Thanks for tackling this huge refactor! I know it was a beast. I have a few comments below on edge cases, but the architecture looks solid."

Acknowledging effort goes a long way.

---

Summary

Great code reviews are a dialogue, not a lecture. Your job as a reviewer is to be a safety net, not a gatekeeper. By automating the trivial stuff, explicitly categorizing your feedback, and checking your tone, you can turn code reviews from a stressful chore into the best learning tool your team has.