Daily Archives: June 26, 2012
Let me start out by saying that I love helping people with programming problems. Giving others a hand as they learn about programming can be both fun and emotionally rewarding. That said, there are definitely a number of factors that can affect how easy it is to help someone with a problem. Here’s some advice that can help improve the quality of your questions and the efficiency of the help you receive.
Try something first.
There’s a whole domain name dedicated to this by now. In short, if you’re asking for help, you should be asking for help, not a solution. Most people are glad to offer advice, but they’re not there to do your job (or hobby) for you. If you have a question, try to figure out what you can on your own first. It’s fine if you don’t manage to make any headway – at the very least, it’ll help the person down the line to rule out what won’t work for you.
If whatever you’re having problems with has documentation (e.g. man pages), try to find your answer there – you might not succeed, but you might be surprised at how many answers are sitting there in plain sight.
Try and see if your question has been answered before. Google searches, FAQs, et cetera can all help in this regard.
Narrow down the problem…
Once you’ve given some thought to the issue, try to narrow down exactly what you need to ask help about. A random person probably isn’t going to want to try to go through your thousands of lines of code to figure out the problem you’re having. If possible, try to create a miniature version of the problem, with only the smallest amount of code necessary to show the issue you’re encountering (see also: SSCCE).
…but provide enough detail.
For instance, when you’re asking for help with something that’s generating an error, always make sure to include the exact text of the error message – ideally, copy and paste it directly out of whatever log, console, or web page contained it. Oftentimes a tiny detail in an error message can be the key to helping someone else figure out what’s going wrong in your code so that they can point out how to fix it.
If you’re asking for help with a particular piece of code, always provide a code sample. Trying to answer questions about code without actually seeing in the code in question is hard. Having the code available makes it easier to understand what is being asked, and also makes it easier to answer a question, since the answer can be phrased in the context of your actual code rather than abstractions.
Similarly, when you’re providing an example of what your code looks like, try not to remove too much – ideally, your code example should run on its own, but at the very least it shouldn’t be semantically different from your actual code. For instance, hiding particular sensitive values in your code is fine, but you shouldn’t change or paraphrase things like loop conditions.
It’s also often useful to describe the larger context of the code you’re showing, even if you only show a smaller snippet of code. Occasionally, you’ll get suggestions on completely different ways to accomplish your goal that bypass the original problem completely (and are often more efficient).
Don’t be lazy.
If you’re asking for help, you’re asking for someone else to use their own time working on someone else’s problem. Don’t waste their time for silly reasons: check your question for typos, make sure any links you post work, and try to format things reasonably nicely if you can. If you’re asking a question somewhere that doesn’t have built-in facilities for sharing code, use a service like Pastebin.com to provide your code sample (and turn on the proper syntax highlighting).
Unless you’re paying someone for their time, you’re not entitled to their help. There are plenty of people willing to answer questions out there, but they don’t tend to like being badgered. Once you’ve stated your problem or question somewhere, give it some time. Generally, people who are willing to help will do so when they’re able. It’s fine to ask a question in other places if you don’t get a response from the first place where you ask (but if you do get a response somewhere else, be polite and let the other places you asked know – and even better, include the answer if possible).
If you liked this post, you might also like the older (and slightly more abrasive) How to Ask Questions the Smart Way, by Eric S. Raymond.