Empowered pull requests

Slack believes that empathy is a superpower, and for developers it should be turned on to the maximum.

The development of high-quality programs depends heavily on how good a review of the code is done by colleagues. This helps detect errors, avoid duplicate work and generally ensure better code quality with less effort. Revision code is a critical part of the development process.

A good culture code review is based on empathy towards 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 condemn 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 needs to be practiced to fully master. Our goal is to be friendly, friendly and open. This is the style of work that is used in the developers of the company Slack. And it creates excellent ground for fruitful cooperation.

Empathy in practice - pull requests

So, how can we stimulate empathy and create a more fruitful environment? This is especially important when most of the work consists of writing a large amount of code. What about review code and pull requests? Undoubtedly, this is one of the main ways of interaction between colleagues and engineers.

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

Good pull requests provide a task context.

The first and most important: good pull requests provide context for the verifier code. Usually when you create a pull request:

• You are satisfied with your work! You fixed a bug or developed a new feature. Cool!
• All the code is already present in your head: you know how everything worked initially, and you understand what you changed in the process.
• You are ready to begin other tasks.

On the other hand:

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

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

• Give the pull request a suitable heading so that people understand what they have to check before they start.
• Give a detailed description to tell the reviewer how you came to such a decision. What did you try, what did not work out of it? Why is the chosen solution the right one?
• Be sure to give links to any other materials that can clarify the situation - a link to a ticket in the bug tracker or to a Slack archive can help a lot in describing the problem.
• Ask for the opinion of the reviewer. For example, if you are curious whether it was possible to avoid a call to “fooBarFrobber”, ask about it explicitly - this way you can direct the viewer's eye to this place.
• Finally, you should explain to the verifier of your code what is happening in general. What have you fixed? Are there any problems with fixing the bug? What other ways were there to fix it, and why did you decide to correct the error in this way?

Not every pull-request should have all of the above, but the more information you provide to the verifier, the better he can inspect your code for you. And if in the future someone finds a problem in this place and views your pull-request, he will most likely understand why you made these changes and what you wanted to achieve with them.

Give your reviewer all the necessary context. This will increase its effectiveness and speed up understanding of your changes. This is very similar to how to give the book to a person, opened on the same page where you are now, while retelling its content to this point.

A good pull request must 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 related. When your reviewer will look through the list of changed files, he should not be surprised.

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

Good pull requests add confidence to code

What is the main idea to conduct a 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 have inspected.

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

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

Conclusion

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

If you are the 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, which are focused on one problem, are equipped with tests and comments, let you forget the context without fear for this piece of code in the future. If you are a reviewer, well-formed pull requests will make your work more efficient, and will focus on the review of the code, rather than clarifying the details in the context of the task. As a result, absolutely everyone benefits from quality pull requests.