& Continuous Learning

Overview

Pair programming is a technique where two programmers work at a single work station.  One person "drives" or has control of the mouse and keyboard.  The other person "navigates" or keeps track of where they are and where they are headed.  This is a perfect environment for teaching and learning to occur.

Roles

Navigator

• Keeps track of the big picture.
• Responsible for directing the flow of work to a specific conclusion.
• Reviews code.
• Keeps track of tasks identified by the driver so they can focus on coding.
• Ensures that best practices are followed.
• Track potential code improvements.
• Asks questions about the driver's implementation

Driver

• Implements the next task provided by the navigator.
• Gives future tasks to the navigator to track.
• Answers navigators questions.

Typical Pitfalls

Navigator

• Taking control of the mouse and/or keyboard.  Resist the urge to always be in control.
• Dictating every step of implementation.  Your partner is not a voice activated typing machine.
• Interrupting you partner's thought process.  Write down your thoughts and bring them up when your partner is ready to focus on what you are saying.  Be patient.  Use this extra time to focus on their code and where your pair is headed.  You are supposed to be focused on the big picture.
• Failing to pay attention to what your partner is doing.
• Questioning every choice they make.  Trust your partner.  You can certainly question some of their decisions, but don't question everything they do.

Driver

• Ignoring your partner.  The navigator is there to keep you on track.  Listen to them.
• Failing to explain what you are trying to accomplish.  Your partner is not a mind reader.  Before you start the next step take a moment to explain what you are going to do to your partner.
• Driving all the time.  This is not smart in a car and this is not a good idea when you are pairing.  Give up the keyboard periodically.

Rotating

Pair Rotation

Teams should agree on how often they will switch pairs.  I prefer to switch partners once a day.  This allows each team member to be exposed to different levels of expertise and different perspectives.  This also prevent teams from having knowledge silos.  On the other hand, switching too often can result in team members knowing a little of everything without understanding anything very well.  Take time to reflect on the effects of pairing on your team.  Adjust the practice of pairing to support the goals of your team.

Role Rotation

The driver and navigator should switch roles periodically.  Driving or navigating too long can become monotonous and mentally overwhelming.  My favorite rotation approach uses TDD as a cadence.

1. writes a failing test.
2. switch
3. make it pass
4. refactor the code
5. write a failing test (step 1)
6. switch (step 2)

This is just a rhythm that I enjoy following. It is fast paced and keeps my attention.  Try different thing and figure out what works best for you.  Just remember that each partner is different.  Find a pace that works for both of you.

Environment

• Make sure you have enough space.  Move you monitors to the center of the desk.
• Use comfortable chairs.
• Agree to take periodic breaks.
• Remove Distractions
  • Turn off or at least silence your phone(s).
  • Tell your significant others to not call/text during pairing hours
  • Suppress distracting new message signals for email
  • Ask other team members to not interrupt you during pairing time.
  • Try to avoid scheduling meetings during this time.  Block out time on your calendar.
• Keep some gum/breath mints handy to mask the onions you ate for lunch
• Get some caffeine in you before you start if you need some.
• Clean off your desk.  Make it inviting for your pair.
• Keep some scratch paper and pens/pencils available for notes.

Conclusion

I spent several years pairing 6 hours a day. I learned more about people and software development than I have ever though I could. I am not recommending that you try to institute a similar policy on your development team. In fact, I was telling Extreme programmer Uncle Bob that our development shop required developers to pair 6 hours a day.  He was shocked and a bit appalled that we would require this much pairing. He explained that pairing is a tool that should be used to distribute knowledge throughout our team. He recommended that we consider being less extreme in the area of pairing.

When we first instituted this requirement we found that we were more tired than usual, at the end of the day. Many of our spouses began to notice that we did not talk as much in the evenings. This fatigue stemmed from the focusing nature of pairing.  We were learning and thinking more than we had before we started pairing.  Pairing is a valuable tool that should not be ignored or abused, but rather used to improve your team.