Pair programming may feel quite strange and frustrating to those new to it. (I guess it can feel strange and frustrating to those who have been doing for a while). I gave a brown bag session to a group who were just starting to embrace pairing to try and help them overcome some of their frustrations. Here are my notes from the session.
What are the concerns around pairing?
- working with an argumentative pair - someone who wants to argue with you all the time, and disagrees with any approach you come up with
- keyboard hogs - the other person wants to snatch the keyboard away from me all the time
- unequal domain knowledge - one person knows everything, one person knows nothing so it is frustrating for the know-all to keep explaining everything all the time, and when they don't the person who knows 'nothing' just tunes out.
- differing styles
- adds to the overhead - eg computer setup, time to bring someone up to speed on what is happening when you swap pairs frequently
- I don't have time to check my emails
- there is no concept of 'my computer'
- you can't get into 'the zone' when pairing, like you can when you are working by yourself because you always are interacting with another person
- too much time rotating pairs
- physical environment - room to work
Why do we pair?
- Shared responsibility
- Knowledge transfer/sharing
- collective code ownership
- reduce key person dependancy (increase bus factor)
- better quality
- increased focus on the job at hand
How can we achieve it?
- Teamwork
- working together to solve the problem.
- Both members remain engaged 100% of the teim.
- Ask when you are not engaged - "You lost me, what are you doing now?"
- Communication
- Toss a few leading questions into the mix. Some of the phrases I usually say are:
-
- "Should we do it in this way?"
- "Do you know what we are doing?"
- "Tell me what you are thinking?"
- "Just let me try this and then we can discuss it."
- "What do you think?"
- Think allowed - vocalise your thoughts, so you can bring your pair on the journey to the solution
- Pass the keyboard around
- Break the story into small tasks and write them down on post-it notes when you start a story. By breaking the story you are working on into small tasks, you can focus your attention on one thing at a time. Your mind does not need to wander thinking about all the other steps to solving the problems, as you know that you will eventually work on them. It also helps with rotating pairs through the story, as they can easily see what has been done on the story, what needs to be done and what they should focus on.
- KISS - Keep the solution and tests simple so there is less overhead when discussing complex solutions
- On board new team members to bring them up to speed on the overall goal and design, so you do not need to repeat basic details when you work with them on a story.
Different Styles of Pairing
- Ping pong - I write a failing test, You make it pass then write a failing test, I make it pass then write a failing test. Rinse and Repeat
- Chessboard clock - this can either be achieved with an actual chessboard clock where every time you start touching the keyboard, you hit your part of the clock, when your partner touches the keyboard they hit their side of the clock, and you aim to keep the times on the clock equal. Or you timebox how long you will drive for, eg I drive for 10 mins, then you drive for 10 mins.
- Inexperience partner drives - there is nothing like learning through your fingers, so let the inexperienced person drive. This style requires that the driver actually does a lot of work, and is not just a typist for the navigator. This works best if the inexperienced person can explain what they want to do, eg "I want to call some sort of repository for this value then I can go on." so the experienced person can show where the file is.
- 2 keyboard and 2 mouse(s)
- Doesn't matter who 'drives' - when you have two people experienced in pairing as both people do the design verbally, and the person at the keyboard just conveys the conversation to code (often the fastest typist)