Pair Programming
- 1 minThere are many reasons to pair program and many arguments not to. Here I discuss techniques that can make all the difference to being a good pairing session.
The first thing to decide on when pairing is how to pair. Will it be pomodora (one person at the keyboard for 25mins, 5 min break then the other pair drives) ping pong (first person will write a failing test, and the second pair makes the test pass then writes a failing test for the first person to pass). Or the pair may decide to break the task up and into smaller pieces, work on it individually and not to sit at the same keyboard.
- The technique you choose will depend on the following factors: The task in hand. Is it a spike, looking around code, driving out a new feature. Below I group common tasks and what I would recommend.
| Task | Recommended Pomodora |
|---|---|
| New feature | Ping pong |
| Spikes | Pomodora or split |
| Research | Split |
| Fixing legacy code | Pomodora |
-
The experience of the pair. If the pair consists of a junior and a senior pomodora, maybe more suitable. Or if they are the same level. Or same level but one knows the area of the task.
-
Knowledge on the tech or the area of code. When we are looking into a new technology or an area of unknown to both pairs, sitting at the same screen and reseaching the area may not be the best practice. Different things will stand out for people. The research and absorb things differently.