Don't be a backseat driver

As I'm pairing with someone, I find it really difficult to negotiate the "contract" for that pairing session. Asking for strong-style pairing (I have an idea, you take the keyboard and I tell you what to do) or traditional-style pairing (I have an idea, give me the keyboard and watch and comment) can both me appropriate, depending on who the person I'm pairing with is, and how they interact with me.  But at time we're setting the rules on how we pair unless they are given by a facilitator for the session, it is the time when I know the least of my pair, it's the time when my inherent "making space for the other" is at its strongest and I find myself easily in a place where I'm disengaged and uncomfortable. 

At a workshop few weeks back, a friend of mine ended up pairing with a stranger. They had only done pairing in workshops with me, where I introduce and enforce strong-style for the connection, but also make the rules and expectations clear. Now they were told to pair, with someone who does not pair, and the setting was far from optimal. There was a skills difference not in their favor and as they ended up watching the more experienced one, they quickly fell off the loop of what was even going on. The computer they paired on belonged to the other and they wouldn't share it because it was set up just right for work. And the only way to pair my friend was taught was strong-style that really increases newbie involvement in uneven pair. It was clear they did not enjoy it. They left half way through the three sessions. 

Learning to talk about the two styles of pairing has helped me a lot in this regard. Now I have words to start the negotiating from. So I was delighted to find two more words for pairing patterns from videos of Alex Harms delivering a talk on pairing. The words were more of anti-patterns than good styles: side by side pairing where the more experienced one sets themselves above and outside the engaged pair, doing their own thing and being available for questions and mild hovering; backseat driving where the person not in position to steer tries to do that anyway. 

I could not help but think if Alex had run into a particularly inconsiderate experience with strong-style pairing, because without setting up the relationship with consent, strong-style pairing can easily be indistinguishable for backseat driving. 

Let's stop to think about that for a moment. What does good pairing look like? It looks like doing work by two people, where both are engaged in the same work. To be engaged, you need to be there willingly. And opting in to pair isn't always willing, if you did not know what is coming up.

Thinking about the roles in a car is helpful in remembering what it could look like. 

• Driver is always the person on the controls. No matter what anyone else says, driver has the ultimate power of taking things their way. 
• Navigator is helping the driver. Navigators can be well versed in the big picture not paying attention to the road, or know the details of the road and help step through the route in an optimal way. In traditional pairing, navigator reviews. In strong-style pairing, navigator controls the high level choices with words. 

If you had a backseat driver in the car, that person would be like a navigator, but operating without consent. That person could be very engaged in the pairing, but their input wasn't welcomed or accepted by the driver. A backseat driver might be exactly like a strong-style navigator. The difference is in the contract, that is often implicit, and the assumed power difference.

In the workshop some weeks ago, I also ended up pairing with someone I had not paired with before. It was their computer, and they used Vim - effectively making me feel unwelcome on the keyboard. I did not leave half-way through hand quite enjoyed the session. Looking back, we ended up with strong-style pairing where I would actively suggest ideas. 

The more I pair, the less the difference of traditional / strong-style makes sense. But in starting, it meant the world to me. And in continuing long-term, I realize that strong-style also made me uncomfortable many times, pushing a power differential I did not consent for. 

Having both in the bag is good. The lesson here is that you should take a moment to negotiate the pairing contract. Especially people who have hard time connecting to the other on emotional level and hearing when words are not used, strong-style can become an act of forcing your opinions over the other just as hogging the keyboard in traditional-style would.

The difference between a backseat driver and strong-style navigator is consent and trust. The first delivers unwelcome guidance and the latter provides instructions asked for, on a level they are able to and that they find necessary.

And since mob programming relies on strong-style pairing as it's mechanism of connecting the group, imagine having whole car full of backseat drivers... That could be very uncomfortable. 

Pairing and Mobbing are not the only ways to collaborate

A friend I enjoy connecting with on testing themes sent me a message today. They expressed they had enjoyed my pair testing article on medium, and had an idea they wanted to contribute on type of testing I had not addressed.

This was a form of collaboration where two people (a pair, you may say) worked on two computers, side-by-side on the same task. The two might be intertwined in the activity so that one looks one end, the other another end. And it is very much collaborative. They suggested this would be a model of pairing with two drivers, both with their hands on the keyboard - a separate one though.

In my article, I introduced the traditional style pair testing, where often the navigator would be making notes, deciphering what was going on with the driver who had control. Nothing says the second person couldn't be taking those notes on a computer, but what typically happens is that the notes, in comparison to strong-style pair testing, are of a private nature and don't always reflect what was going on in a manner that is shared between the pair.

Similarly, here with two computers and testing side by side, we can figure out many ways to still work in a very collaborative manner.

I find myself often testing in ways where there is two or more testers in the same space, at the same time, sharing a task while we still are not mobbing or pairing. It's more about sharing energy, and enthusiasm, giving hints of things others can pick up and run with, and continuously coming back together to understand where we are.

I tested that way today with a developer, over a teams chat. We would be calling out our progress and observations, pondering on things that did not work out quite as we thought. The chat version works when people are active in sharing. I absolutely adore this dev for the way he is transforming the team now from his position of seniority, and driving collaboration without pairing forward.

In the past, some of my most fun days have been when we work side by side with other people, testers and developers, growing ideas and solving problems. While formal pairing and mobbing are great and give a structure, the other ways of working together also beat the "alone in a corner" any day. Some tests require many computers, like the test at Finnish Parliament where they had to bring in 200 people serving with the Finnish military forces to control 200 devices, for one test to be completed.

No matter what, we should be learning and contributing. Work is so much fun, and it makes no sense to dumb or numb it down. 

Power dynamics in pairs and mobs

Four years ago, I wasn't pairing or mobbing. Frankly, I found both of those intimidating. Instead of expressing that I was scared, I talked about needing alone time, being introverted and not being able to think when others are too close.

I came back to think about all this today for a great thread of power dynamics in pair programming and TDD from Sarah Mei.

More on why agile/XP so often fails heterogenous teams (started here: https://t.co/DajwJ71IwP) pic.twitter.com/rgnIXK0M66

— Sarah Mei (@sarahmei) April 30, 2018

If you ever get a chance of watching a mixed gender group of teenagers, you see some of the gender-based power dynamics at their worst. Teaching programming to teenagers in a mixed group results in the girls giggling, downplaying their abilities and focusing on letting the boys shine. It's easy to think of this as characteristic of the girls up to the point you teach the same girls in a separated gender group. The girls are still bubbly, but now concentrating and doing their best. And their best is often much better than the best in mixed gender groups in general.

The problem isn't men's fault, it's structural. Years of belief systems on how men and women interact. And for women in IT, it often takes years (or a lifetime) to overcome the structures that keep them listening rather than contributing. That keeps them apologizing. That causes them to feel they are not good enough.

We see the same dynamic in conferences. We have loads of speakers who are identified as men. We have all male lineups. And when we talk about including women, we hear that we cannot lower the bar. Yet for conferences doing good work on inclusion and blind review, the shortlists end up being very equal or women dominated. There may be less of women, but quality they produce seem to not lower the bar, quite the opposite. But to get considered, you have to listen to some people's hostility in assuming that you're not up to the bar.

Four years ago, I started first mob programming and then pair programming (and testing). I still think of mobbing as the gateway to pairing in situations where the power dynamics are hard or next to impossible like in my team. Imagine having to pair with a man who tells you "women only write comments in code". The pain of having to sit with that person, alone, is enough for many women to walk out. Their attitude shows in the mob too, but a group of people can help moderate, correct or even punish in ways that an individual on the lower end of the dynamic cannot.

I also remember well the first time I paired with a friend. This is a story we've told many times in our shared talks, yet it was a story that I would have never shared unless we ended up working on a share talk. I came back to think of this time for one of the Sarah Mei's subtweets:

Pairing has nothing to say about how to structure an interaction to avoid taking unfair advantage of power dynamics. One of its basic assumptions is that everyone feels empowered to contribute.

When this is true, pairing is amazing. When it's not, it's a nightmare.

— Sarah Mei (@sarahmei) April 30, 2018

We had agreed to pair on exploratory testing a new functionality added to the software I was working on.  So we sat down together, I guided him first to get to the functionality just to see it was there. The functionality included a new dialog, and as it popped open, my first words were "I wonder what size it is...". It wasn't intended a question, but very much taken as one. What I meant is that we have an agreement on the resolution where things still must be usable on the screen without scrolling. We were clearly on a higher resolution, and still the dialog was big and clunky. But before I got in another word, the friend picked up on the cue and started showing me tools that enable me to measure the dialog size in centimeters, pixels you name it.

I didn't even understand right there and then that I was uncomfortable. That I felt overridden. That none of the stuff I was trying to show - my work in exploratory testing - got done. Moreover, I'm sure I acted like one of those teenagers, just telling myself that my contributions weren't expected for real. I tried enjoying the results we ended up with, not miss the results that were hijacked from me by a power dynamic.

After this experience unfolded in prepping the talk, we have had great pairing sessions and learned to explore in a pair and mob a lot better. He actively worked against the power dynamic, paying attention to listening instead of talking over me, thinking their way is always correct.

Thanks to Sarah Mei's tweets, I remembered again how far I've come. And how far there is still to go now that my whole team is expressing openness to pairing - finally after 1.5 years.

1 reply28 retweets107 likes

Grow your Wizard before you need them

Making teams awesome is something I care deeply for, so it is  no wonder that discussions I have with people are often on problems around that. Yesterday again I suggested pairing/mobbing at work to receive cold stares and unspoken words I heard in the last place I worked: "You are here to ruin the life of an introvert developer". I won't force this on people,  but they can't force me not to think about it or care about it.

As I talked about the reactions, and was pointed out a story he has been talking about many times before. And with "just the right slot" in my calendar, I go and write about it. Someone else will probably make an awesome video when they get to it.

Some of us have some sort of history with computer games. Mine is that I was an absolute MUD (multi-user dungeon) addict back in the days, and I still irregularly start up Nethack just for nostalgic reasons. In many of these fantasy game types, we fight in teams. And we have characters of different types. If you play something that is strong in the beginning, you survive early on more easily. The wizards on low levels are particularly weak, and in team settings we often come to places where we need to actively, as a team, grow our wizard. Because when wizard grows to its high level potential leveling up with others support, that's an awesome character to have in your team.

A lot of times we forget the same rule goes around growing people in our teams. The tester who does not program and does not learn to program because you don't pair and mob could be your wizard. At least the results of being invited to "inner circle" fixing problems by identifying them as they are being made feels magical.

Just like in the role plays, you need to bring the wizard fully into the battle, and let them gain the XP, you need to bring all your team members into the work, and find better ways for them to gain experience and learn.

Pairing and mobbing isn't for you. It is for your team.

Pair Testing with a 15-year-old

A few months back, I had the pleasure of working with a trainee at F-Secure. As usual in schools in Finland, there was a week of practice at work with the options of taking a job your school assigns you (I did mine at age of 15 in an elderly people home) or you can find one of your own. This young fellow found one of his own through parents, and I jumped on the opportunity to pair test with him.

At first, he did not have a working computer so it was natural for us to  get started with strong style pairing:

With an idea from my head to keyboard, it must go through someone else's hands. 

He was my hands, as I was testing firewall. And in many ways he was a natural in this style of work. He would let me decide where to go and what to do, but speak back to me about his observations and ideas, extending what I could see and do all by myself. Most of the things we did together were things I would have done by myself. Only difference was the times of going to the whiteboard to model what we knew and had learned, where I guided him to navigate me in the ideas to document very much in the same strong style pairing. As the driver drawing, I would ask questions based on our shared testing experience when he would seem to miss a concept.

His ability to test grew fast. He learned to use the application. He learned to extend his exploration with test automation that existed and play with it to create the type of data we wanted.

My reward was to see him enjoy the work I love so much. His words on the end of our joint experience without me prompting still make me smile: "I now understand what testing is and would love to do more of it".

He joins us for a full month in June. I can't wait to pair up with him again.

Two people who get me to do stuff

Sometimes, I feel like I'm a master of procrastination. For some types of tasks (usually ones requiring me to do something small by myself that has little dependency or relevance to other people) just seem much bigger than they realistically should. I wanted to make note of two people I respect and look up to for making me do things I don't seem to get done.

'I'll just sit here until it's done'

There's a team next door here, that works on the same system but we could easily organize our work so that we don't share that much. I had decided however I wanted to try out running their test automation, maybe even extending that when things I want to test benefit from what they've built. And I got the usual mention: there's instructions, just three steps. So I went and followed the instructions, only to be there in (typically) unlucky day when they had changed everything except their instructions while upgrading their test runner.

So a day later, I hear they've improved the instructions and we're back to just three steps. As I work on something else, I don't really find the energy to go back and see how things are. I gave it change, it did not work out, not like I really need it anyway. So my favorite colleague from that team comes into my team room, with his laptop and sits on the corner of my desk saying: 'Try it. I'll just sit here until it's done'. And I try it, and five minutes later we have delightful discussions on my feedback on making sense of this as someone new.

Thinking back to this, I realize this is a tool he uses all the time. Actively deciding something needs to be done and committing his time to insert positive pressure by just being there. Setting an expectation, and making himself available.

'Let's pair'

Another person takes it further. They volunteers to pair and actively schedules their time to get more out of the shared work. Sometimes their 'Let's pair' attitude feels like pushy, but the results tend to be great. It takes time to get used to the idea that someone is there with you on you doing something you know you sort of could do by yourself.

As one of the organizers for European Testing Conference, they have paired with every one of us. The pairing has both supported timely doing of things, but also created contents we wouldn't create without pairing. On the other hand, it also created schism when the style of pairing was a bad fit.

There was a task that I needed to do, and I was trying to find time in my busy schedules to do it. With him proclaiming 'Let's pair on it', it got done. And while I was sure I had the best skills for the task, I was again reminded on the power of another person on identifying things I could be missing.

From Envy to Stretching

I find it extremely hard and energy consuming to force myself on people who are not actively and clearly inviting my participation. So I envy people who, with a positive attitude just go and do it, like these two people. Recognizing the envy gives me a personal stretch goal. Try it, do more of it, find your own style.

It's not about doing what they do, but knowing if doing what they do would help you in situations you experience. 

Pair em up while they learn!

"But you can't do that", he said. "It's going to be boring", he exclaimed. "You have to give them all their own computers or they won't learn a thing".

With 30 kids in the room, paired up in front of one computer for each pair, I had a moment to deal with a concerned parent who had strong feelings about how kids learn - by doing, not by watching.

"I know what I'm doing", I tried telling him. "I've done this before". "We don't just pair them. Just watch. We do a thing called strong-style pairing". He did not look convinced, but I needed to step out and attend to the class anyway.

We introduced the rules. "Who is in front of the keyboard now? You're the hands only, no thinking allowed. Who is not in front of the keyboard? You're the boss. Use words to say what you want the other to do".

The buzz, the laughter, the learning commenced. And they loved it, being fully engaged as we kept reminding on the rules: the one not touching the keyboard is the boss, and we change positions every four minutes.

The concerned parent seemed happy too. He followed through the session, and I saw him smile too. I suspect that was a meeting with a developer who has either never pair programmed or in particular, never strong-style pair programmed.

This event happened at my work, and the kids were my colleagues kids. The concerned father is not an exception. Adults are concerned when they know how to code on how their kids will feel while coding, because they care.

I've sat through my share of intro events to programming with my daughter. I find that a lot of sessions pair kids (esp. young kids) with their parents, and while they then have a personal tutor, in my experience they learn less.

So I work with the rules: pair the kids up. Parents are welcome to stay and program, but kids pair with kids, adults pair with adults. There's nothing more motivating for kids than realizing they're completing the programming puzzled faster than their parents. After all, collaboration comes more naturally to kids who are not yet worried about "efficiency" - results matter. Us adults should keep that in mind a little more often.

You can't convince me with reason!

At Agile2016 in our session on Strong-Style Pair Programming, we shared a story about inviting trust when pairing. We've been telling a story with our developer-tester collaboration talk too, as it was a very core experience. The understanding of the relevance of what happened has improved since I blogged about it. Actually, it has improved through blogging about it, and making it something to have deep discussions on.

On our 1st Pair Unit Testing session, I was asking a ton of questions. I had this big picture of testing and the application, and I wanted to figure out how whatever we'd be doing would fit into my big picture. We looked at a unit test and were about to do another one, and I insisted on some information I wasn't receiving. I felt frustrated, and was quickly building up to be annoyed. Just when I was annoyed enough to call it a fail to never try something so silly again, they said: "Give me seven minutes". As a grand gesture, he took out his phone and set the timer for seven minutes. I looked at this in disbelief. How seven minutes would help here, there has been no added understanding and making the connection in 15 and we were stuck. I remember feeling almost amused when I decided to humor him and give him the seven minutes - it's not like anything is going to happen in seven minutes anyway!

We strong-style paired, and I shut up. He did not explain anything, but told me what to do and what to type. In seven minutes, it started to make sense. When the buzzer went off, we were not done but I turned it on for another seven minutes as I wanted so see us finish it. And we did.

The lesson is, we could have argued for hours. The answers I was looking for were not deliverable with the lack of experience I had at that time, but there was no way I could see that. My investment of time was about to end to the annoyance. Even if I had put in more time in the discussion, the likely result would have just been that I felt he wasted more of my time. Doing things and making actual progress builds the trust. With the experience under my belt, we were able to reflect on the experience and connect things back to things that made sense to me. I was able to do that by myself, but there were more connections to be made through retrospecting together.

Things like this happen to me all the time. You just can't convince me with reason. It would appear that reasoning is overrated for other people too.

Reason works when you have experience to fuel it. Before that, we easily operate with fears.

Little tricks like 7 minutes of trust can help. I find that working with this is a question of self-improvement. How could I try things more before I make up my mind about them? Go into the experiment mindset, and experience things. Things people suggest we'd do make sense to someone, and your own experience might be just what you need to see how it makes sense to you. 

Thinking at the keyboard in Strong-Style pairing

For the last two weeks, a little researcher in me has enjoyed the opportunity to eavesdrop on two programmers pairing. Don't get this post confused with stuff I talk about when I speak of my work, as for the past two weeks, I've been on vacation. That means I do whatever I feel like, without having to consider what my company expects or would benefit from.

This pair of programmers is an interesting mix. They shared an interest to a problem that needs an open source solution (a testing tool). They are pairing on a problem one knows deeply, and on language the other knows deeply. In fact, the first developer had his first experience on the language three weeks ago in a code retreat trying it out on pairing on game of life.

They pair remotely, sharing voice and screen and I can recognize that they are doing strong-style pair programming, without ever agreeing specifically on the style.

In strong-style pair programming, for an idea from your head to get to the keyboard must go through someone else's hands. A phrase often used around teaching this style is "no thinking at the keyboard" as driver, and this dynamic was particularly fascinating to monitor.

It's clear in this pair that the one who knows the problem deeply is the one navigating - hands off keyboard. This is probably also a result of the fact that he does not have a development environment in the language set up at all, so they will be working on the other's computer. He is navigating by concepts. Also, it's clear that over the two weeks, the navigator who did not know the language before has become very comfortable with the language, picking up ways of how to do the conceptual things as they go on with the implementation.

Listening to them, I feel more that the simplification of saying "no thinking at the keyboard" is harmful one. It's "no decisions of direction at the keyboard". There's plenty of thinking happening, and in this pair, it's very obvious that both programmers bring in a piece of the puzzle and neither could implement the solution all by themselves.

Eavesdropping on programmers also reminds me on the stuff I think while eavesdropping. It makes me generate ideas of what I would test if I would test that stuff. Some of it would be stuff that in a mob I would correct/contribute right away. Others I would intentionally part for later, as I feel they would just divert focus now. 

When two testers meet

Last Saturday, I participated a Code retreat in Vienna, Austria. I wanted to share my favorite moment of the day: meeting another tester.

In a code retreat, we practice programming implementing Conway's Game of Life in pairs with Test-Driven Development and various types of constraints (like data structures, frequency of checking in required, style of pairing). A day fits typically 5 sessions and thus 5 pairs.

I had just finished my first session of the day and a morning break was called, when one of the three women amongst the 25 participants approached me. She had learned that we were both testers, and we set up to pair together on the problem in the next session.

I had great time programming with her. It was one of these experiences some folks tend to refer to as "Reese's pairing" where both parties have ingredients that make the result great but neither has the complete set of things.

** In case you don't know, Reese's are peanut butter + chocolate, an american candy that was advertised as a lucky accident of bringing two great ingredients together to make something even  better. I wouldn't know as I'm neither American or able to each anything with chocolate. 

There were pieces I could bring into the puzzle from past code retreat experiences. With her, I pushed for trying out ApprovalTests and I really liked the way our domain model ended up in the classes. I learned a lot I could use in the later sessions of the day too.

Later in the afternoon, we were sitting with a small group. We got back to the discussion about both of us being testers. My pair was a tester specializing in Java test automation. I was a tester specializing in exploratory testing. What we do for our work has little in common, yet we're both testers to others.  We also work in very different contexts as per ratio of testers to developers and resulting assumption of who would contribute what in the development work.

When two testers meet, it's good to remember that we're not all the same. And instead of us arguing on the essence of which one of us is a true tester, we can just add labels to explain our difference.

Learning from a customer through strong-style pairing

We've been working on a set of features on our product we've labeled around a customer. They're features beneficial for others too, but they're existence is particularly important for one.

At some point of this, we already learned that taking down the distance between the programmer&tester and the customer was a great idea, helping us a lot in solving  the right problem. As often goes, the second hand information was distorted turning it into a feature instead of the need, and the best way to solve the need was altogether a different feature.

With the past learning of direct contact behind us, the product management had no issue with the idea that I would be trusted with getting the customer to use the product too. I was told to write a guideline, and in addition I scheduled a workshop with the customer.

Armed with the goal of knowledge transfer, I asked the customer to share his screen on Skype for me. I walked him through the login, guided him to the library his task was to fill out and made him do the work instructing with my words. I created him an experience of use, and in the end we retrospected for a while on what he learned and found complicated. While observing him as he did what I guided him to do, I learned of a missing feature he never realized to ask for as he even now did not see that was his need. And from our session, he could now do the things that were abstract. The guideline I wrote might be a helpful future reference, but much less necessary having the experience (not a demo) of use under his belt.

Later, I talked with the product manager who assumed I had "demoed the features" and seemed very pleased with the idea that the customer had been my hands on this demo saying he wouldn't have thought to do that. I labelled what I did: Strong-style pairing - for an idea from my head must go through the others hands. The label gave it a place in the ways to do things in the product manager's head, and he said he'd try that too. "Never thought of that", he said. I could feel smug about having thought of it, but the truth is I was told to think of it 1,5 years ago. I too NEVER thought of that before - that the roles in how you pair matter a lot. 

Video: Styles of Pair Testing

After months of procrastinating how hard making videos is, I did one! Very proud of myself, and wanted to share the end result with you.

I already have ideas on how to make this better and how to learn new stuff on making videos. Now that the first step is done, it will be fun to work on an improved version. 

Users reporting bugs

I've had the pleasure of seeing how a friend deals with his open source project ApprovalTests. There's a lot for a tester to learn on the attitude you have towards free labour on your project: encourage it!

Even in closed source project, we have people who are not paid but will contribute to our project. I tend to think of the main group of them as users.

A recent tale of a user

He was playing a popular game, MineCraft, and run into a bug. He isolated the bug and was sure it was one, and decided to go over the lowest level of commitment someone unpaid can have on a project: reporting the problem. The bug wasn't critical for him, but it was not insignificant either. So he decided to contribute some of his time, to help a little.

He found the MineCraft Jira and run into quite a quandary. There were many possible projects the bug could belong to, and instructions disencouraged duplicates. Finding out if yours was in there was already quite a puzzle, but with the work done, he ended up realizing it most likely was not. Thinking he found the right Jira project, he logged an issue with all necessary details of steps to reproduce this.

In two hours, he got a response. Sounds great, right? To his disappointment though, the response was to point him to another project as he apparently had chosen the wrong project to report to.

Being an outspoken fellow, he responded with a kind email suggesting that the company / employee of the company might want to, in future, to consider the answers they give to their end users doing free work for them. Not to say "do more", but to show gratitude on work already done and drive things forward as paid people. That way the user might volunteer time again next time they run into something relevant. The response back was unappreciative, outlining that the employee already did the right thing guiding him to the next project.

As for how the tale ends, the bug got lost. The user never continued to the next project. And most likely won't bother again on spending time.

The contrast to ApprovalTests approach

I've been stunned to learn about how a friend deals with similar cases in his ApprovalTests project. When contacted on a bug, he asks the user for a pairing session. If it's nothing, he gets to briefly meet someone new somewhere. And if it is something, he pairs up with the user, fixing the problem during the session.

Unsurprisingly, he has made friends for life with this approach. He has users who seem to be coming back to report more.  His approach surprises people as it is so rare. But perhaps it should not be.

To get out software to improve, we really need to harness the opportunity and encourage free people to do more work for you. Paid people are in the position to treat the unpaid in a way that encourages their contributions.

I recognize that as professional tester, I hardly ever anymore volunteer reporting bugs without someone paying me for it. I've learned to report bugs as user with "reclamation" added to them, to get proper reaction and compensation for my time in cases of serious issues (2 times tried, 2 times got a discount of the service price I was paying).

Couldn't we treat the users as if we cared since we do? I care enough to take tasks from my internal users and to report back to them. Pairing for fixing with them would be awesome. Perhaps even something to aspire for next.

Four sessions of remote pair testing

Sometimes I feel alone and isolated as the only tester amongst the developers in my team. I start to question my learning, my observational skills and my ability to work with people in general. Pairing up with other testers on an exercise helps with self-doubt. Remote pairing with volunteers has also been a relevant step in my ongoing journey to learn to be a better facilitator and participant in mob programming (testing activities in mobbing in particular).

In particular, after a weekend testing session where remote pairing was a hard experience to deliver through writing and instructions, I asked people from that group to give me an hour to experience it with me.

The setup for pairing was use of my computer, sharing control of it through join.me -application. We would have a Mindmup-document to make notes on. We would have Dark Function Editor as out system under test. And we would have a recon mission, learning what there is that should be tested as our starting task. And we would change who was driving (using keyboard) and navigating (speaking of what to do) every four minutes.

The four sessions I had were completely different in how they felt to do as a pair. The four sessions also had very different outcomes as in the learnings we had on the application within that timeframe.

From the shapes and colors in the mindmaps, you can already see some of the differences. One session was much more attention on the software, trying to understand as much there without making notes regularly. One session was very observant on bugs. Two sessions focused heavily on identifying the  features, noting only occasional bugs. It's hard to do all at once. 

Here's some notes I've written down on the session that I enjoyed the most:

• She made me work on higher level of abstraction, giving me small tasks without details on instruction with instant feedback on correcting if I misinterpreted what she wanted
• We noticed things together, and found bugs in the application I had not seen here
• She knew what she was doing, even if she usually tests backend and logs. 

To contrast to another very output-wise productive session I did not feel at ease with:

• Very focused on what is a bug and knowing the right answer on a product we don't know made me feel like my product, even me, was being criticized.
• Strong assumptions, not testing for what is plausible out of what we think we already know; overconfidence in coverage in short time
• Not staying with the pair but going alone to prepare the data - different idea of working in pair
• As a driver I keep asking "what would you like me to do", "did you notice", "should we make a note of that" - feeling left out. 
• Could not change roles while "in middle of something". 
• Pointed out a type of functionality I had not paid attention to before: tabs.
• Not "pairing" but "working individually with someone watching". 
• Needs longer timeframe to build into collaboration not a skills demo. 

The two others I had not made as specific notes on. I remember really enjoying the flow and ease of one, and enjoying in a very different way with one where we started from basic ideas on how testing works. 

My main lesson: driving and navigating are skills that take practice. I can learn from everyone, but everyone also teaches me very different things about myself. Practicing with different people is good, and a regular reflection on how the pairing makes you feel creates an environment where the experience is going forward. But there's some hard messages to deliver about how you feel sometimes. It's not about getting the most out of the two people, but the best. Both need to be contributing. This experience also gave me a glimpse into the idea why pairing can make people quit: inability to hide while requiring much out of your individual contribution creates extra stress. 

Traditional pairing on adding some Selenium tests

Since my team isn't big on pairing, when I get them to pair, I tend to let things happen as they happen without insisting on mechanisms. Strong-style pairing does not happen naturally.

Today I paired with our summer intern, who's been spending some of his summer getting around our Selenium Webdriver -tests. Pairing meant joining him on his work of today with whatever I could bring into it. And the reason we paired is that I'm an expert in what features there are and how we might know if they work, and he was "out of scenarios to automate".

His computer, his tools and technology, and I was sitting by him fighting sleep. He was very helpful speaking about what he was doing, which is something I've learned not to take for granted. Even though I'm familiar enough with our structure, keeping myself up to date on where he clicked and where he ended up, reading the filenames from the tabs and interrupting him whenever things did not make sense was hard. I was continuously feeling it was too exhausting, that I was not learning as much as I'd like and that I was there just to remind of the scenario we were automating. This was very much traditional style pairing. I could review whatever he was doing. I could contribute and did. I fixed typos and corrected the test naming. I required concepts relevant to the test to be visible in the test and not hidden in the underlying structures to improve readability of the test. I observed the application to realize which wait from our utilities would be appropriate. And I was in control of the test scenario, what happens first and what verifications should be in place. I wasn't useless, but I wasn't as engaged as I tend to be when driving / navigating in the Strong-style.

This however left me thinking: if a non-coder pairs up with a developer, it's easy to imagine they might at first prefer this style. Even if they are asleep most of the time on the details, they are not challenged to actually get into the code. If they drive in strong-style, they will learn to code little by little. The work proceeds slower, as there's more learning going on. If they navigate in strong-style, there's a bit of a confusion on what part is navigating on an abstract level and what part is sharing the navigation with the driver.

So there might be a balancing thing here: how much time are you willing to invest in knowledge transfer in the pairing? Strong-style transfers more knowledge. Traditional style allows two experts of very different fields co-exists and collaborate.

I had enough time to let my mind wonder: for a test that I do manually in 20 seconds, we spent 1,5 hours building the test. And most of the stuff we used was pre-implemented. A big chunk went into finding out what to wait on to avoid Sleeps. I wonder if I will ever see this work worthy of my time within my interests. It bears little to no resemblance to what I know as testing.

Added: 
Hmm, the smell in traditional pairing might be: "I did not have to put in much of my effort and this was not a good use of my time".  

Illustration of traditional vs. strong-style pairing

I'm reading a sample chapter of the book "Pair Programming Illuminated" by Laurie Williams and Robert R. Kessler and on the first example of the sample chapter 13, I pause as I want to share something. Here's the first example from the chapter.

This is an example of Expert-Average pairing. The Expert is the navigator, getting very anxious about the Average guy pondering what to do when driving and speaking out loud. 

This is an example of traditional style pairing. It's described as "One partner, the driver, controls the pencil, mouse, or keyboard and writes the code. The other partner continuously and actively observes the driver's work, watching for defects, thinking of alternatives, looking up resources, and considering strategic implications". 

In this case, the navigator actively observing was also collecting quite a bit of frustration. The given consideration is for the Expert to drive and the Average to learn to ask questions to learn from the Expert. 

This whole scenario would look very different in strong-style pairing in which "from an idea to go from your head into the computer it must go through someone else's hands." The driver is the one reviewing while writing. The navigator is the one setting the direction. 

In strong-style, the above scenario could go like this, if the Expert had the answer all along. 

Donna (an expert, navigating): sum input1 and add it to the average of input1 and divide the average by two. 

Skip (an average programmer, driving): Great, what next? 

If the Expert is in the process of coming up with the answer while the work is going on, the discussion in Strong-style could go like this: 

Donna (an expert, navigating): ...Then we need to do the munge. Input1.munge().

Skip (an average programmer, driving): How do I do that?

Donna (navigating): result = input1.sum() + input1.munge()/2; 

Skip (driving): That seems like it's the general average? 

Donna (navigating): Oh yeah, that's a better name for it. 

The whole discussion above in traditional pairing shows a frustration growing between the pair. The whole dynamics in Strong-style pairing makes the frustration different. You might still be frustrated about not having the answers. You might be frustrated not knowing where your navigator will be taking you. But you are not frustrated looking at the less experienced one dabble for a direction that is right now available in your head. 

I find it fascinating that even the basic practices like pair programming still have fine-tuning to do to make them more effective. And that the fine-tuning isn't at all that obvious.  

Imagine replacing "average programmer" with "brilliant tester who does not code so much". That relationship without strong-style pairing is all about frustration. 

Being a navigator in Strong-style Pairing

...this post continues where I left off with describing the Driver role in Strong-style pairing.

A step back: who should drive and who should navigate? 

You have a pair of people. You are different people, with different ideas and experiences. The two of you are stronger together because you build on each other, and also because each of you have unique qualities. Sometimes the qualities are more of a foundational or long-lasting kind, like experience that does not build up over night or transfer in a few days of pairing. Sometimes the qualities are more of temporary, like one having a rough day just today. 

One of you will take the role of the Driver - the intelligent input device. One of you will be the Navigator, working out the direction you're about to head to together. Which of the two of you should be which?

The first rule on being the navigator would be that whoever has the idea to get on the computer, should navigate. Remember: for an idea to get on the computer, it must go through someone else's hands in Strong-style pairing. This brings quickly the idea that perhaps the more experienced one should navigate. At least first. At least until it's time to switch. You learn very different things in being a driver and being a navigator. 

The dynamic of newcomer and a seasoned professional is interesting. Having the newcomer just drive is already a relevant service for the navigator, freeing you from typing to think on a bit higher level. The information for the newcomer sticks in a completely different way from doing it, hands on the keyboard, than watching what someone else is doing. 

Here's a story that stuck with me about powers of pairing with newcomers from Agile 2015. Someone was teaching his daughter to code by having her pair with him with one rule: ask "is there a test for that?". The daughter would sit and ask that every now and then would ask the question at the right time. Looking at what's going on, information catches on and the questions expand. This style is more of the traditional pairing. Having the newcomer type for you gives a whole other level of learning in strong-style pairing. 

Whoever had the idea of what to do will navigate. When I started pairing on exploratory testing with a developer, I was the Navigator. When I started pairing on unit tests with a developer, I was the Driver. Over time with both tasks, I will take both roles. And I will grow towards navigating so that the first idea that I have that I could navigate us through, I volunteer to do. 

There's three trigger options on change of roles:

• 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".

Regardless of the role you're in, the pair of you should remember to take breaks. Pairing can be very intensive work and outside getting the work done in a pair, you're also responsible for building forward your pairing experience. And that usually works best by inviting for feedback, like taking a small walk around and retrospecting your most recent pairing experience together. 

Navigator: Things to Do

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. 

Three main tasks might sound simple, but there's a bundle of advice to do them slightly better. 

Programming style matters

The style of programming matters. Pair programming would seem to work a lot more fluently if the programming style is consume-first. With this the idea is that you start with an end result at first and then one by one build the things you wish you had in order to have the end result. Consume-first enables the navigator to go immediately, coming up with things to do while figuring things out herself. And the end result and it's division keep a visible checklist of what there is to do to get to the end result. 

Some navigators prefer to work with bottom-up programming style. They build the image of the end result in their head, and feed the smallest possible pieces to the driver, one at a time. In this style, the navigator has a lot more of the information about what we're trying to achieve, leaving the driver to interpret more of why the navigator is having her do things. 

The third style is hardest, when there's no ability to work in small pieces. If the navigator has to figure out the whole thing before feeding driver work, most of the time the driver is paused or participating in design discussions over taking the implementation forward. As a navigator, you're supposed to care for your driver, not just having her type for you. Keeping driver waiting while navigator figures things out by herself isn't exactly the optimal way of caring. Working with partial information is essential.

The abstraction level dilemma

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.

Immediate feedback

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).

Retrospectives

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. 

A Little Lesson on Paired Work

Being the only tester in a group of sometimes not-so-forward-thinking developers can try my patience. With a few more postponing excuses for our autumn-time mob programming, we're still doing solo work. And I'm still feeling the need of connection.

When my developers won't pair with me, I'm lucky to find another developer who will - to learn more about pairing in practice. We spent an hour pairing together in strong-style, with me navigating us testing a new feature of our product. This gives him an opportunity see what I actually do as an exploratory tester and potentially put insights from testing together with ideas of programming to suggest ways to do things better together.

This session was not one of the days on when we'd find stuff to automate. This session was about unbelievable amount of problems at the point when I got my hands on it, and the perceived insanity of not working together better to shorten the feedback loop with my developers.

There was one very small thing that happened during the pairing session.

Paradigm of pairing pushed me to discover more on a tool I had become complacent about. 

We needed to take screenshots of the first of the various problems, and he was about to get to Windows Start-menu to find the snipping tool when I stopped him and navigated elsewhere. I told him to just press print screen -button and could see the argument building up on having to cut pieces of the image later, but he extended the trust to do what I told without explanation - exhibiting wonderful driver behaviour. As he pressed the button, Greenshot on my test machine kicked into play and we could narrow down the screenshot.

Some of the screenshots were just situational pictures without need of explanation, and we could quickly save them to my default location. But others needed information to be added, and we opened them in the editor that comes with the tool for annotation. When we've done our texts and boxes to mark the spots, we needed to save. I insisted on saving through File-menu with the option that saves to default location. And as we opened the menu, his minor hesitance made me pay attention to the keyboard shortcut for that option, which was the usual one for the primary save (ctrl+s).

I've been using the tool for years, but had not stopped to notice a detail that was eating very small bits of my time over and over again, and that there was a better way. He did not know to teach me that, he had never seen the tool before. He did not even directly point it out, but I wouldn't have noticed without him as I wasn't paying attention. Paradigm of pairing pushed me to discover more on a tool I had become complacent about.

This is a great lesson on pairing. There's all these little things that happen in paired work that makes us better. If every day of the year brings one of these insights, we have quite a number after pairing up over time. There's so many chances of learning when working in close collaboration with others, and strong-style pairing feels to be creating a connection enabling this.  

Being a Driver in Strong-Style pairing

...this post continues where I left of with my previous post.

Driver: Things to Do

You are the intelligent input device. What is expected of you except for typing as you're told?

• Push back. Express that you need to modify the way the navigator is navigating you. You may want to change the box in which you work, make it bigger to give you more freedom or make it smaller to be clearer on what to do. You may realise you need to try something else, and express that in questions. Key is to be active even when driving. 
• Improvise. The navigator gives you a box within which you operate. You have choices on how you can do things. You choose what you believe to be nest for context at hand, and driver gives you more detail if she disagrees with your choices. Improvising is about adding your intelligence to the collaboration. 
• Switch level of abstraction. If you feel the abstraction level of navigating could be higher or lower, talk back to the navigator. If the navigator is using too low level, you can give them the higher level. "You can just tell me to run it", when navigator is telling you shortcut in keystrokes. If the navigator is using too high level, you can ask "Tell me what to type?" or "Where's that located?". Change the level of abstraction and enable a common experience of learning to work together better. 
• Ask questions. If you feel something isn't right, ask about it. You can simply go for "Are you sure?" to stop the navigator to think about what is going on. Keep your questions specific so that the answers can be short. You can try validating questions to clarify what is going on right now, "It seems we're using zip-add-object to regulate temperatures, is that correct?". You can check if the thing you did was correct against your understanding: "I thought the database only accepted one connection at a time. Why did we do two?". You can suggest where to go, without deciding for the navigator: "Shouldn't we do this first?". Avoid general why-questions and work to prevent long explanations.
• Initiate role switch on an idea. When you realise what should be done and think you could navigate this task better, initiate a role switch. You can switch roles on idea, without waiting for the timer. Or you could never use a timer and switch on tasks. 

It's good to remember that you as the driver are helping the navigator to navigate. Sometimes navigators will try a general avoidance technique of declaring tasks mundane, and great driver will volunteer to be around even for that task. Sometimes you are just literally trying to go against the excuse. Sometimes the two of you just need to get through the bad stuff together to get to the fun stuff together, to build the long-term relationship. 

Underneath what we actually do as driver, there's a bunch of attitudes to consider:

• Trust your navigator. Stay in the moment. Be ready to work with partial knowledge. Your navigator is probably only one step ahead of you. 
• Just try it. You can always do it both ways and end up with a third that builds on top of both. Learn by doing. Learning while doing is just as important as getting the end result out of the process. 
• Constant self-reflection. Investigate what is going through you. Focus on learning. When following your navigator, you're reverse-engineering. Navigator keeps telling you stuff. You get a very thin, narrow view into the system. You can start putting things together a lot and this gives you a chance to reflect on what you're learning individually as driver with your pair. 
• Patience. Give the relationship time. It's good on  both sides, but it's extra useful on the driver side who works with incomplete knowledge. 

There's two main pitfalls to being a driver. 

• Thinking. You think within the box or change the box. Thinking too far as the driver takes the navigator's focus on bringing you back to the task at hand. 
• Silence. It's not an open box to do anything you think of. If you want to take the lead, switch roles, but try not to run your own way with the silence. 

The pairing experience: foundations

Back in the days when testing dojos were new, I tried some of them. We would pair up in front of a computer to test, rotate on clock so that everyone around the round table got their share of the computer.

I never particularly liked it. I found that people were really bad at explaining what they were doing and that is the key thing I'd want to learn from - ideas that drive them. The roles of driver and navigator split so that the driver tests and talks out loud, the navigator observes, makes notes and adds stuff felt it was not very engaging. Everyone in the room would have a different idea of what was going on at the computer, deciphering most information from actions as people tend to be bad at talking while testing without significant practice.

As I was teaching testing, I adopted free-form pairing into my courses. I'd have people work in pairs, without assigning them roles and see what comes out. Most often I saw one of the people in the pair be active and the other one trying to contribute something, often quietly watching unless there was a specific discussion on what to do.

Then I learned about strong-style pair programming. With strong-style pair programming, the core is that any ideas from one person's head must go through the other person's hands. It relies on the roles of driver and navigator, but changes what each of them is expected to do. Driver is the one who listens and types. Navigator is the one who tells what to do.

In classroom settings, particularly when working in mob (group) format, this style works wonders. You can place the navigator as far as possible from the driver at the keyboard, and everyone can hear what the driver hears. And it guides you to vocalise the core of what we're doing, leaving everyone same experience of navigation as the driver gets.

On way home from Agile 2015,  I collected our ideas about communication in a strong-style pair, in particular as a reaction to many of the issues we see in teaching settings. I've come to realize this isn't programming or testing specific, but it's more about how people work together.

The Story that Triggers This Post

In Agile 2015, I participated a session about unit testing and group learning. The session started with asking for volunteers to join a mob in front of the room, and I was the first to raise my hand as I had promised to model that women could join. Success, we had 50/50 split of genders.

The session was set up with strong-style pairing, with telling driver and navigator their roles. The lady driving first expressed happiness in her role of typist, "I can do that!" and navigator told her what to do word by word, and soon the test was passing. She had just written her first lines of code in her life. With that, the first driver became the second navigator and was soon explaining what the lines of code she was working on would do, just by reading what the English said.

I was third in the queue to become a driver. The third navigator had already been through this before, and he was a programmer, he had already been helping the earlier navigator while he was driving. And when he navigated me, he went to keystrokes telling me what to do. I would have been fine with higher level information, especially since this was not the first time I've seen these Koans.

When I then navigated, I was focused on what level to navigate on, to get the job ("fill in the blanks" as we were doing unit test koans) done fast, as I was feeling slightly annoyed with the idea that I was assumed to need the keystrokes when I was driving.

So the question kept puzzling me: is it better to start your navigation with low-level or high-level? You can say "create a class" or " write 'MyClass VariableName = new MyClass();'". You can say "Copy the text from the file" or go into details of explaining how that happens. And as a woman, I felt particularly sensitive for a level that would be too low. Expressing that idea, I learned I would have been equally uncomfortable with navigation that was too high-level, failing to do what was asked and at worst multiple times in search of the right level.

This and two other posts are about what we learned about Driver-Navigator communication from that trigger.

Driver-Navigator Pairing in Strong-Style

For the pair to work well, both parties in the pair need to work well in their roles, and there's specific skills and techniques you can learn to work better from get-go with a new pair in either one of the roles. Techniques, however, are just ideas until you apply them in practice. Only through doing you can learn to pick up the small hints on what would be right thing to do, as you both are equally responsible for your mutual success.

We may think of the driver as an intelligent input device. Intelligence means that while the driver takes orders on what to do and where to go, the driver can also guide to get on the right abstraction level or improvise within the box the navigator gives her.

The navigator is responsible for mining the to-do list and passing the next things to do with instructions on the highest possible abstraction level.

This all builds on trust. The navigator may be just one step ahead of you, and thus unable to give you a clear overview of what you're about to do. The direction the navigator is going to is where the driver goes. When the driver has an idea, the roles can be switched keeping the basic rule in mind: for an idea to get on the computer, it must go through someone else's hands.

Next post up: Things to do as the Driver.