Getting started with code review
Teams tend to reach for this after something has already gone wrong. A short on-ramp to code review for teams who have not touched it before.
Most development decisions are really maintenance decisions wearing a different hat. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
The reason this keeps coming up
Review catches problems tests were never written for. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Your first week
- Find out what is already in place
- Small pull requests get real review, large ones get approved
- Change one thing and measure it
Comment on the code, never on the person. That sounds obvious written down. It is still the thing most often skipped. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
What this looks like day to day
Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about code review before you move on:
- Someone can say what the current setup is without going to look
- Comment on the code, never on the person — 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.