What inspires you to review Pull Requests?

Not only is it part of most jobs, but pull requests by their nature allow for group analysis of contributions. Programmers love to write code, but for some reason, aren't as motivated to review them.

Trying to get someone to review your PR can feel like pulling teeth. It can take a lot of back and forth to finally getting your feature merged.

I tend to reserve my mornings for PR's. The idea is if done earlier in the day, the rest of the day could be for discussions, revisions, and anything else that comes up.

Do you make time specifically to review your teammates pull request?

Comments

[Jen]

Your team (developer and otherwise), and the product/users is why imo. You’re unblocking your team mates, allowing the feature (assuming you have some sort of CI/CD process) to get deployed sooner.

It’s also for you too! You may interact with this code down the line, so having sight of how it works is useful. You can also pick up any algorithms you might not have seen before.

If there is a lot of back and forth, there are a few things you can try to limit this. What are the common things you tend to go back on?

• Using a linter and/or a code style to automatically reformat code for you will cut down on comments like “use double quotes instead of single”.
• 3 amigos, which is an agile methodology. you tend to take (not limited to 3) a designer, developer(s) and a tester, spend 5-10 minutes before the ticket is started and talk about how it should be implemented
• consider, would it be faster for you to pair program if the other developer is struggling
• also consider, is the code bad? Or is it just different way of implementing a feature than you would? Is it worth requesting a change? Or can you just comment (not requiring a change)
• do the PRs need to be smaller? That (hopefully) means less code to review and less code to change

I look at PRs when I am done with the sub task/thought I was working on, so it’s not disrupting me. We as a team try to look at them ASAP for the reasons mentioned above. I enjoy looking at them, it’s a learning experience for both parties!

[codemattermedia]

What a great answer! I think keeping the users at the top of mind is a great suggestion. The experience engineers build ultimately is about the people using it.

You're spot on; giving reviews is a great exercise that will inevitably make you a better developer. Seeing other people's approaches could add to your repertoire.

Also, self-reviewing! Seeing your code diffs side by side can illuminate anything you didn't catch in your dev env.