Pair Programming

Note from ByteMaster

Pair Programming supports the first of our four initiatives as derived from the Laws of Combat - Cover and Move.

TLDR

Pair programming is equally rewarding as it is draining. There are a lot of resources on the subject and different approaches. Here we will talk about our experiences and how we digested the various versions of this practice.

“Nothing builds a collaborative thinking team quite as well as seeing someone as an equal and sincerely seeking their opinion.” – Joey

Without the actual “want” to see pairing in these ways, the likelihood of any given pairing leading to frustrations grows.

  • Finding the patience throughout the session to get back in sync with another developer every time the two of you go down different directions in thoughts and processes. It is not a question of whether your understandings and approaches will split and deviate, but a question of can you continuously work to find common ground to continue without being dismissive of the other.

  • Have the humility to allow and accept another’s help no matter their skill level or experience. To allow another’s beliefs to challenge your own and leave you with a chance to reinforce your beliefs or grow new ones. A sincere want to hear and digest another’s opinion is sometimes hard, but one of the most important and rewarding aspects.

  • Practicing the ability to express yourself in an empathic way and having empathy towards your pair will significantly help the two of you recover from the very human behaviors that come from closely working with others in mentally challenging, creative problem-solving scenarios. Knowing when to take a break for your benefit is just as important as identifying when your pair might need one also.

Benefits

“Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticise each other, and find each others errors, and use the best ideas.” – Jean Bartik, one of the very first programmers

Clarify ideas Drive out misunderstandings, collective creativity/brainstorming, improve code quality, find and resolve bugs earlier, combined skill sets to approach ideas.

Reduce Frustrations and Roadblock One participant can drive when their partner is stuck or taxed, tackle impediments together, combined skill sets to approach issues, real-time feedback that is harder to ignore than asynchronous feedback.

Share Spread knowledge/skills, reduce technology learning barriers, identify tribal knowledge, and spread the knowledge until the team can resolve it.

Social Get to know team members, respectfully present and focused, spread team culture, beliefs, and practices.

Quickstart

Find a partner and download a Remote Pair Programming Tool.

When you first begin to program in pairs, it would be wise to start small, no more than 3 hours a day, and set regular intervals of 30 minutes to switch who is coding and who is helping.

Contents

  1. Pairing Roles

  2. Pairing Styles

  3. Think Out Loud

  4. Fatigue

  5. Tech

In Closing

“Write all production programs with two people sitting at one machine.” – Kent Beck

OK, so that quote might be a little heavy handed or maybe it is not and sits well with you and your team. Just keep in mind that pair programming is a different way to work.

There will undoubtedly be pain points and learning curves when first coming into it. Remember that successful pairing is built over time and rarely done without a dialog between the people involved.

Hopefully, this will give you enough of a jump start to skip some of the hurdles and start having fun solving problems together sooner.