Critical Thinking and Code Review as High-Leverage Engineering Habits

What I look for in the first two minutes of a review

Whenever I review a pull request or design a new module, I start at the boundaries. How does external input enter this function? What happens if a database query returns zero rows? Are errors handled explicitly or swallowed silently?

Once the boundaries are solid, I look at cognitive load. If a function requires scrolling across three screens or tracking seven mutable variables at once, splitting it into smaller, named steps makes bugs obvious before they ever reach production.

“Write code so that the person debugging it on a Friday afternoon doesn't have to guess what you were thinking.”

Read the tests before the implementation

Tests in a pull request tell you what the author believes the change does. Reading them first gives you the intended behavior in the author's own words, and the gaps are often visible immediately: the happy path is covered, but the empty result, the duplicate request, and the timeout are nowhere to be found.

Asking for a missing test is the highest-value comment a reviewer can leave. It outlives the pull request, protects the next refactor, and turns a one-time catch into a permanent guardrail.

Comment on risk, not taste

A good review separates three kinds of comments: this will break, this might break under load, and I would have written it differently. Only the first two deserve to block a merge. Taste belongs in the style guide and the linter, where it can be applied consistently without spending a colleague's afternoon.

The reviews I remember receiving, years later, were never the longest. They were the ones that spotted the assumption I did not know I was making, and explained it kindly enough that I could actually hear it.