Only when I started a new job earlier this year did I discover the concept of pair programming in an engineering team and since then I have become quite fond of it. I really like the interactions that it creates between team members and working together on a certain task. Having experienced a team where pair programming was not a thing and a team where it was, I can definitely say that there are a lot of benefits to pair programming and it can greatly contribute towards a team. In this article, I will go over what pair programming can do for your team and why your team should also adopt it.
Learning from each other
No two developers are alike. Every developer has their own way plan of approaching a task, works differently, does things in another way, has different nuggets of information, and so on. This means that there is always something to learn or pick up from another developer, also regardless of any difference in years of experience. It could be a simple coding trick, an optimization in the working process, a specific shortcut, a way of thinking, and a whole lot more.
Pair programming creates moments that allow knowledge sharing to happen. By putting these developers together, it makes them observe each other’s way of thinking and style of working. Doing so will provide us with the chance to learn something from one another that can make us better, more efficient, or more clever in what we normally do. In turn, this will elevate the skills of every developer as well as the quality of the team as a unit.
Two minds are better than one
In almost all scenarios will two developers come up with better ideas and solutions than an individual developer. If every member of an engineering team works separately, then every time everyone will create a proposal (Pull or Merge Request) for their work and receive input from other team members during the review process. But if you do pair programming inside a team, then the approach and feedback from one other team member are already mixed into yours. The result is a proposal that is already more refined and basically a mix of two developers’ approaches rather than just one.
This will first of all will make everything after the proposal, like the review process, more smoothly and create less back and forth between the proposer and the reviewer. On top of that, it will make developers more aware of their own way of working during the coding process. Since they will be exposed to the approaches of other team members, they will be made aware of certain parts that they under normal circumstances might not have paid too much attention to. As a result, pair programming will make team members polish each other’s way of working and elevate the quality of the work of both the individuals and team as a whole.
Levels out knowledge gaps
One of the biggest concerns for an engineering team is its truck factor. The truck factor of a team is the minimum number of members that have to suddenly disappear before projects have to stall because there’s too big of a lack of knowledge to continue with the project.
In smaller teams, it’s not too weird to have individual developers responsible for projects. Especially in those scenarios, without any intervention, the truck factor can become dangerously low and have significant business risks long term.
The main cause of a team’s truck factor is the presence of knowledge gaps between members. The more separated members work from one another, the lower the truck factor becomes. Pair programming helps a team in increasing their truck factor by putting more developers onto a task and increasing the horizontal sharing of crucial project-related knowledge. These two factors together will in turn level out knowledge gaps in a team and increase the truck factor to a safe level.
Pair programming is great for newcomers
Onboarding newcomers to an engineering team is by far not a trivial task. It’s a difficult process for all the parties involved, both the team as the newcomer. For the newcomer, there is so much to learn, to absorb, to prepare, to set up, and to find out, like how the team works, how the team approaches certain tasks, and so on. But for every aspect that the newcomer has to receive, the team has an equal responsibility of providing the newcomer with the appropriate resources in a proper way.
The most optimal solution would be to document literally everything about a team so that the newcomer can reach for that document at any moment and place. But in reality, this is an infeasible thing to accomplish. Creating such a document requires a tremendous amount of effort and time. Even if such a document is present, there’s a high chance that it’s incomplete or outdated. Keeping such a document up to date would also introduce another tremendous amount of required maintenance to the table.
So instead, most companies or teams will have created a generic onboarding that every newcomer will have to go through. But the issue is that every developer has a different way and pace at which they absorb certain information most efficiently. It’s impossible for the teams though to be considerate of every edge case beforehand. The ratio of the required effort and time to creating and maintaining such a one-size-fits-all solution against the frequency it will be used and the impact it will have is extremely disproportional.
A great addition to make it more personalized and better assist newcomers that I have experienced is to include pair programming sessions in the onboarding. Regardless of which role the newcomer has during such sessions, they will have the chance to process new information practically and make it their own.
If the newcomer is the driver, then they don’t have to worry about the overall process that they are not aware of yet. An existing team member will be the navigator and in this setup have the guiding role. They will make the general process decisions for the newcomer, walk them through why and how, adjust their course if necessary. So as a driver, the newcomer can focus on doing what they know (writing code), but also immediately get the chance to absorb the new information through hands-on experience.
The other way around, when the newcomer is the navigator, can also be very useful. Contrary to being a driver, the newcomer will have a more passive role as a navigator in which they will focus on observing the existing team member while performing their work. While the following applies to both roles, it’s more prominent in this scenario. Namely that the newcomer as the role of navigator has more influence over the pace of the pair programming sessions. By asking questions and pointing out topics that they couldn’t quite catch the first time, they gain a more active role in controlling the pace of the sessions. So as a navigator, the newcomer can be observant and control the speed at which they absorb information to what is most effective for them.
Keeping one another in check
There’s a high chance that every developer has experienced the scenario before where during a task they encountered a small issue that sparked their interest. They wanted to investigate it a little bit but ended up digging themselves into a rabbit hole on the internet to figure everything out about it. Truth is that working on your own can more easily cause this, which can lead to spending a significant amount of time on something that might not be worth it. This isn’t necessarily a bad thing and being curious is generally good as a developer, but it is an example of putting an incorrect amount of focus and priority on something.
Pair programming with someone can help avoid this issue by keeping each other in check. If one party notices that the other is getting sidetracked or too much attention is spent on a topic that seems trivial to them, then they can mention it. The other way is also true, namely if one party notices that the other party is treating a certain issue as trivial while they believe that it’s quite complicated.
When there are divided opinions in a pair programming sessions, they will have to be discussed because otherwise, both parties will have a different interpretation of the pace of the session. One will think it too fast-paced, while the other thinks it can go faster. This is unpleasant for everyone involved. This will lead to communication and both parties will have to discuss what the correct pace is, thus discussing whether the current issue at hand is worth the amount of time and effort that they are now putting into it. This way team members will keep each other in check and also result in issues being more properly analyzed and estimated.
Improves connections between team members
A more social reason to stimulate the activity of pair programming is that it improves the connection between team members. As mentioned in the other sections, pair programming is really something that happens between two developers. Communication is an essential part of this process. To make the most of pair programming sessions, all parties must be trying their best to get the most out of them for the sake of themselves. If this doesn’t happen, they should therefore communicate it to the other party. This can be done through asking questions, voicing their opinion on the pace of the session, mentioning an overlooked issue, not agreeing with a certain approach and a whole lot of other ways.
To continue smoothly with the sessions, the other party is required to address the feedback and come to an agreement on how to approach it. This could for example be done by means of coming to a conclusion through a two-sided discussion or agreeing on a middle ground solution that satisfies both parties. The only way this can happen is through proper communication. In these moments team members will have to learn how to interact and discuss with each other. Thus in the long term, pair programming will improve the communication and connections between team members.
In this article, I went over what the concept of pair programming can do for a team and provided reasons why I think every team should adopt it based on my experience. Knowledge sharing between team members is one of the greatest benefits of applying this concept, as they will be able to learn from each other and come up with more refined solutions together. It’s also a really great addition to personalizing the onboarding of newcomers more suitably while existing team members can use it to keep one another in check during the coding process. For the team as a whole, it means that long term knowledge gaps will become more levelled out, which in turn helps out with the team’s truck factor, and the connections inside the team will be improved.