Three modes for an enhanced pair programming experience

You may have heard about pair programming and have a rough idea of what it is about. If not, “No problem” – we are going to look into it in this post and there is another nice blog post written in German regarding best practices of pairing.

One aspect of pair programming is that two people sit in front of one computer and work. This is what pair programming looks like from the outside, but there is more to it than just that. While two people sit in front of one computer, only one person is able to operate it; without any bad intentions, it is possible that this person is showing the other one “How things are done”, while the other person is passively observing. The observer’s mind may wander somewhere else or she/he may start checking emails and social media instead of working on the task. This observed pattern is called watch the master and should be avoided since only one person is actively engaged. It is very unfortunate if only one person is engaged and the other one feels they cannot contribute.

You may have started out on the wrong foot with pair programming or you want to try it (again?).

Let’s start over with a quick recap of what it is. Pair programming has a few formalities you should take into account before starting. There are two roles: the driver and the navigator. While the driver has the keyboard and types in what is currently needed to be done, the navigator helps in looking ahead for how that code will fit into the codebase. There may be things to restructure, refactor or reimplement so that the work item fits into the project better. Both people focus on their roles and should communicate all the time about what is happening or about what will need to be done. Communication is the key in pair programming.

Now that we aware of the roles and their responsibilities, when do we switch? You can switch whenever you feel like, this needs to be decided together. Let’s look at three modes of pair programming that can help you switch and work more collaboratively while focusing on the task at hand and less on the mechanics of pair programming.

Mode 1: Ping Pong

The Ping Pong Mode is a way for both of you to switch the keyboard regularly. It goes like this: The starter is writing a failing test and hands over the keyboard. Then the other one implements what is needed so that the test no longer fails and then writes a new failing test and hands over the keyboard to the person who started. In that way the keyboard is hopping from one person to the other like a ball in a game of ping pong. While the tests are not failing, you are able to refactor the code both of you have written. This continuously improves your code and mitigates your codebase from deteriorating.

This mode fits nicely into the workflow of TDD.

While Ping Pong is focused on switching the keyboard task wise, you can also try out to switching by using time boxes.

Mode 2: Pomodoro

Mode 3: Let's discuss!

The next approach is not focused on task or a time-based switching of roles as the other two modes presented. It is heavily influenced by mob programming, first you discuss what you want to do, and if you come to a conclusion, you do it. No code should be written that has not been discussed and decided on by both members of the pair. This style creates room for discussion, assists in making compromises and can create a better shared understanding of the task and codebase you are both working on together.

It's time to experiment and reflect!

Take your time experimenting and try to find what works best for you and your pair member. To enhance the learning experience, reflect on each session. Tell what was good and what could be improved, write action items down and take them into account for the next session. This alone can already improve your current mode of pair programming.

Experiment on modes, mix and match modes, and try out new things to find what matches the needs of both members of the pair.