2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- July 10, 2019
- Collaborate
Another important technique for engaging developers in pair programming is to swap roles frequently.
For new pairs who are just starting to work together, I recommend swapping roles every 2 to 20 minutes. For more established pairs who’ve worked together well, I recommend swapping roles every 20 to 60 minutes, although that could become much more frequent as we’re learning new tasks or building unfamiliar skills.
We also want to do what Arlo Belshee refers to as promiscuous pairing. We want to engage in pair programming with everyone on our team. I didn’t really understand the importance of this until I began to practice it. What I discovered was that my very best pair partners were the ones I had least expected. I learned something unique and special from everyone on the team but it seemed like the people that I knew the least turned out to be some of the very best people to pair with and I would have never known that if I didn’t follow the practice of pairing with everyone at least once.
I always encourage everyone to pair with everyone. I also encourage people to experiment with different time lengths for their pairing sessions. Sometimes it’s valuable when learning new skills to rotate in and out of pairs frequently, I usually like to stay with a pair partner for the entire day or task or iteration. Generally, my preference is to swap pair partners on a task basis.
Aside from gaining new and fresh perspectives by pairing, it’s also an incredibly valuable way to propagate knowledge across the team. I find that this propagation of knowledge happens at many levels from the mundane to the abstract. I learned practical tips for how to use my tools more effectively and I’ve also learned new problem-solving techniques and approaches from pairing.
Sometimes, I’ll pair with a junior programmer and I do this specifically to be in the mentor role and help them improve their craft. I find though that doing this can often help me as a teacher more clearly articulate the things that make good development practices.
I think that software development has been in the dark for far too long and we put ourselves thereby isolating ourselves and thinking that writing code was a solitary activity. When we pair we learn from each other and when we do this promiscuously across the team we can propagate enormous amounts of information and knowledge very quickly. The end result is that we start to adopt common practices and the overall quality of the code improves.
As we begin to level-set our knowledge and skills the code we are working on starts to look more and more generic. This means that anyone on the team can work on any part of the code because everyone is cross-functional. This is a highly valuable thing to have on a team and it gets naturally achieved through pair programming. And this is just some of the many benefits of pairing.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.
Previous Post: « Engage Driver and Navigator
Next Post: Put in an Honest Day »