Tech lead: code reviews that grow the team

As a tech lead, I have mentored developers from junior to senior. Of all the tools at my disposal (pair programming, workshops, documentation), the code review has had the most impact. Provided it is done well: a poor review slows the team down, frustrates authors and does not even catch the real problems.

What is a code review really for?

• Sharing knowledge: at least two people know every part of the code.
• Aligning practices: conventions, architecture, in-house patterns.
• Catching design problems while they are still cheap to fix.
• And, incidentally, finding bugs. Incidentally, because tests and automated tools do that better.

The code review pyramid

One model helps me prioritize: the code review pyramid, popularized by Gunnar Morling. The lower a concern sits in the pyramid, the easier it is to automate and the less it deserves human attention. The higher it sits, the more expensive it is to change after merging.

• Code style: Prettier and ESLint. A human should never comment on indentation.
• Tests: are the important cases covered? Do tests check behavior or implementation?
• Documentation: are non-obvious decisions explained?
• Implementation: readability, error handling, performance, security.
• API and data model design: this is where the hardest decisions to undo live. This is where the review adds the most value.

How to phrase comments

Form matters as much as substance. A few rules I follow:

• Ask rather than assert: "What happens if the list is empty?" invites thinking; "This is wrong" ends the conversation.
• Explain the why: a documentation link or a sentence of context turns a correction into learning.
• Separate blocking from optional: I prefix my comments. blocking: for what must change, suggestion: or nit: for the rest. The author knows where to focus.
• Point out what is done well too: a "nice extraction" reinforces good practices more than you would think.
• Switch to a call after three back-and-forths: ten minutes on a call beat a forty-comment thread.

On the author's side: make reviews easy

• Small pull requests: beyond 400 lines, attention drops sharply. Split them: preparatory refactoring on one side, the feature on the other.
• A useful description: which problem, which solution, how to test, screenshots for UI changes.
• Self-review before asking: re-reading your own diff catches a good share of oversights.

Avoiding the bottleneck

The tech lead should not be the mandatory reviewer of every pull request. Otherwise the team waits, and nobody else learns to review.

• A response-time goal: a first response within half a day.
• Rotating reviewers, juniors included: reviewing other people's code is one of the best ways to learn.
• Written rules: a shared review guide keeps each reviewer from having their own standards.

Conclusion

A good code review is not measured by the number of comments, but by what the team learned and by the fact that merged code is understood by more than one person. Automate the base of the pyramid, focus on design, and phrase every comment as if you were talking to someone you want to see grow.