Pair programming

This post belongs to this root post and may be out of context if it is read separately.

Pairing is a practice where two developers work together in the same computer. We can imagine it like a ride in a car: The driver manipulates the steering wheel and uses its driving skill, while her companion guides and supports her.

In the same way, during pairing, the driver uses the keyboard and writes the code, while the navigator guides her.

But as we all suffered our father/mother/touchy friend being our co-driver, I’d like to empathize that the navigator is never someone meant to supervise the driver, nor to dictate what she has to write. The navigator is someone that wants to reach the destination with the driver. Overall, pairing is a collaborative work. Understanding this is fundamental to enjoy the benefits of pairing.

An illustration of good pairing
An illustration of bad pairing








Such benefits vary depending on the composition of the couple:


  • Newbie – Veteran

Pairing is a great tool for learning, which can help us integrate new developers on a team. In the newbie – veteran couple, the newbie (a developer with low context of the project), uses the keyboard, and the navigator guides her, but avoiding to be intrusive: allowing the driver to explore, fail, and being proactive only when the driver gets stuck.

It works like when helping children doing their homework. If we don’t allow them to try and fail, or if we solve the exercises for them, then they won’t learn anything.

Similarly, if the newbie stays next to the veteran and just watches her working, she may find difficulties to follow the veteran’s rhythm. Also, if the veteran sits next to her and starts dictating the code, pairing won’t make any sense.

In the newbie – veteran case, learning flows in a unidirectional way, but very effectively.


  • Veteran – Veteran

When two developers with the same level and same context on the project pair, the benefit is much greater. The knowledge works like an infection. A developer spreads her knowledge to another one, then the latter spreads it to another one, and so on.

At the end, the knowledge will be owned by the team, instead of staying in someone’s head and leaving the team when this ‘guru’ leaves.

Also, take into account that each developer comes from different projects, different contexts, different wars. Therefore, when two experienced programmers pair, they complement each other. Each one brings her own point of view and tricks, and the strategy will be composed by the ones that worked for them before.

These are just two couple composition examples, of course, there exist others. You may be interested in reading this book.

Another benefit of pairing is that it makes our work much more fun, and helps us enjoy it.



Pairing redefines our concept of ‘teamwork’. Instead of maintaining two developers thinking and delivering separately, we get two developers that complement each other both in technical knowledge and in points of view, thus, will deliver better code in less time.


Go back to the root post to read about other Agile techniques.


Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑