Strong-Style Pairing
Overview, benefits, and usage contexts
Most software engineers know about pair programming. However, comparatively few are aware of the various pairing styles and their distinct applications.
The majority of software engineers with whom I have worked with have a basic understanding of “Driver-Navigator”. In this pairing style, the Driver is in control of the keyboard and thinks aloud while coding the implementation. The Navigator observes attentively, thinking several steps ahead while taking notes, and answering any questions that the Driver may have along the way.
Driver-Navigator is how I was introduced to pair programming almost ten years ago. It has also been the de-facto pairing style in any discussion about pair programming that I’ve had since, with two notable exceptions. The first exception happened during a coderetreat, when I was introduced to Ping-Pong Pairing. The second exception happened when I was recommended Ensemble Programming, which in turn led me to acquire an understanding of Strong-Style Pairing (being a prerequisite to the former).
I cover the value of Ping-Pong Pairing in a prior post. In this post, I discuss Strong-Style Pairing: what it is, why it’s beneficial, and when to use it.
What is Strong-Style Pairing
Strong-Style Pairing was conceived by Llewellyn Falco as a means to coach junior software engineers. The style can be summarized by his Golden Rule of Strong-Style Pairing:
For an idea to go from your head into the computer it must go through someone else's hands.
The roles and interactions in this pairing style are summarized in the diagram below:
Here’s a further elaboration on the two roles.
As the Strong-Navigator, I:
Have control
Instruct the Typist on what to code (instead of typing out the code myself)
Provide instructions in the appropriate level of abstraction for the Typist to follow
Give up control only once I’m ready to do so
As the Typist, I:
Have the keyboard
Type the code
Wait for instructions from the Strong-Navigator on what to code next
Ask for clarification if I am unable to follow the Strong-Navigator’s instructions
Am comfortable proceeding with an incomplete understanding; I trust that the Strong-Navigator knows what they are doing and where they are going
Opportunity and benefits
An opportunity for Strong-Style Pairing arises when one person has an idea that they want to try implementing. I find it works best when two additional criteria are met:
The person with the idea has a high degree of confidence in how they want to implement it.
The idea is straightforward enough to be implemented in a short amount of time (e.g. in under five minutes).
As mentioned, Driver-Navigator is a far more common pairing style than Strong-Style. Assuming that the former is being used, the common approach to the above scenario is for the person with the idea to take the Driver role. If it’s the Navigator with the idea, the Driver gives up control and the roles are switched.
This creates a problem when the person switching to Navigator doesn’t have a good understanding of what the new Driver wants to try; in this case the new Navigator is not be able to navigate effectively due to that lack of understanding. Once this happens, the Driver begins to code on their own, resulting in an effective end to the pair programming activity.
In addition to preventing this from happening, there are a few other reasons why the pair may be better off adopting Strong-Style Pairing instead of staying in Driver-Navigator:
It keeps the other pairing partner (the Typist) engaged. Instead of being relegated to observing, they are actively participating in writing the code.
The Typist is able to gain a deeper, more tactile understanding of how the Strong-Navigator thinks and solves problems. Instead of solely observing the Strong-Navigator, the Typist actively participates in solving the problem.
If the Typist is not familiar with the codebase, Strong-Style Pairing is an opportunity for them to gain that familiarity in a far more effective way than aimlessly “walking through” the codebase on their own.
It constrains the Strong-Navigator to having to articulate their idea coherently and efficiently, so that the Typist can implement it effectively. This develops technical communication skills that lead to a stronger shared understanding on a team.
If the Strong-Navigator is not familiar with the codebase while the Typist is familiar with it, then the former role can focus on their idea without getting caught up in implementation details. For example: the Strong-Navigator has an idea around code design they wish to explore, while the Typist has a good understanding of the existing design and can therefore lead them through it efficiently.
Usage Contexts
Having covered an overview of Strong-Style Pairing and some of its benefits, I will now cover some contexts where I’ve found the style particularly effective.
Interviewing
Evaluating the technical acumen of software engineers fairly and effectively has been and continues to be a hard problem to solve. Take-home coding assignments discriminate against people who lack free time outside of work. Asking candidates to code independently during an interview session means that they’re expected to perform in an unfamiliar coding environment while being observed and evaluated.
At Connected, we use strong-style pairing to maintain fairness while reducing the pressure of coding during an interview session. The candidate takes on the Strong-Navigator role, while the interviewer does the typing. This means that the candidate does not need to navigate an unfamiliar IDE setup; in fact they do not even need intricate knowledge of the language syntax (though a rudimentary familiarity definitely helps). It also means that we can evaluate for skills that we care most about — namely, technical communication skills and an understanding of language-agnostic software engineering concepts such as TDD and simple design.
Onboarding
A typical approach to onboarding is to give the new team member a straightforward task and let them implement it on their own, while “encouraging” them to ask for help if they need it. I use scare quotes here because this strategy has the opposite effect for any software engineers who are inexperienced relative to their teammates. Imposter syndrome is an unavoidable reality for these new hires, who oftentimes have the added sceptre of probation hanging over their heads.
Instead, I find that a much kinder approach is to pair them up with a teammate as soon as they’re ready to work on a task. Ideally, neither the task nor the teammate should matter. The new hire is put in the Typist seat, while their teammate takes on the role of Strong-Navigator.
While this may seem intimidating at first, remember that in Strong-Style Pairing, the Typist need not be concerned with anything other than following instructions. If they cannot understand the instructions, they can ask for clarification. It might seem like throwing them in the deep-end of a pool. I contend that it’s actually like walking them into the shallow-end. Throwing them in the deep-end would be expecting them to solo1 on a new ticket, in a new codebase, on a new team.
Off the bat, set the expectation that the point of the pairing session (and perhaps even the first week) is for them to get familiar with what they need to learn in order to be effective on the team. Setting this expectation is a powerful way to invite honesty and openness, while allowing them to set aside time for deliberate learning and practice as they ramp up onto the team.
Wrap-up
There were a few more usage contexts for Strong-Style Pairing that I wanted to cover. I’ve save them for a follow-up post that can be found here: Pairing with a Subject Matter Expert. In the meantime, I hope that Strong-Style Pairing has given you food-for-thought in regards to how you can incorporate pair programming on your product team.
In contrast to Pair Programming, a Software Engineer programming on their own (without a pairing partner) is referred to as “soloing”.