Probably a lot of comments will bounce off the title to discuss the XY problem in general, and especially stackoverflow. The article does claim to go further than XY though!
"Diagnosing the ask" and "When they’re missing the philosophy" seem to me like traditional XY problem answers - the user doesn't know what the right question is, we need to step back to guide them.
"When the product needs to change" on the other hand is about figuring out what users want in order to add it to the product. Which takes a lot of figuring out, because it adds debt and you can add things the wrong way. This feels much less condescending to me than traditional XY where it's just tech support for a dumb user. Instead now figuring out questions from enough users helps direct new features.
"When the right path is hidden" I think the text for this one could do more to discuss helping direct the product as well, specifically in terms of documentation, if https://perfetto.dev/docs/getting-started/periodic-trace-sna... exists why is it hidden instead of where people find it when wanting to visualize a long trace.
If you read the title and just want to talk about XY eh fine, but the article's last sentence is the difference, "Both sides almost always walk away with more than they came in with."
In the particular case of SO what is annoying is that even if the person who posed the X question really did actually have a Y problem and responders figured that out and solved Y, that doesn't help people who really have an X problem who come there later.
When people who really have an X problem find that every SO answer to X questions is an XY answer and try to ask a new X question clearlystating that they have looked at all those other questions and none of them answer X...their question gets quickly closed as a duplicate by the idiots that moderate SO.
The solution to this type of problem is typically escalation.
I have worked in IT support and the problem is that the vast majority are problems of users who won't read even the most basic instruction, error message or hint. That means two things (1) users suck at describing their problems ("My account does not work" which could mean anything from a full network fail to them having forgotten their password) and (2) actual technical problems where something really is the fault of the tech are the minority of cases.
This means when someone says their account doesn't work that could mean anything from the utterly absurd like their laptop being broken, over hardware failure (broken patch cable), all the way to actual technical problems like their email address containing an umlaut and being parsed wrong, and it wasn't a problem till the last update. Since the dumber reasons are much more common your issue will stay at the dumb level until you convinced someone it needs an actual technician to look at. And the best way to skip to that level quickly is to do your homework, make sure the rest of the reasons aren't it and communicate clearly what is working and where things fail and how that failure presents itself. Basically by not coming across as one of the dumb reasons as much as you can.
In my whole IT support time I have probably received one well-written request.
> This feels much less condescending to me than traditional XY where it's just tech support for a dumb user. Instead now figuring out questions from enough users helps direct new features.
I don't really agree. I think the blog post tries to put together a case that a textbook XY problem is not a XY problem because they explore a way to force Y onto all users seeking X. It's still condescending to accuse users of being confused and asking the wrong questions. It doesn't make it less condescending if they can claim success in persuading users to give Y a try.
A fairer and better way to frame this is to claim they avoid introducing changes to the service by convincing users to accept tradeoffs, such as tolerating a less than satisfying solution today than waiting for an acceptable solution tomorrow. At the end of the day users still do not get what they want. That is a problem, not a reason to pat themselves in the back.
If a user says: "how do I do X in your product", I think a response of "Hey, there's not a great way to do X right now. We're thinking about the best way to make that work in the product though, and want to better understand what you're trying to do and why you need to do X. Would you mind spending 30-45 minutes talking to us about your specific needs in exchange for a $XX incentive?" strikes me as very different from what you're describing
> *Instead, the confusion that produced the wrong question is itself an opening, and the conversation it sparks is valuable to both sides. The user walks away with a better mental model of the tool. I walk away with a clearer picture of where the product confuses people.*
The blog post clearly frames the user as a confused individual who, by asking for X, has a bad mental model and requires guidance to be directed towards Y.
It's not only terribly condescending, it also spins the problem as an issue caused by ignorant and clueless users.
Back when I worked at Google there was an internal page someone put up that denoted what they called "the YX problem": the observation that the XY problem, applied to a sufficiently great extent, creates an environment where more productivity is lost convincing one's interlocutor that X is in fact the correct problem to solve than would be lost by chasing X and having to later pivot to Y if that turned out to be wrong.
It's extraordinarily aggravating when it happens. I really wish it was something we talked about more.
In my experience, the ones who most fervently believe they have such “clues” are often the same ones who lack them. I can’t tell you the number of times I’ve encountered engineers who become indignant when someone tries to redirect them to safe, scalable, and operable ways to solve problems. What they often want is to have the problem solved their way because it would be less work for them or otherwise advance their own personal interests, regardless of the problems that doing so would create or the risks it would pose. They don’t want a discussion; they want a rubber stamp.
> because it would be less work for them or otherwise advance their own personal interests
I've seen plenty of people rationalize not wanting to learn a new thing with those words.
The thing is, this is a rationalization too. It may be true, it may also be false. The only certain thing is that they don't want to learn a new thing.
That said, this happens in small circles, where you know the context of the person asking the question. People assuming they know why a stranger is asking something tend to be wrong too.
I mean, yeah, if you’re selling someone a product it’s pretty fair for them to expect, or at least hope, that it will reduce their workload and advance their personal interests…
Can confirm, I had a coworker doing that a while ago and it was incredibly frustrating. After going through the whole quizzing you still end up with no answer to your actual question, as if they were more interested engaging with their own process and not what you were actually asking
There's a fine line here when dealing with customers. Sometimes it works well to answer the exact question, if you can, and follow up with "Can you tell me a bit why you're asking so I can understand a bit more about the problem?" Once you tease out a bit more about how they got there, it's often possible to offer better solutions and it never feels like you blew off their original ask.
People who really don't have a clue ignores the added context and answers the question that wasn't asked anyway, because they've answered that particular question before.
This is in many ways what user experience designers might call "the five whys". People don't express their problem in the form of a problem, but a solution they've thought of. They don't say "I'm hungry, find me a way to get food" they say "I need a ride to the grocery store".
I always teach designers to remember that users and stakeholders aren't software designers. So we should pay careful attention to their problems, but not assume their solution is the right one (though it can be).
Getting these questions answered without insulting the requester (especially stakeholders) is an important soft skill. You have to make them feel heard, intelligent, and supported.
> If you do this with people who know their stuff, they will just take it as you undermining them.
That's because they realise that other party is simply trying to answer the question they wished was asked instead of the question that was actually asked.
I think it depends on the individual and the culture. In a strong culture, engineers don’t their egos get in the way of healthy conversations and will be capable of defending their position against probing questions without it upsetting them.
> In a strong culture, engineers don’t their egos get in the way of healthy conversations and will be capable of defending their position against probing questions without it upsetting them.
Everything is great when you don't have constraints. If I, however, have to spend 30-60 minutes justifying something to you every time I come to you, then you definitely are the problem.
Using the wrong tool to solve a problem is not inherently problematic. If it's a one-off and it solves the problem, abusing an existing tools is about the finest engineering imaginable. Sure, if it's a long term solution to something important, I can understand the pushback.
As other commenters have said: I'm all for a deeper discussion provided two things:
> If I, however, have to spend 30-60 minutes justifying something to you every time I come to you, then you definitely are the problem
That might be true if you’re skilled in whatever the particular subject matter is.
But what if you’re not? Have you ever had a colleague that kept trying to solve problems the wrong way? Such people do exist.
I don’t personally withhold answers, but when I suspect something is amiss, I ask probing questions in order to better understand the deeper problem underlying the question. Then I collaborate on a better answer, if one exists, with my colleague.
Yes it's called being XYed and it's infuriating when some condescending person decides they know so much better than you that even your question is wrong.
What resonated with me in this article was that there's something about question itself that seems off. And that's even more the case if you answer a lot of people's questions on similar topics. This guy's post is obviously coming rom that standpoint, he's an expert on the software he's supporting people to use.
But if you genuinely find that you're often being guided to Y when your actual need is X then perhaps you need to think about how you approach it. For example, are you including enough context of why you're asking the question in the first place?
After becoming familiar with XY I have learned to specify "yes this is really the problem I'm trying to solve". Invariably you still get people asking "are you sure".
If you are sure, you're generally not going to answer "Yea, I'm sure", you'll answer "Yea, I'm sure because A, B, C"
In fact, if you're asking on a forum about how to solve X, be sure to add "because A, B, C" or you're just wasting everyone else's fucking time. The more details you put up front, the more apt you're going to get the answer you're looking for in the first place instead of wasting everyone elses time of exploring the problem space.
> you're just wasting everyone else's fucking time
you sure you're not the one wasting people's time by demanding they convince you of something you don't have any need to be convinced of - like did you know that just answering a question at face value is a completely plausible option?
In this context your question is likely a request for help, yet you're unwilling to take the time to include the relevant information in that question.
The fact you're complaining about the this, rather than modifying your own behaviour in a way that improves people's chances of helping you, seems quite extraordinary.
Funny term to use as it has a very particular meaning of something that cannot/should not be interpreted because it is well defined.
This is a common flaw of the programmer type, especially when they go about writing code and documentation. That is, that what they are writing can only be interpreted in one way.
Then they toss it out into the real world and it turns out every human has a different interpretation, the runtime operates differently based on the phase of the moon, and even the compiler seems to be making its own best guess based on undefined behavior.
The value of int is typically well defined, but once you start stacking up these well defined bits, subjectivity quickly takes over.
> 3. Figurative Usage ("Taking at face value")When used in everyday language as a phrase, "taking something at face value" means accepting a statement, situation, or person exactly as they appear or are presented, without digging deeper for hidden meanings, motives, or questioning their authenticity
...
not sure what version of the english language you're using but in colloquial english "taking something at face value" means having a good faith interpretation.
What if they don't, in fact, have more experience than me?
Edit: this is why tech people are insufferable socially. In any other walk of life assuming you know more than someone is a manifestly obvious faux pas.
> Then solve the problem yourself? Why are you asking someone who knows less than you?
you seem to completely misunderstand XY: it's not someone giving you the right solution to your problem which you aren't capable of arriving at yourself. it's someone telling you the problem you're having isn't the one you should be solving. it happens very frequently that some arrogant person is 100% certain X problem isn't possible, or isn't really happening, or isn't really the source of issues and they try to gaslight you into believing you've made a mistake in your reasoning and you should solve problem Y instead. you know... kind of like how you're doing right now...
This is a hypothetical, not an assumption. I’m interested in your response to the hypothetical.
As a side note, experience isn’t a unidimensional value that is directly comparable. You can have more experience than someone else in one dimension, and the other person can have more experience than you in a different dimension. I’d never argue with my mother about how to perform a blood draw.
> experience isn’t a unidimensional value that is directly comparable. You can have more experience than someone else in one dimension, and the other person can have more experience than you in a different dimension.
When two such people communicate, it's rarely clear who knows more. Typically, I know more about the task I'm working on, and he knows more about X, and that's why I'm asking him about X. Sure, if he wants to know what I'm working on - happy to engage, provided he doesn't withhold the information I'm asking for.
I already implicitly responded: this should be handled like in any other walk of life - a few probing questions, maybe a preceding dialogue, etc. Admittedly tech people probably don't know how to handle this outside of tech either <shrug>
“well the answer to your immediate question is X but that’s a pretty strange thing to ask for because of reason Y. Can you tell me more about the wider problem you’re trying to solve?”
This is the right way to answer these questions. SO was famous for the infuriating "You shouldn't do X, so as a favor to you I'm not going to tell you how." or "Before I answer thee, thou must first answer me these questions three!" kinds of answers.
Edit: Don't want to take credit for this. It's a quote from the article.
Your way is good because it answers my question first. I've been wanting to do a weird thing X and had to first spend half an hour convincing people that yes, I really do know what I'm doing, so they'd give me the one-liner answer I came for.
Ultimately, it should be on me to choose whether I want to risk doing X or whether I want to take up your offer to explain Y, not the "as a favor to you, I'm not going to tell you how" way you described.
If, as you admit, X was a “weird thing,” what’s wrong with taking the time to persuade your peers that it’s worth pursuing? That’s how you build consensus on a team and construct a decision record to help future teammates and other stakeholders understand it.
I do want to clarify my point of view since there does seem to be some interpretation which I didn't entirely anticipate (wholly my mistake):
1. I'm not claiming that every interaction with a user needs to be turned into a full discussion. There are lots of cases where the answer is "this is what you're looking for, here's a link to the docs". In my experience, this has gone down a lot over time because people tend now to rely on AI much more heavily for those sort of questions in the first place so they won't even reach you. But it does happen and in that case, the best thing for both sides is to point to the documentation and move on.
2. If I am going to employ this strategy, I always try and both give the direct answer to the question and, as a separate point, ask them the context. Quoting directly from the post:
> well the answer to your immediate question is X but that’s a pretty strange thing to ask for because of reason Y. Can you tell me more about the wider problem you’re trying to solve?
3. This does necessitate that you are in some sense an "knowledgeable" on the problem space someone comes to you with: I would never employ this strategy in an area I didn't already feel I was quite well equipped to give my 2c on.
4. If the person I'm speaking to I know for a fact is already knowledgeable on an area, I would be very hesitant to use this approach because I try and be charitable with assuming that people generally know what they are talking about. While yes, I'm not going to be perfect every time in judging this, I think you can get a pretty good sense from the way they ask their question and how clearly they respond to your initial answer whether they are not (ties to 3 as it requires you are good enough in the space to judge this).
5. If someone pushes back, I will always defer to their read of the situation, I'm not here to make people do what I suggest, I will simply say "well I think you should do/not do A because of B reason but at the end of the day your call" and leave it at that. I think it's a good thing to be able to have respectful discussions on topics even if both sides agree to disagree.
The funny thing is, this works well with people too. Not to literally not answer, but dig into the question or problem they bring up to understand their mental model and whether there was just a miscommunication or an actual disagreement.
Domo is now apparently "Governed Data for AI Agents".
The desperation for commodity services and second-tier products to stay relevant is widespread. See also intercom.com "The only helpdesk designed for the AI Agent era".
I think this comment got attached to the wrong article somehow. Not relevant here but probably relevant to "Enough with the AI FOMO, go slow-mo, says Domo CDO"[0]
Probably a lot of comments will bounce off the title to discuss the XY problem in general, and especially stackoverflow. The article does claim to go further than XY though!
"Diagnosing the ask" and "When they’re missing the philosophy" seem to me like traditional XY problem answers - the user doesn't know what the right question is, we need to step back to guide them.
"When the product needs to change" on the other hand is about figuring out what users want in order to add it to the product. Which takes a lot of figuring out, because it adds debt and you can add things the wrong way. This feels much less condescending to me than traditional XY where it's just tech support for a dumb user. Instead now figuring out questions from enough users helps direct new features.
"When the right path is hidden" I think the text for this one could do more to discuss helping direct the product as well, specifically in terms of documentation, if https://perfetto.dev/docs/getting-started/periodic-trace-sna... exists why is it hidden instead of where people find it when wanting to visualize a long trace.
If you read the title and just want to talk about XY eh fine, but the article's last sentence is the difference, "Both sides almost always walk away with more than they came in with."
In the particular case of SO what is annoying is that even if the person who posed the X question really did actually have a Y problem and responders figured that out and solved Y, that doesn't help people who really have an X problem who come there later.
When people who really have an X problem find that every SO answer to X questions is an XY answer and try to ask a new X question clearly stating that they have looked at all those other questions and none of them answer X...their question gets quickly closed as a duplicate by the idiots that moderate SO.
The solution to this type of problem is typically escalation.
I have worked in IT support and the problem is that the vast majority are problems of users who won't read even the most basic instruction, error message or hint. That means two things (1) users suck at describing their problems ("My account does not work" which could mean anything from a full network fail to them having forgotten their password) and (2) actual technical problems where something really is the fault of the tech are the minority of cases.
This means when someone says their account doesn't work that could mean anything from the utterly absurd like their laptop being broken, over hardware failure (broken patch cable), all the way to actual technical problems like their email address containing an umlaut and being parsed wrong, and it wasn't a problem till the last update. Since the dumber reasons are much more common your issue will stay at the dumb level until you convinced someone it needs an actual technician to look at. And the best way to skip to that level quickly is to do your homework, make sure the rest of the reasons aren't it and communicate clearly what is working and where things fail and how that failure presents itself. Basically by not coming across as one of the dumb reasons as much as you can.
In my whole IT support time I have probably received one well-written request.
> This feels much less condescending to me than traditional XY where it's just tech support for a dumb user. Instead now figuring out questions from enough users helps direct new features.
I don't really agree. I think the blog post tries to put together a case that a textbook XY problem is not a XY problem because they explore a way to force Y onto all users seeking X. It's still condescending to accuse users of being confused and asking the wrong questions. It doesn't make it less condescending if they can claim success in persuading users to give Y a try.
A fairer and better way to frame this is to claim they avoid introducing changes to the service by convincing users to accept tradeoffs, such as tolerating a less than satisfying solution today than waiting for an acceptable solution tomorrow. At the end of the day users still do not get what they want. That is a problem, not a reason to pat themselves in the back.
I don't think that's it at all.
If a user says: "how do I do X in your product", I think a response of "Hey, there's not a great way to do X right now. We're thinking about the best way to make that work in the product though, and want to better understand what you're trying to do and why you need to do X. Would you mind spending 30-45 minutes talking to us about your specific needs in exchange for a $XX incentive?" strikes me as very different from what you're describing
> I don't think that's it at all.
Quoted from the blog post:
> *Instead, the confusion that produced the wrong question is itself an opening, and the conversation it sparks is valuable to both sides. The user walks away with a better mental model of the tool. I walk away with a clearer picture of where the product confuses people.*
The blog post clearly frames the user as a confused individual who, by asking for X, has a bad mental model and requires guidance to be directed towards Y.
It's not only terribly condescending, it also spins the problem as an issue caused by ignorant and clueless users.
And it's a textbook example of a XY problem.
While this strategy is fine for clueless users, I suspect that it will lead to immense frustration for the ones with clues
Exactly.
Back when I worked at Google there was an internal page someone put up that denoted what they called "the YX problem": the observation that the XY problem, applied to a sufficiently great extent, creates an environment where more productivity is lost convincing one's interlocutor that X is in fact the correct problem to solve than would be lost by chasing X and having to later pivot to Y if that turned out to be wrong.
It's extraordinarily aggravating when it happens. I really wish it was something we talked about more.
In my experience, the ones who most fervently believe they have such “clues” are often the same ones who lack them. I can’t tell you the number of times I’ve encountered engineers who become indignant when someone tries to redirect them to safe, scalable, and operable ways to solve problems. What they often want is to have the problem solved their way because it would be less work for them or otherwise advance their own personal interests, regardless of the problems that doing so would create or the risks it would pose. They don’t want a discussion; they want a rubber stamp.
> because it would be less work for them or otherwise advance their own personal interests
I've seen plenty of people rationalize not wanting to learn a new thing with those words.
The thing is, this is a rationalization too. It may be true, it may also be false. The only certain thing is that they don't want to learn a new thing.
That said, this happens in small circles, where you know the context of the person asking the question. People assuming they know why a stranger is asking something tend to be wrong too.
I mean, yeah, if you’re selling someone a product it’s pretty fair for them to expect, or at least hope, that it will reduce their workload and advance their personal interests…
There’s no product being sold here. The person is trying to solve some self-described problem on his own.
Can confirm, I had a coworker doing that a while ago and it was incredibly frustrating. After going through the whole quizzing you still end up with no answer to your actual question, as if they were more interested engaging with their own process and not what you were actually asking
There's a fine line here when dealing with customers. Sometimes it works well to answer the exact question, if you can, and follow up with "Can you tell me a bit why you're asking so I can understand a bit more about the problem?" Once you tease out a bit more about how they got there, it's often possible to offer better solutions and it never feels like you blew off their original ask.
People who really have a clue add enough context in their request to understand why they are trying to do the thing in question.
People who really don't have a clue ignores the added context and answers the question that wasn't asked anyway, because they've answered that particular question before.
This is in many ways what user experience designers might call "the five whys". People don't express their problem in the form of a problem, but a solution they've thought of. They don't say "I'm hungry, find me a way to get food" they say "I need a ride to the grocery store".
I always teach designers to remember that users and stakeholders aren't software designers. So we should pay careful attention to their problems, but not assume their solution is the right one (though it can be).
Getting these questions answered without insulting the requester (especially stakeholders) is an important soft skill. You have to make them feel heard, intelligent, and supported.
This isn't a black-and-white tactic. If you do this with people who know their stuff, they will just take it as you undermining them.
> If you do this with people who know their stuff, they will just take it as you undermining them.
That's because they realise that other party is simply trying to answer the question they wished was asked instead of the question that was actually asked.
I think it depends on the individual and the culture. In a strong culture, engineers don’t their egos get in the way of healthy conversations and will be capable of defending their position against probing questions without it upsetting them.
> In a strong culture, engineers don’t their egos get in the way of healthy conversations and will be capable of defending their position against probing questions without it upsetting them.
Everything is great when you don't have constraints. If I, however, have to spend 30-60 minutes justifying something to you every time I come to you, then you definitely are the problem.
Using the wrong tool to solve a problem is not inherently problematic. If it's a one-off and it solves the problem, abusing an existing tools is about the finest engineering imaginable. Sure, if it's a long term solution to something important, I can understand the pushback.
As other commenters have said: I'm all for a deeper discussion provided two things:
1. Both of us have the time.
2. You actually answer the question I asked.
Not providing an answer is patronizing.
> If I, however, have to spend 30-60 minutes justifying something to you every time I come to you, then you definitely are the problem
That might be true if you’re skilled in whatever the particular subject matter is.
But what if you’re not? Have you ever had a colleague that kept trying to solve problems the wrong way? Such people do exist.
I don’t personally withhold answers, but when I suspect something is amiss, I ask probing questions in order to better understand the deeper problem underlying the question. Then I collaborate on a better answer, if one exists, with my colleague.
How about answering the question and then add details later? IME that tends do work better.
[dead]
Yes it's called being XYed and it's infuriating when some condescending person decides they know so much better than you that even your question is wrong.
What resonated with me in this article was that there's something about question itself that seems off. And that's even more the case if you answer a lot of people's questions on similar topics. This guy's post is obviously coming rom that standpoint, he's an expert on the software he's supporting people to use.
But if you genuinely find that you're often being guided to Y when your actual need is X then perhaps you need to think about how you approach it. For example, are you including enough context of why you're asking the question in the first place?
After becoming familiar with XY I have learned to specify "yes this is really the problem I'm trying to solve". Invariably you still get people asking "are you sure".
If you are sure, you're generally not going to answer "Yea, I'm sure", you'll answer "Yea, I'm sure because A, B, C"
In fact, if you're asking on a forum about how to solve X, be sure to add "because A, B, C" or you're just wasting everyone else's fucking time. The more details you put up front, the more apt you're going to get the answer you're looking for in the first place instead of wasting everyone elses time of exploring the problem space.
> you're just wasting everyone else's fucking time
you sure you're not the one wasting people's time by demanding they convince you of something you don't have any need to be convinced of - like did you know that just answering a question at face value is a completely plausible option?
In this context your question is likely a request for help, yet you're unwilling to take the time to include the relevant information in that question.
The fact you're complaining about the this, rather than modifying your own behaviour in a way that improves people's chances of helping you, seems quite extraordinary.
>face value
Funny term to use as it has a very particular meaning of something that cannot/should not be interpreted because it is well defined.
This is a common flaw of the programmer type, especially when they go about writing code and documentation. That is, that what they are writing can only be interpreted in one way.
Then they toss it out into the real world and it turns out every human has a different interpretation, the runtime operates differently based on the phase of the moon, and even the compiler seems to be making its own best guess based on undefined behavior.
The value of int is typically well defined, but once you start stacking up these well defined bits, subjectivity quickly takes over.
> define: face value
> 3. Figurative Usage ("Taking at face value")When used in everyday language as a phrase, "taking something at face value" means accepting a statement, situation, or person exactly as they appear or are presented, without digging deeper for hidden meanings, motives, or questioning their authenticity
...
not sure what version of the english language you're using but in colloquial english "taking something at face value" means having a good faith interpretation.
What if they do, in fact, have the experience to “know better”?
What if they don't, in fact, have more experience than me?
Edit: this is why tech people are insufferable socially. In any other walk of life assuming you know more than someone is a manifestly obvious faux pas.
Then solve the problem yourself? Why are you asking someone who knows less than you?
We need a word for the inverse of being XY'd for when someone asks an XY question but is too proud to accept there's a better alternative to X
> Then solve the problem yourself? Why are you asking someone who knows less than you?
you seem to completely misunderstand XY: it's not someone giving you the right solution to your problem which you aren't capable of arriving at yourself. it's someone telling you the problem you're having isn't the one you should be solving. it happens very frequently that some arrogant person is 100% certain X problem isn't possible, or isn't really happening, or isn't really the source of issues and they try to gaslight you into believing you've made a mistake in your reasoning and you should solve problem Y instead. you know... kind of like how you're doing right now...
You are right, we are operating on different definitions of the XY problem. The definition I prefer is the one described here: https://xyproblem.info/
This is a hypothetical, not an assumption. I’m interested in your response to the hypothetical.
As a side note, experience isn’t a unidimensional value that is directly comparable. You can have more experience than someone else in one dimension, and the other person can have more experience than you in a different dimension. I’d never argue with my mother about how to perform a blood draw.
You answered your own question:
> experience isn’t a unidimensional value that is directly comparable. You can have more experience than someone else in one dimension, and the other person can have more experience than you in a different dimension.
When two such people communicate, it's rarely clear who knows more. Typically, I know more about the task I'm working on, and he knows more about X, and that's why I'm asking him about X. Sure, if he wants to know what I'm working on - happy to engage, provided he doesn't withhold the information I'm asking for.
Useful conversation relies on mutual purpose.
I already implicitly responded: this should be handled like in any other walk of life - a few probing questions, maybe a preceding dialogue, etc. Admittedly tech people probably don't know how to handle this outside of tech either <shrug>
“well the answer to your immediate question is X but that’s a pretty strange thing to ask for because of reason Y. Can you tell me more about the wider problem you’re trying to solve?”
This is the right way to answer these questions. SO was famous for the infuriating "You shouldn't do X, so as a favor to you I'm not going to tell you how." or "Before I answer thee, thou must first answer me these questions three!" kinds of answers.
Edit: Don't want to take credit for this. It's a quote from the article.
Your way is good because it answers my question first. I've been wanting to do a weird thing X and had to first spend half an hour convincing people that yes, I really do know what I'm doing, so they'd give me the one-liner answer I came for.
Ultimately, it should be on me to choose whether I want to risk doing X or whether I want to take up your offer to explain Y, not the "as a favor to you, I'm not going to tell you how" way you described.
If, as you admit, X was a “weird thing,” what’s wrong with taking the time to persuade your peers that it’s worth pursuing? That’s how you build consensus on a team and construct a decision record to help future teammates and other stakeholders understand it.
They aren't my peers, and they don't have a stake in it. I'm usually just asking on IRC.
I do want to clarify my point of view since there does seem to be some interpretation which I didn't entirely anticipate (wholly my mistake):
1. I'm not claiming that every interaction with a user needs to be turned into a full discussion. There are lots of cases where the answer is "this is what you're looking for, here's a link to the docs". In my experience, this has gone down a lot over time because people tend now to rely on AI much more heavily for those sort of questions in the first place so they won't even reach you. But it does happen and in that case, the best thing for both sides is to point to the documentation and move on.
2. If I am going to employ this strategy, I always try and both give the direct answer to the question and, as a separate point, ask them the context. Quoting directly from the post:
> well the answer to your immediate question is X but that’s a pretty strange thing to ask for because of reason Y. Can you tell me more about the wider problem you’re trying to solve?
3. This does necessitate that you are in some sense an "knowledgeable" on the problem space someone comes to you with: I would never employ this strategy in an area I didn't already feel I was quite well equipped to give my 2c on.
4. If the person I'm speaking to I know for a fact is already knowledgeable on an area, I would be very hesitant to use this approach because I try and be charitable with assuming that people generally know what they are talking about. While yes, I'm not going to be perfect every time in judging this, I think you can get a pretty good sense from the way they ask their question and how clearly they respond to your initial answer whether they are not (ties to 3 as it requires you are good enough in the space to judge this).
5. If someone pushes back, I will always defer to their read of the situation, I'm not here to make people do what I suggest, I will simply say "well I think you should do/not do A because of B reason but at the end of the day your call" and leave it at that. I think it's a good thing to be able to have respectful discussions on topics even if both sides agree to disagree.
The funny thing is, this works well with people too. Not to literally not answer, but dig into the question or problem they bring up to understand their mental model and whether there was just a miscommunication or an actual disagreement.
> with people too
I'm pretty sure the article is about interacting with people.
> there isn’t an easy way to do that, but what’s leading you to collect traces large enough to want to split?
That's basically every first Stack Overflow answer. It was obnoxious then, and it's obnoxious now.
And sometimes, I get some bloviating idiot who DEMANDS that my question is a XY issue, constructs their own strawman, and solves THEIR strawman.
No, I had a reason why I asked the way I did. You're just too arrogant and think only your procedure is the "right" one.
I believe this is the process that defines Julia Evans' writing (and cartooning)!
Domo is now apparently "Governed Data for AI Agents".
The desperation for commodity services and second-tier products to stay relevant is widespread. See also intercom.com "The only helpdesk designed for the AI Agent era".
I think this comment got attached to the wrong article somehow. Not relevant here but probably relevant to "Enough with the AI FOMO, go slow-mo, says Domo CDO"[0]
[0]https://news.ycombinator.com/item?id=48179029
Facepalm. Thank you.