How to ask a technical question that actually gets answered

There is a skill that separates developers who get unstuck quickly from developers who stay stuck, and it is not technical ability. It is the ability to ask a question that someone can actually answer.

Most questions that go unanswered are not ignored because people are unhelpful. They are unanswered because answering would require the reader to do twenty minutes of work first — guessing at the setup, imagining the error, asking three clarifying questions. Faced with that, most people move on.

The good news is that this is a mechanical skill. There is a format, it takes about five minutes, and it reliably turns an hour of back-and-forth into a two-minute answer.

Why bad questions fail

Here is a real shape of question, of the kind posted thousands of times a day:

My API is not working. I get an error when I try to fetch data. Any ideas?

Nobody can answer this. Not because they do not know the answer, but because there are several hundred possible answers and no way to narrow them. Which API, yours or someone else's? What error? At what point? Did it ever work?

Anyone who wants to help has to start by interrogating you, and each round trip takes hours if you are in different time zones. Most people will not begin.

Compare:

Fetching from our internal orders API returns 401 in production but works locally. Node 20, using fetch with a bearer token from an environment variable. The token is definitely set in production — I logged its length and got 64, same as local. The same token works in curl from my machine. It started after we moved to the new hosting on Tuesday.

That is answerable, possibly in one line, and several plausible causes have already been eliminated by the asker.

The format

Six parts. It works for a colleague, a forum, an issue tracker, or a support session.

1. What you are trying to do. One sentence, in terms of the goal rather than the method. This matters more than people think, because sometimes the answer is that you are solving the wrong problem — and nobody can tell you that if they only see your attempted solution.

2. What you expected to happen.

3. What actually happened. The specific behaviour, plus the complete error as text.

4. What you have already tried, and what each attempt told you. This is the part that saves the most time and the part most people leave out.

5. Your environment. Language and version, framework and version, operating system, and anything relevant about where it runs. Version numbers matter far more often than beginners expect.

6. The smallest reproduction you have. Ideally something someone can run.

Optionally, but valuably: what changed. If it used to work, say when it stopped and what happened around then.

The rules about error messages

Paste the complete error, as text. The whole stack trace, not the last line. You do not know which part is significant — that is why you are asking.

Never a photograph of a screen. It cannot be searched, copied, or read on a phone. It is the single fastest way to make people skip your question.

Use code formatting. Unformatted stack traces are unreadable, and in some chat tools the formatting mangles quotes and backslashes into something that no longer matches the real error.

Redact secrets, and say that you did. Replace the token with REDACTED rather than deleting the line, so the structure stays visible. And if a real key ever appeared in a message, rotate it — assume it is compromised.

Show what you tried, not just that you tried

"I have tried everything" tells the reader nothing and slightly annoys them. What helps is the narrowing:

I checked the token is present in production (logged its length, 64 characters, same as local). I tried the same token with curl from my laptop against the production URL and it worked, so the token itself seems valid. I compared the request headers by logging them on both sides and the only difference is that production sends an extra x-forwarded-proto header.

Every sentence there eliminates a whole branch of possibility. The reader can now skip straight to what remains, and they can see that you are worth spending time on — which, honestly, is part of what determines whether strangers help you.

This is also why the debugging method and question-asking are the same skill viewed from two sides. If you have narrowed properly, the question writes itself. If you cannot write the question, you have not narrowed yet.

The minimal reproduction

The strongest thing you can attach is a small piece of code that fails when run.

To build one, start from your failing case and remove things until removing anything more makes the failure disappear. Strip the framework, the database, the other services, the UI.

This is worth the effort even if you never send it, for a reason worth internalising: roughly a third of the time, the bug becomes obvious while you are shrinking it. The act of removing variables is the act of finding the one that matters.

If you cannot produce one — because it only fails in production, or only with real data — say so explicitly, and describe precisely what you cannot reproduce and what you think differs. That is itself useful information.

Where to ask

Your team first, in a channel rather than a direct message, if the culture allows. Public questions get answered by whoever is free, and the answer helps the next person.

The project's own issue tracker or discussion forum, for library-specific problems. Search closed issues first; the answer is very often there.

Public Q&A sites, for general problems. Read the tag's rules; they are stricter than they look and following them raises your answer rate considerably.

Someone experienced, directly, when the problem is specific to your codebase and no amount of general search will help. That is what job support is for.

One note on chat tools: do not send "hi" and wait. Send the whole question in one message. The other person may see it hours later, and if all they have is a greeting, nothing can happen until you are both online again.

Asking about design, not bugs

Some questions are not "why is this broken" but "how should I do this". These need a different shape:

• The constraint set. What must be true? Volume, latency, budget, existing stack, team skills, deadline.
• What you have considered, and why each option worries you. This is the whole question, really.
• What you are optimising for. Speed to ship, maintainability, cost, or correctness. These conflict, and an answer optimised for the wrong one is useless.
• What you are not allowed to change.

Without constraints, every design answer is "it depends", and that is not the answerer being evasive — it genuinely does.

After you get an answer

Say whether it worked. Not just politeness. If you vanish, the next person with your problem finds a question with no confirmed resolution.

Post what actually fixed it, especially if it was not the suggested answer. "Turned out to be a proxy stripping the Authorization header" is worth more to the next reader than the entire thread above it.

Ask why, if you do not understand it. A fix you do not understand is a fix you cannot adapt. The follow-up question is usually welcome, because it signals you are trying to learn rather than collect a patch.

Do not delete the question once solved. It is now the answer for someone else.

The part that sounds like a trick

A significant share of well-written questions answer themselves before they are sent.

The reason is straightforward: the format forces you to state your assumptions explicitly, and stating an assumption is often enough to notice it is wrong. You type "the token is definitely set in production" and pause, because you realise you have never actually checked in the deployed environment, only in the build logs.

This happens often enough that it is worth writing the question out in full even when you have nobody to send it to. Some developers keep a file for exactly this. It works because the discipline is the value, not the audience.

And if you write the whole thing out and it does not solve itself, you now have a question that someone can answer in minutes rather than hours — which was the goal anyway.