Code Reviews, Not Code Approvals

In our brave new world of remote work, asynchronous methods of collaboration have become essential. When you’re working in different locations—or even different time zones—you need communication tools that allow you to send a message and move on. The idea is simple: you deliver a message, and whenever the other person has a moment, they’ll respond, then continue with their own work. No one’s blocked, and no one is forced to interrupt their focus to keep someone else unblocked. The alternative would be intolerable: waiting hours, or even days, for responses, or stopping whatever you’re doing to reply immediately just to avoid holding someone up.

There are, of course, times when quick responses are necessary, but if you frequently feel blocked, there may be underlying project management issues. Is your manager simply assigning tasks one by one, without giving you a broader sense of direction? Is your organization failing to consolidate on-boarding and reference materials, leaving you hunting for answers instead of finding them documented? Regardless of the cause, people need the ability to work independently without constant guidance.

Assuming you’re able to code independently most of the time, and have good asynchronous ways to communicate with coworkers, there’s still one big hitch: code reviews. For teams striving to work asynchronously, code reviews can be a serious roadblock. When a piece of code is ready to deploy, it often grinds to a halt, waiting for review. Progress stops cold. Blocking the pipeline with a manual approval step can mean days of waiting for someone to sign off on it. Sure, you could pivot to another project, but context switching is costly. When you’re on a roll with your highest-priority item, getting stopped by a code review is about as inefficient as it gets.

The real issue here is that code reviews aren’t reviews at all—they’re approvals. “Review” implies that something is complete and you’re looking it over after the fact. But what we call a “code review” today is more of a gate-keeping process, where the code is almost done, and someone has to give it a green light. It’s not simply getting a second opinion; it’s waiting for permission, holding up the flow while work sits on the sideline. If it were a true review, you’d be able to push your code live and get feedback afterward. Instead, you’re stuck, watching as progress slows.

Imagine this alternative setup: you deploy your code, and a notification goes out letting someone know there’s something new to review. At their next opportunity, when their mind isn’t deep in another problem, they can look it over. In the meantime, you’re able to keep moving on your next task.

I know this idea might give some managers heartburn, but it doesn’t have to. If a problem does slip through, it can be addressed in a future commit, which would go live faster since it isn’t waiting on a review. For serious issues, a basic smoke test could automatically catch and roll back errors. And let’s be honest—a robust test suite is likely to catch issues more reliably than a human reviewer. Wouldn’t time spent on manual reviews be better invested in building more comprehensive tests?

Ultimately, code reviews should empower us to keep moving, not hold us back. By shifting from code approvals to genuine code reviews, we can create a workflow that prioritizes progress and learning without unnecessary delays. Embracing a post-deployment review approach allows us to maintain momentum, foster independence, and focus on building reliable tests that catch issues before they reach production. Let’s make code reviews a tool for growth, not a bottleneck.