How to get Pull requests (PRs) reviewed faster

There is something really cool about having other engineers look at your code via pull requests (PRs) and give you feedback on what can be done better. With that being said, PRs can sometimes have lots of back and forth due to many reasons and this would eventually slow the merge of the PR. You would then end up maintaining this PR and actioning feedback while working on your current work and this would require context switching which is a little disruptive. 

So here are a few things that I think can certainly speed up the approval of your PR

1. Write a good intro to the issue and mention the fix 

Context for me is everything. I need to know why the need for a certain fix originated when I'm reviewing a PR, so that I can then see how the fix effectively is a fix. I try to do this by outlining the issue as effectively as I can in a Jira ticket/or asking a stakeholder who discovered the issue to do so, and then link that ticket in the PR description. 

When outlining how the solution is the solution, I try to add detail about where the issue was originating from, why it was causing the said issue, my fix and the steps I took to decide on it being the best possible fix. This would give the other engineers insight into my thinking patterns so that they can give me better contextual feedback. 

Another cool thing I have seen engineers do is adding a before and after video of the fix. This is especially important if the change is something that is visible on the User Interface (UI) of the app. 

2. Make smaller PRs

The more lines of code a PR has, the longer it takes to review. And it's really tough to ask someone to diligently review 12000 lines of code. People get tired, make mistakes and then there is an increased chance of bad code being merged in. 

Dividing a larger PR into several smaller PRs means people would review them faster as the cognitive overload is much less.

3. Make a PR do one thing, really well

This stems from the above. It's so much easier to follow and give feedback on a PR that does one thing than many different things. An example of this would be, let's say there is a sizable React class component that needs to be updated to be a functional component and contain typescript. A good way to go about this is to divide the task into 3 PRs. The first PR would be to convert the code into typescript. The 2nd to convert the now typescript-covered class component to a functional component. The 3rd would be to update the tests that might be breaking due to the conversion of the class component to a functional component. 

4. Ensure all the checks are passing 

Sometimes a PR gets held up because you didn't run the pre-commit tests and the unit tests are failing on your CI/CD pipeline. Sometimes the build might be failing because the linting is off and there are 4 spaces in front of a line of code instead of 2. So make sure to run any pre-commit checks you need to ensure that there are no easily preventable issues that might end up being flagged by the reviewers. 

5. Action the feedback and ask for a rereview

Once you receive some feedback from a reviewer, and action that, make sure to ask the reviewer for a second look.  This makes sure your PR is on their radar and you get approved faster. 

6. If you don't action the feedback, mention why and have a discussion 

If there is a time when you don't agree with some of the feedback provided, it's important to convey that and have a discussion. Doing so is important because both parties have to come to a consensus about what is best for the product, mark the issues as resolved and move towards having the PR merged. 

7. Clear the ambiguity 

Sometimes there might be updates to lines of code that at first glance might not have much to do with the objective of the PR. If there are such situations, it’s good to leave a comment outlining why that was required so that the reviewers will not pick up on it. This saves time for both parties. 

Of course, the above is not at all a comprehensive list with rules set in stone that must be followed. Each PR is different and it’s our duty to do what’s right for them. I do hope that the above gives some food for thought, and if you have any more I can add here, feel free to comment below!