Tinkerer

Adventures in code RSS Icon


How To Not Get Blocked While You’re Waiting For A Code Review

You’ve made your awesome new Pull Request, but the person who has to review it1 won’t have time for several hours.
While we all strive to review code as fast as possible, there’s always going to be delays.
So what do you do while you’re waiting for that review?
There’s always the coffee machine, but if you’re going to be hanging out there for hours, people might start asking questions like “Why are you here all the time?”, “Is that much coffee healthy for you” and “Please stop staring at me”

Here’s three ways to avoid those comments and keep working, while you’re waiting for a code review

Work On Something Else In The Codebase

A good strategy is to always have at least two tasks you can work on - preferably tasks that have as little as possible to do with each other.
That way, when you’re done with your first task, you can branch out from your main branch again to do some completely unrelated work.

Examples of this:

Here we see two branches branch out from main. When your first branch is ready for review, start the second branch and keep working.

To me this is one of the most effective ways to keep your velocity up, but it requires that you can juggle multiple tasks (and that there are multiple tasks to juggle)

There’s a lot to do in software development that isn’t just software development. There’s a lot of possible tasks we can do that don’t have anything to do with the code. These tasks are perfect to spend time on while waiting for review. Some examples:

Or just take a break so you’re ready to start working again afterwards.

Continue Working From The Same Code

Unfortunately it’s not always feasible to do something else.
Sometimes there’s only one thing to work on - and you have to base your work on the stuff you’ve just submitted in your PR.
You can branch out from the branch you’re looking to merge into master.
This means that while you’re waiting for the branch, you can simply continue working. You can then merge in the first branch, and later on the second one.

An example of this workflow. When you're done with your first branch, you create a PR, but also a new branch, based on the first branch. Then you can keep working, while keeping all your original changes.

Some caveats:

  1. More like gets to review it, knowwhatimsayin? 

Did you enjoy this post? Please share it!