Where to Ask Coding Questions
Questions to work through before you post a programming problem: which venue fits the question, what the reader needs in order to reproduce it, what you should not paste, and what to do when nobody answers.
The questions
Open any question for the note
Is this a bug in someone's code, or a question about how to use it?
Why ask it
The answer decides the venue before anything else does. Bugs belong in the project's issue tracker with a reproduction; usage questions posted there are often closed as not-a-bug, which reads as rudeness but is really triage.
Does this project say where it wants questions?
Why ask it
Most maintained projects put this in the README, CONTRIBUTING file, or a support page, and ignoring it is the fastest way to be ignored back. Some explicitly forward usage questions to a forum or tag and close everything else.
Has someone already asked this, and is the top answer still current?
Why ask it
Accepted answers from years ago frequently describe a version that no longer exists. Check the dates and the version numbers in the answer before you follow it, and search the error text verbatim in quotes before you post.
Am I asking about one specific failure, or asking someone to design something for me?
Why ask it
Narrow failures get answered in minutes; "what is the best architecture for my app" gets opinions or silence. If the honest answer is the second one, you want a discussion forum or a design review, not a Q&A site.
How fast do I need this, and does that argue for chat over a written question?
Why ask it
Chat is good for a stuck-right-now problem and terrible as a record, since the answer scrolls away for the next person. A written question is slower and outlives you, which is why maintainers often prefer it.
Can I reproduce the problem in a small self-contained example?
Why ask it
The act of shrinking it finds the cause surprisingly often, which is why it is worth doing even if you never post. If the bug disappears as you cut things away, the last thing you removed is your answer.
What did I expect to happen, and what happened instead?
Why ask it
Two sentences that most posts leave out, and the reason answers arrive off target. "It does not work" makes a reader guess which of five plausible failures you have.
Which versions am I on: language, framework, library, operating system?
Why ask it
Version differences explain a large share of problems where the code looks correct and the tutorial disagrees. Paste the output of your version commands rather than describing it from memory.
Have I included the complete error message and the top frames of the stack trace?
Why ask it
Experienced readers often recognize a failure from the exact wording, and truncating to the last line removes the part that identifies it. Paste the whole thing as text, trimmed only where it repeats.
Am I posting code as text rather than a screenshot?
Why ask it
Screenshots cannot be searched, copied, run, or read by anyone using a screen reader, and they are one of the most common reasons a question gets no replies. Use a code block, and include the imports.
What have I already tried, and what changed each time?
Why ask it
This saves the reader from suggesting the three things you did last night, and it shows the shape of the problem. It also stops the thread where someone says "have you tried restarting it" and you have.
Is anything in what I am about to paste secret?
Why ask it
API keys, tokens, connection strings, customer data, internal hostnames and stack traces containing file paths all leak this way, and public posts get scraped and indexed within minutes. If something does slip through, rotate the credential rather than trusting that deleting the post removed it.
Am I allowed to share this code at all?
Why ask it
Employer policy and client contracts often prohibit posting proprietary source in public. If so, reproduce the failure with invented names and generic data, which usually makes a better question anyway.
Does my title state the actual problem?
Why ask it
A title is the only thing most readers see, and "help please" or "urgent" filters out exactly the people who could help. Say the operation, the technology and the failure in one line.
Is there a channel or tag for my specific language or library rather than a general one?
Why ask it
The narrower room usually contains the people who wrote or use the thing, and the general room contains people guessing. Tags also determine who sees the question at all on most Q&A sites.
Would a maintainer read this as unpaid consulting?
Why ask it
Asking a volunteer to debug a commercial deployment on a deadline tends to go badly. If the project sells support, or if the work is substantial, say so and ask what the paid route is.
If I ask in chat, can I stay available for the next twenty minutes?
Why ask it
Real-time help is a conversation, and the common failure is asking and walking away. If you cannot sit with it, write the question up properly instead.
Would writing this publicly help more than asking a colleague quietly?
Why ask it
A private message gets you an answer; a public question gets you an answer and leaves it where the next person searching finds it. For anything likely to recur inside a team, the internal wiki or issue is worth the extra effort.
If I solve it myself first, will I go back and post the answer?
Why ask it
Abandoned threads with the original poster's "never mind, fixed it" are a small tax on everyone who searches later. Post what the cause was, even briefly, and mark it resolved.
If nobody has answered in a day, what should I change before asking elsewhere?
Why ask it
Reposting the same text somewhere else rarely works. Silence usually means the question was too broad, missing a reproduction, or in the wrong room, so edit it with what you have learned since and say what you have ruled out.
Choosing a venue and writing the question
Practical guidance for the conversation itself
What each kind of venue is for
Public Q&A sites
Best for a specific, reproducible problem that someone else will hit later. They enforce narrow scope, so opinion questions, shopping recommendations and open-ended design discussions tend to get closed rather than answered.
The project's issue tracker
For defects and unexpected behavior in the library itself, with a minimal reproduction and version numbers. Check the existing issues and any discussions area first, because usage questions often belong in the latter.
Chat servers and community forums
Good for being unstuck quickly, for questions too vague to write up, and for judgement calls. Read the channel list before posting, and use a thread if the platform has them so the room stays readable.
Colleagues and internal channels
The right first stop when the problem involves your own systems, your own data, or your own deployment. It is also the only place you can paste code you are not allowed to share.
Building a reproduction that gets answered
- Start from a fresh file and add only what is needed for the failure to appear.
- Replace real data with the smallest fake input that still breaks it.
- Include imports and setup, so the reader can paste and run it without guessing.
- State the exact command you ran and the full output you got.
- Say which line the error points at, and what you believe should happen there.
- Note anything unusual about the environment: container, corporate proxy, old runtime, unusual locale.
After you post
Answer clarifying comments quickly
Most questions are answered by whoever is reading in the first hour. A question that sits unanswered for a day because a request for the version string went unread rarely recovers attention.
Edit the question rather than replying with corrections
New readers see the question, not the comment thread. Fold clarifications and things you have ruled out into the post itself.
Close the loop
Accept or mark the answer that worked, and if you solved it yourself, write down the cause. This is the entire mechanism by which these places stay useful.
Why questions get ignored
The problem is described, not shown
No code, no error text, no version. Readers will not reconstruct your setup from prose, and most will move on rather than ask.
Too much code
A whole repository dumped into a post is as unanswerable as no code at all. Cut it down to the part that fails, which also tends to reveal the cause.
Urgency aimed at volunteers
Deadlines are yours, not the reader's, and saying "urgent" or "please help fast" reliably reduces replies. State the problem plainly instead.
Asking in the wrong room and then again in another
Cross-posting the same text in several places splits any answers and annoys the people who recognize it. Pick the best venue, wait, then improve the question before moving.