Code review: the questions we get asked most

There is no clever trick in this one, just a handful of decisions worth making deliberately. The questions about code review that come up most often on our calls.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Do we need to care about this?

Review catches problems tests were never written for. There is a version of this that is over-engineered, and it is worth avoiding. Assume whoever inherits this will have half your context and none of your patience.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. There is a version of this that is over-engineered, and it is worth avoiding.

How do we know it is working?

Comment on the code, never on the person. The cost of getting this wrong is rarely visible on the day it happens. Budget a little time for it every quarter and it never becomes a project of its own.

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
• Review catches problems tests were never written for — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.