Good Resources Elsewhere
We didn’t write these guides, but you should read them anyway.
On Pair Programming
by Birgitta Böckeler and Nina Siessegger
This is an extremely thorough article on the subject. It covers techniques, compelling benefits, and practical solutions for arguments commonly used against pairing.
Pairing feels hard – but that doesn’t necessarily mean it’s not good for a team. And most importantly, it does not have to stay hard.
It started as an internal slide deck that was curated and crowd-sourced, so it’s full of quality advice derived from real experience:
Different skill levels
When two people with different experience levels pair on a topic, this often leads to false assumptions on how much each of them can contribute, or frustrations because of difference in pace.
Ways to tackle
If your pair has more experience on the topic: Don’t assume they know best. Maybe the need to explain why they are doing things the way they are will bring them new insights. Asking questions on the how and why can lead to fruitful discussions and better solutions. […]
The detailed explanations and examples make this article a must read.
The Art of Agile Development: Pair Programming
by James Shore
This article is worth reading if only for the 99-word summary of pairing at the top:
It’s more fun than it sounds: two programmers at one computer. One drives; the other navigates. Switching roles fluidly, they constantly communicate. Together, they accomplish better work more quickly than either could alone.
The driver types. She focuses on tactics–writing clean code that compiles and runs. The navigator focuses on strategy–how the code fits into the overall design, which tests will drive the code forward, and which refactorings will improve the entire codebase.
Pairs self-organize by selecting partners who can best help with the current task. They switch every few hours to share perspectives and knowledge.
Beyond that, James’ guide is packed full of quality advice, written with the voice of experience:
When you start pairing, expect to feel clumsy and fumble-fingered as you drive. You may feel that your navigator sees ideas and problems much more quickly than you do. She does—navigators have more time to think than drivers do. The situation will reverse when you navigate. Pairing will feel natural in time.
As navigator, help your driver be more productive. Think about what’s going to happen next and be prepared with suggestions. When I’m navigating, I like to keep an index card in front of me. Rather than interrupting the driver when I think of an issue, I write my ideas on the index card and wait for a break in the action to bring them up. At the end of the pairing session, I tear up the card and throw it away.
How To Pair Program
by Jeff Dickey
This post is worth reading because it’s someone who started off skeptical of pairing, tried pairing with experienced devs, and discovered he really enjoyed the experience.
Jeff’s post is full of practical advice from someone who’s put the time in.
Some highlights:
Don’t expect just because you can program you can pair […]
Try to do it each and every week. Don’t expect it to go swimmingly every time, but trust that once you and your team get the hang of it the edges will be roughed out.
While you are pairing, the number one thing to keep in mind is “Is my pair engaged?” or “Am I engaged with my pair?” usually the person that’s driving will be more engaged, and switching it is one technique to help bring yourself or your pair back into the action.
The goal of pairing is always to learn. Whether it’s to learn about the programming language, learn about the company, learn about your coworker, learn about the project, or learn how to pair in general, you should be learning something new the whole time.
Five Rules of Pair Programming Etiquette
by Rapid7
Unlike the other links in this article which cover pairing broadly, this post focuses on etiquette during your pairing session.
The five rules:
- Agree on the physical environment beforehand
- When talking about code, always refer to line number and file name
- When disagreeing, talk in terms of benefit
- When feeling ill at ease, say so
- Bestow as many compliments as possible
I find the first rule least compelling of the bunch, but the remainder are great.
The Art of Pairing
Yours truly, on the Full Stack Radio podcast.
Topics covered:
- The benefits of pairing with someone more experienced than you
- The benefits of pairing with someone less experienced than you
- How pairing helps you build things faster
- Why pairing often removes the need for code review
- How to get started with pairing if you’ve never done it before