Get your code reviewed fast ⚡️

Few pointers to become a better PR author

Are you tired of waiting for your PR (Pull Request) to get reviewed?

Chances are that you might be the reason behind the delay.

If you get into the shoes of a reviewer, you will realise that they have lots of PRs to review everyday.

It’s your job to make it easy to understand and interesting for them!
(Just like how you polish your resumes for your recruiters)

What has worked for me so far

I. Structure your PR description as if you are telling a story

Sections which you can add in the description:

1. Context

   • What is this PR about?

     • any issue (bug) you fixed

     • any new feature you added

   • Add references:

     • of Slack/Teams discussion threads about these specific changes

     • ClickUp links (or any other task management tool)
       
       

2. Summary of changes done

   • Briefly mention about what changes you did

   • Few examples:

     • “updated links in these specific files”,

     • “refactored a piece of code”

     • “added a new utility function”,

     • “fixed pylint issues”, etc...

       
       

3. Screenshots

   • Add few screenshots especially if there are UI related changes. Avoid adding too many.

   • Add short screen-recordings of your changes. Useful if you want to explain a flow (for example: web-app sign-in flow)

     
     

4. How changes were tested

   • Add test-cases if any

   • Add images/query logs if you are testing some database changes

     
     

5. Additional info

   • Mention if these changes have already been discussed/confirmed with other stakeholders (like infra or design teams) or not

   • Add important notes if any

II. Keep it short

• It’s better if your PR does not have more than 30 line changes.

• Try to divide big PRs into several small ones.

• Try to make sure that your changes doesn’t touch more than 3 - 4 files.

I am also guilty of not following this sometimes 😛. It’s ok.

III. Help them help you

Help them navigate easily.

Under the Files section where you view file changes,

• add brief explanatory comments under those changed lines which you think might become a point of discussion/argument with your reviewer later

• mention in the comment if a particular change has already been explained in the PR description

  Bonus: Can add screenshot below a specific changed line so that reviewer knows which specific UI section is changed after making that particular change
  

This personally has done wonders for me in the past.
Helps avoid unnecessary PR review meetings.

---

If you follow these points, it will definitely save your’s as well as your reviewer’s time.

Cheers!