Tips to Get Your PRs In Faster (and make your team love you)

Huge and complicated PRs suck, and are awful for team velocity, shipping features and the bottom line. They can take lots of time to review and an immense amount of back and forth between you and your reviewers to drive the PR over the line, by which point you're exhausted and demotivated. Here are some of my tips to help you get your code in faster 👉

🧠 Minimise cognitive load in each PR!

If your colleagues can quickly wrap their head around what you’re doing (and why), it’ll lead to your PR getting in faster. This removes pressure from your peers to approve haphazardly, and often leads to more insightful feedback. What does this mean in practice? 

• A larger number of smaller PRs are easier to evaluate than a single big PR. While there's a tradeoff in the overhead of creating and describing each smaller PR, smaller PRs on average allow you to concentrate on producing the best quality work you can (which is easier in small chunks) and help your reviewers quickly get up to speed with the intention behind the PR. 
• If you can't avoid larger PRs, keep them self contained and atomic. Sometimes it is unfeasible to make your PRs smaller, so the best thing for minimising cognitive load is to keep them very well contained. Don't go changing multiple, tangentially related parts of the codebase. Keep your changes logically connected to one another, and easy to wrap your head around as to how and why you've done it a certain way. For instance if you're making new CRUD endpoints, there's an argument to be made about including all of them in one PR rather than splitting it out, as the cognitive load is smaller by virtue of it being a well known pattern. 
• Avoid giga-PRs: Long lived feature branches that you merge code into may seem good in theory, but really really suck when it comes to getting the feature branch over the line in the final PR into dev. 

👷 Separate PRs for refactors and adding new features!

Refactors should be aimed to be done quickly and to not change or break functionality if possible. By combining refactors and new features, it becomes very unclear which parts are new code (ie, needing greater scrutiny) and which parts are simply moving code around. Separate them out and your colleagues will thank you. 

💭 Explain and give clear testing methods!

Give clear and concise testing methods, comment your code and record a Loom video in your description. Write tests where appropriate to give your reviewers confidence. Basically, make it easy to replicate what you’re doing and validate that your approach is the correct one.