{
    Adam Ard
}

Code Reviews Not Code Approvals

In our brave new world of remote work, asynchronous methods of collaboration are especially important. When you are working in different locations, perhaps on different schedules, you need communication mediums that allow you to send a message and go on to something else. When someone on the other end of that message finds time, they will respond and quickly go on with their own work. No one is blocked. The alternative would be intolerable. Waiting for responses that may not come for hours, or even days, before continuing your work would be a colossal waste of time. And being forced to stop whatever activity you are engaged in to immediately respond to incoming requests, all to avoid making someone wait, is equally problematic.

While there are times when you need information quickly and are truly blocked, if this is common, there are likely issues with how your project is being managed. Is your manager feeding you tasks, one after another, without giving necessary high-level direction? Is your engineering organization failing to collect on-boarding information into documentation that is available for reference when you get stuck? Whatever the reason, it is clear that people need the ability to work independently without having to continuously ask for guidance.

But assuming you are able to code independently most of the time and have good asynchronous ways to communicate with coworkers, there is still the issue of code reviews. If you really want to stick with an asynchronous working paradigm, then code reviews are totally backwards. When a piece of code is ready to deploy, it always gets stuck waiting for a code review. Progress comes to a screeching halt. Isn’t this a synchronous wait? Blocking the pipeline with a manual approval step? You may wait for days before someone can look it over. Sure you can work on some other project, but context switching is expensive. And when you are pushing forward with momentum on your highest priority item being stopped for a code review is about as wasteful as it gets. Efficiency experts shed tears over this kind of stuff. Even assuming that you could move forward on a secondary project, what happens when you finish another task and the first project’s task still hasn’t been approved? Do you work on a third project? At some point the madness must stop.

The real problem here is that code reviews are really not reviews at all. The word review implies that something has been completed, and you are just looking it over — after the fact. What we do now should be called a code approval. Something is almost done (your scrum master will be quick to point out that nothing is ‘done’ until it is in production), and someone needs to check a box so it can move to completion. It is held up because it is hitting against a gatekeeper. If it were truly a review, you could have pushed it up and been on your way. But instead, you are waiting for permission. You’re stopped, sitting on the side of the road, watching while your competitors run by.

In an ideal world, you could deploy and then someone would immediately get a notification that there was new stuff to look at. Then, when they had a chance, when their brain wasn’t deep in another problem, they could look over it. In the meantime you can make progress on your next item.

I am aware that this would give some managers heartburn, but it needn’t. If something is broken in code that goes live, it can be fixed in a future commit (that will go up nice and quick since it doesn’t have to sit waiting for a review). If it is a serious issue, hopefully a basic smoke test would catch it and automatically roll it back. Truthfully, I would trust a test suite to catch a problem more than a human reviewer anyway. Wouldn’t time spent on reviews be better spent building more comprehensive tests anyway?

Have I convinced you? Are you ready to start doing actual code reviews and leave code approvals to the birds?