Pair Programming: Thinking Out Loud

“Pair Programming is a dialog between two people simultaneously programming, analyzing, designing, and testing.” – extreme programming

While we have a lot of experience working on software by ourselves, sharing your thought process while working on a task is new to many. Here we find ourselves having to overcome the hurdle of keeping the two minds in sync, so confusion and deviations do not often occur. The good news is that many of us have experiences in examples like group design sessions, mentoring, assisting troubleshooting a bug, etc. We just have to look at applying these in the minutiae of coding and live peer-reviewing.

Falling out of sync during a pair session will lead to the session not giving us the full benefits we are striving for and potentially lead towards some of the more harmful behaviors that pop up from time to time. Here we’ll mention a few approaches to help keep the pair strong.

Consider when driving, talking out loud the task that you are performing.

“When a pair is silent, it might mean they are so perfectly in-sync that nothing needs to be said — this is rare. More often, it means that they are not sharing their thought processes.” – pair-programming - codementor

Thinking and talking through an idea out loud is very helpful when solving problems. It is so successful that software developers gave it a funny term and actively practice it; rubber ducking. Here though, you have a rubber duck actively engaged and participating in solving the tasks before you. When you talk through what you are doing while driving, you are both getting the benefits of rubber ducking and sharing your thought process with another to help keep them in sync.

Consider when driving or navigating, actively asking for feedback.

“He took his time, sat back and asked my opinion like an equal. I responded in kind.” – how-to-be-a-great-pair

Another technique software developers employ to improve the solutions we create is peer feedback loops. These often surface as Peer Reviews, Pull Requests, Knowledge Transfer Sessions, Rubber Ducks, and the Second Set of Eyes on a problem. In pair programming, though, we have a live peer reviewer there ready to help us. Feel empowered to pause before you begin your task and engage them for their opinion and advice. Brainstorm ideas between the two of you. Weed through the pros and cons of each of the paths that you can take. Then make some judgment calls together about where to go next.

Consider tackling one problem at a time.

Keep a pen and paper handy so that if you remember a to-do item for another task, you can quickly jot it down and come back to it later. – one-task-at-a-time

With any combined effort, we often find things that we would miss on our own. Sometimes it comes from your partner noticing something while you were focusing elsewhere. At times, they arise from alternative directions that you discussed, and other times they come from clearing up misunderstandings about the task itself. Whatever the case is, rabbit holes tend to pop up when pairing. Reminding ourselves to tackle only one problem at a time goes a long way here.

When a deviation appears that could cause a side track, the Navigator can help keep things on track by recording it for discussion after completing the current task. After an individual task, do a quick review and put the item in the priority list to pick up now or where the future work task list lives. Addressing the issue found is essential, but so is keeping the momentum of the task at hand.

« Back