Code review

Two directions, one skill: reviewing, and being reviewed.

Reviewing

Read the diff against what the change is for, not against your preferences. Order matters — spend attention where damage is expensive:

1. Correctness — does it do what it claims, including at the boundaries and on the error path?
2. Blast radius — what else consumes this? Signature and schema changes are the ones that break things far away.
3. Security and data — untrusted input, authorization, anything logged or persisted.
4. Tests — do they pin the new behavior, or do they pass regardless?
5. Design — will this shape hold under the next change?
6. Style — last, and only where a linter cannot.

Say which category each comment is, and whether it blocks. A review that mixes a data-loss bug with a naming preference in one undifferentiated list wastes the author's judgment.