Get Pull Requests Merged Faster
The biggest blockers to getting PRs merged quickly are: Size, Attention, and Communication. Everything else is a symptom of these three core issues.
Size
Smaller is better
Unless your colleagues love a 3 hour coffee meets code review break each day, you’re gonna want to ship smaller diffs. Our customers aim to be in 100-200 LOC change with 3-5 files implicated as a benchmark.
If smaller PRs aren't a focus at your company you should absolutely ask why and try to be the change they need. Larger PRs slow review time and this decreases the entire velocity of your team.
Complexity
More lines & files changed not only increases review time & difficulty, it increases complexity. This means your reviewer has to focus and use their working memory more in order to hold all the code changes in mind as they consider your diff. This is an exhausting task. Which is why your team mates might take one look at that 2,000 liner and nope out of it until tomorrow morning, when they're fresh and ready to tackle it.
Ship more frequent and smaller PRs to get around the complexity problem.
However, sometimes you need to ship a mammoth PR, in those cases it’s good practice to pick a reviewer ahead of time and warn them you’re landing a cargo plane of a diff that they're going to need to review. This takes great communication.
You can also just ask Squire to do the review for you:
Squire.ai: Line by line code review
Squire reviews pull requests and has the context of your codebase.
Communication
Descriptions should be descriptive
If you’re aiming for a quick review cycle on your PR, write a good description. By framing the code change well it makes it easier for your team to provide a review. Most PRs that hang long without review are due to teammates lacking context; what are you changing, what’s the impact, where should I focus my attention?
It’s your job to write a good PR description. It’s their job to ask you 500 questions about it.
Seriously, by communicating well you’ll see your PRs get picked up for review & get hit with a LGTM faster.
Squire automatically creates PR descriptions for you if you want to skip crafting these yourself:
Squire.ai: PR Description
Leave your PR description blank or add tags to your template and we'll summarize for you.
Too much of a good thing
Another core communication issue is too much back and forth in a PR. Our customers tend to keep it to two cycles at most before merge or close:
- First review, remember an acceptable first review is “I believe this is implemented wrong, let’s close this PR and chat” Be kind and you’ll go far.
- Once all open suggestions are resolved the second review should really be focused on getting the PR merged unless a show stopper is discovered.
Debating implementation details, why typescript is superior, or that you really think this repo should be tabs instead of spaces does not belong in a PR review - it’s just going to hold things up. Take those conversations into slack or a room and figure it out as a team. Agree and commit to standards and then simply hold each other accountable to those standards in PR reviews.
Nitpicks
Ah the glorious nitpick, an important and yet terribly misunderstood part of PR reviews. Our customers describe a good nitpick as “a suggestion that doesn’t need to be accepted” and “a suggestion that helps future proof, keeps code base cohesion, or improves readability but isn’t material to the functionality”
All of them agree though that while a nitpick suggestion may not need to be accepted it must be addressed. All developers are expected to reply to the message and decline a suggestion or, if accepted, ship the change.
Communicating a nitpick well helps your team understand your intention and how they are handled should be a part of those standards we mentioned above. That way your team knows how to address them quickly.
Attention
Probably the biggest blocker to getting your pull request merged is simply getting the attention of a reviewer. We’re all busy, trying to reduce context switching, and basking in flow with good music. And someone gave us ‘focus mode’ and you’re damn right I’m using it.
What’s a noble dev to do?
Go direct
If you’re familiar with the code base you’re pushing your PR to, it's likely you know who the top reviewers are, hit them up on slack and add them as a reviewer directly. Offer to swap reviews to sweeten the deal on any work they might have coming in too.
Be loud
If you’ve got structured slack channels per repo or team don’t be afraid to drop your open PR link in the appropriate channel and ask for a review. You can often get feedback much faster by asking, sometimes you even score some feedback in a thread that you can get at immediately.