Pair programming in Vineti

Almost a year has passed since I moved to live and work in Yerevan from Moscow. In this story, I’ll tell you not about my life in this wonderful city (it’s very cool here), but about more mundane things. Namely, about the practices that we apply when developing our product at Vineti.



If you are still interested, then welcome to cat.



At Vineti, we use extreme programming methodology and actively use pair programming. When I came to Vineti extreme programming was something new and unknown to me, but after a year of development in this style I can say that now single-coding for me has become something not too convenient and productive.



When there is a person next to you who carefully watches what you write, the code is extremely readable. Also, in the process of writing the code, training and knowledge transfer between the process participants takes place, and this, in my opinion, takes place in the most effective form.



It happens that those who have not used this approach before in practice experience embarrassment and discomfort, because you have to constantly communicate with your partner and write code under close supervision, but over time it passes, and you understand that the partner is here, to help you, not hurt you.

Benefits of approach

The advantages of pair programming in comparison with the standard approach are several, but, from my point of view, the most important is the constant transfer of knowledge about the application code between the participants in the process. You can build pairs and rotations (change of participating engineers) so that each engineer has complete knowledge about all parts of the application. This is especially important if you need to maintain a large code base.



The next advantage is a fairly effective learning process. You can pair in such a way that the more experienced are always paired with the less experienced engineers. For the senior developer, the rule is “if you want to know something well, try to teach it to another.” There is also the opportunity to tighten up your communication skills, as you will have to explain a lot and often.



At Vineti, we use TDD in the process of pair programming, which allows us to initially break down a large and complex task into small parts and think through a solution architecture even before the code is written. Also, in solving complex problems, having a partner with whom you can discuss the chosen approach to solving the problem and analyze its optimality right in the process of work without the need to plan additional meetings within the team helps a lot.



And finally, pair programming works well with the TDD methodology. In Vineti, usually one engineer writes tests and tries to describe as many situations as possible. The second engineer writes the feature code, when the first engineer tells how to simplify the code, thereby implementing a red-green-refactoring circle.

disadvantages

The disadvantages of this approach, I would probably attribute the complexity of setting up the process itself and the need for proper selection of participants in pairs, which requires additional efforts from the team leader and a thorough understanding of the skills and habits of all members of his team.

If we talk about the human factor, it is important that the engineers who are currently paired for the period of joint work have a common mode of coming to the office, lunch, etc. This is not always easy to do and it is necessary to form pairs taking into account this feature.

Maintaining a common standard

One of the conditions for effective pair programming is the presence of a strictly and most standardized approach to writing code within commands. For example, we use eslint, prettier, rubocop so that the code is in the same style in the process of writing it. As a development environment we use VS Code, and the terminal iTerm c zsh. This standardization allows you to quickly rotate engineers within pairs while minimizing the adaptation period.



In my opinion, couples need to be rotated after completing one task. This provides the lowest possible effective rotation. A change of role can occur in a day, but this remains at the discretion of a more experienced engineer in a pair. It is important not to get carried away, not to try to solve all the problems yourself, as the absence of a change of role can negatively affect the effectiveness of the couple as a whole.

Pair programming with San Francisco

Personally, I had the experience of remote pair programming with a colleague from the Vineti American office, for this we used the Live Share plugin for VS Code. The experience is interesting, but this situation has several disadvantages compared to standard pair programming. The first is the lack of direct personal communication. In my case, this is also a big difference in time zones. I had to write code after almost a full day, which, for me personally, was very tiring.

How to adapt to pair programming

Try to use the experience of other companies and eventually develop your approach within the company. Unfortunately, the ideal option for a convenient and working one for everyone does not exist.



I'm also not sure that this methodology is suitable for all companies. For example, if you have only 3 developers in a team, you obviously will not be able to get much benefit from the implementation of pair programming. Or, if you have too much overweight in the team, it will be very difficult for you to build good pairs.