Code reviews have their value, but I'm increasingly convinced their current iteration is a net negative for developer productivity.

It started with my own frustrations at our own review processes at Sourcery.

We’ve got pretty great engineering practices, but I still found myself waiting hours to get a review on a PR that was ready to go out into the world.

On its own a single review taking a few hours might not be a huge deal. But when your team is trying to move as fast as possible it adds up quickly.

It finally hit a point where I started thinking that reviews in their current form just aren’t worth it.

And I’m certainly not alone in thinking this.

Now, my takeaways are probably a little different than Erik’s and Bob’s in that post.

Reviews have more value than either of them ascribe to them, but the value doesn’t outweigh the time cost reviews have today. In order for teams to move as fast as possible you need a review process to give feedback so you’re not building up tech debt or letting bad things slip into production. But that feedback needs to happen while a developer is still in flow.

In other words we need to start shifting code reviews further left.

One way to do that is through pair or mob programming, but that’s taking up more developer time in a different way.

I envision a workflow for feature development where:

• I agree the design and implementation plan of the feature with the team or a team mate
  • Depending on the complexity of the feature this could be no design at all, a few bullet points in the issue tracker, or a full design discussion
  • Ideally this happens before I finish my current task so I can start the feature immediately
  • In many teams this happens during pull request review which is way too late, and either blocks the PR or is waved through without proper consideration
• I implement the feature in a series of small PRs. For each PR:
  • I write the code
  • I open a PR
  • I immediately get a complete code review in seconds
  • I address any issues that review raises
  • My PR is immediately approved (assuming I’ve fixed all the blocking changes)
  • I fix any CI issues
  • I merge my PR (ideally within 5 minutes of opening it)
  • I can repeat this 10+ times / day
• Peer reviews can be done asynchronously after the fact
  • I am not blocked waiting for a review
  • My team mate can review my PR when is convenient for them
  • I can address any of their additional comments in follow up PRs, or they can quickly merge PRs to address them themselves

In order for this to happen a couple of things need to be true.

1. I need to be working with smaller PRs at all times. There are lots of reasons this is a good practice to begin with. But, it’s even more important if we’re trying to get quick decisions about whether or not a PR should be merged.

2. I need a way to get my PR reviewed and approved immediately. In other words - I need a fully automated code reviewer.

This is why we’ve started building the new version of Sourcery Code Reviews. We want to make it so any engineering team can:

• Get every code change reviewed in seconds
• Get immediate decisions on approval/rejection of a PR
• Receive feedback on their code changes without needing to context switch
• Move to a workflow where they’re designing up front, then rapidly iterating with frequent, small pull requests

We’re still in the early days here, but you can try out the first version of our code reviewer for GitHub. We’re not making approval or rejection decisions yet (that’s coming in a few weeks), but we are able to give you immediate feedback on every PR.

I love thinking about how code reviews should work, so if you’ve got thoughts on this let me know.

• Brendan and the Sourcery team