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
Pomodoro is a time-box technique for tracking the time spent solely focused on one work item. You can use it as a Mode for pair programming. The base line of Pomodoro is: set a timer to 25 minutes and start working on the task you want to work on. While the timer is running, you are not allowed to work or do anything else, than the task you have committed yourself to work on for this time box. Where is the switching in this mode? You can choose to switch after each iteration. Each iteration has a following 5-minute break. This can give you enough time to switch the keyboard or computer. You could invite your colleague to your desk for the next iteration of collaborative work.
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.
Have a happy and productive day of coding!
Photo by Christina Morillo from Pexels
Top comments (0)