What you'll learn

  1. Quick answer
  2. The structure
  3. What to do before asking
  4. Why writing the question often answers it
  5. The mistakes that get questions ignored
  6. Afterwards
  7. FAQ

Quick Answer

State what you are trying to do, what you tried, what happened including the exact error, and what you need. Struggle for a bounded time first, and write the question properly — doing so frequently reveals the answer.

The structure

Four parts, in this order:

  1. Goal — what you are trying to achieve, not just the immediate blocker. Context lets someone suggest a better approach entirely.
  2. Attempt — what you tried, with the actual code or command.
  3. Result — what happened, with the exact error text.
  4. Ask — what you want. A cause? A review? A direction?

Compare the two versions.

"My code is not working, can anyone help?"

"I am trying to run database migrations against our staging environment.

I ran make migrate ENV=staging. It fails with psycopg2.OperationalError: connection timed out after about 30 seconds.

I checked the credentials in .env.staging and they match the runbook, and I can reach the app itself in a browser.

Is there a VPN or IP allowlist requirement I have missed?"

The second is answerable in one line by someone who knows. The first requires four rounds of questions before anyone can help at all.

What to do before asking

Not because asking is bad — because these steps often produce the answer, and because they make your question better when they do not.

  • Read the error properly. The whole thing, including the stack trace, and find the last line that points at your code. See debugging.
  • Search the exact error text, with your own file paths and variable names removed.
  • Check the documentation for the specific function, not a tutorial about the general topic.
  • Reduce it. Can you reproduce it in ten lines? A minimal example is both more likely to get answered and frequently reveals the cause.
  • Check the obvious. Right file, right environment, saved, server restarted, correct branch.

Set a bound on this — thirty to sixty minutes is reasonable for a junior. Beyond that you are burning time that a colleague could resolve in two minutes, which helps nobody.

Why writing the question often answers it

A common experience: you write a careful question, and while explaining what you already tried, you realise what is wrong and never send it.

That is not luck. Writing forces you to state your assumptions explicitly, and one of them is usually false. Reading "I checked the credentials in .env.staging" is the moment you realise the application actually reads .env.

This is the same mechanism as rubber duck debugging — explaining aloud to something that cannot help. The value is in the articulation, not the listener.

So write the question properly even if you expect to solve it yourself. A reasonable share of the time you will, and the effort is not wasted either way.

The mistakes that get questions ignored

  • Screenshots of code or errors. Nobody can copy, search or run an image. Paste text in a code block.
  • "Any ideas?" with no detail.
  • Asking to ask. "Is anyone good with Docker?" gets no reply because nobody wants to commit before knowing the question. State it.
  • Saying "it does not work" instead of what actually happened. Crashed? Wrong output? Nothing at all?
  • Omitting what you tried, so people suggest things you already ruled out and you both waste time.
  • The XY problem. Asking about your attempted solution rather than the actual goal — so you get help with an approach that was never going to work. Stating the goal first prevents this.
  • Direct-messaging a stranger instead of asking publicly, which removes the chance of anyone else answering or benefiting.

Afterwards

Say what worked. Not just thanks — which specific suggestion resolved it. That closes the loop for the person who helped and, more importantly, helps the next person who finds the thread with the same error.

An unanswered-looking question with a hidden resolution is a small waste for everyone who arrives later.

If you solved it yourself, post the solution. Especially in public forums. Many of the most useful answers online are people answering their own questions.

Do not delete the question because it turned out to be simple. Someone else will hit the same thing.

And once you have been helped a few times, answer someone else's question at your level. That is how these places keep working — see tech communities.

Frequently Asked Questions

How long should I struggle before asking? Thirty to sixty minutes as a junior, after reading the error, searching it and checking the obvious. Beyond that you are spending hours on something a colleague could resolve in minutes.
What is the XY problem? Asking about your attempted solution rather than the actual goal, so you get help with an approach that cannot work. Stating what you are ultimately trying to do prevents it.
Why do people ignore my questions? Usually missing detail — no exact error, no code, no explanation of what you tried. Questions answerable in one line get answered; questions needing four follow-ups get postponed.
Should I post screenshots of my code? No. Images cannot be copied, searched or run. Paste the text in a code block, and include the full error rather than a fragment.
What should I do after my question is answered? State which suggestion worked. It closes the loop for whoever helped and makes the thread useful to the next person with the same problem.