How to pair program
Pair programming was introduced in the book eXtreme Programming by Kent Beck . I’ve come across many teams which said it did not work or that it was inefficient. Pair programming is definitely not for everyone and every piece of work, however most teams that I’ve talked to that tried it, didn’t even do it currently.
Pair programming is one of the trickier practices to get right, but if you do, you’ll suffer the following symptoms:
- Talking and discussing problems as you solve them with someone else. And they’ll be doing the same to you.
- Accomplishing more in a shorter amount of time.
- You’ll lose the urge to check email, your phone or going to the pantry.
- You’ll feel drained at the end of a pairing session.
Contrary to popular myths, pair programming when done right does not reduce productivity. In fact, it could and will increase team productivity and improve code quality.
Programming or software development at it’s core is solving problems with code. Look at pair programming as a way of solving problems with someone else. Much like how we would use a whiteboard to discuss and solve design issues, pair programming is the same, just in front of a computer.
The benefits of pair programming are, but not limited to:
- Constantly having someone that you can brainstorm with and validate ideas as you have them.
- The other person serves as an accountability partner to help keep you focused.
- Two heads are better than one. He or she may know something that you didn’t know and comes in handy.
- Two pairs of eyes are better than one, this results in better code quality.
- Create healthier and closer working relationships.
- You’ll get to learn more about the code, domain and level up your coding skills.
The above is true for both partners in a pair.
How to start pair programming.
Alright, you’re sold and you’d like to give this a go. So how do you start? Follow these steps:
1. Create a pair.
Find someone that you’d like to work with to pair. That person does not have a be a junior / senior person, but rather just somebody else in the team (or even out of it!) that you’d like to solve a problem with.
2. Find a piece of work to pair on.
This could be a user story, a problem, task or spike. This piece of work should have clear outcomes attached to it. For example, to implement behavior in code that satisfies the acceptance criteria of a user story, or to try out a nice piece of technology if it will solve a specific problem. Simple pieces of work may not be appropriate to pair on, though this could be indicative of a code smell.
To quote Martin Fowler:
It's only worth pairing on complex code, rote code yields no advantage. I think there is a point to this - pairing is about improving design and minimizing mistakes. Rote code that's simple to write yields little opportunities for pairing to make a difference. Except this: writing boring rote code is a smell. If I'm writing boring repetitive code it's usually a sign that I've missed an important abstraction, one that will drastically reduce the amount of rote code to write. Pairing will help you find that abstraction.
3. Agree to a time box for this pairing session.
Set a time to end the pairing session. This could be anywhere from 1.5 hours to half a day (or more). The human mind can only take so much mentally intense work that it’s good to have breaks in between.
4. Set the goals of this pairing session.
What are the goals for this session? Would it be to implement a feature, work on some refactoring or find options to a problem. Be as clear as you can. Discussion this as a pair will yield insights in to the solutions for the selected problem.
5. At the end of the session, review what was accomplished.
Ideally, there will be outputs from the pairing session, like code that can be checked in.
6. Rinse and repeat.
Take a break, and start over!