Good Resources Elsewhere
We didn’t write these guides, but you should read them anyway.
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.
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.
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.
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.
Yours truly, on the Full Stack Radio podcast.
- 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