6 ways to make sure you get helpful replies when posting a programming question to Stack Overflow (and reddit, mailing lists, and forums...)
You’ve spent the last day and a half trying to work through a programming problem, and just can’t make any progress. You’ve googled, read documentation and blogs and Stack Overflow questions, and you’re just completely stuck. Time to post your question to Stack Overflow and get some help from the community…
You post your question: “Problem deploying app to Heroku – what’s wrong?” and wait for the wisdom of Stack Overflow to help you out. You wait… and wait… and don’t get a single helpful response. What went wrong?
There are good ways and bad ways to ask questions on any online discussion group, and Stack Overflow is no exception. Here’s what you need to do to make sure your question gets read by other members, and get helpful replies.
Make a statement
Take a look at some Stack Overflow subjects, and you’ll notice that statements get more replies than questions, which get more replies than sentence fragments.
- bad – “problem deploying app to Heroku”
- okay – “Why does my app break when I deploy it to Heroku?”
- good – “App breaks when I deploy it to Heroku.”
If you want replies, you need people to read your post first. Make your subject count. Statements get more replies than questions, so state your problem instead of asking a question. Questions get answers. Problems get solutions. Do you want an answer, or a solution?
And don’t be lazy. If you can’t be bothered to write a complete sentence, why should someone bother reading your post?
Details give readers something to think about. Without details, people are just stabbing in the dark – and at worst are going to ignore you, and at best are going to ask for details. Help them out by providing details upfront.
You need to provide details in your subject and your body. Details in the subject help draw readers in. Details in the body get them to reply. Start with the subject. What details can you provide to hint at the problem you’re having?
- bad – “App breaks when I deploy to Heroku.”
- okay – “App has HTTP problem when I deploy to Heroku.”
- good – “App gets stuck in HTTP redirect loop when I deploy to Heroku.”
Put yourself in the reader’s shoes. Which of these would be the easiest to answer, especially if you had already seen the problem? “App breaks” could be anything. “HTTP problem” at least narrows things down a bit. “stuck in HTTP redirect loop” would jump out at anyone who has had that problem before. Then they could click your thread and present you with a solution that worked for them.
What about the thread body? It turns out that debugging is almost impossible when you can’t read or run the code and see what happens, or make changes. Provide debugging information upfront. What kind of information?
- error messages
- log output
Those are the three main things you look at when debugging a problem, right? How do you expect anyone to help you out if they don’t have that information? They can’t, because they’re flying blind.
Keep it short
Pretend you’re surfing Stack Overflow looking for some people to help. You spot a thread that looks promising – in fact, you just had the exact same problem the other day. You click the link and then boom! You’re met with pages and pages of frustration, code snippets, error messages, and log output. What do you do? Well unless you’re feeling unusually wealthy in time that day, you probably hit the back button and go looking for another thread.
You want to provide enough detail that people can help you, but not so much that you scare them away. Nothing scares people away like clicking what looks like a straightforward question, and being met with a giant wall of text.
How do you find the balance between providing too little detail, and too much? The best way is to…
You only need help with ONE problem – the thing that’s preventing you from making progress right now. Don’t ask a bunch of questions, or present a bunch of problems. Stay focused on the problem that’s immediately in front of you. Yeah, you’ll run into another problem once you’ve fixed this one, but you can deal with that when you get there.
If it doesn’t help people understand your immediate problem, don’t include it in your post. Simple as that.
Show them you tried
You know how to draw readers in with a subject, and how to provide enough detail to get help. The final piece is demonstrating that you’ve tried to solve your own problem. Not telling, but demonstrating. I like to use the format 1) what I want to happen 2) what I tried 3) what actually happened (with supporting details).
- bad – “My app is stuck in an HTTP redirect loop when I deploy it to Heroku. I’ve tried EVERYTHING and it’s STILL not working. Help!”
- good – “My app is stuck in an HTTP redirect loop when I deploy it to Heroku. I want it to render the home page when I visit the site. I’ve tried removing the redirect filter (see the code below), and updating my DNS records (see DNS records below). It’s still redirecting. Help!”
Programmers value laziness in themselves, but abhor it in others. Don’t give them any reason to think you’re being lazy. And if you are being lazy… try figuring it out for yourself first, so you can demonstrate what you’ve tried if you still need help.
Okay, you’ve posted a question and gotten your first reply… and it doesn’t solve your problem.
Take a deep breath. Debugging stuff over the internet is hard, as we’ve talked about. Thank the person for taking the time to help you – after all, they don’t owe you any of their time and energy.
If their suggestion doesn’t work, chalk it up as a “thing I tried” and reply back. Try something like:
“Hey, thanks for taking the time to help me out. I tried your suggestion, but I don’t think it worked. Maybe I did something wrong? Here’s the error message I got…”
Again, you’re telling them what you tried (their suggestion!), as well as what happened. That’s the information they need to help you out. Of course, if their suggestion does help you make progress, be sure to thank them… and when it leads you to a different problem, start the whole process over: try to figure it out for yourself, do the research, and only then follow up with your new problem.
Most of all, don’t be rude to people who are trying to help you out, especially if their suggestions don’t work out. I know you’re frustrated, but people will think twice before helping you out if they’ve seen you respond rudely to a stranger who’s donating their time and energy to try to help you.
Use this checklist before posting to Stack Overflow
You’ve composed your question to Stack Overflow… before you submit it, run through this checklist:
- Have you stated your problem in the subject? Remember, questions aren’t as effective as statements (and fragments don’t work!)
- Have you given enough detail in the subject to get people interested? Have you provided enough detail in the body that people will be able to help you out?
- Have you kept the body as short as it can be, while still providing enough detail that people can help?
- Have you kept your post focused to only the problem immediately in front of you? Too many questions or problems will scare people off.
- Have you shown people what you’ve tried to do, so they don’t think you’re lazy? Remember to include: 1) What you want to happen 2) What you tried 3) What actually happened (and provide details for each)
- (after you post) Are you thanking people for taking the time to reply? Are you trying their suggestions, and then trying to make progress on your own? There will ALWAYS be a next problem – it’s up to you to try to solve it before posting on the forums.
Run through the checklist, compose the best possible question you can… and watch the replies roll in!
Examples of good Stack Overflow posts
Here are some example threads to check out – and to follow! How does your Stack Overflow post compare?