Hello everyone, this is Dima Vdovin again. In my previous article on integrating Juns into a team, I briefly touched on pair programming as an effective teaching and learning practice. Now I would like to talk in more detail about the practice of pair programming in teams. I tried various variations of them on different projects, and today I would just like to share what I see in this as the advantages of this approach.
Pair programming
It seems to me that just to explain how pair programming works, we can take the example of rally racing. There is a driver (driver) and a navigator (navigator). The driver is focused directly on driving. The navigator controls where we are now going and tells the pilot about the upcoming turns and jumps.
The same is in pair programming.
The driver focuses on writing code, here and now. At this time, the navigator holds the whole picture in front of him, checks that the driver does not make mistakes, and says where and how to move on.
The only major difference from rally racing is that in pair programming, the driver and co-driver must periodically change places. The distribution of functions coincides almost completely.
It is the full inclusion of both participants in pair programming in the process that distinguishes this method from other methods of learning and control. On the one hand, we do not allow the driver to write the code completely independently and do not give the finished βproductβ to the conditional navigator's review. At the same time, the driver is focused not only on specific lines of code, but must see the area it creates in a wide perspective. The same applies to our navigator.
In addition to this classic pair programming scheme, several more effective approaches have been created over the years of the industry's existence. For example, the ping pong or backseat navigator approach is popular. Some people generally practice mixing different techniques. This is normal. The effectiveness of this or that method depends on the goals and the composition of the participants: who participates in the pair, what they want to achieve, how experienced both coders are. By the way, pair programming is quite applicable not only in a mentor-junior pair, which I talked about in the last article, but also in a pair of two experienced coders of about the same level.
Next, let's discuss the driver + navigator setup options a little more broadly, depending on the goals of pair programming.
Beginner training
Pair programming is great for teaching beginners and is most often used for just that. However, when using this method of training your jun, you must understand that you are sacrificing the speed of development of the immediate feature if the development takes place in a real piece of code. At the same time, the team seriously wins in the long term: pair programming with an experienced colleague seriously increases the speed of onboarding and learning a Jun.
But in the context of the "beginner training" case, June does not always appear. For example, pair programming can be used to onboard a conditional newly hired middle that needs to be quickly onboarded to a project. In this case, the speed does not drop so much, and the mentor can be a colleague comparable to a newcomer to the project in terms of skill level. Here we are already talking about the transfer of experience and knowledge not in programming, but namely knowledge about a specific project.
On the other hand, coding in a pair of two middle is a little more risky than a pair of June + Middle or June + Signor. The leader in a pair of two middle must approach the process with great responsibility, but if all conditions are met, the benefits for the whole team are quite tangible.
Sharing of knowledge and liquidation of the "Tower"
A common problem for many teams is the availability of irreplaceable specialists. This most often applies to either start-ups or small isolated groups of developers who quietly themselves saw some features or a separate project. An irreplaceable specialist is one who thoroughly and individually understands either a specific section of the code / project, or only he has a complete understanding of how it all works. The knowledge pool about the project of such a specialist is also called the "Tower of Knowledge".
An irreplaceable specialist or "Tower" is a dangerous bottleneck that must be avoided by any means. Because a banal sick leave during the integration of new features into the combat part of the project (or during the move, or at another serious stage) - and the team's work is paralyzed. Not to mention the dismissal of such developers.
To eliminate such a bottleneck, indispensable specialists should share their knowledge with other developers.
As it is already clear, pair programming is again great for sharing knowledge. Only in this case, we do not receive advanced training and onboarding for a beginner, but the transfer of knowledge about aspects of the project within the team itself. If you do a feature in a pair, then at least two people will already know about it, plus, in the process of writing, the background of one of the members of the pair will be tightened.
The liquidation of the "Tower of Knowledge" has one more advantage that is not obvious to many. In addition to decentralizing knowledge about specific features and areas of the project, we also reduce the burden on the developer, around whom this very βTowerβ was originally built. Indeed, more often than not, if the team has an irreplaceable specialist, he often has to work in a wear-and-tear mode, with overtime, seven days a week during releases, and in general, be available 24/7. All this constant pressure sooner or later leads to professional burnout or, at best, the desire to find a quieter job.
Using pair programming proactively is also a great way to avoid creating Towers of Knowledge out of the blue. The constant circulation of knowledge about features and different parts of the project within the team is a normal process, which, unfortunately, begins to be organized only at the moment of the dismissal of a key employee. True, pair programming is not the only way to deal with "Towers" and increase the level of understanding of the project within the team, but this is a completely different story.
Solving complex problems
Pair programming can be used like a local brainstorming tool, that is, literally applying the adage "one head is good, two is better." Pair programming is great for when you need to implement a complex feature or logic according to the business requirements of the project. Here we are no longer talking about the transfer of knowledge from the leader to the follower, but we are creating a system of two developers, equal in experience and understanding of the project, who combine their efforts.
Some developers may argue that they are more comfortable working on complex areas alone, but practice shows that two strong coders in a pair are more likely to produce high-quality code than working separately.
The strengths of pair programming in such situations is just outside the coding process. Rather, the gain is achieved through the ability to actively discuss on an equal footing possible ways to solve the problem - the process of writing code in such a case is secondary and is not a problem. But how and what exactly should be written is the problem. The possibility of direct communication, discussion and substantiated dispute between two specialists has a positive effect on the quality of decisions made. The time required to find a successful solution to our problem is also reduced.
Mixed tasks
The last case is a team of all the cases described above. Here we have two experienced developers with different areas of expertise, who are joining forces to work on one task. Perhaps one of them writes the code well, and the other is thoroughly familiar with the requirements of the project. Moreover, it is not necessary that these were two programmers. These can be pairs of coder and QA engineer or coder and analyst.
Here we get a pure win-win situation: in the case of mixed problems, each member of the pair complements the other. This way we squeeze the maximum out of the potential of both specialists, eliminate their weaknesses and use only their strengths.
At the same time, the solution of mixed problems covers all the previously described cases: onboarding, if we are talking about insufficient knowledge of the requirements of the project, and liquidation of the "Tower", and solving a complex case.
Total
It is important to understand that pair programming is not a silver bullet and the answer to any development problem and challenge. In almost all cases, this method leads to a decrease in development speed, so it is worth using this approach with caution.
Also, we must not forget about the human factor: if we are talking about teaching Jun, then the mentor in pair must be able to interact with the beginner at the proper level so that the learning process does not turn into beating and ridicule. If we are trying to liquidate the "Tower", then the composition of the pair must be matched accordingly so that the transfer of knowledge takes place in the right direction. The same applies to complex and mixed problems: you cannot put two random developers on one computer and wait, they will give you a ready-made solution in N hours.
But even with the difficulties voiced, pair programming is a great practice that not only solves the problem of onboarding and teaching newcomers, but also allows you to bridge the knowledge gaps in the project of other team members or effectively solve a complex problem.