I have distilled my ethnographic research on pair programming into a number of observed desirable and un-desirable pair programming behaviours*. I previously posted two of the un-desirables: Thrasher and Divider. Here is one of the desirables, Tag team. Note that I use the terms driver and navigator only to indicate who is currently typing rather than as a way of implying other behaviour. Also that I assume a single keyboard and mouse, although I am aware that this is not always the case.
Even programming alone is cognitively very demanding. In pair programming, as well as typing code and mentally working on the task at hand, the programmer has the additional cognitive load of providing a commentary on what he/she is doing. We can minimise this load by regularly changing which partner types.
Use the tag team when:
- Current driver is tired or cognitively overloaded.
- Current navigator needs to show an example or indicate which part of the code they are referring to.
- Navigator input needs to be encouraged.
- Either or both programmers would prefer (i.e. whenever you’d both like).
- Cognitive overload can be avoided – the driver can take a break from typing and commentating.
- Navigator input can be encouraged – thus avoiding navigator drift.
- Specialist knowledge can be maximised – Most able partner can type in code or show a tangible example.
Note that additional verbalisation is required as the navigator must be up to speed if he/she is to be ready to spontaneously change role.
- The driver or navigator may ask verbally (e.g. “Here….you drive”).
- The driver may simply slide the keyboard and/or mouse over to the navigator.
- A surrogate artefact may be used. I observed pairs sub-consciously using objects like paperclips, where picking up the surrogate object indicated a relinquishing of the keyboard and mouse.
* I am reticent to call them Patterns as they were not derived using the accepted manner. However I found adopting a pattern-like way of expressing them was very useful.