What Is a Pull Request?
A Pull Request (PR) is a crucial step in software development. It ensures the code base is thoroughly reviewed and approved, confirming that it aligns with business requirements and coding practices.
Importance of PR
A mostly overlooked thing is that PR encourages collaboration and open communication between developers. This helps the developers and code base in many ways:
- Help level up developers by learning from experienced developers.
- Business knowledge is spread across more team members, reducing the bus factor.
- Company coding standards can be introduced or re-forced.
But often, PR can become a part of frustration/hostility for developers:
- Developers can feel they are getting attacked.
- Personal opinions can cause clashes.
- Comments can be misinterpreted.
- pressure from timelines.
Hostile PR and Impacts
When PRs are conducted in a supportive manner, they can significantly enhance future work and collaboration, making developers feel valued and part of a cohesive team.
- Developers will start thinking about what they must do to reduce frustration in PR reviews, not what is best to resolve the problem.
- Reduce cooperation among developers.
- Slow down growth and improvement of developers and codebase.
A significant problem is that a hostile PR can lead a developer to leave the company. The constant exposure to a hostile environment, mainly when PRs occur multiple times a week, can be a significant deterrent.
Hostile PR can also start impacting other parts of development interactions:
- Developers will not want to work with or be part of a project that they know other team members are known to be hostile in previews.
- Developers will not raise an idea/improvement since they think they are treated the same way in PRs.
- Will not raise questions or concerns in meetings.
How to Improve a PR
Comment standard
Many companies focus on coding and branch standards but don't take the time to develop PR / comment standards. These standards are crucial to coding standards since they can protect the health of your engineering department and reduce misinterpretation. Also, make it easier when you are a new team member.
I use https://www.conventionalcommits.org/en/v1.0.0/ or slight variation since it's straightforward and quick to learn.
I see other developers use emojis to help describe the comments.
It doesn't matter what approach you use. Just align to a standard.
Short and sweet
Keep your comments direct and to the point to reduce the chance of misinterpretation.
If you notice that you are writing long comments or many comments on PR, having a rubber ducky session with the developer and reviewing the PR together is worth it. It has many benefits:
- Help build stronger bonds between team members.
- You can better understand why the developer did something a certain way.
- It can be faster since it will reduce the back and forth on PR.
Coding standards
Having coding standards documented is essential for PR comments.
You can link to the standard that is not being followed.
Help reduce introducing personal preferences or opinions.
Coding standards need to be documented for all developers to reference. If not, how can they be a standard? How will a new developer know a standard vs. someone's preference?
The coding standard document should outline:
- Why does this standard exist
- What is trying to solve
- Example of the standard
Also, having coding standards helps remove some hostile comments from appearing:
- "I said this 1000 times ..."
- "This is not how we do it here."
- "Why are you doing this?"
- "I don't get why you are doing it like this. We do it like.."
- "As I stated before, I prefer .."
Remember that each developer is at a different level, and PR is one way to help someone grow and improve. Use that opportunity to help them out.
Top comments (3)
Great article! Congratulations 🎉
I really like the "have a runber ducky session" if you find yourself writing too many comments in a PR.
This definitely helps to mitigate so many stressful moments and it is the best way to align on a solution. Sometimes, the reviewer may not have the full picture of what's being addressed.
Rule #0: Just be nice, it's not that hard! 😉
Well said. PRs exist to help, not hinder.
Adding on the human side of things, let's consider the following PR comment:
"The way you implemented XYZ algorithm is wrong, consult this other code location for reference."
Using "you" may make the reviewee feel attacked. Instead, we could use a more passive approach:
"We should look into homogenizing the implementation here with the existing codebase, you can find it at this location for reference."
This is an overly simplified example, but applying a "we" mindset instead of "you" really puts an emphasis on the fact that PRs are meant to improve the codebase as a whole, not judge an individual developer's coding capacity.
Really appreciated how this article emphasizes the human side of PR reviews. The point about documented coding standards reducing personal preferences is spot-on.
One thing I'd add is that automating these standards through linters, formatters and automated workflows is a game-changer - it takes all those formatting and style discussions off the table, allowing reviewers to focus on what actually matters: architecture, business logic, and knowledge sharing. When standards are enforced by tooling, PR discussions naturally shift toward more meaningful topics.
Building on this, treating the coding standards doc you mentioned as a living document that evolves through PR discussions can be powerful. When a new standard emerges from a productive review discussion, it gets added to both the documentation and, where possible, to the automated checks. This way, PR conversations help build and refine team practices over time.