Week One of My Pairing Tour
Last week (5/13-5/16) was the first week of my pairing tour, a two-week period where I pair with a different 8th Light craftsman each day. Last week I worked with Dave, Patrick, Dariusz, and Craig. I worked on Rails apps, wrote some Ruby code, and paired on a Node app. I learned a lot, both about code and about how to effectively pair.
There are several things about pairing that I noticed as I moved from project to project, craftsman to craftsman, each day trying to gain enough context quickly enough to contribute.
- Verbally communicate at all times.
The best work happens when you and the developer you’re pairing with are constantly talking. You should explain your reasoning when necessary, describe what you’re doing, and ask for feedback. There should be a constant flow of communication.
- Alternate driving frequently.
It can be tiresome to drive for long periods of time and similarly, you can find yourself feeling fatigued and almost absent when the other person is driving for a long time. It’s really great when you can get in the rhythm of alternating frequently. One strategy for achieving this is ping-pong pairing.
- Be engaged when you’re not driving.
Sometimes it’s strange to be the “other” person in the pair, the navigator, the one without the keyboard and mouse. It’s important to be engaged in the process by asking questions, providing suggestions, and most importantly, letting the driver know when they’re moving too fast or going in a confusion direction.
Pairing has many advantages. As you’re pairing, you’re sharing knowledge. You’re learning about the codebase, the design and architecture, the domain, the technologies being utilized (language, framework, etc.). Sharing knowledge helps you avoid a very common situation where all domain knowledge belongs to one developer. If that person leaves the company or takes a week off, everything stalls.
Pairing invites debate and forces developers to explain their reasoning. It provides accountability and leads to cleaner, smarter, more well-written code. That is the most fascinating part about pairing. It’s true that over the course of the day, you might get slightly less done. But in the long run - because you’ve written better, more maintainable code - you ultimately save time.
Pairing can be a great way to learn. Someone is always teaching (and therefore learning, too) and someone is always learning. But it’s a skill, not just something you do. It takes practice and the first week of my pairing tour definitely reinforced that.