How To Find The Best Context For Pair Programming 🔊

Last time I wrote about the general definition of Pair Programming. I investigated the origins of the term and how it only works if done right. To do it right also means to apply it in the proper context.

However, it's impossible to generalize what is the "proper context" and what it means "to do it right." It depends on too many variables. It's the team's responsibility to judge whether the practice makes sense or not for a given task. However, if you understand the differences between Pair Programming and traditional programming, you'll be more capable of looking at the tradeoffs and make your own decision.

That's what this post is all about.

Each team has the responsibility to judge whether Pair Programming makes sense or not given the task at hand and the circumstances

When you work in a task alone and gets blocked by something that somebody else can help you with, you probably tend to communicate asynchronously either by text or audio/video. Asynchronicity is good because it has a lower impact on context switching. However, waiting for someone to answer questions takes more time than a chat in person.

Asynchronous conversations can encourage you to have unconscious procrastination. Before you can resume the task you're blocked, you'll have to wait for the other person to be available.

While context switch doesn't impact simple individual tasks, it does affect the person that helps you. They don't have all the context for the job you're working. You need to explain everything all over again. It also has the potential to make the person that is helping you to lose the context of something else they're doing.

Interruptions take people out of the “zone.” According to some studies, a programmer may take up to 10–15 minutes to start editing code after resuming work from an interruption.

You can argue that when you wait for somebody else to respond, you can start another task in parallel. Unfortunately, focus on multiple concerns damage productivity. The reason is you split your attention and efforts instead of focusing all of them on a single thing.

Asynchronicity can create lower or more significant friction depending on the circumstances

When one works in a task alone, they will be able to elaborate the question better before asking it. That creates the opportunity to dig deeper and research the subject of the matter thoroughly. However, depending on how the issue is structured and the research is done, the resulted conversation can contain too many assumptions and cause the wrong impression that the one who requests for help have more experience than they do, that can increase the Impostor Syndrome level of the other.

Communication by text has another kind of issue. When reading a direct response, it's impossible to know the expression and body language of the person providing that response. The lack of expression shifts the responsibility of interpretation to the reader, which might interpret the message as an aggressive statement depending on the reader's state. The aggressive assumptions can be mitigated if both know each other very well, but that's not always the case if it happens in a big software project.

Text communication relies on the subjective interpretation of the reader who might see a statement as aggressive due to the lack of body language

If you work on a difficult task, it's natural to push to try to solve it as much as possible before you bother someone else unnecessarily, only asking for help when a blocker already consumed a lot of your time. In this case, once you end up asking for help, the time struggling will have been mostly wasted. If you had worked together with the other person on the same task simultaneously, you would never have lost that time.

There's an effect on time-consuming blockers that can make you stuck in a task forever. The time cost of a blocker cannot be recovered anymore and can drive you to keep struggling even if there is no clear sign the blocker will go away anytime soon. That is a cognitive effect called the Sunk cost, which also happens in economic and business decision making. The Sunk cost occurs when you consider what you have already paid in the past for a future decision. In this case, the Sunk cost is the time spent on a task and the unconscious belief that if you spend a little more time, you might complete the work because you have paid so much already.

You can't recover the Sunk cost invested in a blocker, and that can drive you to persist on the blocker because of the time already spent on it

Pair Programming helps to distribute knowledge quickly with no friction, which speeds up the ramp-up of the team members. This kind of benefit is enormous because it reduces the cost of change in the future. It also helps to spot problems early and to minimize the Truck Factor of the project.

When a single person tries to solve a complicated task, he or she might be guided by feelings or biases that are hard to be identified by themselves. However, when two independent people are trying to solve the same task together, even if one of them is angry, being guided by personal experience, feelings, personal issues or biases, there is a high chance at least one of them is not.

The chances for human problems to impact the decisions when programming in pairs is low. Also, if you detect and handle a problem early, it has a lower cost. However, if you discover a problem later, it can sometimes not be treated appropriately and cause more damage.

One of the fundamental benefits of Pair Programming is to spot problems early to reduce the cost to fix it

Another good thing about Pair Programming is being able to infer a mindset more efficiently. It is tough to make sure someone is applying TDD, Fail-Fast or have the Growth Mindset without pairing together, preferably (but not required to be) in person.

Mindset is a human characteristic. The code is just an inevitable side-effect

There are many fundamental differences between doing Pair Programming and asking someone to help. They look similar, but they are not the same.

Human communication is essential to find problems early in the development process and prevent unnecessary costs in the future.

If you understand the context, that's good. However, it may not be enough. You also need to understand the execution.

If you want to know more, see also how The Power Of Pair Programming Lies On The Execution.

If you liked this, you might like readplace.com, built for exactly this kind of reading.

Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or Github.