From Pull to Push: Optimizing the Code Review Cycle with Automation

Building software is a highly collaborative endeavor, and code review is key to ensuring this collaboration goes smoothly. An inefficient code review process frustrates engineers, blocks project progress, and can even allow bugs to make it into production.

As engineers, we often need to work outside the system to make code review efficient.

• How many times have you messaged a teammate on Slack asking them to review a PR?
• When you leave feedback on a PR, do you have to periodically refresh GitHub, just to make sure your comments were addressed?

We believe these problems stem from the inherent pull-based model of code review tools — engineers are forced to constantly pull data and decide if they need to take any actions.

At Monolist, we want to move to a push-based model, where we can provide intelligent reminders and suggestions to make sure nothing slips through the cracks.

The problems with pull-based code review

At each handoff point in the code review flow, one party is depending on the other to discover that they’re now unblocked.

For example, after you leave comments on your coworker’s PR, you have to wait for her to first discover the new comments, and then ultimately address them. Once she has modified her code, she has to wait for you to discover that your feedback has been resolved, and approve the PR. This discovery happens by sorting through the voluminous email notifications you receive from Github, or worse, periodically refreshing and scanning Github itself.

This pull-based discovery process is problematic for a few reasons:

1. Pulling requires context-switching. Being a good teammate requires you to avoid blocking your coworkers, which requires you to periodically scan GitHub. However, this comes at the cost of distracting you from your own work.
2. Pulling is unreliable. Even if you manage to consistently scan and discover new information, you still may be blocked from taking your action due to external factors. For example, you may notice that your teammate has approved your PR, but if the build hasn’t passed yet you can’t merge it. This means you have to wait until the next time you scan GitHub.
3. Pulling is prone to error. We’re all human, which means we can easily forget to consistently scan GitHub. This blocks our teammates and lengthens our project delivery timelines.

Moving to a push-based paradigm

At Monolist, we ultimately believe that computers are better at scanning and discovering information than people. Instead of you stressing about discovering when you’re on the hook, Monolist will intelligently tell you.

When you integrate Monolist with GitHub or GitLab, pull requests you create or are assigned to will automatically come into your inbox. Unlike email, this inbox never gets stale. Merged or closed pull requests will go away, and you can view comments and build status inline.

At each stage, we’ll create reminders for you only if the PR is actually ready for your action. For example, we won’t remind you to approve a pull request that still has outstanding comments.

When you’re ready to take an action, you can comment on, approve, and ultimately merge your PR without leaving Monolist.

Ready for better code review?

• Tweet a link to this blog post with #PullToPush and we’ll invite you to skip the waitlist!
• Don’t want to tweet? Request access to join the waitlist instead.