What to ask your agency about code review
The version of this that works is simpler than the version most people imagine. If you are briefing an agency or a freelancer on code review, these questions are worth asking early.
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.
Questions worth asking
- Who will actually do this work, and have they done it before?
- How will we know afterwards whether it worked?
- What happens if it needs changing in a year?
- What are you assuming that we have not confirmed?
What a good answer sounds like
Review catches problems tests were never written for. That sounds obvious written down. It is still the thing most often skipped. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Comment on the code, never on the person. In practice this is a scheduling problem more than a technical one. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
What this looks like day to day
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
- 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.