What review taught me

I expected code review to make me better at spotting bugs in other people's work. It did, a little. What it actually changed was how I open a pull request.

Reading is slower than writing

The author has the whole change loaded in their head. The reviewer has a diff, in file-alphabetical order, with no idea which part is the point.

That asymmetry is the entire problem, and almost every review frustration traces back to it. A reviewer who cannot find the point will either approve without reading or ask questions the author considers obvious. Both outcomes are the author's to prevent.

Three habits that came out of it

Separate the mechanical commit from the thinking commit. A rename touching forty files and a logic change touching one should never arrive together. Reviewed separately, both are quick; reviewed together, the logic change is invisible.

Say what you decided against. "I did not use a computed here because the value is read once during setup" prevents the most common review comment before it is written. It costs one line.

Point at the risky part. Every change has one. Naming it is not an admission of weakness — it is directing the limited attention the reviewer has toward the place where it pays.

The uncomfortable part

Most review comments I received were things I already knew and had skipped. Not knowledge gaps — attention gaps, at the end of a task when it felt done.

That is a harder problem than not knowing something, because you cannot read your way out of it. The only fix I have found is mechanical: read the diff yourself, in the review interface, before assigning anyone. Half the comments never get written.