Code Review

Reviewing is a skill, separate from writing. What a good review looks for, in order: is it correct, is it safe, will somebody understand it in six months, and only then, is it how I would have written it.

That last one is where most bad reviews live. A different approach that works is not a defect, and treating it as one is how review becomes something people avoid.

Make the change easy to review. A small pull request gets a real review; a two-thousand line one gets approved. That is not laziness, it is a limit on attention, and the fix belongs to the author.

Write a description saying what changed and why. Separate refactoring from behavior change into different commits or different pull requests, because a reviewer cannot see a logic change buried in four hundred lines of renaming.

Reviewing your own work. Alone, open your own pull request and read the diff before merging. It is remarkable what you notice reading a diff that you did not notice writing it: the debugging line left in, the commented-out block, the function that no longer matches its name.

Leave it overnight if you can. Reading your own code as a stranger is a genuine skill and this is how you practice it.