Empathy Pull Requests / MobileUp Blog

The Slack company believes that empathy is a superpower, and developers should have it turned on to the maximum.

The development of high-quality programs is highly dependent on how much quality code review is done by colleagues. This helps to detect errors, avoid duplicate work, and generally provide better code quality with less effort. Code review is a critical part of the development process.

A good code review culture is based on empathy for your fellow developers. What do we mean when we talk about empathy? Brené Brown , a Texas professor and psychology researcher, offers a suitable definition. In her opinion, empathy includes four components:

• to be able to see the world as others see it;
• Do not blame other people;
• understand the feelings of others;
• make it clear to others that you understand their feelings.

Empathy is a skill that can be developed. It must be practiced in order to master fully. Our goal is to be friendly, friendly and open. This is the style of work that Slack developers use. And it creates excellent soil for fruitful cooperation.

Empathy in practice - pull requests

So, how can we stimulate the manifestations of empathy and create a more fruitful environment? This is especially important when most of the work consists of writing a lot of code. What about review code and pull request? Undoubtedly, these are one of the main ways of interaction between fellow engineers.

It is very difficult to make a code review if the author of the code did not make it convenient for you to inspect its code. So try to do the same for your reviewers. Listed below are a few signs of a good pull request.

Good pull requests provide context for the task.

First and most important: good pull requests provide context for the reviewer. Usually when you create a pull request:

• You are happy with your work! You have fixed a bug or developed a new feature. Cool!
• All the code is already in your head: you know how everything worked from the beginning, and you understand that you changed it in the process.
• You are ready to start other tasks.

On the other hand:

• A colleague who checks your code did not participate in fixing the bug.
• He has no understanding of what exactly you were doing.
• He has no idea what problems you encountered while writing code.

In fact, your reviewer does not take into account the context of the task at all. Your pull request should provide it with this context. And there are several ways to do this:

• Give the pull request a suitable headline so that people understand what they have to check before they start.
• Give a detailed description to tell the reviewer how you arrived at that decision. What did you try, what didn't work out of this? Why is the chosen solution the right one?
• Be sure to give links to any other materials that may clarify the situation - a link to a ticket in the bug tracker or to the Slack archive can significantly help in describing the problem.
• Ask for the opinion of the reviewer. For example, if you are curious if you could avoid calling “fooBarFrobber”, ask about this explicitly - so you can direct the viewer's eyes to this place.
• Finally, you should explain to the reviewer of your code what is going on as a whole. What have you fixed? Are there any problems while fixing the bug? What else were the ways to fix it, and why did you decide to fix the error like that?

Not every pull request must have all of the above, but the more information you provide to the reviewer, the better he will be able to inspect your code for you. And if in the future someone finds a problem in this place and looks at your pull request, he will most likely understand why you made such changes and what you wanted to achieve with them.

Provide your reviewer with all the necessary context. This will increase its effectiveness and speed up understanding of your changes. This is very similar to how to give a book to a person disclosed on the same page where you yourself are now, while retelling its contents to this place.

A good pull request should be focused

Changes in each pull request must solve a single task. It is permissible to correct several minor errors in one pull request, but they must be connected. When your reviewer looks at the list of modified files, he should not be surprised.

It is also good practice to create small pull requests. Firstly, it is easier to notice an error in the code of a smaller volume, and secondly, this will help to avoid the fatigue and dispersion of attention of the reviewer when reading the code.

Good pull requests add confidence to the code

What is the main idea of ​​code review? It allows you to detect problem areas before they become problems. Therefore, when we ourselves are in the place of the inspectors, we must take responsibility for the problems in the code that we inspected.

Let's repeat, because it is really important: you must take responsibility for problems in the code that you approved . If the change goes into production and causes a bug, this is also your mistake. Therefore, check the code carefully to be sure of it.

If you want people to take responsibility for your code, do not waste your time and make extra efforts. A bug fix is ​​great, but adding a unit test to ensure that it will never play in the future is even better. Code refactoring is good, but it’s also important to supplement the documentation on modified methods to the current state. Be sure to cover all the details.

Conclusion

A good pull request is a manifestation of empathy for both the author and the reviewer.

If you are an author, adding detailed information about the problem to be solved in your pull request will not only improve the quality of the check, but also arouse the favor of the reviewer. Good pull requests that focus on one problem, are equipped with tests and comments, allow you to forget the context without fearing for this piece of code in the future. If you are a reviewer, well-formed pull requests will make your work more efficient and focus on code review rather than clarifying details in the context of the task. As a result, absolutely everyone wins from high-quality pull requests.