The code review comment that changed how our teams work

Our pull request template used to ask the usual things: what changed, how to test it, which ticket. Reviews were slow, comments skewed towards formatting, and the genuinely risky parts of a change routinely went unexamined because nobody knew where they were.

We added one field: "What made this hard?" It is optional. It changed everything about the reviews.

Why it works

The author is the only person who knows which twenty lines of a four-hundred-line diff kept them up. Asking them to name it hands the reviewer a map. Reviews got shorter and better at the same time, because attention went where the risk was instead of being spread evenly across a diff.

It also does something subtler. Admitting difficulty in writing normalises it. Junior engineers stopped performing effortlessness, which meant they started asking for help earlier — the single largest source of avoidable delay on any team we have measured.

The latency problem

Most teams believe their review problem is depth. Measure it and you usually find it is latency: a pull request that waits eleven hours for a first comment costs far more than one reviewed shallowly in twenty minutes, because the author has context-switched and must reload everything to respond. We now track time-to-first-comment as a team health metric and leave review depth to the engineers.

What we do not do

We do not mandate a minimum comment count, block merges on approval from a specific senior, or run style discussions in review — the formatter owns style and it is not negotiable, which removes an entire genre of argument. A review is a conversation about risk between two people who both want the change to ship.