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.

» read the rest of this entry »

A portrait of Malcolm Ocean

I'm Malcolm Ocean.

I'm developing scalable solutions to fractal coordination challenges (between parts of people as well as between people) based on non-naive trust and intentionality. More about me.

Become more intentional
Check out Intend, a web-app that I built to help people spend their time in meaningful & intentional ways and be more playfully purposeful. Intend logo
Connect with me on Twitter!