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.