At CARFAX, we Pair Program. Conceptually, Pair Programming is two people sharing one mouse, one keyboard, and one computer. In reality, technology keeps it from being a cumbersome experience. Although I have done this at other companies, we don’t literally shove the mouse, keyboard and computer back and forth. Still, the concept is preserved. Referred to as Driving, one person is typing and the other person helpfully participates. Both brains are engaged. Their minds are in sync.
Pair Programming covers a lot of ground when it comes to the benefits that it delivers when done well. I have heard many examples of Pair Programming not going well. Most of the time, it’s because one or more of the following things were in play:
- Culture didn’t support it
- No process of providing constructive feedback between team members existed
- Lack of formal Pair Programming training
The third one is sadly the most common and easiest to fix. Do not confuse Pair Programming training with Test Driven Development (TDD) training. You could have all the TDD training you want, yet that doesn’t guarantee that one of the two people won’t behaviorally be a domineering alpha-male / alpha-female. As the Star Trek fans might say, you are going for a mind meld.
Both brains are engaged. Their minds are in sync.
It also means that they both learn to share, listen, and come prepared. There are various other articles out there that cover whether Pair Programming is great or not and how so. This article covers some of the items related to how to make Pair Programming work and not to jump the gun in deciding that Pair Programming is not working for you or your team.
Pair Programming Should Be Taught
Far too often, people are not told how to pair program well. Two people are put together and told to just “do it.” I have coached teams and specific individuals on how to Pair Program well. Before sharing how one can Pair Program well, it’s important to point out to not judge their experience too quickly.
When Should I Judge My Experience?
In short, you have to do something well before you can judge an activity fairly. Have you ever tried a new activity such as learning how to code? After just trying it for just a few days, did you throw your hands up into the air and say this is a stupid waste of your time never to return again? Probably not. It took time and you were willing to spend the time because the benefits were important to you.
From How Important is Pair Programming? by Ron Jeffries:
..you can’t assess whether you like something if you don’t do it well
..does take some practice to do well
..do it well for a few weeks to see the results
What are the Benefits?
There are other articles that cover this more in-depth such as the Better Together: The Benefits of Pair Programming article. Here’s a handful:
- Continuous code inspection – As opposed to a boring meeting full of people who weren’t there with you when you faced the challenges and legacy code.
- Backup memory – Everyone has brain farts. Your fellow pair programmer gets you past that.
- Self esteem supporter – If done well, you’re both in it together. You are white-hat. You are kind and yet you also hold each other accountable.
- Collective Code ownership – No-one claims that this code-over-here is my code. Everyone can touch any of the code with the right pair of people.
- Knowledge sharing – If one gets hit by a bus or wants to go on vacation, the entire team is not severely hindered.
- and so many more. With respect, go google it.
When does the developer have time to think?
That’s a great question! It’s important for the team to set up a structure so that developers have time to think about what they are about to work on and while they are in the middle of working on it. That means structure. That means understanding and respecting each others’ needs to explore a little on their own computer, setting aside any investigative code they wrote and then coming together to work on it as a pair.
Scheduled breaks should also be taken. It allows time to freshen up the mind and explore the code more on ones one if desired. That means committing to a source-code-branch and publishing it so both can play on their own. When doing this, enough time is needed in order to come up with a draft idea. Not a perfect idea!
Time To Think aka 3T is critical. It comes in many forms both informal and formal. Even time to explore a small bit of code together needs to be supported. Sometimes one person should just wait patiently for a few minutes. You never know what you might see! However, that technique should not be abused such that one person just codes ahead for a long time and leaves the other behind.
Work together to figure out how to support the 3Ts or bad things will happen such as people dominating the keyboard and pair programming experience.
Pair Programming Tips
- Do head nods or occasional mmhmmm
- Give compliments
- Do not over prompt. Allow five seconds after you spot the Driver making a mistake. Saying oops over and over quickly is just annoying
How do you make it work when at least one person is remote?
- More audio cues are needed because body language is much harder to see.
- Can you see their face? Facial expressions and body language account for 90% of what’s being communicated. Use video if possible.
This Pair Programming practice ties into Extreme Programming. What is Extreme Programming?:
- ..based on values of simplicity, communication, feedback, courage, and respect.
- ..works by bringing the whole team together in the presence of simple practices
- ..feedback to enable the team to see where they are and to tune the practices to their unique situation
Hopefully this helps. Good luck and happy coding!
Update: It was suggested that we have an alternative name for Time To Think (3T), Design Exploration Time (DET). So now it’s known as either.