Hacker News Reader

Comment by bena | Hacker News Reader

People who descend into this are kind of missing the point of the XY problem in the first place.

The XY problem is to get all parties involved in thinking about the actual goal and how to achieve that goal. By presuming you know what the Y is already, you're kinda falling to the XY problem yourself.

Very rarely do we need to, for example, draw a square for the sake of drawing a square, there's usually a larger problem we're trying to solve.

Using this: https://news.ycombinator.com/item?id=10024188 as the example.

None of those responses is actually relevant to solving the XY problem (if it exists). The user wants to draw a square with HTML Canvas. Before suggesting any course of action, we need to know why he wants to do that.

View on HN

The amount of information needed before answering a question can and should vary depending on the question itself, depending on the context. There is zero harm in giving an answer about how to draw a square with HTML Canvas, even if the asker actually has a different problem they're trying to solve—they'll probably figure that out pretty quickly. On the other hand, if the question is "How can I encrypt and decrypt credit card numbers for storage in my database", or "What ratio of bleach to ammonia is best for cleaning mold", some inquiry about the broader problem is warranted.

That's my reading too, it's not really 'YX' problem (that doesn't even really make sense to me by analogy?) - it's when someone claims you have an XY problem and No actually you do need X, you just didn't bother to go into why because it's not relevant/none of their business/etc.

I think this frequently comes up in the form Well actually the idiomatic way to do this is not X but X'; but X really was needed by OP due to some unstated constraint. (Because why would you state it, especially if you're unaware that you're doing it a remarkably unidiomatic way. You're just asking how to do what you're doing.)

Your response seems to assume that "XY-probing" responses are equally good as straightforward responses, but they aren't. If your question is solid, it's really annoying when others try to XY-probe it instead of answering it.

Therefore, before giving an XY-probe response to a question, one should think about the probability that the question hides an XY problem.

If the question is about drawing a square, there's no good reason to assume it's an XY problem. Better to just answer the question.

If the question is about something strange that should never come up in typical applications, maybe you can start XY-probing towards the "real question".

Graphics programmer here. Many times drawing a square isn't a great option in games; particularly when there are many. The usual approach is blitting them squares from raster/image data which is a mere copy of texture data into frame buffer. If you're experimenting with Bresenham's line drawing or writing a game is the right probing question here.

If you don't know how to draw a square then it's probably not the time to worry about that level of efficiency. Figure out the method that keeps your development and learning pace as high as possible.

We need to know why to optimize or refine the suggestion but nothing really says we need to halt any suggestion until that point.

For almost all real world questions a more neutral mix of "Well, you could try ${x} by doing ${xthings} but it might also make sense to do ${y} or other things depending on the ultimate goal" actually gets better results faster than a pure XY or YX approach.

There are always a million problems people are trying to solve.

I'm trying to draw a square because I need to draw a button. I'm trying to draw a button because I need the user to be able to click it. I'm trying to make something the user can click so they can use this feature. I'm trying to make this feature so the user can do ... I'm trying to enable the user to do ... so my product can be successful. I'm trying to make the product successful so my company can survive. I'm trying to help my company survive so I can keep getting paid. I'm trying to get paid so I can feed my family. ... It goes on.

The XY problem, at least as I usually see it phrased, implies that there's exactly one problem up the stack that the asker should have asked about. There's not. It's impossible to know how much context would be useful and it depends on how much help the asker wants. Sometimes, I just want to draw a square and don't want help redesigning the feature. Maybe sometimes I _could_ use that kind of feedback. I think what's important is to meet people at the level they've asked the question, and _maybe_ suggest that it might be the wrong level. But so often respondents just obnoxiously insist on redesigning the feature when I just need to draw a square.

It can be counterproductive though.... reminds me of quite a few OSS projects where the user asks "how do I do X?" only to be met with "you shouldn't do X, <insult>"

Reply on news.ycombinator.com