Elucidating problems in pairs

The best way of explaining why pair programming works is that two people can understand how to write some code better than just one programmer. It is true that when we code trivial parts of the system, pair programming is unnecessary – even counterproductive. So, it's important to choose when to pair program and when to solo program.

Here are a few situations where pair programming works great, and where the two heads are better than one rule applies:

• A junior programmer learning from a senior programmer.
• A new programmer in a team learns from an existing programmer in the team.
• Fresh tasks are assigned to the team, and two people can tackle the problem better and faster.
• A programmer learns new practice (that is, test-driven development, unit testing, and so on).

As a rule of thumb, it is a good idea to use pair programming when we have a task with higher complexity, either the technical or the business side. It's good to acknowledge that programmers are more likely to make mistakes in complex or unknown areas of code.

There are situations where we'll have simple, trivial tasks that don't necessarily need pairing, or even more, where pairing would be just a waste of time for at least one of the two. Often, it's a good idea to have this discussion with the whole team. After all, it should be the decision for the whole team on how they use their common time, what the learning or improvement focus is in the next period, and where they can't afford pairing because they need to deliver faster.

Should I pair? Before you start a new task, ask yourself the following questions:

• How would I benefit from using pair programming?
• How would the team/product benefit from using pair programming?
• Would we learn anything useful for the team by pairing?
• Would pair programming delay a delivery?
• Would pairing on this task be boring or superfluous?

These questions could help you and your team decide if it's worth investing in pair programming for that specific task. Yes, it is an investment, and you should treat every decision with objectivity and respect for the rest of the team. After all, two heads are better than one in some situations, though in other situations, where even one head wouldn't be used too much, using pair programming would just be a waste of time and energy.

Managing complexity

Following the idea that two heads are better than one, we can use pair programming to manage better complexity.

Let's face it: programmers almost never do the exact same task. It might be that the domain is similar, or identical, but there are so many moving parts in the whole ecosystem, such as programming language, frameworks, external or internal use libraries, programming patterns, architecture patterns, business domain variations, performance, security, scalability, and so on. A programmer needs to think about all these and more when writing code. That is why we can make a strong case when we say complexity is inherent in most programming tasks.

Having two people who look at all the aspects of the code is clearly beneficial. There is a driver who writes the code and a navigator who oversees the code, thinks about possible next steps, thinks about possible caveats, and improves the code while it is being written.

Humans only have one brain, and we can only focus our full attention on one thing. We can pivot our focus from one aspect to another, but that is tiring and during the switch, we might lose some details. That is why the driver focuses on writing the code while looking at low-level details such as code syntax, code logic, framework/library usage, or code formatting. And, at the same time, the navigator focuses on high-level details such as design aspects, architecture concerns, performance, security, and so on.

After all, what pair programming does is split the overall complexity into smaller, less complex parts that are easier to manage. These smaller parts are managed by two people, who use the clear responsibilities that are attributed to the driver and the navigator.

A good guideline is necessary for clarifying the driver and navigator roles before starting the pair programming session. Even if we have paired many times before, or if we are at the beginning of our first pair programming session, it's a good idea to clarify what each of the two pairs will do so that we can manage complexity better. We need to take into account the experience, knowledge, and skill level of both programmers before we start.

In this section, we discussed the history of pair programming and how pair programming can help you. It's a good option to solve complex problems we consider difficult and troublesome to solve on our own. You have now a few good guidelines about when to use pair programming or when it's better to solo program. Next, we'll discuss the various ways we can pair program, depending on our teams.