Pull Request Psychology

Introduction

Pull Request is a process that allows multiple people in a team to review peers source code by commenting, providing suggestions, pointing out potential bugs, and checking code styles.

The output is a better source code being merged into the main branch and ensuring that everyone is somewhat familiar with the code introduced.

Human beings involved

Code is written by men and women alike, and while they work on it, they might be going through some purple as well as rough patches. This is something to keep in mind when reviewing someone else’s code. We don’t always know the challenges that others are facing outside the workplace so having a little empathy won’t hurt anyone, especially since tomorrow we might be the ones needing that same empathy.

The easiest way to show empathy is to assume that person did the best they could do at that point in time. It might not meet your standard… it’s then an opportunity for you to help this person grow and reach higher standards. Teaching can be very rewarding so it could be worth giving it a try.

Team Work

By reviewing Pull Requests every day, I realised how this task is actually a great opportunity to strengthen the collaboration among developers in a team.

Collaboration starts when the developer opens the PR, selects his team mates for review, and asks them for help. Not only on the GitHub or Bitbucket web interface, but often on IRL as well, I’m sure you also ask the question: “Can you please review my PR?”.

Having to ask for help, and depending on others to get your work approved, validated and completed, can make the developer opening the PR feel in a weak position. As a consequence the team balance can be compromised.

This can be demonstrated by something you might have said yourself: “I will review your PR if you review mine”. This shows how reviewing a PR is a favour done to someone else. The good thing here is that when pull requests reviews are managed this way, the balance I mentioned earlier is restored (at least between the two individuals) since each developer is making a favour to the other.

My first suggestion to create a safe environment in your team is exactly this one: to introduce PR Sessions where everyone reviews each other’s code, which helps keeping a good balance in the team. With time, people might just do it naturally as they gain confidence in the support of the entire team.

Avoiding the Ego War

Now that we’ve got everyone on the same page, let’s see how we can make sure the review itself doesn't fall into an Ego War.

When a developer opens a PR, they might have spent a few hours, even days writing that code. And when they open the PR, they are putting themselves at risk, they are submitting their work for review, and, in a sense, for judgement.

Being pragmatic, concise and polite, will often avoid misunderstandings and wars. This can be achieve in various ways.

The truth is elsewhere 👨👱‍♀️👽
Referring to existing code, official documentation, or best practice guide, will help the developer to understand why a bit of code should be changed. The idea is to introduce a third party in the conversation, so it’s not about each individual opinion but about what has been decided collectively, by the team or the community.

Dealing with complexity 🍝
Code can be complex and hard to understand straight away. This can put the Reviewer in a situation where they give up on that part. Here it is important to ask questions, maybe ask for commenting a code section, if you don’t understand it straight away. In fact, clarity benefits everybody as another teammate might not get it either. It’s ok to ask for clarification and maybe have a quick chat about a piece of code. Always ask a question first, rather than judging the implementation and loosing yourself in writing an essay.

Introduce a fun and relaxed mood 🧘‍♀️🧘
The use of emojis and smileys can help in keeping the conversation light and respectful. Using keywords such as please, as well as should and may, will often result in a nicer and more enthusiastic environment.

Not the place for arguing 🤬
If you find yourself writting a long comment, supporting your point of view, you might have entered into the red zone. If the message is too long, its nature is going to fade. It might be clever to have a chat with the team, again introducing a third-party will help to come to an agreement.

It is also about what is well done 👍
If you feel like a part of code has been particularly well written, say it! Add a thumb up, a heart, a smiley. Anything that can encourage, support and motivate the developer is welcome. On top of that, this will highlight sections of the code to other reviewers, leading to acknowledge the best practices.

TL;DR

Consider others as human beings doing their best at this point in time.

Have PR sessions to avoid the doing a favour feeling.

Rely on a third party to support your point. Use emoji and polite words. Don’t try to be right, just chat with the team. Highlight good sections being positive, supportive.

Conclusion

I’ve have been applying all these tips in the last few years with a relative good outcome. The team I’m currently leading is very healthy and I believe it is thanks to this process, at least in part. Should you have any suggestion and/or be willing to share your experience, please use the comment section below.