Good code review is a skill you can get genuinely good at, and it's as much about tone as about catching bugs. The best reviewers are remembered for the reviews that made the author think, not the ones that made them defensive. Learning to give and receive that kind of feedback is worth more than any single syntax rule.
About 2 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
I used to review with a verdict, and the author went defensive instead of thinking. Let me read someone else diff, then write the kind of note that explains the why, points to the exact line, and asks a question instead of issuing an order.
Start by reviewing your own diff before you even open the pull request. git log --oneline shows the commits, and the diff between them is what you are about to ask someone to read. You will spot the obvious mistakes, a leftover debug line, a test you forgot to update, that a reviewer would call out anyway.
Before you run it, say out loud what it will print. Then open the answer.
The pull request is where the review happens. Open it so the reviewer can read the exact change with a field for what changed and why. The whole back-and-forth lives in one place, tied to the real lines, instead of being lost in chat.
Before you run it, say out loud what it will print. Then open the answer.
Now read the diff as a reviewer. Instead of "this is bad", point to the exact line, name the risk it carries, and offer a fix or ask a question. Explain the why and say what is working too, so the author learns something and keeps their dignity.
Before you run it, say out loud what it will print. Then open the answer.
Ask about the intent, not just the syntax. Sometimes the single most useful note is "why are we building this at all?". The question can save wasted code and open the reviewer to your feedback, because it treats the author as a thinker rather than someone who got something wrong.
Before you run it, say out loud what it will print. Then open the answer.
Finish by either approving or requesting changes on the pull request, with the specific note attached. If you requested changes, the author fixes it and the merge waits. If you approve, the branch merges and the review is done.
Before you run it, say out loud what it will print. Then open the answer.
Point to the exact line, explain the risk it carries, and offer a fix or a question. Vague comments slow everyone down and leave the author guessing.
Ask about the goal, not just the syntax. Sometimes the single most useful note is "why are we building this at all?", and that question can save a lot of wasted code.
Bad: "This is bad."
Good: "Line 22 could overflow on large input. Add a check. Why are you using int here?"A good note explains the why, asks a question instead of issuing an order, and says what's working too. It's the difference between "fix this" and "help me understand this." The author learns something and keeps their dignity.
What changed here?
Is that test still passing?
Did I leave a console.log in production?Before you open a PR, read through your own diff once. You'll spot the obvious mistakes, typos, leftover debug output, a test you forgot to update, that a reviewer would call out anyway. Self-review short-circuits a slow back-and-forth and usually earns you a quicker, friendlier review.
They're pushing back on the code,
not on you as a person.
Ask: "What is the real concern here?"Separate your ego from the diff. Most blunt notes are hiding a genuine problem you can solve. Answer the problem, not the tone. Not every review is gentle, but almost every harsh one points at something real worth fixing.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.