The XY approach can be perfectly legitimate. You're a domain expert. You have a problem X. It's a standard problem in your domain but only you can really understand it. However, you can see that a general purpose approach, Y, could solve it. Y might even sound complicated but is at least fully explainable whereas X isn't easily explainable at all.
Of course, the "XY problem" usually presumes a naive person ("user")who falsely imagines the more complicated-sounding solution Y would solve their simple problem. And that's a pretty common situation.
The general approach for all this stuff is whenever someone is asking for the solution to a complicated or weird question, just verify they have some reason to approach it that way. There's no reason to automatically assume either they do or they don't and not assuming anything lets you approach them more respectfully.
Sure, but it’s still worth explaining what X is to give people context. Also the majority of question askers tend to be the ones who came up with the incorrect solution or are trying to use something dangerous to solve their problem.
Classic physical world example: I was making a wooden frame to go between a light fixture and the ceiling of the overhang on my porch. I made the frame in my workshop, was going to paint it and mount it outside.
So I went to home depot and asked for exterior paint. It was winter, and I instantly got a lecture about how you can't paint outside because it's too cold (before the guy showed me where the paint was).
It's minor obviously, but it stands out because it's just like all these internet discussions where someone would rather tell you you're doing it wrong then try and help you. To me it's a cultural problem along the lines of lots of "we better not give people information because they are not enlightened enough to use it the way we want them too" ways of thinking. Personally I think it's a bad approach everywhere.
Indeed. One should check for XY problem and one should not be offended when someone is checking, but just help them help you by getting through the standard procedure.
The worst XY problem is knowing you want to do Y, even if its strange or whatever, asking how to do it, and people asking you "why do Y? Do X instead".
Happens all the time in Stack Overflow.
Just answer the fucking question, and then give the lecture on why you think it should be done that way, or why it shouldn't be done at all...
In the absence of evidence-you-know-you-need-Y: the odds are often HEAVILY skewed towards you not knowing about X, or being confused about either X or Y's purpose.
If you do tech support of any kind with random people, it's pretty clear that a majority simply don't know what's available, or why Y may not be a good idea. They need to do a thing, heard that Y can do it, and now they're asking how to use Y - reasonable, but frequently misguided. When Y is dramatically more complex (either harder to set up, or more error-prone to use), recommending X before sinking a ton of effort into explaining Y solves a lot of cases quickly, for both parties.
I once asked a question about an obscure corner of C++. I was only trying to learn more about the language[0]... The answer with the most useful information also contained a long and patronizing rant about why I should never do that. I'm not a novice, and I'm capable of deciding for myself whether I should or shouldn't use something.
I just couldn't bring myself to give that jerk credit, so I deleted the question and never logged in again. There are a lot of smart people there, but it's just not worth dealing with them.
Maybe this isn't an XY problem, but I suspect it's just as common (at least on most of the Stack Exchange sites).
[0] Anyone who thinks they know all of C++ doesn't even know what they don't know.
You have to consider that SO exists not only to answer your specific problem, but also to help other users who might face a similar problem. In that context, it might be helpful to mention, if you are the asking person, include the details why you cannot do X, if you know you can't; or, if your question doesn't include details about your specific circumstance, answers that mention that common solution is to do X instead.
- Provide a solution to Y first. This is OP's point.
- Then as a corollary, provide some of their guesswork of what X might be and if it is true, then this is how to solve X without having to do Y.
So, it is still beneficial to n00bs and the uninformed, just puts the direct answer to Y first. That's all OP is asking and I agree with that.
Most of the time, smartass responses go into the guesswork regime by assuming the User wanted to do X. More than often User actually wanted to do Z, it's not always true and it is polluting SO against the spirit of "Direct question ---> Direct answer" because discovery and searching of answers happen through Y, not X. Most people came to SO because of Y, that's how they landed there in the first place.
This is not a good approach. For the typical person asking a question, you waste their time at best. At worst, they actually use your solution to Y and ignore why it's bad. Both of those are significantly worse than clarifying the problem in the first place.
No one is saying we shouldn't provide why Y is bad. I said, it should be a corollary.
The bad approach is when the entire thread is full of guesses of what X might be without knowing the full context. Y is nowhere to be found. It breaks the UX of SO.
Your question, without explanation why you want to do Y, when obvious way is to do X, is then not specific enough to people who have XY problem and are not aware of it.
>not specific enough to people who have XY problem and are not aware of it
Again, they should be expected to ask their own questions on the site, so they could get the answers they're looking for. Come on, that's not hard to grasp.
A question like "How to delete a project from Google Cloud Console" [1], should have a clear, definite answer. I wouldn't expect to see something like "this is how you register an account on AWS", just in case "the user is changing providers".
The reality that Stack Overflow doesn't seem to want to admit is a huge number of questions are coming from people in school, MOOCs, going through tutorials, books, whatever the case may be, trying to learn and doing things in an intentionally suboptimal way for pedagogical purpose, even though you would never deploy such code to production. Or they're working through LeetCode or something. If an assignment says they have to do something a particular way, they don't have a choice and it's patronizing and annoying to see all the responses questioning why they're doing exactly what the assignment requires them to do.
Might also point out that a lot of people finding the question later on Google because they the same question are just trying to do the same assignment, so Stack Overflow is undermining its own stated purpose here.
There are a few people who frequently have this complaint, but I don't think it's a real problem. If you actually need to do Y in a situation where most people who think they need to do Y are wrong, it's not everyone else's responsibility to divine that you are the magical case. It's your responsibility to demonstrate that you actually do know what you're doing.
This isn't something you do by discussing how unfair other people are. It's something you do by communicating the constraints you're working inside, your knowledge of more typical solutions, and why they don't work for you.
If you aren't providing that information, you're wasting the time of everyone who is voluntarily helping others. It's not their fault that you're not providing critical information for answering your question effectively.
When you're the special case, you have to communicate that fact. It's just wasting everyone's time when you expect others to know it without communication.
If you're the one asking the question for the first time, yes, you should make it clear in your wording that you know about X and you really want Y.
There are two failure modes though:
1) You really want to do Y, not X. You are not asking the question, just searching for the answer, and find that "how do you do Y?" question, and the answer is "do X instead". Because you're a special case, these answers will likely dominate your search results.
2) You decide to ask the question. You make it very clear that you want to do Y, not X. Your question is closed as a duplicate of the one whose answer was "do X".
I've come across this multiple times. Some communities are worse than others on StackOverflow about it. Golang in particular seems to look for reasons not to answer a question, and I've come across your 2nd more than once.
Typical situation: I get called in as a consultant/freelance/whatever, I inherited X. I can make a small patch if I can do Y. Even when I preface it with "I would normally rewrite X correctly, but that touches on all systems, how can I do Y?" It turns straight into an argument about doing X right.
It's like I'm driving, make a left turn and end up lost. They are telling me to make the right turn at Albuquerque instead of the left.
Other scenario is that I'm trying to glean some insight on the language and I'll reduce a problem to bare basics and ask something like, "what's going on here?" They will answer "don't use that, use X library instead." That wasn't the question, the question was what's going on with the programming language -- why is it acting weird. I know that nobody would write the code that way, I isolated the problem to specifically inspect a single element.
This happens all the time, and no, not only in super exceptional special cases. Ask how to change the spark plugs on a Lotus. Nobody has a freaking clue, but their neighbor told them Lotus is unreliable, so you get half a dozen yahoos replying "you should buy a Toyota, it's more reliable." Thanks, geniuses, but I already have a reliable car, I also happen to like playing with my Lotus, which I did not purchase because I was tricked into believing it was a great value. I feel I should not need to provide a full inventory of my garage and driving habits to ask a basic question.
Ok, you're annoyed at rude people. That's fair. Rude people are maddening.
But that's not what the XY problem is about. There is no case where "you should have bought a Toyota" is a valid response to "how do I change the spark plugs on my Lotus?". That's just internet jerks being... Jerks.
That sounds great in theory, but in practice you end up having this enormous, long list of "defenses" as to why it isn't an XY problem, and then ... people will ignore them anyway. This has happened to me on Hacker News.
People hit that XY button more than needed, and I have seen this even in the earliest days of Linux. I remember, pre-Google, when asking some questions on IRC about recompiling the kernel for my distro, I would get smart-ass responses like "What you should have done is selected this other distro."
It's led to me rarely asking questions if I think the issue could be construed as XY.
I ask a quæstion about a specific, unusual grammatical form in a language I find hard to understand, and I am met with “You should instead phrase it in this more basic way that you already understand.”.
I am obviously not asking how to translate the specific example sentence I conjured up, I am asking about how to use the specific grammatical form I inquired about.
I've had two cases on SO where I explicitly started my question with "I know X is the standard way to solve this problem, I can't do X because I work at a big company that has policy Z which prevents that, so I'm trying to make Y work, here's what I've done..."
and the question was marked as a duplicate of a "how to do X?" question and closed.
I've also had plenty of good experiences on StackOverflow, so YMMV, but in general I've found other forums better.
>There are a few people who frequently have this complaint, but I don't think it's a real problem. If you actually need to do Y in a situation where most people who think they need to do Y are wrong, it's not everyone else's responsibility to divine that you are the magical case.
Well, that's strange, because what they do is still divining. They try to divine "what you actually wanted", even though you asked another thing.
Even worse, a lot of the time the one doing the asking has explicitly said "I know this is unorthodox" or "just answer how to do Y please, don't give me your 'better' options".
It's especially annoying when what you what to do is hack something (and not do it the official way), bypass some restriction that absolutely prevents X, try an alternative style, push the envelope, or generally think Y is better even though the "conventional" sheep-like answer is "do X".
An example of the latter would be trying to use Java with simple POJOs and lite patterns in ~2005, and everybody suggesting you go through some monstrous J2EE setup with half the GoF book thrown in instead because that's "idiomatic".
Or e.g. trying to ask about trying to use a regex to quickly parse some known-quantity HTML where regex will work just fine (say, extract all href out of all a elements), and everybody insisting they lecture you on proper html parsing instead, not caring about your use case.
> known-quantity HTML where regex will work just fine (say, extract all href out of all a elements),
Regex doesn’t work fine even on that. You still need to tell apart actual tags from contents of attributes, comments, uninterpreted contents of <script>, and so on. A regex alone doesn’t give you the ability to do that. If you want to parse HTML, you need a parser. Simple as that.
Not sure why you're downvoted. What you're describing is perfectly reasonable. Like you might be scraping a page with no user-generated content. Regex can make a lot of sense because if the regex stops matching, the page probably changed enough that a parser wouldn't stop it from breaking the scraping either.
Most of the time it works just fine for my purposes.
And it's not like I don't know alternatives. And I've written a toy compiler in the past (C with classes subset), done heavy XSLT work, know how to write a parser (manually, with flex/yacc, with PEG), have parsed XML with SAX, DOM, XOM, have used xpath expressions, css and jquery selectors, and used libs like BeautifulSoup.
Most of the time a quick regex will do just fine for that purpose.
See, I don't intend to send the href's to the ISS or to some medical equipment that will blow up if, god forbid, I accidentally found an A tag in a comment or inside a script or attribute.
And I'll probably run another regex or simple editor or awk filter to get rid of some false positives and I'll be fine.
>If you want to parse HTML, you need a parser.
That's a tautology, so it's always true.
If on the other hand you just need to extract some information from an HTML file, and you can just open the bloddy file and see its structure and it is perfectly servicable with a regex, you might not need a parser at all. Simple as that.
If you're in a situation where you know enough about both HTML and regex to know that you can definitely solve your HTML parsing problem safely using a regex...
What possible question could you have for an online forum?
'a lot of the time the one doing the asking has explicitly said "I know this is unorthodox" or "just answer how to do Y please, don't give me your 'better' options".'
After being burnt by a person who never wanted to do anything in a conventional, well-supported way* and kept making that explicit request, I have given up volunteering my time to appease them.
At work I get paid to say "I know a couple of ways of doing that, but if you could tell me more about your problem and the constraints, I can give a better answer."
*Problem: router and three laptops need to be networked. Conventional solution: ethernet cables or wifi. Requested solution: IP over serial (SLIP or PPP) over USB-serial connectors. Had not purchased USB-serial adapters.
> After being burnt by a person who never wanted to do anything in a conventional, well-supported way* and kept making that explicit request, I have given up volunteering my time to appease them.
That's fine and completely fair. Just don't provide unasked for answers as an alternative.
I’ve found (on both sides of the conversation) it’s really effective to find a third party that consistently asks what X is: when I’m on the “answering” side of this problem, I’ve generally found that saying something like “Y is impossible” or “Y can be done this way but that’s usually a bad idea, why do you ask?” Goes a long way to being effective at answering the question.
No. The question is about Y. Not about X, not about my life story. Only Y, so everything else is just a distraction and does not belong in the question.
Nobody is making them devine, they do it themselves and pat themselves on the back for reading that XY problem article and spamming XY "answers" everywhere.
I've never asked a question on Stack Overflow, but many, many times I have entered a question into a search engine, received a Stack Overflow link with my question at the top, and been greeted with several screens full of text none of which is an attempt to answer the question.
In other contexts Stack Overflow's conventions are set up on the understanding that they're trying to produce a curated database of questions with their answers, rather than acting as a technical support forum for individuals. It's a real shame that culture doesn't extend to dealing with this case properly.
(The most common case is where the question is something like "does A provide a function for doing B?" and the correct answer is simply "No".)
>When you're the special case, you have to communicate that fact. It's just wasting everyone's time when you expect others to know it without communication.
I strongly disagree. The base assumption is to take it at face value, and therefore should be to answer it that way. The recommendation that comes after is always the optional part. You're wasting everyone's time if you give the Y only, and optionally the X.
>it's not everyone else's responsibility to divine that you are the magical case.
The irony here is that the only divining happening is assuming that I should be doing Y when I specifically asked for a solution to X.
What you're proposing also requires me to divine all the ways that people will say "Don't do X, do Y." and explicitly state how I don't wish to do Y but really just want to accomplish X.
"I'd like to accomplish X. No I can't do Y1 since E1, no I can't do Y2 since E2, ..., Y_N since E_N. Please just stick to X."
It would be better if people just stuck to X in the first place, instead of doing all this divining. It also makes it really frustrating for others who share problem X and search for solutions to problem X, only to get people solving problem Y.
I suspect the type of person who answers questions unhelpfully like this is often highly experienced, but without terribly deep technical knowledge (in the rigorous, scientific or academic sense). You get an often practical answer, but it's just not helpful when you are pushing the boundaries in any particular domain.
I think people are treating this is as a binary issue.
IMO both Y should be answered as well as X should be discussed. Why can't an answer have both? The frustrating part is when Y is never to be found on the answer thread.
Regarding SO, it suffers from a strange form of cognitive dissonance:
A. You can't ask "what's the best way to do X" because, for whatever reason, these kind of questions are not aligned with "the site's scope".
but
B. When you ask something specific, you get a lot of "it's better if you do X" answers. I even have had some really nice questions closed because some mods thought I was "asking the wrong thing".
Both behaviors are allowed and encouraged ¯\_(ツ)_/¯.
I wonder... What if you made a slight phrasing adjustment to ask "what is the idiomatic way to do X?" Would SO be fine with that? It sounds less like a question inviting opinions even if in many cases the answers will be exactly the same as using the word "best".
I get these types of questions from time to time, and the way it usually goes is:
them: how can I do Y?
me: you can do A, but you're probably going to run into B, I'd recommend doing C instead because D
them: ok, well, I'm already too committed to Y, so I'm going w/ A. Thanks!
them, later: hey, I ran into B. Can you help me?
me: ...
At that point, I just accept that sometimes people need to get burned to learn their lesson.
There are also cases where people ask how to do Y, but explain that it's not an XY problem because such and such reasons. These often actually turn into stimulating conversations because now you're in brainstorming territory and it's clear that the conversation is about procuring novel solutions.
Yeah, that drives me nuts. It would take me quite a long time to explain the combination of constraints, requirements, goals, and office politics that make Y the thing I actually have to do, yet even when I say as much in the question people still insist that they know my problem domain better than I do. It is maddening.
Don't take the actual problem and pretend it is an easier one you know how to solve just to look smart and/or helpful.
I think this is due in part to the gamification in stack overflow. Often Y is a very detailed question that few people know the answer to. But X is a more general problem that anyone knows some answer to. So you answer the question you know how to answer, even if it wasn't asked.
However, at least in the case of stackoverflow, you're getting advice for free, even if it's occasionally unhelpful. You aren't entitled to an answer.
I interpret this to mean: if you are going to answer the question, just answer the one asked rather than assuming that the question was asked in error and answering some other one.
I don’t interpret this to mean: I’m entitled to your answer.
That being said, I appreciate answers of the form: “here’s how you do Y. If you really just wanted X, you can do this instead”
on stack overflow, the more friendly and 'treat other people like humans' esque a question is, the more off track it becomes. dry, cold questions tend to get the best answers. if the goal is to learn something, it's best to treat the site like an answer vending machine.
for example, a question treating other people like humans: "hi. I need to get the last two letters of a string in Javascript. can anyone help? thanks" is likely to attract a bunch of curious types of 'why do you need to get the last two letters of a string?' type answers, versus posting something deliberately robotic seeming: "javascript: get last 2 letters of string" immediately gets replied with no-nonsense answers from people wanting to drop their knowledge and get stack overflow green checkmark points for being the fastest answerer etc.
To quote the TFA: After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn't even a suitable solution for X. (emphasis mine)
Whose time was wasted? For the asker, the exploration of Y and the eventual realization that it is not a good way to pursue X is a learning experience with value. For the answerer, they may feel their time is wasted if the goal is to answer questions. But if the goal is to help the asker deepen their understanding then the discussion of Y isn't wasted time at all.
This presupposes two things: 1. The asker must have the curiosity and humility to interrogate Y as their chosen method to reach X. 2. The answerer must set aside their ego in order to provide genuine help instead of patronizing advice.
The question/answer format of Stack Overflow does not lend itself to curious exploration of questions and I think the gamification aspect rewards egotistical answerers. I say this despite deriving a lot of value from SO over the years.
The time spent on the interaction between asker and those who answered to actually get the asker to provide context and outline his X.
If the asker had done this right from the start, instead of making the answerers guess, then the goal to help the asker deepen their understanding can be reached much more quickly.
Absolutely. Which is why we require askers to fill out a template which asks the big questions up-front; version, config, logs, what do you want to do, what did you try, what did you read. It always takes longer if askers are stubborn and don't answer those questions properly. Help me help you.
From the perspective of someone asking for Y, I've often been a victim of
this because I'm met with a slew of imagined X's -- X0, X1, X2, ... an
unending list of problems, often more complicated than Y -- due to their
narrow preconceptions, making the whole exercise of asking someone not worth
the time.
From the perspective of someone being asked for Y, yes, often I can suspect
that there might be some mis-matched X there, but in order to be helpful, I
try to answer Y directly and honestly, and then point out my concerns,
describing my presumptions. If, indeed, the one posing the question has
jumped to some invalid conclusion Y from X, then I've given them all I can.
Trying to pre-empt it by telling them "don't do that!" is pointless -- if
they knew where they had made an unwarranted conclusion, they wouldn't be
asking the wrong question to begin with.
Not sure why you are complaining about this author in particular when both of the examples in the link show exactly what you asked for: they answer Y and then ask for clarification on X.
Yeah, my comments about the author were mis-placed. This version redacts the source material in a way that comes across as nicer, although it retains the use of "n00b" to identify who is asking the question.
I may have confused this with the "Source 2" linked from the article:
In its examples, responses include an immediate "Why?" non-answer, an angry "ASK FOR WHAT YOU WANT!", and the observation "Literal answers to bad questions can be dangerous" from one presumed non-noob to another.
I have ben asked countless times to explain the problem, and in practice problems are harder to explain than attempted solutions. I once spent a long time explain the architecture of a multiserver supervisor dæmon manager because they insisted when I was looking for a rather simple answer regarding unix domain sockets.
The actual problem often requires an explanation of the entire design strategy of the software at hand, which is often much.
> but in order to be helpful, I try to answer Y directly and honestly, and then point out my concerns, describing my presumptions.
This works fine as long as Y actually does have a simple solution. Often it does not, and already the question for Y is really weird, but once you hear about the X you can give a quick and simple answer.
That said, sometimes X is really really complicated. But even in that case it'll help anyone you are asking if you quickly outline X in a short sentence, just so the one you are asking has enough context.
(I have been on both sides, but more often then not the simple X was missing from questions was really strange Ys. Though I also have asked for Ys (and even outlined the X) and have been annoyed by people who insist that I should do something else, and describe my X in more detail, but when I do, they can't answer either, because the X really complicated and Y actually was a valid attempt at solving it).
The XY problem is really a collaboration problem... most discussion media are all horribly transient. When you're explaining a problem you did figure out all that context, but you're guessing as to what context the next person needs. That's necessarily going to leave out things you don't know you need to explain.
At work, I have to go from team to team for some issues, and we're special (yay) because we're an acquisition, so we're doing some very odd things by corporate standards. Even the fact that we have a customer facing application is unusual, and I've essentially renamed our API to be "BackendForFrontend" entirely because each new team assumes our API must be entirely developer facing.
What I've found is it's tremendously helpful to always link back to (and quote from) Jira issues so the necessary context is present whenever I'm asking questions. Whether it's Jira or Confluence, you want to treat problem resolution the way you do development: it's a permanent thing you're building. And I mean permanent, if you solve a problem, you do a write-up for future you.
I find it strange that some people get offended with this approach to problem solving. There is this legendary interview question, "I have a mountain in India and I want to move it in France, how do I do it?". And some questioners (presumably people who like to be authoritative, in charge and order people around), really seem to dislike if my first impulse is to ask "Why do you want to do that? What is your goal?" And they respond with something like, "Why does it matter, just get on with the task, I didn't hire you to ask questions!"
Because the method really does depend on what you want to do. Can I destroy the mountain? Do I have to recreate the geological structure, or is it the biosphere you're interested in, or perhaps there is a holy place on that mountain that is important? And so on. If you want me to think outside the box (and presumably the question is posed to test that skill), then you have to be willing to provide more details on what you ultimately want.
To satisfy the authoritarian impulse, one can ask "in what manner should the mountain to be moved? Would just transporting the dirt be enough?"
And if this is "just interview question", the literal answer is "I don't want the fricken mountain moved to France, I just want to this exercise in hypothetical done with and you're not making it easy on me"
> And some questioners ... really seem to dislike if my first impulse is to ask "Why do you want to do that?"
An interview works both ways. If you can suss out the interviewer's nature and help you determine it's not a place you'd want to work, then trust that impulse.
When somebody asks me a question, I find it best to answer their question directly (because maybe I don't understand their situation as well as they do), and then give them the information that I think they actually need (because maybe they're asking the wrong question).
What I find very frustrating is when I ask a question, and get an "answer" that doesn't actually answer my question.
I get that this is a real problem, especially in tech support. And this write-up is better than others I've seen. At the same time, I think people referencing this don't seem to understand how self-centered this perspective is. As the asker, you've got a stack of problems that might start with: well, I need to eat, so I got this job, so I need to do this task, ... (20 technical problems later), so I'm trying to do Y. How am I supposed to know how far up my stack _you_ want to go? If I knew I made a wrong step 3 problems ago, presumably I would have just asked about that problem.
The suggestions here are fine. Still, I think it's more important that the responder have some empathy and be willing to go back and forth a bit to understand someone's problem instead of expecting the asker to guess what information the responder is going to want.
Also, what's with the name "XY problem"? If "asking about Y when you want to do X" makes it an "XY problem", couldn't any problem involving any two things also be called an "XY problem"?
It's always good to ask the person about the context surrounding their question, but I also don't see much harm in seeking how to do Y, for the sake of Y. What is a 'strange problem to want to solve' anyways? To me, they are all just problems.
Yes, it is often the case that the person has the wrong idea of how to solve X, but this does not always say something about the validity of problem Y. Often times knowing how to do Y is valuable for other contexts besides X. We should try to be friendly and make it clear that Y is not a good way to achieve X without downplaying Y, necessarily.
Is there a name for when person A asks B and B thinks A has fallen victim to the XY probem but A really didn't and has indeed an unusual problem at their hands?
In my experience, people who have proven fairly to themselves that they're in an odd situation can prove it to others pretty easily. "I'm not doing $Z because..."
I've always called it "The XY problem problem". It's not usually an issue in person but in async messaging it can waste a lot of time if you're not careful. And it goes on forever "The XY problem problem problem" where someone is aware what an XY problem is but thinks this is for sure an XY problem problem so they refuse to spend time thinking otherwise. Then of course "The XY problem problem problem problem"...
In those async situations it's best to provide bits of information for both directions every time, in person it's usually best to collaborate.
But sometimes this happens because the questioner wants to avoid other people's waste of time asking a more specific and limited question instead of a generic one. Often this happens because the environment where the question is asked is highly selective and does not accept too verbose and indirect questions. The solution is to be more open to conversation on both sides.
That isn't my experience at all. In contexts that are highly conversational, people constantly ask XY problems. It's hard to see that the path you went down so far may or may not be correct, so a lot of people just assume their last three determinations in solving their problem were valid.
Conversational environments certainly make it easier to root cause them, but it's often still painful.
Many will refer to stackoverflow since that's the reason this website was created in the first place. But one of the most important thing in solving problems in programming is context.
Here is one real question I got in an interview: How do you efficiently sort a table containing a million record in JavaScript?
My question was "in the front end?"
And my answer was it's probably not a good idea to sort that much data in the front end since the user will most likely not be able to consume that much data. Since it was an interview, I explained how to sort the table anyway.
Sorting in the backend makes sense, but even then using a database is more efficient then doing it in JavaScript.
If this question was on SO, I'd probably answer: You shouldn't do that in the front end, explain why. And of course they will get pissed for not answering how.
But it is nice when you stumble across an answered question that fits your use case.
For instance, if I was making heavy use of local storage where I have no back end, it is nice if that question is already answered. At that point I don't really care if the previous user got a better method, that's what I need to do now.
I've found that this issue crops up in situations where someone has a new app idea. They don't possess the skills to create it themselves because they're in a different domain.
They ask you about building Y, maybe even Z but they don't want to give X away in case someone steals their 'disruptive product'.
There is too little information to go forward, too little trust. Project doesn't take off.
"the world wasn't ready for X, anyway", they say. Whatever that was.
Had a Product Manager who would always ask for Y, but had ego issues and would shut down when asked for context, examples, or client problem statements. Too many times we built Y then we had to face the consequences of not building X when put in front of customers. Very frustrating.
To call the XY learning QA a problem is akin to calling learning to swim a problem. It can be a problem on a sinking ship but not at the community pool.
I’ve heard this cited by a couple ctos I’ve worked for. It’s a popular metaphor in the engineering department. I think it’s articulating an important message, but in an ineffective way. The name “XY Problem” is too vague and easy to forget. I prefer simpler messages like:
- What’s the root cause of the problem?
- Is this a solution looking for a problem?
As software engineers, part of our job is naming things well and the “XY Problem” isn’t a great name IMO.
You're right the "XY problem" is vague. But that's exactly why engineers cling to it. The concept cloaks a messy, human interaction in the guise of math & logic. It enables an answerer to dissect their questioner without bearing the cost of the questioners feelings. It inverts the power dynamic, basically.
That duplicity makes "XY" useless as an analytic tool to improve inquiries. But as a political cudgel to stop inquiries, I think "XY" can be effective. When outsiders are forced to constantly justify and explain themselves in detail, in triplicate, then the price of Q&A will eventually increase to the point where no one wants to ask.
I think a CTO who is uncomfortable with inquiries will find the "XY problem" a much needed mental gymnastic.
Well said! Cloaking a messy human interaction in the guise of math and logic is an effective way to communicate with engineers. Never thought of it that way.
This is the entire game in consulting. Your client comes to you asking for something but with certain expectations in mind. The job of a good consultant is to meet those expectations - stated or not. You learn pretty quickly how to figure out what they’re really asking.
There's also the Big Bad consulting trope which has it all backwards.
Client states they need something like Y, consultants assess the situation, understand they should do X but keeps it to themselves, the parties come to an agreement to solve Y and do so. Client states they need something like X..
In my experience it’s usually more client states they need Y, consultants assess the situation and recommend X, but the client still insists on Y. 6 months later they come back to the consultant and ask for X because Y didn’t work.
Sometimes the XY problem occurs because the fact that X is being worked on is a company trade secret and the reporter tries to turn it into Y, which can be disclosed. This isn't always successful.
That's not my experience. A lot of the time there is a VERY straightforward answer, e.g. "here's this evil metaprogramming thing" or "here's where you access this legacy representation with bitey cornercases" or whatever, which is trivial to provide (but also harmful).
Of course people who present you with an XY problem are often the same sorts of people who begin the conversation with my most hated trope of them all...
"Asking to ask"
(Often coupled with diverting the conversation from a public forum, where it can be useful to others, into a private one-on-one conversation where you suddenly become on-the-hook for solving all of their issues.)
This is similar to the "faster horse" quote. If you care about helping someone, it's important to understand what they really need.
That said, I enjoy giving literal answers to things. Sometimes it's a fun challenge, others I'm just being a smartass, and occasionally it's a teaching opportunity. A few times I've done this to younger team members, then set myself a reminder to check on them to see if they figured out why that's not the best way.
The XY approach can be perfectly legitimate. You're a domain expert. You have a problem X. It's a standard problem in your domain but only you can really understand it. However, you can see that a general purpose approach, Y, could solve it. Y might even sound complicated but is at least fully explainable whereas X isn't easily explainable at all.
Of course, the "XY problem" usually presumes a naive person ("user")who falsely imagines the more complicated-sounding solution Y would solve their simple problem. And that's a pretty common situation.
The general approach for all this stuff is whenever someone is asking for the solution to a complicated or weird question, just verify they have some reason to approach it that way. There's no reason to automatically assume either they do or they don't and not assuming anything lets you approach them more respectfully.
Sure, but it’s still worth explaining what X is to give people context. Also the majority of question askers tend to be the ones who came up with the incorrect solution or are trying to use something dangerous to solve their problem.
Classic physical world example: I was making a wooden frame to go between a light fixture and the ceiling of the overhang on my porch. I made the frame in my workshop, was going to paint it and mount it outside.
So I went to home depot and asked for exterior paint. It was winter, and I instantly got a lecture about how you can't paint outside because it's too cold (before the guy showed me where the paint was).
It's minor obviously, but it stands out because it's just like all these internet discussions where someone would rather tell you you're doing it wrong then try and help you. To me it's a cultural problem along the lines of lots of "we better not give people information because they are not enlightened enough to use it the way we want them too" ways of thinking. Personally I think it's a bad approach everywhere.
Indeed. One should check for XY problem and one should not be offended when someone is checking, but just help them help you by getting through the standard procedure.
The worst XY problem is knowing you want to do Y, even if its strange or whatever, asking how to do it, and people asking you "why do Y? Do X instead".
Happens all the time in Stack Overflow.
Just answer the fucking question, and then give the lecture on why you think it should be done that way, or why it shouldn't be done at all...
isn't the XY problem that you don't really know you want to do Y? and if you did know, wouldn't you know?
You know you want to do Y, but you don't tell others that you actually want to do X, and Y seems like a reasonable thing (to you) to do to reach X.
In the absence of evidence-you-know-you-need-Y: the odds are often HEAVILY skewed towards you not knowing about X, or being confused about either X or Y's purpose.
If you do tech support of any kind with random people, it's pretty clear that a majority simply don't know what's available, or why Y may not be a good idea. They need to do a thing, heard that Y can do it, and now they're asking how to use Y - reasonable, but frequently misguided. When Y is dramatically more complex (either harder to set up, or more error-prone to use), recommending X before sinking a ton of effort into explaining Y solves a lot of cases quickly, for both parties.
I once asked a question about an obscure corner of C++. I was only trying to learn more about the language[0]... The answer with the most useful information also contained a long and patronizing rant about why I should never do that. I'm not a novice, and I'm capable of deciding for myself whether I should or shouldn't use something.
I just couldn't bring myself to give that jerk credit, so I deleted the question and never logged in again. There are a lot of smart people there, but it's just not worth dealing with them.
Maybe this isn't an XY problem, but I suspect it's just as common (at least on most of the Stack Exchange sites).
[0] Anyone who thinks they know all of C++ doesn't even know what they don't know.
You have to consider that SO exists not only to answer your specific problem, but also to help other users who might face a similar problem. In that context, it might be helpful to mention, if you are the asking person, include the details why you cannot do X, if you know you can't; or, if your question doesn't include details about your specific circumstance, answers that mention that common solution is to do X instead.
No.
User asks I want to do Y.
The responding party should in my opinion:
- Provide a solution to Y first. This is OP's point.
- Then as a corollary, provide some of their guesswork of what X might be and if it is true, then this is how to solve X without having to do Y.
So, it is still beneficial to n00bs and the uninformed, just puts the direct answer to Y first. That's all OP is asking and I agree with that.
Most of the time, smartass responses go into the guesswork regime by assuming the User wanted to do X. More than often User actually wanted to do Z, it's not always true and it is polluting SO against the spirit of "Direct question ---> Direct answer" because discovery and searching of answers happen through Y, not X. Most people came to SO because of Y, that's how they landed there in the first place.
This is not a good approach. For the typical person asking a question, you waste their time at best. At worst, they actually use your solution to Y and ignore why it's bad. Both of those are significantly worse than clarifying the problem in the first place.
No one is saying we shouldn't provide why Y is bad. I said, it should be a corollary.
The bad approach is when the entire thread is full of guesses of what X might be without knowing the full context. Y is nowhere to be found. It breaks the UX of SO.
>but also to help other users who might face a similar problem
They could ask their own questions.
I'd rather have a database of specific questions with specific answers than "X-Ys" all over the place.
Your question, without explanation why you want to do Y, when obvious way is to do X, is then not specific enough to people who have XY problem and are not aware of it.
>not specific enough to people who have XY problem and are not aware of it
Again, they should be expected to ask their own questions on the site, so they could get the answers they're looking for. Come on, that's not hard to grasp.
A question like "How to delete a project from Google Cloud Console" [1], should have a clear, definite answer. I wouldn't expect to see something like "this is how you register an account on AWS", just in case "the user is changing providers".
1: https://stackoverflow.com/questions/16621921/how-to-delete-a...
The reality that Stack Overflow doesn't seem to want to admit is a huge number of questions are coming from people in school, MOOCs, going through tutorials, books, whatever the case may be, trying to learn and doing things in an intentionally suboptimal way for pedagogical purpose, even though you would never deploy such code to production. Or they're working through LeetCode or something. If an assignment says they have to do something a particular way, they don't have a choice and it's patronizing and annoying to see all the responses questioning why they're doing exactly what the assignment requires them to do.
Might also point out that a lot of people finding the question later on Google because they the same question are just trying to do the same assignment, so Stack Overflow is undermining its own stated purpose here.
There are a few people who frequently have this complaint, but I don't think it's a real problem. If you actually need to do Y in a situation where most people who think they need to do Y are wrong, it's not everyone else's responsibility to divine that you are the magical case. It's your responsibility to demonstrate that you actually do know what you're doing.
This isn't something you do by discussing how unfair other people are. It's something you do by communicating the constraints you're working inside, your knowledge of more typical solutions, and why they don't work for you.
If you aren't providing that information, you're wasting the time of everyone who is voluntarily helping others. It's not their fault that you're not providing critical information for answering your question effectively.
When you're the special case, you have to communicate that fact. It's just wasting everyone's time when you expect others to know it without communication.
If you're the one asking the question for the first time, yes, you should make it clear in your wording that you know about X and you really want Y.
There are two failure modes though:
1) You really want to do Y, not X. You are not asking the question, just searching for the answer, and find that "how do you do Y?" question, and the answer is "do X instead". Because you're a special case, these answers will likely dominate your search results.
2) You decide to ask the question. You make it very clear that you want to do Y, not X. Your question is closed as a duplicate of the one whose answer was "do X".
I've come across this multiple times. Some communities are worse than others on StackOverflow about it. Golang in particular seems to look for reasons not to answer a question, and I've come across your 2nd more than once.
Typical situation: I get called in as a consultant/freelance/whatever, I inherited X. I can make a small patch if I can do Y. Even when I preface it with "I would normally rewrite X correctly, but that touches on all systems, how can I do Y?" It turns straight into an argument about doing X right.
It's like I'm driving, make a left turn and end up lost. They are telling me to make the right turn at Albuquerque instead of the left.
Other scenario is that I'm trying to glean some insight on the language and I'll reduce a problem to bare basics and ask something like, "what's going on here?" They will answer "don't use that, use X library instead." That wasn't the question, the question was what's going on with the programming language -- why is it acting weird. I know that nobody would write the code that way, I isolated the problem to specifically inspect a single element.
This happens all the time, and no, not only in super exceptional special cases. Ask how to change the spark plugs on a Lotus. Nobody has a freaking clue, but their neighbor told them Lotus is unreliable, so you get half a dozen yahoos replying "you should buy a Toyota, it's more reliable." Thanks, geniuses, but I already have a reliable car, I also happen to like playing with my Lotus, which I did not purchase because I was tricked into believing it was a great value. I feel I should not need to provide a full inventory of my garage and driving habits to ask a basic question.
Ok, you're annoyed at rude people. That's fair. Rude people are maddening.
But that's not what the XY problem is about. There is no case where "you should have bought a Toyota" is a valid response to "how do I change the spark plugs on my Lotus?". That's just internet jerks being... Jerks.
That sounds great in theory, but in practice you end up having this enormous, long list of "defenses" as to why it isn't an XY problem, and then ... people will ignore them anyway. This has happened to me on Hacker News.
People hit that XY button more than needed, and I have seen this even in the earliest days of Linux. I remember, pre-Google, when asking some questions on IRC about recompiling the kernel for my distro, I would get smart-ass responses like "What you should have done is selected this other distro."
It's led to me rarely asking questions if I think the issue could be construed as XY.
I even have this issue in language learning.
I ask a quæstion about a specific, unusual grammatical form in a language I find hard to understand, and I am met with “You should instead phrase it in this more basic way that you already understand.”.
I am obviously not asking how to translate the specific example sentence I conjured up, I am asking about how to use the specific grammatical form I inquired about.
I've had two cases on SO where I explicitly started my question with "I know X is the standard way to solve this problem, I can't do X because I work at a big company that has policy Z which prevents that, so I'm trying to make Y work, here's what I've done..."
and the question was marked as a duplicate of a "how to do X?" question and closed.
I've also had plenty of good experiences on StackOverflow, so YMMV, but in general I've found other forums better.
>There are a few people who frequently have this complaint, but I don't think it's a real problem. If you actually need to do Y in a situation where most people who think they need to do Y are wrong, it's not everyone else's responsibility to divine that you are the magical case.
Well, that's strange, because what they do is still divining. They try to divine "what you actually wanted", even though you asked another thing.
Even worse, a lot of the time the one doing the asking has explicitly said "I know this is unorthodox" or "just answer how to do Y please, don't give me your 'better' options".
It's especially annoying when what you what to do is hack something (and not do it the official way), bypass some restriction that absolutely prevents X, try an alternative style, push the envelope, or generally think Y is better even though the "conventional" sheep-like answer is "do X".
An example of the latter would be trying to use Java with simple POJOs and lite patterns in ~2005, and everybody suggesting you go through some monstrous J2EE setup with half the GoF book thrown in instead because that's "idiomatic".
Or e.g. trying to ask about trying to use a regex to quickly parse some known-quantity HTML where regex will work just fine (say, extract all href out of all a elements), and everybody insisting they lecture you on proper html parsing instead, not caring about your use case.
> known-quantity HTML where regex will work just fine (say, extract all href out of all a elements),
Regex doesn’t work fine even on that. You still need to tell apart actual tags from contents of attributes, comments, uninterpreted contents of <script>, and so on. A regex alone doesn’t give you the ability to do that. If you want to parse HTML, you need a parser. Simple as that.
Only if you care about absolute accuracy in sufficiently complex pages. There are many use cases I can think of that really don't.
Parsing HTML with regexes is fine if you're not solving a general case. A regex "parser" will carry implicit assumptions about the document structure.
Like, I know "<div.+>.+foo\s+([a-z]+)" will work, because I've crafted it for a specific site whose sources I've seen.
Not sure why you're downvoted. What you're describing is perfectly reasonable. Like you might be scraping a page with no user-generated content. Regex can make a lot of sense because if the regex stops matching, the page probably changed enough that a parser wouldn't stop it from breaking the scraping either.
>Regex doesn’t work fine even on that.
Most of the time it works just fine for my purposes.
And it's not like I don't know alternatives. And I've written a toy compiler in the past (C with classes subset), done heavy XSLT work, know how to write a parser (manually, with flex/yacc, with PEG), have parsed XML with SAX, DOM, XOM, have used xpath expressions, css and jquery selectors, and used libs like BeautifulSoup.
Most of the time a quick regex will do just fine for that purpose.
See, I don't intend to send the href's to the ISS or to some medical equipment that will blow up if, god forbid, I accidentally found an A tag in a comment or inside a script or attribute.
And I'll probably run another regex or simple editor or awk filter to get rid of some false positives and I'll be fine.
>If you want to parse HTML, you need a parser.
That's a tautology, so it's always true.
If on the other hand you just need to extract some information from an HTML file, and you can just open the bloddy file and see its structure and it is perfectly servicable with a regex, you might not need a parser at all. Simple as that.
If you're in a situation where you know enough about both HTML and regex to know that you can definitely solve your HTML parsing problem safely using a regex...
What possible question could you have for an online forum?
'a lot of the time the one doing the asking has explicitly said "I know this is unorthodox" or "just answer how to do Y please, don't give me your 'better' options".'
After being burnt by a person who never wanted to do anything in a conventional, well-supported way* and kept making that explicit request, I have given up volunteering my time to appease them.
At work I get paid to say "I know a couple of ways of doing that, but if you could tell me more about your problem and the constraints, I can give a better answer."
*Problem: router and three laptops need to be networked. Conventional solution: ethernet cables or wifi. Requested solution: IP over serial (SLIP or PPP) over USB-serial connectors. Had not purchased USB-serial adapters.
> After being burnt by a person who never wanted to do anything in a conventional, well-supported way* and kept making that explicit request, I have given up volunteering my time to appease them.
That's fine and completely fair. Just don't provide unasked for answers as an alternative.
I’ve found (on both sides of the conversation) it’s really effective to find a third party that consistently asks what X is: when I’m on the “answering” side of this problem, I’ve generally found that saying something like “Y is impossible” or “Y can be done this way but that’s usually a bad idea, why do you ask?” Goes a long way to being effective at answering the question.
> Well, that's strange, because what they do is still divining.
Then don't make them devine, outline your X in a short sentence.
Ignore those who still divine.
Listen to those who tell you that Y is really hard, but to solve X, you can try Y' instead.
No. The question is about Y. Not about X, not about my life story. Only Y, so everything else is just a distraction and does not belong in the question.
> Then don't make them devine
Nobody is making them devine, they do it themselves and pat themselves on the back for reading that XY problem article and spamming XY "answers" everywhere.
It is a real problem.
I've never asked a question on Stack Overflow, but many, many times I have entered a question into a search engine, received a Stack Overflow link with my question at the top, and been greeted with several screens full of text none of which is an attempt to answer the question.
In other contexts Stack Overflow's conventions are set up on the understanding that they're trying to produce a curated database of questions with their answers, rather than acting as a technical support forum for individuals. It's a real shame that culture doesn't extend to dealing with this case properly.
(The most common case is where the question is something like "does A provide a function for doing B?" and the correct answer is simply "No".)
>When you're the special case, you have to communicate that fact. It's just wasting everyone's time when you expect others to know it without communication.
I strongly disagree. The base assumption is to take it at face value, and therefore should be to answer it that way. The recommendation that comes after is always the optional part. You're wasting everyone's time if you give the Y only, and optionally the X.
>it's not everyone else's responsibility to divine that you are the magical case.
The irony here is that the only divining happening is assuming that I should be doing Y when I specifically asked for a solution to X.
What you're proposing also requires me to divine all the ways that people will say "Don't do X, do Y." and explicitly state how I don't wish to do Y but really just want to accomplish X.
"I'd like to accomplish X. No I can't do Y1 since E1, no I can't do Y2 since E2, ..., Y_N since E_N. Please just stick to X."
It would be better if people just stuck to X in the first place, instead of doing all this divining. It also makes it really frustrating for others who share problem X and search for solutions to problem X, only to get people solving problem Y.
I suspect the type of person who answers questions unhelpfully like this is often highly experienced, but without terribly deep technical knowledge (in the rigorous, scientific or academic sense). You get an often practical answer, but it's just not helpful when you are pushing the boundaries in any particular domain.
I think people are treating this is as a binary issue.
IMO both Y should be answered as well as X should be discussed. Why can't an answer have both? The frustrating part is when Y is never to be found on the answer thread.
+ 1 on your username :)
Regarding SO, it suffers from a strange form of cognitive dissonance:
A. You can't ask "what's the best way to do X" because, for whatever reason, these kind of questions are not aligned with "the site's scope".
but
B. When you ask something specific, you get a lot of "it's better if you do X" answers. I even have had some really nice questions closed because some mods thought I was "asking the wrong thing".
Both behaviors are allowed and encouraged ¯\_(ツ)_/¯.
I have also been perplexed by that. I think it's a kind of gatekeeping similar to notability policing on Wikipedia.
I wonder... What if you made a slight phrasing adjustment to ask "what is the idiomatic way to do X?" Would SO be fine with that? It sounds less like a question inviting opinions even if in many cases the answers will be exactly the same as using the word "best".
I get these types of questions from time to time, and the way it usually goes is:
them: how can I do Y?
me: you can do A, but you're probably going to run into B, I'd recommend doing C instead because D
them: ok, well, I'm already too committed to Y, so I'm going w/ A. Thanks!
them, later: hey, I ran into B. Can you help me?
me: ...
At that point, I just accept that sometimes people need to get burned to learn their lesson.
There are also cases where people ask how to do Y, but explain that it's not an XY problem because such and such reasons. These often actually turn into stimulating conversations because now you're in brainstorming territory and it's clear that the conversation is about procuring novel solutions.
Yeah, that drives me nuts. It would take me quite a long time to explain the combination of constraints, requirements, goals, and office politics that make Y the thing I actually have to do, yet even when I say as much in the question people still insist that they know my problem domain better than I do. It is maddening.
Don't take the actual problem and pretend it is an easier one you know how to solve just to look smart and/or helpful.
I think this is due in part to the gamification in stack overflow. Often Y is a very detailed question that few people know the answer to. But X is a more general problem that anyone knows some answer to. So you answer the question you know how to answer, even if it wasn't asked.
However, at least in the case of stackoverflow, you're getting advice for free, even if it's occasionally unhelpful. You aren't entitled to an answer.
> Just answer the fucking question,
Beep Boop. Insufficient funds. Insert card to continue.
Or perhaps treat other people like humans instead of an answer vending machine?
If you came to learn something you failed if you respond like that to someone trying to help. Hope it was worth it.
I interpret this to mean: if you are going to answer the question, just answer the one asked rather than assuming that the question was asked in error and answering some other one.
I don’t interpret this to mean: I’m entitled to your answer.
That being said, I appreciate answers of the form: “here’s how you do Y. If you really just wanted X, you can do this instead”
on stack overflow, the more friendly and 'treat other people like humans' esque a question is, the more off track it becomes. dry, cold questions tend to get the best answers. if the goal is to learn something, it's best to treat the site like an answer vending machine.
for example, a question treating other people like humans: "hi. I need to get the last two letters of a string in Javascript. can anyone help? thanks" is likely to attract a bunch of curious types of 'why do you need to get the last two letters of a string?' type answers, versus posting something deliberately robotic seeming: "javascript: get last 2 letters of string" immediately gets replied with no-nonsense answers from people wanting to drop their knowledge and get stack overflow green checkmark points for being the fastest answerer etc.
True! Some XY problems are YY problems in disguise.
To quote the TFA: After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn't even a suitable solution for X. (emphasis mine)
Whose time was wasted? For the asker, the exploration of Y and the eventual realization that it is not a good way to pursue X is a learning experience with value. For the answerer, they may feel their time is wasted if the goal is to answer questions. But if the goal is to help the asker deepen their understanding then the discussion of Y isn't wasted time at all.
This presupposes two things: 1. The asker must have the curiosity and humility to interrogate Y as their chosen method to reach X. 2. The answerer must set aside their ego in order to provide genuine help instead of patronizing advice.
The question/answer format of Stack Overflow does not lend itself to curious exploration of questions and I think the gamification aspect rewards egotistical answerers. I say this despite deriving a lot of value from SO over the years.
>> To quote the TFA
Is that how "TFA" is used now?
In imo this is legit
Made me lol loud.
> Whose time was wasted?
The time spent on the interaction between asker and those who answered to actually get the asker to provide context and outline his X.
If the asker had done this right from the start, instead of making the answerers guess, then the goal to help the asker deepen their understanding can be reached much more quickly.
Absolutely. Which is why we require askers to fill out a template which asks the big questions up-front; version, config, logs, what do you want to do, what did you try, what did you read. It always takes longer if askers are stubborn and don't answer those questions properly. Help me help you.
The mentality of this author is problematic.
From the perspective of someone asking for Y, I've often been a victim of this because I'm met with a slew of imagined X's -- X0, X1, X2, ... an unending list of problems, often more complicated than Y -- due to their narrow preconceptions, making the whole exercise of asking someone not worth the time.
From the perspective of someone being asked for Y, yes, often I can suspect that there might be some mis-matched X there, but in order to be helpful, I try to answer Y directly and honestly, and then point out my concerns, describing my presumptions. If, indeed, the one posing the question has jumped to some invalid conclusion Y from X, then I've given them all I can. Trying to pre-empt it by telling them "don't do that!" is pointless -- if they knew where they had made an unwarranted conclusion, they wouldn't be asking the wrong question to begin with.
Not sure why you are complaining about this author in particular when both of the examples in the link show exactly what you asked for: they answer Y and then ask for clarification on X.
Yeah, my comments about the author were mis-placed. This version redacts the source material in a way that comes across as nicer, although it retains the use of "n00b" to identify who is asking the question.
I may have confused this with the "Source 2" linked from the article:
http://mywiki.wooledge.org/XyProblem
In its examples, responses include an immediate "Why?" non-answer, an angry "ASK FOR WHAT YOU WANT!", and the observation "Literal answers to bad questions can be dangerous" from one presumed non-noob to another.
I very much echo this experience.
I have ben asked countless times to explain the problem, and in practice problems are harder to explain than attempted solutions. I once spent a long time explain the architecture of a multiserver supervisor dæmon manager because they insisted when I was looking for a rather simple answer regarding unix domain sockets.
The actual problem often requires an explanation of the entire design strategy of the software at hand, which is often much.
> but in order to be helpful, I try to answer Y directly and honestly, and then point out my concerns, describing my presumptions.
This works fine as long as Y actually does have a simple solution. Often it does not, and already the question for Y is really weird, but once you hear about the X you can give a quick and simple answer.
That said, sometimes X is really really complicated. But even in that case it'll help anyone you are asking if you quickly outline X in a short sentence, just so the one you are asking has enough context.
(I have been on both sides, but more often then not the simple X was missing from questions was really strange Ys. Though I also have asked for Ys (and even outlined the X) and have been annoyed by people who insist that I should do something else, and describe my X in more detail, but when I do, they can't answer either, because the X really complicated and Y actually was a valid attempt at solving it).
The XY problem is really a collaboration problem... most discussion media are all horribly transient. When you're explaining a problem you did figure out all that context, but you're guessing as to what context the next person needs. That's necessarily going to leave out things you don't know you need to explain.
At work, I have to go from team to team for some issues, and we're special (yay) because we're an acquisition, so we're doing some very odd things by corporate standards. Even the fact that we have a customer facing application is unusual, and I've essentially renamed our API to be "BackendForFrontend" entirely because each new team assumes our API must be entirely developer facing.
What I've found is it's tremendously helpful to always link back to (and quote from) Jira issues so the necessary context is present whenever I'm asking questions. Whether it's Jira or Confluence, you want to treat problem resolution the way you do development: it's a permanent thing you're building. And I mean permanent, if you solve a problem, you do a write-up for future you.
I find it strange that some people get offended with this approach to problem solving. There is this legendary interview question, "I have a mountain in India and I want to move it in France, how do I do it?". And some questioners (presumably people who like to be authoritative, in charge and order people around), really seem to dislike if my first impulse is to ask "Why do you want to do that? What is your goal?" And they respond with something like, "Why does it matter, just get on with the task, I didn't hire you to ask questions!"
Because the method really does depend on what you want to do. Can I destroy the mountain? Do I have to recreate the geological structure, or is it the biosphere you're interested in, or perhaps there is a holy place on that mountain that is important? And so on. If you want me to think outside the box (and presumably the question is posed to test that skill), then you have to be willing to provide more details on what you ultimately want.
To satisfy the authoritarian impulse, one can ask "in what manner should the mountain to be moved? Would just transporting the dirt be enough?"
And if this is "just interview question", the literal answer is "I don't want the fricken mountain moved to France, I just want to this exercise in hypothetical done with and you're not making it easy on me"
> And some questioners ... really seem to dislike if my first impulse is to ask "Why do you want to do that?"
An interview works both ways. If you can suss out the interviewer's nature and help you determine it's not a place you'd want to work, then trust that impulse.
When somebody asks me a question, I find it best to answer their question directly (because maybe I don't understand their situation as well as they do), and then give them the information that I think they actually need (because maybe they're asking the wrong question).
What I find very frustrating is when I ask a question, and get an "answer" that doesn't actually answer my question.
I get that this is a real problem, especially in tech support. And this write-up is better than others I've seen. At the same time, I think people referencing this don't seem to understand how self-centered this perspective is. As the asker, you've got a stack of problems that might start with: well, I need to eat, so I got this job, so I need to do this task, ... (20 technical problems later), so I'm trying to do Y. How am I supposed to know how far up my stack _you_ want to go? If I knew I made a wrong step 3 problems ago, presumably I would have just asked about that problem.
The suggestions here are fine. Still, I think it's more important that the responder have some empathy and be willing to go back and forth a bit to understand someone's problem instead of expecting the asker to guess what information the responder is going to want.
Also, what's with the name "XY problem"? If "asking about Y when you want to do X" makes it an "XY problem", couldn't any problem involving any two things also be called an "XY problem"?
It's always good to ask the person about the context surrounding their question, but I also don't see much harm in seeking how to do Y, for the sake of Y. What is a 'strange problem to want to solve' anyways? To me, they are all just problems.
Yes, it is often the case that the person has the wrong idea of how to solve X, but this does not always say something about the validity of problem Y. Often times knowing how to do Y is valuable for other contexts besides X. We should try to be friendly and make it clear that Y is not a good way to achieve X without downplaying Y, necessarily.
Some past threads:
The XY Problem (2014) - https://news.ycombinator.com/item?id=20068686 - June 2019 (158 comments)
Ask HN: What's your favorite technical formulation (i.e., the XY problem)? - https://news.ycombinator.com/item?id=17344147 - June 2018 (1 comment)
The XY problem - https://news.ycombinator.com/item?id=13578522 - Feb 2017 (1 comment)
The XY Problem - https://news.ycombinator.com/item?id=10023882 - Aug 2015 (70 comments)
The X-Y Problem - https://news.ycombinator.com/item?id=52486 - Sept 2007 (1 comment)
Someone on HN a year or so back mentioned they like to call this ‘going up the rabbit hole’. It’s a great name, so it stuck with me.
Is there a name for when person A asks B and B thinks A has fallen victim to the XY probem but A really didn't and has indeed an unusual problem at their hands?
Overfitting?
In my experience, people who have proven fairly to themselves that they're in an odd situation can prove it to others pretty easily. "I'm not doing $Z because..."
Yes, the name is "Stack Overflow".
I've always called it "The XY problem problem". It's not usually an issue in person but in async messaging it can waste a lot of time if you're not careful. And it goes on forever "The XY problem problem problem" where someone is aware what an XY problem is but thinks this is for sure an XY problem problem so they refuse to spend time thinking otherwise. Then of course "The XY problem problem problem problem"...
In those async situations it's best to provide bits of information for both directions every time, in person it's usually best to collaborate.
YX Problem?
But sometimes this happens because the questioner wants to avoid other people's waste of time asking a more specific and limited question instead of a generic one. Often this happens because the environment where the question is asked is highly selective and does not accept too verbose and indirect questions. The solution is to be more open to conversation on both sides.
That isn't my experience at all. In contexts that are highly conversational, people constantly ask XY problems. It's hard to see that the path you went down so far may or may not be correct, so a lot of people just assume their last three determinations in solving their problem were valid.
Conversational environments certainly make it easier to root cause them, but it's often still painful.
Many will refer to stackoverflow since that's the reason this website was created in the first place. But one of the most important thing in solving problems in programming is context.
Here is one real question I got in an interview: How do you efficiently sort a table containing a million record in JavaScript?
My question was "in the front end?"
And my answer was it's probably not a good idea to sort that much data in the front end since the user will most likely not be able to consume that much data. Since it was an interview, I explained how to sort the table anyway.
Sorting in the backend makes sense, but even then using a database is more efficient then doing it in JavaScript.
If this question was on SO, I'd probably answer: You shouldn't do that in the front end, explain why. And of course they will get pissed for not answering how.
But it is nice when you stumble across an answered question that fits your use case.
For instance, if I was making heavy use of local storage where I have no back end, it is nice if that question is already answered. At that point I don't really care if the previous user got a better method, that's what I need to do now.
Of course they would be pissed. You spammed something into the answer field that does not answer the question. Just write a comment instead.
I've found that this issue crops up in situations where someone has a new app idea. They don't possess the skills to create it themselves because they're in a different domain.
They ask you about building Y, maybe even Z but they don't want to give X away in case someone steals their 'disruptive product'.
There is too little information to go forward, too little trust. Project doesn't take off.
"the world wasn't ready for X, anyway", they say. Whatever that was.
Had a Product Manager who would always ask for Y, but had ego issues and would shut down when asked for context, examples, or client problem statements. Too many times we built Y then we had to face the consequences of not building X when put in front of customers. Very frustrating.
To call the XY learning QA a problem is akin to calling learning to swim a problem. It can be a problem on a sinking ship but not at the community pool.
I’ve heard this cited by a couple ctos I’ve worked for. It’s a popular metaphor in the engineering department. I think it’s articulating an important message, but in an ineffective way. The name “XY Problem” is too vague and easy to forget. I prefer simpler messages like:
- What’s the root cause of the problem?
- Is this a solution looking for a problem?
As software engineers, part of our job is naming things well and the “XY Problem” isn’t a great name IMO.
You're right the "XY problem" is vague. But that's exactly why engineers cling to it. The concept cloaks a messy, human interaction in the guise of math & logic. It enables an answerer to dissect their questioner without bearing the cost of the questioners feelings. It inverts the power dynamic, basically.
That duplicity makes "XY" useless as an analytic tool to improve inquiries. But as a political cudgel to stop inquiries, I think "XY" can be effective. When outsiders are forced to constantly justify and explain themselves in detail, in triplicate, then the price of Q&A will eventually increase to the point where no one wants to ask.
I think a CTO who is uncomfortable with inquiries will find the "XY problem" a much needed mental gymnastic.
Well said! Cloaking a messy human interaction in the guise of math and logic is an effective way to communicate with engineers. Never thought of it that way.
This is the entire game in consulting. Your client comes to you asking for something but with certain expectations in mind. The job of a good consultant is to meet those expectations - stated or not. You learn pretty quickly how to figure out what they’re really asking.
There's also the Big Bad consulting trope which has it all backwards.
Client states they need something like Y, consultants assess the situation, understand they should do X but keeps it to themselves, the parties come to an agreement to solve Y and do so. Client states they need something like X..
In my experience it’s usually more client states they need Y, consultants assess the situation and recommend X, but the client still insists on Y. 6 months later they come back to the consultant and ask for X because Y didn’t work.
Yes, I've experienced as much. Reality gives a more nuanced impression on things.
Content aside (good points!), I love the site's simple layout. Though I did have some difficulty reading the code blocks because of the low contrast.
The author apparently wants to reduce their stress level by getting people to stop asking XY questions. They should become a Buddhist monk instead.
My wife does this all the time. I didn't know there was a name for it!
By now I know to ask her what the actual problem is right up front.
Be careful, she might answer that you are the actual problem. I’m pretty certain that’s what my wife would tell me!
Reminds me of the classic stack overflow answer to "RegEx match open tags except XHTML self-contained tags" [1]
1. https://stackoverflow.com/questions/1732348/regex-match-open...
Sometimes the XY problem occurs because the fact that X is being worked on is a company trade secret and the reporter tries to turn it into Y, which can be disclosed. This isn't always successful.
http://3e.org/xy.png
Nice touch: Angela and Obama instead of Alice and Bob
This shows up in the library space as the Reference Interview: https://en.wikipedia.org/wiki/Reference_interview
Patrons engaged in research show the same pattern and it's important for a librarian to accurately assess what the patron is truly looking for.
Also known as the "I don't know the answer to your question, but here's an answer to a different question so I can look smart" problem.
That's not my experience. A lot of the time there is a VERY straightforward answer, e.g. "here's this evil metaprogramming thing" or "here's where you access this legacy representation with bitey cornercases" or whatever, which is trivial to provide (but also harmful).
Also the "I'm withholding simple answers to simple questions until you give me a full backstory".
Of course people who present you with an XY problem are often the same sorts of people who begin the conversation with my most hated trope of them all...
"Asking to ask"
(Often coupled with diverting the conversation from a public forum, where it can be useful to others, into a private one-on-one conversation where you suddenly become on-the-hook for solving all of their issues.)
This is similar to the "faster horse" quote. If you care about helping someone, it's important to understand what they really need.
That said, I enjoy giving literal answers to things. Sometimes it's a fun challenge, others I'm just being a smartass, and occasionally it's a teaching opportunity. A few times I've done this to younger team members, then set myself a reminder to check on them to see if they figured out why that's not the best way.