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 24, 2019
- Collaborate
Another key to discovering what works best for you when doing pair programming is to try all configurations. By that I mean mix it up as much as possible. On each project, you should try pairing with at least everyone once. Also try pairing for different periods of time before you switch pair partners, like an hour at a time or half a day at a time or two days at a time (with breaks), etc.
Mix things up as much as possible. This is the way that we stumble upon the things that work best for us. Just observe as you vary things. It also helps to write things down. Observe how long your attention span lasts to determine how often it makes sense for you to swap driver and navigator. Is it about the same for your pair partner? Or do they have significantly more or less stamina than you do?
These questions are worth exploring when determining who you pair best with. I often find that the best pair partners are not the ones who are the most senior or the most knowledgeable. I often find that complementary skills and personalities tend to work best for pair partners.
In other words, pair an introverted person with an extroverted one. Pair a practical person with a more abstract one. The benefits that we get from pairing come from the differences in perspectives that the other person brings and so we’re looking for people who are not like us, who are different from us and can bring that different perspective.
When I am introducing pair programming to developers who haven’t been exposed to it before I sometimes meet with resistance because they think that they’ll get criticized but they learn very quickly that we’re all human and we all make mistakes. Even the best of us can make silly mistakes.
I teach a software developer class that includes three afternoons of pair programming. At the beginning of my class, I sometimes spot a student who is clearly resistant to the notion of pairing with another developer. I love watching the process transpire because very often the person that was the most resistant to trying pair programming, in the beginning, becomes my very best advocate. I know one developer at a very large software development company who was definitely resistant to the notion of pair programming and later became one of the big proponents for pairing in his team and then across many other teams in his organization.
I keep saying throughout this series of posts on pair programming that you have to experience it to really understand it and it has to be done in the right way. When done well, pair programming can be one of the most powerful and valuable techniques for learning new skills and bringing the best of our skills and talents to our work.
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: « Put in an Honest Day
Next Post: Let Teams Decide on the Details »