mikeash.com: Getting Answers

Getting Answers

I hang out in several programmer related chats and forums and I see a lot of people having trouble getting answers. They get no answers, poor answers, or absorb a lot of verbal abuse. As a person asking questions, there are some simple things you can do to help your chances of getting good answers. This guide will show you ten easy things you can do to ensure your questions are answered quickly and well.

If you're in a hurry, you can skip the boring introduction and go straight to the guide.

Please leave your comments on this article in the blog post.

Other people have written articles on this subject before, but they suffer from problems. My goal is to avoid those problems and make something that's directly useful to you, the person with problems, rather than something that's mostly useful for the people answering the questions.

How To Ask Questions The Smart Way is pretty condescending, especially if you already feel insulted by somebody telling you that you need help asking questions. If you're pointed at a guide with a filename of smart-questions, that means this person thinks you have stupid questions, and who needs that?

Help Vampires: A Spotter's Guide is great, but it's written from the other side. While it's great for people who hang out and answer a lot of questions, and helps them deal with the titular Vampires, it's not something that's very useful for a person asking questions.

Another guide I just discovered is Getting help on IRC. It's a handy companion to this one, although more geared towards the nitty gritty of IRC etiquette and less towards the actual questions.

And so I present to you Getting Answers. The goal of the article is to get answers to your questions, nothing more and nothing less. I'll completely ignore boring stuff like the proper way to greet people or when to read the topic. This guide will walk you through ten basic things you can do to increase the chances of getting answers, and increase the quality of the answers you get. Getting a reply of rtfm! is considered failure, no better than no reply at all, and getting advice that solves your problem is success. All else is secondary to that.

You'll notice a distinct IRC and Mac flavor to the guide, but the ideas should be true for any topic in any context.

Question Buddy and Answer Friend will be helping us out by illustrating the principles in the guide. QBuddy and AFriend will have simulated conversations showing the right and wrong way to get good answers quickly. The conversations are made up, but every single one of them is taken directly from situations I've seen.

Explain what doesn't work
You'd think this would be obvious, but it's not. Many people will ask about general technique or something they feel is simpler and related instead of just saying what is going wrong. If you think it's a problem with general technique, then ask that too, but always tell people what isn't working for you.
Bad question:
QBuddy: how do I compile an app on 10.4 that works on 10.3? AFriend: set up the SDK like so: ... QBuddy: is there any other way? AFriend: I don't understand what you mean QBuddy: well, my app crashes on launch on 10.3 AFriend: ...
Good question:
QBuddy: my app crashes on 10.3 but works fine on 10.4, how do I discover the problem? is this a problem with how I set up my build? AFriend: your build setup shouldn't matter, you're probably linking against something that doesn't exist on 10.3. look at the Console output after the crash to see what it is
What's going wrong is, "my application crashes on launch on 10.3", but this doesn't even get mentioned until several rounds into the question/answer process, and after much time wasted on both sides. Answer Friend's explanation of SDKs was completely pointless because Question Buddy already knew about it. Question Buddy lost time by turning Answer Friend onto an irrelevant path instead of stating his problem at the start.
By stating exactly what is going wrong right away, Question Buddy got a useful answer from Answer Friend instantly.
Provide everything up-front
Making people fish for information wastes your time. Give as much background information in your original question as you can.
Bad question:
QBuddy: how do I append to a string? AFriend: use stringByAppendingString: QBuddy: well, I don't want to create a new object AFriend: then use NSMutableString and appendString: QBuddy: but I'm using C, not ObjC AFriend: argh, why didn't you say so? use strcat QBuddy: what if I have a CFString? AFriend: gah! use CFStringAppend QBuddy: but that doesn't work, I need to append a char * AFriend: screw this
Good question:
QBuddy: how do I append a char * to a CFString? The stuff I'm finding only works with CFMutableString AFriend: that's your only choice, you'll have to make a mutable copy, then use CFStringAppendCString
Under-specifying your question doesn't save you any time (you'll have to say it all eventually anyway) and makes people less likely to reply to you, both now and in the future.
You might be afraid of saying too much. Don't be. It's far better to be over-specific than under-specific, as it's much easier for somebody to ignore the extra details than it is to ask you for the missing ones. When in doubt, say, "I'm not sure if it's relevant, but I'm doing...."
Post your code
This doesn't apply to big conceptual questions, of course, but for everything else it's essential. Never describe your general approach to a problem without posting the code behind it, because the code is what counts, and translating everything through English tends to change it beyond recognition.
Bad question:
QBuddy: when I create an NSString from UTF-8 data it fails, why? AFriend: post your code QBuddy: I don't think it's a code problem AFriend: screw this
Bad question #2:
QBuddy: if I subclass NSMatrix then nothing appears on the screen, but using a plain NSMatrix works, why? AFriend: how the heck should I know?
Bad question #3:
QBuddy: when I create an NSString from UTF-8 data it fails, why? AFriend: post your code QBuddy: I don't have the code with me, but I'm doing something like char *utf8str = ...; [utf8str stringWithUTF8String] AFriend: you can't send a message to a char *, and there's no such method as stringWithUTF8String with no parameters, try ... ...the next day... QBuddy: I figured out the problem, I was actually using stringWithCString: AFriend: aarrgghh!
Good question:
QBuddy: when I create an NSString from UTF-8 data using char *utf8str = ...; [NSString stringWithCString:utf8str] it fails, why? AFriend: because stringWithCString: doesn't expect UTF-8, use stringWithUTF8String
Asking for code takes time and effort, and you can hasten the answer by providing it right away. If you don't know whether it's relevant or not, post it anyway. Never paraphrase or type from memory. Even when done with the best of intentions, you'll introduce subtle or blatant errors in your code, and the people you're talking to will be solving a problem completely different from what you actually have.
(On IRC, don't forget to use a pastebot. Pasting your code directly into the channel is considered rude if it's more than a line or so.)
Do your research beforehand
While it can be a good idea to ping a friend or two about a problem as soon as you run into it, asking strangers should be near your last resort. Do as much as you can to research the problem and solve it on your own before you do so. This will help you get an answer by letting you pose a much more informed question. The more you know about the topic, the better chance of asking what you need.
Bad question:
QBuddy: how do I create a thread? AFriend: rtfm!
Good question:
QBuddy: I read the NSThread docs but how can make it call a method with an int parameter? AFriend: make a new method that takes an NSNumber and just calls the other method with its intValue
In the first version, Question Buddy didn't get a very useful response. The second version's response was much more useful, because Question Buddy read about the topic before he asked his question.
Question Buddy also made the smart move of detailing what he researched. You're much less likely to get the useless rtfm! if you tell everybody which fine manuals you've already read.
Do your research during
Your work doesn't stop once you ask the first question. When presented with an unfamiliar piece of advice, research it before you ask about it. Even just sticking the unfamiliar term into Google can help a lot.
Bad question:
QBuddy: how can I get a directory listing? AFriend: use NSFileManager QBuddy: what's NSFileManager? AFriend: rtfm!
Good question:
QBuddy: how can I get a directory listing? AFriend: use NSFileManager ... QBuddy puts NSFileManager into Google... QBuddy: ok, thanks... is there any way to make it only give me results whose names begin with "tty"? AFriend: you can get all of the results, then filter them using NSPredicate by doing...
Researching your followup questions as well as your original question will get you more useful replies.
Do your research afterwards
I bet you saw this one coming. After you get advice and depart, you should do as much research as you can, before coming back and asking questions about the advice.
Bad question:
QBuddy: how can I get a directory listing? AFriend: use NSFileManager ... QBuddy departs...later: QBuddy: how do I use NSFileManager? AFriend: rtfm!

Good question:
QBuddy: how can I get a directory listing? AFriend: use NSFileManager! ... QBuddy departs...the next day: QBuddy: when I use NSFileManager to list the contents of /, I get "Applications" instead of the translated name I see in the Finder, why does it do that and how do I duplicate Finder's behavior? AFriend: localized names don't exist in the filesystem, but you can use...
As before, doing your research makes for better answers.
Don't post the same question repeatedly
This especially applies to forums and mailing lists, but it applies to IRC too. Unless your problem is highly complicated, many people will be able to help you. Chances are one of those people saw your question the first time. If nobody answers, do more research, try to produce a small test case or at least narrow the problem down, and come back in a day or two with more information.
Bad question:
QBuddy: my custom NSMatrix subclass doesn't draw, help? ...crickets...the next day: QBuddy: my custom NSMatrix subclass doesn't draw, help? ...crickets...the next day: QBuddy: my custom NSMatrix subclass doesn't draw, help?
Good question:
QBuddy: my custom NSMatrix subclass doesn't draw, help? ...crickets...the next day: QBuddy: my custom NSMatrix subclass doesn't draw, I created a simple test project that exhibits the behavior, you can download it at http://blah, anybody know what's going on? AFriend: don't override drawRect:
If nobody could answer your question the first time, they probably can't want to answer it the second time either. Use the time you spend waiting for an answer to work on the problem yourself. Even if you have no hope of solving it, you can produce something and gather information that will help others solve it.
Follow up after you get an answer
You should always reply to people who give advice, even if you understand it and it works perfectly and you don't need any more information.
Bad question:
QBuddy: my program crashes with an EXC_BAD_ACCESS when I do [obj release], what's going on? AFriend: you're probably over-releasing, try using NSZombieEnabled ...later... QBuddy: my program crashes in some sort of notification callback, how can I debug that? AFriend: wait, did you solve your [obj release] crash? ...later... QBuddy: my program gives me an error saying NSString doesn't respond to setObject:forKey:, how do I debug that? AFriend: screw this
Better question:
QBuddy: my program crashes with an EXC_BAD_ACCESS when I do [obj release], what's going on? AFriend: you're probably over-releasing, try using NSZombieEnabled QBuddy: ok, thanks ...later... QBuddy: I found my over-release problem from before, but now my program crashes in __CFXNotificationPost, how can I debug that? AFriend: make sure you remove yourself as an observer from the NSNotificationCenter in your -dealloc method QBuddy: oops, thanks ...later... QBuddy: ok, got the notification crasher fixed, but now my program gives me an error saying "-[NSCFString setObject:forKey:]: selector not recognized", how do I debug that? AFriend: that could be due to another over-release bug, or just a confusion of types where you're treating a string like a dictionary QBuddy: ok, I'll take a look, thanks
Unless you're paying for help (in which case you can probably ignore this entire page, and the person you're paying will just charge more), the people who are answering your questions are doing it for free. Like a cute puppy who sits on command, you need to reward them when they do what you want.
The second conversation is labeled "better" instead of "good" because it probably violates rule #2. The basic answers to these questions should exist in the conceptual documentation, which can then be used to ask a better question and get a better answer. But I couldn't think of a better example.
For more complex questions, follow up with how you finally solved it and which advice you used. This not only provides a powerful reward to the people who provided it, but it allows other people to learn from your example.
Treat the list like people
Many conversations I see indicate a subtle, buried belief that the list or chat is some kind of answer machine, and the key to obtaining a good response is to hunt around until the precise required format for the question is found.
Bad question:
QBuddy: how do I append to an NSString? AFriend: read the NSString docs, search for "append" QBuddy: I'm new to Cocoa and I want to append to an NSString, how do I do that? AFriend: hello? read what I said above QBuddy: I'm on 10.4.7 using Xcode 2.3, I don't know much about Cocoa, how do I append to an NSString? AFriend: ...
Good question:
QBuddy: how do I append to an NSString? AFriend: read the NSString docs, search for "append" QBuddy: doh, sorry, I forgot to mention that I want to append a C string AFriend: in that case, make an NSString from the C string, then append that, or use %s with stringByAppendingFormat:
It's not a game, you're talking to real live people. Treat them just as you would treat people you're talking to face-to-face, and you'll get much better results.
Always consider the answer
Sometimes a real moron will reply to you, and sometimes you'll get a smart guy who's having a bad day or who didn't correctly read your question. However, most of the time you'll be talking to people who know more about the subject at hand than you do (that's why you came to them for help in the first place, remember). As such, it pays to at least entertain the possibility that they know what they're talking about.
Bad question:
QBuddy: how can I memory-map a file using Cocoa? AFriend: NSData QBuddy: please read my question again, I want to memory-map a file AFriend: ...
Better question:
QBuddy: how can I memory-map a file using Cocoa? AFriend: NSData QBuddy: huh? how is that related to memory-mapping a file? AFriend: NSData has initializers that let you create one by memory-mapping a file
Good question:
QBuddy: how can I memory-map a file using Cocoa? AFriend: NSData QBuddy: got it, thanks!
If the other person's answer really was correct, then you gain a lot of time if you started with the assumption that it was. If you assume it's wrong, you'll either have to wait for the other person to correct you, or if you're unlucky he won't even bother and you won't have an answer. Even if the answer is wrong, you're more likely to get a correct answer if you're gentle when pointing out the wrongness.
Having your solutions get rejected by the person asking the question is frustrating. Frustrated people are less likely to answer your questions. Be good to them, and they'll be good to you.
Note for mailing lists: unlike ephemeral media like IRC, mailing lists are typically archived and searchable. When you find a solution, post it! That way, when you forget about how you did this months later and search the list for an answer, you can see how you actually solved it before.

Questions, comments, other feedback? E-mail the author.