Dive 23: How to avoid backseat drivers
Hey, it’s Alvin!
Over the last decade of software development, I took part in a fair share of pair programming sessions. Pair programming is where two programmers work together at one workstation. The “driver” is at the keyboard, and the “observer” is watching what’s happening.
When pair programming goes well, both parties learn and grow together. When it doesn’t, it’s an unbearable waste of time. Having experienced both ends of that spectrum, I found that pair programming works better when neither party exerts authority over the other. For example, sometimes it helps if both parties face the same amount of uncertainty ahead.
This extends beyond programming to any situation where you’re working with another person towards a common goal, and one of you assumes the lead. For example,
Maybe you’re, literally, a driver, and your passenger is critiquing you constantly.
Maybe you’re cooking a meal, and your partner is keeping an eye over your shoulder.
Maybe you’re travelling with someone, exploring a new country neither of you have been before.
Let me share with you 3 example interactions I had while pair programming to show you what I mean.
1. The Backseat Driver
(Where there is unequal authority, done poorly)
Brandon: You can drive. Start with the function.
Brandon: Remember to declare the variable.
Dave: Like this?
Brandon: No, further down.
Brandon: Just before the if-statement.
Brandon: I would add the for-loop while you’re here.
Brandon: Yeah, you’re gonna need a counter.
Brandon: Just declare another variable.
Dave: Like this?
Brandon: No, just…
At this point, either Brandon will ask to drive, or Dave will ask Brandon if he wants to take over.
This is not pair programming. It’s an utter waste of time.
It doesn’t have to be, though.
If you want to avoid being like Brandon, the backseat driver, it helps to develop some self-awareness. Recognize how often you’re directing the driver. Does the driver seem confused or lost constantly? Are you feeling an increasing sense of frustration that the driver isn’t doing what you want? If so, you’re probably backseat driving.
What makes this such a failure is that Brandon already has a clear idea what he wants to do, while Dave has no clue. From the start, it made more sense for Brandon to drive while Dave observes. Of course, Brandon and Dave could have discussed the details of what they wanted to do before they started. That way, Dave would have a clear idea of what he needs to do, and both would be on the same page.
Now that the backseat driver is in the driver’s seat, a new dynamic has emerged…
2. The Teacher
(Where there is unequal authority, done well)
As a student, I cherish moments when I can watch a sensei masterfully execute their craft, especially when I have no idea where to even begin.
The way to make the most of this situation is to observe all the subtle actions of the teacher. Try to think along, and always seek to understand why they’re doing what they’re doing. Ask lots of questions early and often to learn as much as possible, just like the way I described in Dive 10.
As the teacher in the situation, the goal is to get the student confident and capable of taking back the steering wheel as fast as possible. To get them to think along, it helps to verbalize what you’re doing as much as possible. As someone who doesn’t “talk to think,” I find it’s challenging to talk while typing or even just thinking out loud. But I find even some running commentary is better than nothing.
Check in with the student often. Are they following along? Do they understand what’s happening? If I feel the student is mentally checking out, I’ll ask them for input on some decisions to get them more involved, like a good Socratic mentor. Explore solutions to problems by bouncing ideas off each other.
Focus on learning, rather than getting the job done.
This means the teacher should leave plenty of time to address questions along the way.
The teacher should also gauge the student’s confidence throughout. When the student seems confident enough to take the steering wheel, put them back in the driver’s seat.
To avoid or minimize backseat driving, I find it helps to set all expectations upfront. Then, as the teacher, I let the student do their thing, commenting only on major, fundamental errors that need correcting right away. Note minor errors but save them for later.
The goal, now, is to get the job done. A sense of completion will give the student a sense of satisfaction and confidence. Go over the minor errors at the end to be fixed for a separate iteration.
So, this is one form of “pair programming,” but it’s not the best because one party generally benefits way more than the other.
3. The Partner
(Where there is equal authority, done well)
The best scenario for pair programming is exploratory.
It’s a scenario where both parties are facing something new to both. Neither party has authority over the other because the road ahead is equally uncertain and unknown to both.
It’s sort of like exploring a country neither you nor your partner have been to before. Each of you might have different ideas on how to get to a destination. So, those will be opportunities for you two to discuss the best routes, deciding, then working together to get there safely.
In the world of software development, that could mean two developers exploring a new technology together. Help each other learn how it works. Discuss how it can solve a specific problem. Then, collaborate to get a proof of concept working.
Because this situation puts both parties on even ground, it’s not about one person looking down, or over the shoulder of, the other. It’s about exchanging ideas and helping each other when stuck with a problem.
This is the true spirit of teamwork—achieving something through collaboration that you can’t achieve on your own. Everyone benefits.
Like all tools, pair programming is only beneficial when used correctly, and offers more benefits in some situations more than others. It’s most valuable when both parties are an equal ground, exploring the unknown together in lockstep.
I hope you enjoyed this dive Below the Surface of pair programming. Reply to firstname.lastname@example.org if you have questions or comments. What were your pair programming experiences like? How did you deal with backseat drivers of the literal or figurative variety? I’d love to hear from you.
Thank you for reading. Have a wonderful day. And I’ll see you in the next one.