Management

Pair Programming: basic rules

Pair programming is one of the techniques in the extreme programming methodology. Today this technique has turned out to be especially relevant because of the development of microservices and related changes in communications between developers. The technique itself is that two, and sometimes more developers, simultaneously solve a common problem, using the same computer. Since the keyboard is one for two, one of the pair gets the role of the “driver” or leader. The second plays the role of a navigator, while determining the direction of work at a more abstract level and constantly monitors the code written by his colleague.

Of course, the roles are not permanent, the process participants take turns taking the lead: in time or as needed, depending on the specific task. There is a kind of pair programming known as ping-pong adapted for development through testing. But we are going to observe the classic version, when one writes, and the second tells where we will move on in this article.

When is it useful?

There is no situation when pair programming cannot be dispensed with. But we recommend using it when you, as a whole team, master an unknown subject area or the latest technology, the use of which the project requires. PP significantly accelerates the exchange of knowledge and allows a team member who knows at least a little more than others to communicate this information to everyone at once, rather than talking to everyone individually.

The second ideal user case for PP is when you write something critically important. This technique allows you to not send a code for a review of 20 times to different people, accompanying each sending with a letter with difficult questions. Writing code together and then testing it together is an effective approach for systems with high significance.

It is proved that parallel programming significantly improves the quality of the code. Although the success of using the technique will, in the first place, depend on specific people and their experience in its use. The quality of the code is increasing primarily because we get not just more code analysis, but we get it at much earlier stages.

When it’s better to avoid PP

PP is a complex communicative exercise; it does not work well where people are too accustomed to hierarchy. The peculiarity of human communication is that if one of the couples takes on the role of senior, the second, if he is not prone to conflict, automatically assumes the role of junior, regardless of experience and level of training. From the project, this is counterproductive, but to avoid this, all groups at first will have to be closely monitored, maintaining equality.

Rules for effective communication

3 simple rules to make your work easier:

  1. Do not be afraid to speak out loud.

  2. Be polite and friendly.

  3. Do not fall into an instructive tone.

We recommend a very simple trick. If you see that a person sitting next to you is doing something wrong, then count to 5, and then to 10. If you think that he is persisting in his error, you need to say. Instant reaction to a mistake can bring down the mood of a partner.

If something important is lost, return to normal communication as soon as possible. For example, you can quickly discuss the issue that has arisen, and continue talking about feedback: find out in what form your interlocutor would like to receive feedback. This topic goes beyond pair programming, but it is very important in any team and setting. It is most productive to accept any feedback as a gift, although this will have to be studied. It is important to remember that anyone who decides to criticize is at risk for your joint work. He takes the risk of conflict, which no one loves, and deserves gratitude.

Another difficult skill is to abandon unnecessary assumptions. When we talk with other people, we often make a communication mistake: we think that we know what they intend to do or say. Such speculation often overshadows the obvious facts, which just serve as the starting point for a constructive conversation. Suppose if you were interrupted, it is hardly worth saying to your partner: “Of course, you consider yourself the smartest!” It is much more useful to note: “I was going to correct this line in two seconds. You noticed an important mistake, but do you agree that you interrupted me? ” Some facts: a fair remark was made, but you yourself were going to correct the mistake. Then you can decide how to avoid such situations in the future, if they annoy you.