This is the third part of a small series of posts talking about the fundamentals of Pair Programming. I have already written about what is Pair Programming and how we can find the best context to apply it. Today I will be writing about the tips one can follow to be able to pair efficiently.

Pair Programming is a pattern to solve problems in a better way, it's not doing somebody else’s job, it’s doing the job. Together. When you tell the other what to do you are trying to solve the problem alone. Even if you believe to know the "correct answer", never tell the partner what to do, instead, ask if it makes sense propose an experiment to test something that you have in your mind. There is a risk that the "correct answer" might turn out to be not so correct in that specific context, therefore it's worth keeping an open mind and never jump to conclusions early to avoid unnecessary conflicts.

Never tell the partner what to do, ask if it makes sense first

Before doing anything everyone should agree and state clearly what is doing next and why. This will expose discrepancies and conflicts that would have to be handled anyway, the difference is that doing it early drastically reduces the costs resulted of doing it later.

Before doing anything state clearly what will be done next and make sure both agree on that

Synchronization is an important aspect of pairing. Never lose the sync. If any of the pairs is feeling that the other is doing something that they don’t understand, they should go back and explain again, as many times as necessary. If anyone pretends to understand what is happening, Pair Programming will have no effect at all. It is the responsibility of the one that notices the loss of sync to point it out and suggest a step back to recover.

If losing sync, take it back ASAP

The constant focus on a single task is very important, parallelization of subtasks is not Pair Programming. If the pair shares the input (mouse and keyboard) they will create an implicit dependency on each other in a way that it will be necessary a synchronized movement of both for an action to succeed. This will help to ensure that both are in sync and agree on what needs to be done next, without splitting tasks.

Share the mouse and keyboard to make sure both are in sync and agree on what needs to be done next

Pair Programming has an initial time cost because it leverages the effort of two individuals to maximize the overall return. Such cost should be spent consciously. It is very useful to timebox the pairing session within a reasonable timeframe so that both can be aware if the pairing is being efficient or not given the amount of time spent on each subtask.

It's easier for useless discussions and bikeshedding take longer, therefore it's necessary to be mature and keep track of the time that both want to dedicate to that session. If time is up, analyze again if there’s value in keep going given the perceived benefits so far.

Timebox the session to be conscious about unnecessary discussions and the time cost

Sharing knowledge is one of the greatest benefits of Pair Programming. When pairing in a team, try to pair with individuals holding more or less business or domain knowledge in that specific task. Nothing prevents someone from pairing with the same level of skill, but rarely a team will have all individuals with the same level of skill in all types of tasks, there's always room for learning, and Pair Programming is the best and fastest approach for increasing the ramp up of the team members.

When two individuals with different levels of skills are pairing, everybody wins. The one teaching will have a higher retention of information by being forced to discuss the answer in details, and the one listening will learn better because they will be forced to elaborate the right questions.

Prefer pairing with individuals holding different levels of skill in a specific task

Just because the name is "Pair Programming" that doesn't mean that pairing is restricted only to programmers. The fundamental benefits of pairing make it possible for multiple roles — including Business Analysts, Quality Assurance, Project Owners and Designers — to pair with each other and the developers. It is very important for a developer to start pairing with different roles to understand and learn with their point of view and be able to come up with better ideas to tackle the problems.

Encourage all roles on the team to pair between themselves and the developers

Another important requirement to receive a good answer and increase personal growth is asking the right question. In Pair Programming we should try to ask the right question as much as possible, this allows the pair to close gaps of knowledge and understand each other clearly.

Nobody should have doubts and uncertainty on the definition of something alone, be it technical or non-technical. If there are uncertainties and someone from the pair didn't know it, then something is wrong. All members of the pair should be aware of gaps, together.

Asking the right question is much more valuable than believing to have the right answer

Last, but not least, the most important requirement for being able to do Pair Programming is to kill your ego. As a member of a team with a common objective, nobody should try to be better, everyone should try to help themselves in order to achieve the common objective. Having an ego, consciously or unconsciously, will destroy any chances of leveraging any of the benefits of Pair Programming in a team.

Kill your ego

Many teams fail to apply Pair Programming. It's hard to tell what is done wrong because it's impossible to measure it. One thing that is easy to measure, albeit anecdotally, is the day-to-day of a team that knows how to communicate efficiently with each other. Teams on that level of maturity are naturally prone to apply Pair Programming efficiently and can even discover Pair Programming by themselves naturally.

The point is that the power of Pair Programming doesn't lie just on the mechanics of how it is applied, it lies in the mindset of the ones who apply it.

Pair Programming is not just about the mechanics of how it is applied, it is about the mindset of who applies it

Pair Programming works but is not a silver bullet. Do not treat it simply as a buzzword but as a set of attributes for your belt of utilities, worth experimenting under certain circumstances. It might fail or succeed in the current state of your team, but not trying is the same as failing by default.

As Wayne Gretzky, a Canadian former professional ice hockey player, liked to say:

You miss 100% of the shots you don’t take.

Enough showing how to do it correctly. If you want to know how to do Pair Programming the wrong way, see How to do Pair Programming The Wrong Way.