Code review for small teams

The advice here is unglamorous, which is probably why it gets skipped. Most advice about code review assumes a team that does not exist at your size. Here is the version that does not.

Most development decisions are really maintenance decisions wearing a different hat. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What to keep

Review catches problems tests were never written for. There is a version of this that is over-engineered, and it is worth avoiding. If it only works because one person remembers to do something, it does not work yet.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. This is the sort of thing that compounds, quietly, in both directions.

How to approach it

Comment on the code, never on the person. Small and consistent beats large and occasional here. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

In practice

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about code review before you move on:

• Someone can say what the current setup is without going to look
• Small pull requests get real review, large ones get approved — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.