Sharpening our knowledge

There are several contexts that need to be accounted for when you're using pair programming for learning; that is, collaboration, alignment, and improvement. Let's learn how to pair program in a different way, depending on the team's current level and knowledge uniformity.

Collaborative work

The idea of collective code ownership existed in programmers' lives even before the existence of pair programming. This means that all the code that we write as individuals is our code, and anyone can change it as per their needs. We don't have codebase areas that are owned by their authors. We don't need the author's permission to change anything. However, we do need to obey some rules that can be summed into two areas: improve the code and don't introduce defects.

Pair programming cannot work without you having collective code ownership. There are two immediate effects that occur when you're implementing collective code ownership: it's difficult to know the other author's code, and you remove some bottlenecks as there is no need to wait for someone to do their task.

The most effective way to know a particular author's code is to program with the author. Due to this, pair-programming opens the door to spreading knowledge within the team. There are multiple ways of spreading knowledge in the team, depending on our focus in the short-, medium-, and long-term future. We can focus on people and then decide if we want to improve their skills. Similarly, we can focus on the product/system and then decide if we want to improve the team's knowledge about it. In fact, we should do both, but take the timing into account. Maybe there are moments when it's more appropriate to learn new skills, as we may have good knowledge about the system, or vice versa. If a completely new feature arrives, with its own different and difficult domain logic, it's obvious that we should focus on that, and it's not a good moment to learn new skills.

After all, a team should be more than the sum of its parts; that's when you will see collaborative work. Any team member should be able to help another, and any team member should be open to new skills, practices, tools, and system or domain knowledge, as long as it evolves the overall delivery capacity.

Collaborative work means that we understand and act under the underlying principle that the team needs to work well together, to have continuous improvement. Pair programming is a manifestation of collaborative work, a tool of fair collaboration that fosters productivity and enjoyment for good quality products.

Leveling knowledge

A team needs to have the same minimal level of knowledge on essential topics, be it related to business as well as technical. What better way to level knowledge than two people who have different levels of knowledge to work together?

Of course, this whole process is not necessarily easy, especially if you were used to working alone. It might feel intrusive, cumbersome, frustrating, or even annoying. That is why I wouldn't recommend anyone starting to level knowledge with pair programming without some sort of management or outside coaching.

Using pair programming to level knowledge is a great approach, which comes with a few short-term disadvantages, along with a few long-term ones. First, in the short term, you will see the team being more tired, often with more stress and them delivering below par. Nevertheless, during the next few pair programming sessions, you will feel less and less tired and you will get used to this way of working. In the long term, we have the benefits of real collective code ownership, where anyone can change the code in any part of the system, without the fear of introducing defects.

When we start to level the knowledge, we need to explain the process really well to the team; that is, we need to explain why we are doing this, how it will be done, how long we expect it to last, and what the possible short-term and long-term effects may be. After that, a good practice is to start collecting some tasks that are appropriate for pair programming with the purpose to level knowledge. We don't aim to do full-time pair programming, because it will be extremely difficult for everyone to cope. Rather, in the beginning, it is preferable to do 1-2 hours per day of pair programing. A good practice is to have the first few days be completed under the supervision of a technical coach, with all the pairs in a room and the coach observing and giving advice on how to pair program in an effective way. After that, the technical coach can remain as an adviser, as many questions remain on how to effectively work as a pair.

Advancing knowledge

Once the team has a similar minimal level of knowledge about the business and technical side, the next step is to think about improvements. Often, while leveling knowledge through pair programming, every team member starts having ideas about how things could go better. So, don't miss the opportunity and note down every idea that appears. Often, taking notes about what you would like to learn next is a good approach so that when the time comes to pair program with the focus on advancing knowledge, you have a clear idea of what to do next.

During sessions of advancing knowledge, you can involve a technical coach as well, to make sure that the focus remains on that specific learning activity. A technical coach would make sure there is a prioritized learning backlog for each of the team members, and that they have the time and space to learn.

Let's take an example of a programmer who knows Java and would like to learn JavaScript to help their team's endeavor to implement their next feature, which is user interface-intensive. For that, an experienced JavaScript programmer would pair with a Java programmer. They would take an appropriate task that was in line for JavaScript and work on it together. Of course, the time to finish that task will be significantly higher when the two programmers work together in the beginning, because learning is involved. But after 2-3 weeks of daily pair programming sessions, usually, the time taken to complete such a task is reduced. Now, the Java programmer can take on easy JavaScript tasks on their own, helping the team deliver faster.

Using pair programming to advance knowledge is a very good practice to help the team solve long-waiting lines at specific specialties. In our example, what would have happened if all the Java programmers had to wait their turn until the only JavaScript programmer reached their request from the long list of tasks they needed to perform? We want to avoid that as much as possible. And the solution is not to give all the difficult tasks at the back to the most experienced programmer – we should do the opposite if we want to improve our productivity in the long term. We want to spread the knowledge that is needed in the near future inside the team. In practice, this means that the most experienced people would teach volunteers how to perform simple tasks, thus relieving them of the trivial tasks and letting them focus on the intricate ones. This attitude can bring a huge difference to the overall timeline and success of your software product.

The idea of improving your knowledge through practice is very old. It comes from the medieval times of manual crafts. We can learn from those times and take what can be applied today. Learning while working with someone is very powerful as it brings more positive aspects to the table: observing, working with expert supervision, discussing aspects of the craft, and thus understanding how to do the work better. Now, we will move on and discuss how we can improve our current knowledge base when we pair program.