Why do you ask?

(This post starts with a technical example, but it’s not about the technical stuff so don’t worry about trying to understand the details.)

The XY Problem

A friend of mine reached out to me earlier today, with a question about trouble she was having while coding something. She’s working in NodeJS, which I’m really familiar with since it’s what my productivity app, Complice is built on. “I’m having this problem with doing GET-requests… I can’t get them showing different things based on the url…”

A few sentences later, when I still didn’t really understand her problem, I said, “Hang on. Let’s back up—what is the user trying to do here? Like what’s the point of this page?”

She said something like, “so it’s like, they’re trying to load the data, but when they bring up the page, I can’t specify exactly what data they want.”

“Nonono, back up. I still don’t know what problem you’re solving for the user of this system. What’s the user trying to do?”

When you’re stuck on (or in) a problem, it can be easy to end up with a really narrow view of what you need to do to solve it, becoming overfixated on a given intended solution and focusing all of your questions around that solution, rather than around the original problem. This can happen on the scale of a day’s debugging, or on the scale of an entire startup.

It took me several more times of asking before I finally got my friend to back up far enough to talk about the situation from the user’s perspective, and once she did, she was suddenly like WAIT! and then came back a few minutes later with the solution.

As I had predicted, the biggest hurdle to her figuring out this problem was an assumption that she was making. I actually still don’t know what that assumption was. It would have also been possible for this story to end with her stating one of these assumptions, which I would have then overturned. But she ended up realizing it all on her own.

Stack Overflow, a Q&A website for programmers, calls this whole thing the XY Problem: when the asker asks about their attempted solution, rather than about the original problem they didn’t know how to solve.

Debugging communication

And this isn’t unique to programming.

The experience I had, where my friend’s question struck me as sufficiently odd that I figured she was probably making some sort of incorrect assumption, is one that can show up in just about any context.

A month ago, I observed that my mentor, Jean, would regularly respond to my questions (about her, or about the ecosystem we live in) with “Why do you want to know that?” She would say it in a tone that was some mix of skepticism, confusion, and amusement. Sometimes, this question reminded me of times when people have asked me the same question (with a similar tone even) because they weren’t sure if they trusted me with the answer.

This, I knew, was not what Jean was doing. She asked me why I was asking, to try to get a better sense of just that: what question exactly was I asking? For one, this would give her a better ability to respond to my actual curiosity rather than just to the first phrasing for it that came out of my mouth. This, we might note, is the exact opposite of what politicians stereotypically do: they interpret questions as a chance to make prepared talking points that may have little to do with the question asked and even less to do with the curiosity that prompted the question.

The second useful effect of this curious inquiry into the reasons for the question is that it could start to unearth the assumptions I might be making in asking the question, so that she could make sure not to accidentally reinforce them in her answer.

Mu (無, not μ)

Have you ever heard the question: “Do you still beat your wife?”

It’s one of the classic examples of a loaded question—”loaded” here refers to it carrying the additional load of an assumption: that the askee at one point did beat their wife. It might also be called a trick question, because it appears to be a “yes” or “no” question and yet either of those answers still affirms that assumption of wife-beating.

A third option is given by the answer “mu”. Originally appearing in Buddhist koans, it was taken in the 1970s by Pirsig (Zen and the Art of Motorcycle Maintenance) and later Hofstadter (Gödel, Escher, Bach) to mean concepts such as:

• un-asking the question
• indicate the question contains some fundamental flaw
• rejecting the premise that a dualistic answer to the question can be given

Example usage, hugely biased towards the kinds of things in general that I would say “mu” to:

• “What’s your star sign?” “Mu”
• “So who’s really to blame here?” “Mu”
• “Are you pro-Israel or pro-Palestine?” “Mu”
• “So I’m trying to figure out… am I an angry person?” “Just mu that whole question.”
• “Are you religious or atheist?” “Mu”
• “So is she your girlfriend?” “Uhhh… mu?”

So “mu” is a great defense against loaded questions. Well, aside from the fact that you’ll probably have to explain what it means. But it’s a useful concept to have around anyway, because in some cases the assumptions in a question are really subtle. It’s not that by answering the question you’d agree to some point of fact, but just that the question appears to be framed in a way that means that any answer you give is likely to be misinterpreted or miscontrued, into something that you don’t mean.

Afterthoughts

In general, I recommend the “why are you asking?” approach for cases where the issue is minor, or where there mightn’t even be a misunderstanding but you want to make sure. For questions where you just have ambiguity in one or two words, you might just taboo those words to get clearer about what’s being meant. “Mu,” though, works really well when you’re quite confident that the framing isn’t one in which it makes any sense at all for you to engage with the question.

As I relayed the first story, I found myself noticing that I was also asking questions to my friend, without explicitly stating my reasons for asking them. This prompted me to wonder if there mightn’t be a meta version available: where she, encountering my, “wait, what’s the user trying to do?” would ask (at least herself, if not me) “why is he asking me that?” Another option would have just been for me to take an extra sentence or two to explain my reasoning for taking that approach.

It seems that either of these might have expedited the problem-solving process substantially. Either the questioner or the questionee (or, for that matter, a third person listening) can take on the role of attempting to really get at the core of the curiosity.

If you found this thought-provoking, I invite you to subscribe:    

Leave this field empty if you're human: