Code Review for Small Teams: What to Check and What to Skip

What is a code review for?

A code review is a second person reading a change before it is merged. It has two jobs. The first is to catch problems the author cannot see, such as a wrong assumption, a missed edge case or a security gap. The second is to spread knowledge, so that more than one person understands each part of the product.

Style arguments and personal preference are not on that list. When reviews fill up with them, the real jobs get less attention.

What should a reviewer check?

Read the change in this order. Each step matters more than the one after it.

1. Does it do what was asked? Compare the change with the ticket or the agreed behaviour, not with what the reviewer would have built.
2. Is it correct in the unusual cases? Look at empty input, failures, repeated requests and two users acting at once.
3. Is it safe? Check who is allowed to call this code, what user input reaches it, and whether any secret or personal data ends up in a log.
4. Is it tested? A change that alters behaviour should come with a test that would fail without it.
5. Will the next person understand it? Names, structure and comments should explain intent, not just mechanics.

What should you leave to automation?

Anything a tool can check should not use human attention. Formatting, import order, unused variables, type errors and known vulnerable dependencies belong in the build pipeline. If the pipeline fails, the change is not ready for a human to read.

This keeps review comments about design and behaviour. It also removes the awkward conversations about style, because the tool decides and nobody takes it personally.

How big should a change be?

Small. A reviewer can read a short change carefully. A long one gets skimmed, and skimmed reviews miss defects. As a working rule, if you cannot explain the change in a few sentences, split it.

Useful ways to split a change:

• Move or rename code in one change, and alter behaviour in another
• Add the new code path behind a switch, then turn it on separately
• Separate a database change from the code that uses it

How fast should a review happen?

Fast enough that the author is not blocked. A change waiting for days loses context, collects merge conflicts and encourages people to batch more work into each change, which makes the next review harder. Many teams agree a simple expectation, such as a first response within one working day, and treat a waiting review as a priority over starting new work.

How should feedback be written?

Comment on the code, not the person. Ask a question when you are unsure, and explain the reason when you are asking for a change. Mark clearly which comments must be fixed before merging and which are optional suggestions. The author should never have to guess whether a comment blocks the merge.

Authors have a duty too. Describe what the change does and why, point out the part you are least sure about, and say how you tested it. A clear description makes the review quicker and the result better.

What if the team is only two or three people?

The same rules apply, and the knowledge-sharing benefit is larger, because a small team has less cover when someone is away. If you are a solo developer, a review is still useful: read your own change on the screen the next morning, or ask a trusted outside engineer to look at the riskiest changes, such as payments and access control.

Where does review fit in the wider process?

Review is one layer of quality, alongside automated tests, staging checks and monitoring after release. It works best when the other layers exist. Our guide to software testing and quality assurance covers those layers, and documentation best practices explains how to record the decisions a reviewer needs to understand. If shortcuts are building up despite review, read technical debt explained for founders.

*Want an experienced team that reviews every change before it ships? Talk to us →*