Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The XY Problem (2014)

xyproblem.info

Post reply on HN
Print view View original

101–110 of 111 posts

Re: The XY Problem (2014)

#101

Post by anoncake »

dirkt wrote: post #83
coldtea wrote: post #43

Earlier quoted context omitted.

> 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…

> 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.

Re: The XY Problem (2014)

#102

Post by anoncake »

firefoxd wrote: post #52

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…

Of course they would be pissed. You spammed something into the answer field that does not answer the question. Just write a comment instead.

Re: The XY Problem (2014)

#106

Post by wayoutthere »

Jiocus wrote: post #69
wayoutthere wrote: post #21

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.

Re: The XY Problem (2014)

#107

Post by Can_Not »

dirkt wrote: post #83
coldtea wrote: post #43

Earlier quoted context omitted.

> 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…

> 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.

> 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.

Re: The XY Problem (2014)

#108

Post by hitekker »

peterthehacker wrote: post #53

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 an…

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.

Re: The XY Problem (2014)

#109

Post by Can_Not »

tedunangst wrote: post #10

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.

Also the "I'm withholding simple answers to simple questions until you give me a full backstory".

Re: The XY Problem (2014)

#110

Post by Jiocus »

wayoutthere wrote: post #106
Jiocus wrote: post #69

Earlier quoted context omitted.

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.
Post reply on HN