A step back: who should drive and who should navigate?
- On time: you can just change roles on a regular interval. Start with shorter times and grow the time as you grow to work as a pair.
- On task: you can change roles when some task is completed. Like a typical ping-pong style pairing, you change so that one creates a unit test and other implements, and both get to do both types of tasks.
- On idea: you just change when the driver feels there's a direction he'd like to navigate to. It's like saying "hey, I have an idea, you take the keyboard now".
As navigator, you are in responsible for caring for your driver. If the driver is the intelligent input device, for her to operate properly, you need to care for the conditions of work. Being the navigator, you need to pay attention to your driver, to constantly know where she is going. And you need to enable her to go as fast as possible.
As a navigator, you have three main tasks you're paying attention to:
- Feed driver the next thing to do. You're creating the driver the box she works in on as high abstraction level as your driver can handle. We'll talk about abstraction level a little more later.
- Mine the to-do-list. Create an idea on where to go next. You might be just one step ahead, but being that one step ahead is important. Where to go to get your thing done?
- Observe your driver. See where she is and where she is going, and correct if the direction does not match what you had in mind. Pay attention on how she is doing, and help her whenever she needs it.
Programming style matters
As the navigator feeding the driver the next thing to do, finding the right abstraction level to communicate with her is relevant, even key to making progress. For driver to go forward, you need to find the right level on which to talk. If you are using an abstraction level too high, you will see puzzled expressions and nothing happening at the keyboard. If you are using an abstraction level too low, you're not harnessing the powers of your driver by keeping her on too short a leash.
I was particularly puzzled with the idea of using highest abstraction level possible, until I realised finding the level is really a listening and observation exercise. If you give instructions and following them is hard, you're probably working on a too high abstraction level. Drilling down can be instant, just be more specific. If you're not noticing the need to change level, you're perhaps risking an experience of failing with tasks that lowers motivation in pairing, so it's good to keep your eyes and ears open. If you start from a very low abstraction level, the driver can always correct you by telling you the level she is comfortable with. But if she has not yet learned how to, she might get a feeling of being talked down. And I found I am particularly sensitive to that, being the only woman and paying attention to being treated differently.
Mining the to-do-list
There needs to be an idea of where we're heading. But the road ahead might be only clear for the next few steps, instead of all the way. An important thing for a driver is keeping track of the work ahead. There's three main things to consider on this:
- Timing: Find the right time to use an item on the list. What should be done first, what would make a coherent shared story in your pairing. What choices would enable you as the navigator to care for your driver in the best possible way?
- Backlog: what is there on the list of things to do? Your backlog is best if it can somehow be part of the code and become a shared view - with consume-first style. But you can also make notes by scribbling on a piece of paper of a whiteboard. Whatever you need to keep track of things. Notes are disposable, code (including test code) is what remains when you're done.
- Prioritisation: Deciding what comes next and in what order to do things. It's not just about the right time in long term, but the right thing right now. And it keeps changing as you learn.
Express a in-a-nutshell idea of what you're doing
As a navigator in strong-style, you are not supposed to have to justify all your chosen actions to your driver. Sometimes the driver has little clue on where you're about to be heading, and a great practice in these cases seems to have been to invite temporary trust saying you'd like to just go to this direction for like 10 minutes, and if she is still unsure about doing this, you can change then. The argument of what is right thing to do takes easily more time than that. And nothing stops the pair of you implementing both of your ideas and then deciding that a third, completely different option is what you should go for. With programming in particular, there's a lot of uncertainty that unfolds only through implementation and experimentation.
If you need to express what you're doing, you should learn to express that in a very concise format. Instead of all the rationale, pick only the part of the message that is absolutely relevant to care for your driver.
When you navigate, keep an eye on your driver. Double-check with questions what the driver does. And if the driver does something you consider a problem, help her correct it right away. Feedback belongs with the action the feedback relates to.
Recognizing time to switch
Either one in the pair can suggest a switch of roles. But as a navigator, you are usually in a controlling position, so your position gives you a bit of extra responsibility to pay attention to when the driver would have ideas that she should navigate on. You want, in the long term, to build a pair where both can contribute. Switching pairs gives a chance to try out the other role, and only practice helps you get better.
Step back and think about what you're doing
Sometimes you may feel you get bogged down into the details of implementation, and you might want to take a step back and think if you are spending your efforts in the right area. You may not notice without intentional step back to look at the bigger picture, because you're going fast with support of your pair (and usually a nice bunch of unit tests too).
Looking at your collaboration and how the two of you feel about it on regular intervals is also necessary. Not just looking at what you implemented and stepping back on that, but talking about what you learned and what you like and dislike about your collaboration, in a constructive tone.
Ending this with a word of warning
I've started to really enjoy looking into the dynamics of this style of pairing. But there's a story I learned, that I also find very specific to this style.
Two programmers were pairing in strong-style and had the time of their life. There was a lot of talk, as all ideas must go verbally for two people to share. Sometimes the discussions were very enthusiastic and to an outsider they might have appeared even heated.
While the pair was enjoying, the environment that did not recognise the different pairing style was betting on which one of the two in the pair would quit first.
Don't care just for your pair, care also for your environment. Verbalising your thoughts makes them available for more people than just the two of you. Take it as an opportunity to build relationships outside your immediate pair.