Asking Good Questions

Before you ask

1. Define the problem. What did you expect, and what happened instead?
2. Search first. Read the error message, the documentation and the project’s own tickets and chat history.
3. Narrow it down. Reproduce the issue in the smallest setup you can. See Reproducing Bugs and Troubleshooting Methodology.
4. Explain it aloud. Describing the problem step by step, even to a rubber duck, solves many of them.
5. Set a time limit. Decide how long you will struggle alone, for example 30 to 60 minutes, then ask. Asking too soon wastes others’ time, and too late wastes yours.

What a good question contains

• The goal: what you are trying to achieve, including the step that fails. This avoids the XY problem, where you ask about your attempted solution (Y) instead of the real problem (X).
• Context: language and tool versions, operating system, environment, what changed recently.
• Evidence: the exact error text, a log excerpt, a failing test, a minimal code sample. Paste text instead of screenshots when you can.
• Attempts: what you tried and what happened. This stops people suggesting the same thing.
• A clear request: the kind of help you want, such as a pointer, a review of an approach or a yes/no.

Never paste secrets, personal data or confidential code into a public place. See Secrets Management and Confidentiality and AI.

An example

Weak:   "The build is broken, can someone help?"

Better: "I am trying to build the api module locally (Linux, Node 22, main at
        commit abc123). The build fails at the lint step with
        'Cannot find module config/local'. I checked that the file exists,
        re-ran the install and cleared the cache. The same commit passes in CI.
        Could my local setup be missing an environment variable?"

Etiquette

• Ask in the right channel, and in public when others may benefit.
• Do not post “hello” or “can I ask a question?” on its own. Send the question itself.
• Follow up: report what worked, thank the helper and, when the fix was non-obvious, write it down for the next person.

Try it

Take a problem you got stuck on recently and write the question you should have asked, with goal, context, evidence and attempts, in under 150 words. Give it to a colleague and ask what they would still need to know.