Hey there, news-letterers. I’m Nat Bennett, and I only occasionally want to throw all computers into the ocean. You’re reading Simpler Machines, which for the next few weeks is going to be all pairing, all the time, because Andrew Edstrom and I are working on a video course about pair programming. Yesterday we recorded the majority of it, so that should be getting edited and posted over the next few weeks.

This particular course is only a few hours long, and it’s aimed at moderately experienced developers who are trying pairing for the first time, so we’ve had to cut a lot of more advanced or esoteric stuff. We had to cut one of my absolute favorite darlings: OODA loops, and how you can apply them to create better pairing experiences.

Ever had one of those pairing sessions that just… didn’t work? Maybe you were sitting there watching your pair type all day. Maybe you were the one typing, waiting for your pair to just say something. This kind of pairing sucks, no matter which side of it you’re on. Instead of bringing two minds together to create something that neither person could do on their own, one person is dragging the other along, and both people are having a worse day than they would have soloing.

Luckily, United States Air Force Colonel and military strategist John Boyd has a solution. Boyd developed this great concept called an OODA loop. It stands for "Observe, Orient, Decide, Act." It's a model of how air combat in particular and conflict in general work, but it’s secretly also a model of how pair programming works.

First, you look around at a situation. Then, you figure out what you're seeing. Next, you make a decision about what to do. Finally, you act on that decision. Then you return to beginning of the loop, because the situation has changed.

Your enemy is also moving through this loop, and it interacts with yours. If you can move through the loop faster than your enemy, you have an advantage. You can change the environment before they've had a chance to act, forcing them to spend more time observing and orienting, or making their decisions worse.

If you can move through the loop fast enough, you can "get inside" your enemy's OODA loop, and make it impossible for them to make good decisions. By the time they get to "Decide" your actions have rendered their mental model of the world obsolete.

This is great if you're dealing with someone who's trying to kill you. You can use it to overcome some major disadvantages in raw power with enough speed.

It's a lot less great if the mental model that you’re invalidating is your pair’s mental model of the codebase you’re both working on.

See, it’s possible to “get inside” your pair's OODA loop. If you're able to orient yourself in a codebase much faster than your pair, and you're making, or directing your pair to make, changes to that codebase, you can put them into a state where they will never be able to catch up with you and start contributing ideas to the session. Your changes will keep bouncing them back to "orient," over and over and over again. Worse, if they do make suggestions, those suggestions are likely to be terrible in ways that are obvious to you, because they're based on a model that's much less accurate than yours.

So then you're in that terrible soul sucking pairing nightmare: Spending hours annoyed that your pair is just sitting there, watching you. (Maybe you give them feedback that they should be more proactive while you're pairing together.) And your pair is equally frustrated, and maybe starting to wonder if this coding thing was all a terrible mistake, and they should maybe move to the mountains and build a boat or something.

The solution, if this is what’s happening, is to synchronize your OODA loop.

For the “faster” pair that means slowing down and checking in with your pair more. Ask them to explain the problem as they understand it before you start figuring out how to solve it. Encourage them to stop you and ask questions if they get confused. Handing the keyboard off can help. So can taking more frequent breaks. I’ve seen folks go so far as to physically unplug their keyboards to stop themselves from taking over the controls.

(I’ve personally used my dog as a mutex for this purpose: Me and my pair handed him back and forth as we took over the driver role.)

If you’re the slower pair, though, you probably need to speed up. There are three ways to do this: Improve the speed at which you orient in a codebase, demand more time to orient in the codebase, or decrease the resolution of the model you need to make decisions.

Speeding up your orientation phase mostly comes down to practice, and it’s a slow process. More productive in the short term is to demand more time to orient, and decrease the resolution that you need to move from "orient" to "decide/act."

"Demanding more time to orient" means stopping your pair when you don't understand what's going on, asking questions, reading the code, and asking for the keyboard more. This is often uncomfortable, especially if it doesn't come naturally, or you're regularly the more-confused person in the pair, but it's really important to pairing effectively.

(As an aside: Managers, this is why it's really important to put new people onto pairing teams regularly. Intermediate folks need the opportunity to be the more experienced pair in order to stabilize what they're learning and secure their position socially on the team. One of the ways to do this is team rotation.)

"Decreasing the resolution of the model you need to make decisions" is a fancy way to say "make more guesses and try more stuff you're not sure about." Basically, apply the Frizzle Principle. "Take chances, make mistakes, get messy!"

This is the approach that has made the biggest difference for me personally in improving my own execution speed, both in and out of pairs, and I'll be writing about in more detail next weeks. In the meantime, please let me know if you've got any pairing questions, problems, or topics you want me to cover. It's going to be all pairing, all the time around here for the next few weeks.