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
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.
Also asking "how do you feel about that?" helps, although might come off a bit psycho-analytical if asked repeatedly and directly.
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.
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)