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?
Top comments (2)
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?
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!
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.