Pair Programming: Roles

The Driver

The person at the wheel

During a pairing session, the person who is actively at keys coding the implementation at the given moment. Beyond coding at the allotted time, the driver should be thinking out loud and asking questions. Additionally, the driver should actively solicit the navigator’s opinions and advice.

The Navigator

The active observer position

The Navigator is an active observer in the pair programming dynamic. They benefit from having their thoughts and perceptions not focused on what they would have been typing. They watch to identify issues, help resolve them, and see if they can find opportunities for alternative paths that could benefit the pair. They are as much a live peer reviewer as they are a rubber duck for sounding ideas. However, this rubber duck comes with views and opinions to share also. Much like the Driver, the Navigator should be asking questions and soliciting the opinions and advice of the Driver.

Changing Roles

Switch keyboard and roles regularly

While different pairing styles vary as to whether the roles switch or how often, it is generally good to alternate who is driving and navigating throughout the pairing session. With two keyboards and mice, or the right remote pairing tool that allows dual control, switching can be seamless and without friction. It is essential, though, that both participants are ready for the switch to happen. Expecting someone to take over and drive without warning can be jarring; taking control without addressing it can break down a pairing fast.

During a pairing session, switching roles between the Driver and the Navigator allows each participant to actively code and implement the solutions to the problems they are solving while still taking a step back and assessing the direction they are going. Switching roles often allows the participants to understand each other’s styles and the teams’ processes. Switching also combats the mental fatigue that comes with heads-down coding for hours upon hours.

A key concept to consider is that every time a pair switches roles and the next takes over to drive, any misconceptions between the two are quick to surface. This particular effect is vital to making sure the pairing session is a two-way road in the creative process of solving complex problems. Without noticing deviations between the two and just pushing forward, the pair programming can evolve into hurt feelings or, worse, an alpha-beta relationship.

Additionally, pair programming can produce a somewhat rare experience in development, being able to both get into the weeds of the code and to be able to see the effect it has on the next developer immediately.

« Back