MildFist
← Back to Blog
EngineeringProcess

How We Do Code Reviews

Code review is the practice of having one or more engineers read and provide feedback on another engineer's code before it is merged. Done well, it catches bugs, improves code quality, spreads knowledge across the team, and builds a shared sense of ownership over the codebase. Done poorly, it becomes a bureaucratic obstacle that slows teams down without adding proportionate value.

The difference between effective and ineffective code review is mostly about clarity of purpose and consistency of execution.

What Code Review Is For

We use code review for three things: catching bugs and logic errors that the author missed, ensuring that new code meets the team's quality standards and fits coherently into the existing architecture, and spreading knowledge about changes so that more than one person understands each part of the codebase.

We are explicit about what code review is not for: enforcing stylistic preferences, relitigating design decisions that were made earlier in the process, or demonstrating the reviewer's knowledge. Reviews that focus on these things are demoralizing and slow.

Making Reviews Useful

The most valuable reviews focus on correctness first: does this code do what it is supposed to do? Are there edge cases that are not handled? Is the error handling adequate? These are questions that are hard for the author to answer about their own code, because they naturally test the paths they have thought about.

We ask reviewers to explain their concerns clearly and, where possible, to suggest alternatives rather than just flagging problems. "This will fail if the list is empty" is more useful than "this is wrong." "Consider using a map instead of a filter followed by a find" is more useful than "this is inefficient."

Review Culture

Code review creates a feedback dynamic that can either build trust or erode it. We try hard to maintain a culture where reviews are collegial and constructive, where authors are not defensive and reviewers are not adversarial, and where the shared goal is always code that works well and is easy to maintain.