Staff engineering
Tech lead code review is a system
Good code review is a system for quality, ownership, mentoring and risk control.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
3 min read
Review is not a style contest
Weak code review spends too much time on taste and too little time on risk. Naming, spacing and small style issues matter, but they should not consume the review budget if the feature has unclear ownership, missing tests or a broken failure path.
A tech lead has to make review useful at the system level. The goal is not to leave many comments. The goal is to make the code safer, the author stronger and the team more consistent.
That requires a review system, not just reviewer opinions.
Separate correctness, design and coaching
Correctness comments are about bugs, data loss, crashes, security, performance and broken product behaviour. These should block when necessary.
Design comments are about boundaries, naming, testability, ownership and future change. These should explain the tradeoff, not just state a preference.
Coaching comments are about helping the author grow. These work best when they teach the reason behind the suggestion instead of turning the pull request into a lecture.
Review the failure path
Mobile code often passes review on the happy path and fails in production on the interrupted path. The app backgrounds, the request returns late, the cache is stale, the user taps twice, the network disappears or the view is recreated.
A tech lead review asks what happens when the ideal flow breaks. What state is persisted? What work is cancelled? What can be retried? What does the user see? What is measured after release?
That habit catches more production bugs than arguing about pattern purity.
One pull request, three comments
Take a PR described as:
Add automatic retry when checkout returns a network error. Tested on the simulator.
It says nothing about what the endpoint guarantees or what a retry means to the user. Compare the comments:
| Weak comment | Better comment |
|---|---|
| This feels unsafe | Identify the server contract for a request whose response is lost. Until we know how a repeated operation is handled, this retry has an unresolved correctness condition. |
| Add tests | Add a contract test for server acceptance followed by a lost response. Show the state the client presents and the identifier used to reconcile. |
| Rename this variable | Non-blocking: operationID would make the request's identity clearer. The contract and the recovery behaviour are what block this PR. |
Mark each comment blocking or not, so the author does not have to guess. The contract test runs against a fake that models the agreed protocol. It shows the client behaves; it does not show that production does. Keep that line in the review record.
Turn repeated comments into standards
If you leave the same comment every week, the team does not need another comment. It needs a standard, checklist, lint rule, example, template or shared component.
This is where tech lead work compounds. A good review fixes one change. A good standard prevents a class of future review comments.
The team should not rely on one person remembering every risk in every pull request.
Review should make ownership clearer
At the end of review, the owner should know what they are responsible for after merge: tests, rollout, metrics, follow-up cleanup, documentation, migration and support.
Code review is one of the places where teams teach what quality means. If the review culture is vague, quality becomes personality-driven. If the review culture is clear, engineers can grow into it.
The checklist version of this review is The Second Pass.
