Pair Debug to Understand, not Fix

[Vaniver]

I’m an adjunct instructor at CFAR, but this is my opinion, not CFAR’s.

At CFAR, one of the exercises is ‘pair debugging’; one person is the protagonist exploring one of their problems, and the other person is the helper, helping them understand and solve the problem. (Like many things at CFAR, this is a deliberate and distilled version of something that already happens frequently in normal life.)

This used to have a different frame; we used to talk about the debugger and the debuggee, the person solving the problem and the person who had it. This predictably led to problems, because the frame mismatched what it actually meant to do the task well. This post is an attempt to point at the difference between the two, and why I think it’s important to lean heavily towards the ‘understand’ side. There seem to be two broad clusters of reasons, which I’m going to label “model-based” and “social.”

image taken from here

“Root cause analysis” is the term we’d use in industry, or “five whys.” The point is that when you explore an issue in the right way with sufficient depth, you come up with a better solution; not to the immediate situation in front of you, but the entire class of situations that are caused by the same root cause. One of the pieces of advice that Duncan, CFAR’s curriculum director, gives is that the worst success at a pair debug is you solving their problem for them. The best is that by the end of the debug, the two of you aren’t the sort of person for whom that type of problem could happen anymore.

That is, someone else having a problem isn’t just a task to be done and forgotten about; it’s an opportunity to learn about how their mind works, and how your mind works. I think one of the things that’s helped CFAR instructors ‘level up’ is both getting rich models of how other people think, but also exposing lots of their own models and how they think. (“Oh, in this situation I would do X, how do I explain X to someone else?”)

It’s also often the case that the original frame for a problem is not one where the right solution is readily apparent. (If that were the case, generally the solution would have been implemented already!) Exploring a problem and uncovering other frames and perspectives can help discover the ontology in which the solution to the problem is obvious and exciting.

It isn’t about the nail—it’s about the reasons underlying the nail still being there.

The second reason is that by trying to understand the other person, you actually establish a connection with them; they get to be heard and seen instead of manipulated like a math problem. Oftentimes, that’s the actual function of discussion about problems—social grooming and shared vulnerability. (Compare to the claim that “what are you doing?” is often code for “can I do that with you?” instead of “please explain it to me.”) This one seems harder to elaborate on than the model-based version, but is nevertheless as (if not more) important. Responding positively to others being vulnerable with you leads to more vulnerability, which can lead to them discovering the right frame or acquiring the resources they need in order to embark on a solution.

[alexei]

Also asking “how do you feel about that?” helps, although might come off a bit psycho-analytical if asked repeatedly and directly.

[Ben (old)]

Yes! I often put this lesson down in my top three most useful things learned at CFAR.

In the pair debugging sessions, if I came up with a solution to my partner’s problem, straight up presenting the solution rarely worked (it was often wrong in some way, and then we were conversationally a bit stuck). However, when I asked leading questions around where I thought the solution could be (e.g. “Is there a way to remove subproblem X?”), they found it themselves, or sometimes better solutions.

I now make it my goal to understand their problem and its different parts, rather than to solve it, and this allows they themselves to generate the best solutions.

[Dr_Manhattan]

I think this http://​​lesswrong.com/​​lw/​​9v/​​beware_of_otheroptimizing/​​ is a large part of it, you need the other person to be part of the process to avoid the failure mode.

(But also, I think it’s healthy to develop relationships with specific people who can give you “unsolicited” feedback/​observations. True they’re going to be less nuanced and maybe off-base, but too much value could be lost without being open to these, we’re frequently too blind to our own behavior)