The Psychology of Pair Programming
Behaviours and skills exhibited by the very best pair programmers.
Dr. Sallyann Freudenberg is a software engineer and psychologist who has spent some serious time observing the behaviours of high performing software teams. Her blogs contain a wealth of information for any software professional looking to sharpen their skills.
As an engineer with no psychology background whatsoever, I couldn’t help but think — this is some really, really good stuff. It’s accessible, easy to understand and clear. I thought… perhaps I’ve picked up the wrong career? Maybe I’m a psychologist! So I read a little Freud and oh my god the horror, so I’m definitely still an engineer and have no interest in psychology any more. Also I can’t look my mother in the eye.
Anyway, after many hours of repetitive strain injury-inducing labour, here is what I have produced. A collection of tips, based on the work of Dr. Freudenberg. My hope is that you’ll use this as a primer, an appetiser if you will, before diving into Dr. Freudenberg’s work and developing a more full understanding. Let’s get started.
Take Regular Breaks
Easy one to open up with. I know I sound like your mother when you were young. She warned you against square eyes. Well she was wrong about the square eyes thing but she was right about taking a damn break once in a while.
Regular breaks are well understood in psychology. In the context of pair programming, they:
- Prevent context from building up too much. Breaks break things up.
- Lower the cognitive load and enable longer overall pair programming sessions.
- Make you happier!
Of all the basic sins I see, this is the most common. Five hour meetings with no time budgeted for breaks. “Powering through” isn’t always the answer. Sometimes, going for a coffee or a beer (depending on how stuck you are) can provide the answer too. If you’re interested, there is a brilliant book about slack time that gives a much fuller answer to this topic.
Push the keyboard, don’t take it
The keyboard, in Dr. Freudenberg’s research, was the physical component of control. Engineers would pass the mouse around freely in Canada, but the keyboard was held sacred. In high performing pairs, the driver would volunteer control of the keyboard. It would never be taken. From this, we can glean a simple rule for both the driver and the navigator.
The Driver — learn when to pull over.
The example from Dr. Freudenberg’s research illustrates this.
Example 1 (Anna is navigating, Ben is driving):
Anna: “If you…..go to….”
Ben: (sliding the keyboard over to her) “(You) drive….it’s easier”.
The driver is aware of the most effective way to communicate and is happy to relinquish control when needed. Don’t let your ego cling to the keys. Hand it over when necessary.
The Navigator — don’t disempower.
When you’re watching, watch. Drop hints, be friendly, but don’t force control out of the driver’s hands. It creates resentment. Treat that keyboard carefully.
The driver is often seen as the position of power in the pair, but the navigator has the ability to derail the whole exercise by hijacking the keyboard when things get tricky. With great power comes great responsibility.
Have somewhere to draw.
A whiteboard is the gold standard here. A nice, big, clear space to draw all over. Words are great and all but nothing beats a bunch of wonky boxes and not so straight lines.
In Dr. Freudenberg’s research, a key finding was the use of scribbled on diagrams in high performing pairs. The creative act of writing the diagram sparks thoughts and jogs memories. They were far more powerful than pre-existing diagrams, which seemed to be more useful when seeking a holistic view of multiple teams and systems.
Sometimes things are difficult to convey without a hastily drawn picture. If you don’t have a whiteboard, use a notepad. In one example, Dr. Freudenberg observed someone tracing a diagram with their finger. Drawing sparks joy people!
Invite spontaneous outside help
So there you are, working through a problem. An API that needs consuming and saving into a database. You debate, discuss and start writing. Nothing is working and you don’t know why, but if you can just focus… just a little longer. A few more uninterrupted hours.
Then… Bill from the payments team leans over and asks you about something you just said.
But Bill has got a good point.
“Hey, that endpoint actually uses a different model to the other APIs”, Bill mutters, acutely aware of the thunderous look in your eyes. You could be mad at Bill, but the truth is, he was right to stop you. You were about to write some broken-ass code. Is Bill the enemy? No. Your way of working is.
Interruptions are going to happen, especially when you’re building the wrong stuff. The truth is, Bill just saved your bacon. In Dr. Freudenberg’s research, this kind of open communication was welcomed by high performing pairs. It increased knowledge transfer and made for a much more efficient pairing.
So go apologise to Bill. He just saved you a bunch of time and fresh grey hairs.
Preserve Context
The problem with the previous scenario was the context. Maybe Bill could use some personal boundaries training, but if it wasn’t Bill, you know it’d be Sandra from the Ops department. Bloody Sandra…
That complex clockwork of context in your minds eye is only available in your living room. In the workplace, you’re gonna need to talk and not always on your own terms. Dr. Freudenberg explains that software engineers need to operate at multiple levels of abstraction at the same time, constantly flitting in and out of levels of detail. This creates problems when building up large, complex images in your mind. How do the high performing pairs deal with this?
Lists, you silly goose
The key is to keep focused on what you’re doing. When you find new things, put that down in writing. The items in the list form little flags, reminders of questions and facts you’ve unearthed. This means you can remain focused on the problem at hand and not lose track of the discoveries you’ve made along the way.
The next time James from HR comes in to tell you to stop high fiving strangers in the lobby, your context won’t be obliterated. You might be slowed down for a moment, but glance down at those sweet lists. You’re back in the matrix.
And one more thing about lists
Before you go all sharpie-pro on your checklist, Dr. Freudenberg has one more finding. More often than not, lists are not revisited. They’re written and discarded. It’s essentially just a bit of ephemeral storage for your brain. Don’t worry about neatness. Worry about getting your ideas on to something more permanent than the jelly in your head and protecting the current object of your focus.
Share the burden with tag team pairing.
Coffee number seven. This damn test won’t go green, no matter what you try. You decided to swap when it did, so you’ve been driving for well over an hour. You’re tired, your partner is bored and progress has all but stopped. Soon, you’ll go home and drink whiskey like any 90s American action hero.
We’ve seen this a thousand times. Individuals investing too heavily in the problem and refusing to review their goals. Often it’s pride, sometimes it’s sheer belligerence. To combat this, Dr. Freudenberg found that as well as specified goal points, high performing pairs would “tag” one another in.
This makes intuitive sense, right? In the ring, if Stone Cold Steve Austin is growing tired, you know he is gonna tag The Rock in (my wrestling knowledge is pretty out of date). If you’re running out of juice, it should be a legitimate reason to change drivers. Don’t trip and fall into the death march.
Follow Dr. Freudenberg on Twitter! I do and you should too. Also, the source material for this article (including all relevant academic sources) is available on Sal’s wonderful blog.
While you’re at it, follow me on twitter. I’m regularly blogging about the work of other, smarter people.
