Introduction
Anyone who ventures into programming will find themselves on Stack Overflow at some point, looking for answers on how to debug the most obscure of bugs (anyone from before the era of GPT-3, anyway). It’s highly likely then that you know the pain of asking for help with an implementation, only to get downvoted to oblivion and temporarily blocked from asking questions, and be left wondering why you even bothered to ask
I used to think that there was a massive problem of elitism amongst the people who went around replying to these posts, and that in a way, they were almost gatekeeping knowledge from the newbies, and it turned me off completely from the site. While I do still believe that there are issues such as overzealously marking new posts as duplicate, or even resorting to flat-out insulting the authors of some questions, I’ve come to realize that the fundamental root of the often problem lies in how we ask questions, in the form of something known as The XY Problem.
What is the XY Problem?
The XY Problem is a communication issue that arises when someone looking for help puts focus on their attempted solution (Y) rather than the actual problem they’re trying to solve (X). This can lead to ineffective solutions and wasted time and energy, both on the part of the person asking for help, and on the part of those who are trying to provide it.
It usually goes a little something like this:
- User wants to do X
- User doesn’t know how to do X, but thinks that they can find a solution if they just manage Y
- User doesn’t know how to do Y either
- User asks for help with Y
- Others are confused because Y seems like a strange problem to want to solve
- After much interaction and wasted time, it finally becomes clear that the user really needed help with X, and that Y wasn’t even a suitable solution for X.
We get stuck on what we believe is the solution and in doing so, fail to provide a broader context and requirements that would enable others to assist in solving the real problem more effectively.
How to avoid the XY Problem?
- Always include information about the broader picture X along with any attempted solution Y
- If someone asks for more details, provide them
- If you have ruled out other solutions already, say so and state the reason why.
Remember that if your diagnostic theories were accurate, you wouldn’t be asking for help right?
There’s also something to be said about the sunk cost fallacy, and our tendency to become heavily invested in an approach that we’ve already invested time, energy, and resources on, when the better idea would simply be to give it up and explore alternate solutions. Sometimes, the reason we’re so fixated on the Y of a problem, is that we believe there’s simply no other way to solve our specific problem, leading to tunnel-vision and lots of wasted time.
You’ll find that this is true even for the modern developer in 2024 who uses ChatGPT and Claude for all their programming-related questions and debugging. No matter how advanced and impressive these LLMs become, they do not posses the intuition or indeed, divination to understand the broader picture of your specific problem, unless you structure your questions well and provide all the necessary context. This is so important that there are entire full-time positions now devoted to “Prompt Engineering” - the act of skillfully tailoring prompts to guide the LLM towards a desired outcome.
There are several other things one can improve in their approach to asking questions, and I’m currently reading How To Ask Questions The Smart Way by Eric Steven Raymond, and I highly recommend that you do too. Coming back to the topic of Stack Exchange, I think it’s really important to understand this concept because it can lead to a lot of unproductive and undue frustration with the platform, something that I too felt after being blocked from posting questions after my very first post there. But as Eric bluntly explains in the section “On Not Reacting Like a Loser”, you will only find growth and improvement if you learn how to take criticism and use it to fix your approach to problem-solving:
Odds are you’ll screw up a few times on hacker community forums — in ways detailed in this article, or similar. And you’ll be told exactly how you screwed up, possibly with colourful asides. In public.
When this happens, the worst thing you can do is whine about the experience, claim to have been verbally assaulted, demand apologies, scream, hold your breath, threaten lawsuits, complain to people’s employers, leave the toilet seat up, etc. Instead, here’s what you do:
Get over it. It’s normal. In fact, it’s healthy and appropriate.
Conclusion
There’s a LOT to learn in software engineering. Most of us can barely keep up with all the new JavaScript frameworks that seem to come out every 3-4 days, much less be able to build with all of them effectively and without errors. It’s easy in the midst of all our technical issues, to forget the very-important (arguably sometimes more important) non-technical part of software engineering, which is communication and understanding.
I’m far too junior of a developer to speak on this with any authority, trust me. But I’ve definitely noticed that my ability to solve problems is directly proportional to the amount of documentation I read, thorough research for existing solutions on forums that I do, and the amount of context that I can accurately describe when asking for help–whether that’s to a senior, someone on Stack Exchange, or even to ChatGPT.
I hope you learned something out of this too :)