8 things you should consider when (and before!) asking a question on Stack Overflow

Full article

I don't write this post as some representative of the Stack Overflow community or whatever, just one guy who's found enjoyment in providing nearly 1600 answers over the years. Whether it's finding the answer to some obscure IDE oddity, digging into a .NET class or teaching someone about a C# feature, I enjoy the challenge and opportunity to pass on some piece of knowledge I've learned. After all, what good is learning something if it's just locked up in your head?

Stack Overflow has developed a rep over the years for being harsh. It wasn't always that way, and there are a few reasons for it - individual egos, emotional detachment from the human beings involved in the process, but also (most of all?) the myriad of poorly written questions that kills the fun of participating on the site. Questions that could be easily answered with a quick Google search or basic debugging skills, or which seem to provide as few details as possible. It starts to feel less like you're helping someone over a rough patch, and more like you're doing their work for them... and pulling out your own hair in the process. So after five years of participating, here's my advice to you...

Stack Overflow should be your last resort!

That wasn't always the case, but it is now. You can be pretty certain you will get an answer, and probably quickly too, but low quality basic questions are generally discouraged and sometimes even met with a certain level of hostility. If that doesn't bother you and you're perfectly happy just getting your answer and being on your merry way then nothing below will make much difference anyway. For anyone that's left...

Here are 8 suggestions to consider before (and while) asking a question.

  1. If you're getting an error message, take the exact message and paste it into the search engine of your choice. This seems so obvious, but from what I've seen many people aren't doing it. SO has become their first resort, instead of their last. More likely than not, you'll even get hits for previous SO threads.
  2. If you need to know how something works, look for documentation. Microsoft's WPF, MySQL... there's always some official documentation to check out, and the last thing anyone wants is to have to look it up for you and post the link... they probably will anyway, but expect some snark. When it comes to Erlang, I check the offical and unofficial docs all the time.
  3. If you're at work, look to your left and right. Is there anyone nearby who can help out? Your coworkers have a much more intimate knowledge of the particular system you're working on than anyone on SO could possibly have. If you're new and there's no one willing to help, I'd seriously be questioning whether I wanted to stay there.
  4. If you're in school, make your instructor do their job. I've seen plenty of people leave comments under their questions explaining that their instructor is frequently unavailable, or unhelpful, or taught some material too quickly. Your money is valuable, and limited, and school loans follow you forever. If your instructor isn't helping, then they are stealing your money and you should hound them until they help.
  5. If you're using an IDE like Visual Studio or RubyMine, learn how to perform debugging. If a particular line or block of code is causing you problems, set break points that can be hit while the code is executing, which will stop execution at that point and allow you to inspect the state of things at that moment.
  6. If you're not using a full-blown IDE capable of helping you debug, then go the poor man's route and write some statements to the console or a log. I've had to do that before. Find the code where you think the problem lies, and then place copious log statements all around it, including the values of various variables so you get a feel for the state of things when the failure occurs.
  7. If you've done everything you can, and can't come up with an answer, you've probably got a fair amount of data to share by this point. Get credit for it! When you ask a question, include:

    - the exact problem code, not pseudocode (when possible), and formatted so it's easy to read and understand (this markdown guide may help)
    - just the problem code, not the entire app
    - the exact error message, including any stack traces
    - what the current result is, and what you expected it to be
    - things you already tried (be as specific as possible), and why they didn't work for you (this saves everyone the trouble of suggesting things you already figured out won't work)
    - appropriate tags for the language or technology you're using - I usually only watch the C# tag, and I know the developers of certain products like iTextSharp watch related tags closely
  8. Stick around for at least 10 or 15 minutes! People usually respond within minutes, asking for clarification. If you're not around, then by the time you come back your question is off the first page and those who were available to help have probably moved on to whatever else they were doing. Those first few minutes really are crucial, so don't post if you're rushing off to something else.

Do you have your own suggestions for someone looking for help online? Hopefully you've had good experiences with Stack Overflow - if not, try these suggestions next time and hopefully it will go better!

This is post #7 in my personal challenge to do #30DaysOfBlogging. I'm hoping this short-term challenge will help me become more comfortable with blogging in general. I expect some hits and misses; hopefully something here inspires or helps you.


Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.

Comments / Reactions