A code review can be a team’s best learning tool or its number one source of friction. The difference is almost never in the code: it’s in the tone and the focus.

If you’re reviewing

  • Critique the code, not the person. “This function does two things” instead of “you don’t know how to separate responsibilities”.
  • Separate blocking from optional. Prefix preferences with something like nit: so they don’t read as mandatory.
  • Ask before asserting. “Is there a reason not to use map here?” opens a conversation; “use map” closes it.
  • Acknowledge the good. A “nice solution for the edge case” costs nothing and motivates.

If you’re being reviewed

  • Depersonalize. It’s not your code being reviewed, it’s the code. Nobody is attacking you.
  • Respond to everything, even with a 👍 or by explaining why you won’t apply a change.
  • Small PRs. A 1000-line diff doesn’t get a review, it gets a surrendering “LGTM”.

The real goal

It’s not to find faults: it’s for the code to enter main better than it left, and for both people to learn something. If your review teaches nothing and improves nothing, it’s noise.