“There are no bad questions.”
It’s a popular saying in tech. The intent is good: we want to create psychological safety and lower the barrier for juniors asking for help. But while there may be no bad intentions behind a question, there are certainly poorly framed ones. These aren’t bad because the problem is simple; they are bad because the thinking behind them is incomplete.
I was reminded of this recently in a DevOps community chat. Someone asked for help with a query they were stuck on. No context. No constraints. No indication of the end goal. People asked for clarification, but the follow-ups added little. Eventually, the thread just died.
What actually broke down in that thread wasn’t knowledge—it was the distribution of thinking.
Transferring the Load
We tend to view questions as simple requests for information. But really, they are transfers of cognitive load.
When you ask a vague question, you aren’t just asking for an answer. You are asking the listener to reconstruct your mental model, guess at your missing constraints, and explore the solution space from scratch. You are asking them to do the work you haven’t done yet.
A well-formed question carries the weight of that work already. A poorly formed one offloads it entirely onto the listener. This is why vague questions feel “low effort.”
The Difference in Practice
You see this friction most clearly when troubleshooting.
The High-Load Question:
“My deployment isn’t working. It works on my machine but fails in prod. Any idea what’s wrong?”
There is no meaningful way to answer this. The responder is forced to play a guessing game. What is being deployed? Where? What does “not working” actually mean?
The Low-Load Question:
“I’m deploying a containerized service to Kubernetes. The pod starts but crashes after ~30 seconds. Logs show a database connection timeout. The database is reachable from other pods in the same namespace. What else should I be checking?”
This question respects the responder’s time. It contains observed behavior, constraints, and eliminated possibilities. Even if the responder doesn’t know the answer, they know where to look next.
The XY Trap
Formulating a good question is hard because it forces you to confront the shape of the problem before you understand it. It forces you to avoid the “XY Problem”—asking how to fix your attempted solution (Y) instead of the actual root problem (X).
For example: You ask how to increase a connection timeout (Y), when the real issue is that your service depends on a database that isn’t ready yet (X).
To ask a good question, you have to back up and define the reality of (X):
- What exactly is failing?
- What outcome am I actually trying to achieve?
- What assumptions am I making?
Answering these forces you to think. And this is where something interesting happens: The act of preparing the question often dissolves the problem.
Engineers experience this constantly. You start writing a bug report and realize it’s a race condition. You draft a message to a staff engineer and solve it halfway through. The answer didn’t come from outside; it emerged because you were forced to structure your confusion.
The AI Parallel
This rigorous definition of the problem is exactly what modern tools demand of us.
The rise of LLMs has taught us this lesson by force. They call it “Prompt Engineering,” but it’s really just rigorous questioning. If you give ChatGPT a vague prompt, you get a hallucination. If you give a senior engineer a vague question, you get a decline to the meeting invite with a ‘?’.
In an era of instant AI and abundance of answers, the quality of your question matters even more. Clarity produces insight; confusion just produces noise.
The Pre-Send Test
Before you ask a technical question—to a colleague, a forum, or an AI—run it through this filter. If you can’t answer these, the question isn’t ready.
- Context: Where is this running, and what is different from where it works?
- Goal: What outcome do I actually want (not just the method I’m currently trying)?
- Failure: What observable behavior proves it is broken?
- Attempts: What explanations have I already eliminated?
Instead of treating questions as something you ask before thinking, treat them as the final artifact of thinking.
When you can articulate the gap between what you know and what you need, you are usually already halfway to the answer. Good questions aren’t requests for answers. They are evidence of work already done.