A guide to Pull Requests

Thanks for the shout! Nice article. Happy to see more code review content out there in the world.

I liked how thorough your approach is — making sure to run the tests and linters, and also double checking diffs before opening the pull request.

I also like how as a reviewer, you focus on the code itself, and not the person. This is key for building relationships with empathy.

You also touched on the soft skills of humility, open-mindedness amd willingness to share knowledge. These will be key for growth in code review, as well as other aspects of your software engineer career.

A few pieces of feedback:

• Take a look at Slack/GitHub integration. It'll automatically post in a Slack channel when a PR is opened.
• Looks like all review comment examples are questions. Questions are OK when the deadline is far away, but remember that they also introduce back-and-forth — this adds cycles and blocks the PR. Know when to use a question, and when to make a direct suggestion.
• The problem with pair reviews is that the reviewer has a person explaining the code, as they reviewing it. This is not a realistic situation. In reality, a developer will be reading the codebase on their own, as they're adding features. They need to be able to understand it on their own, and if they can't, it needs adjustment. Individual, async reviews realistically simulate this.
• If PRs are forgotten or ignored, there's a problem with the team's code review process that needs adjustment.

Overall, awesome article! Thanks for sharing your thoughts, and for the shoutout! Good to be connected with you here on Hashnode.