The point of this post is that you shouldn't be afraid about asking stupid questions, and that you should never punish anyone for asking them. Because so-called stupid questions teach something to the ones that would answer it.
This is related to another unwritten blog post about how noobs are good for you. Also somewhat related to the long list of reasons to reject questions as stupid which I find annoying. Haven't bothered figuring out exactly why it bothers me (perhaps a topic for a future post), but others seem to have similar opinions.
Mind you, these observations only apply in some contexts, let's say on a project mailing list between people who are already engaged/employed in the project, rather than somewhere that might receive end-user help requests. Among other things, this means that it's in your interest to make sure that whoever is asking makes progress and that you remain friendly with them, and there's probably some kind of competency requirement they've already passed so you can assume they're not an idiot.
You might think that either a question is a stupid question or it's not, and that all stupid questions are intrinsically bad. This is what ESR's essay would tell you. But there are Good Stupid questions!
A lot of the Good Stupid questions come from stuff that the incumbent experts would consider obvious, but that is evidently not obvious to the one asking a question. Other Good Stupid questions are about stuff that's technically explained by the relevant FAQ or introduction document, but where the documentation doesn't actually explain it well enough.
Instead of rebuking the asker about how they failed to RTFM and do their own research, think of the question itself as a symptom of an underlying problem.
For a question like "How do I build foo?" the underlying problem(s) might be:
- It's not obvious where to find this information
- The build instructions are not in the right place
- The wiki's search function is poor (if there's a wiki and it has this information at all.)
- The naming of wiki pages is not intuitive, e.g. everything uses code names that aren't easy to guess
- The source repo does not have the relevant documentation
- The information was easy to find, but simply wrong. Perhaps it was meticulously well-maintained for Foo 1.0 but nothing was updated for the big Foo 2.0 rewrite.
I think (in the case of a new member asking questions), a lot of these causes boil down to institutional memory not getting transferred. You could view the question and answering as a transfer of those memories, but I rather like to think of it as a symptom of failing to transfer it in the first place.
For other questions, let's say something like "How do I use X to Y?" you'll have a different set of underlying causes. Perhaps Y is something that should be provided by X but isn't. Perhaps X is the worst possible way of doing Y, but it's not obvious that X is not appropriate, or the obvious answer (using the finely tuned Y frobnicator contained in misc/flibnel.c, for example) is in reality quite obscure.
The very best stupid questions are the ones that expose fundamental misunderstandings of important core concepts - considering most people will do anything to avoid having to risk asking a "stupid" question, how many other developers misunderstood the same thing without ever being set right? Or how much time did they waste before realizing it themselves?
In other words, questions that you think are stupid point out things that you haven't made obvious. Stupid questions are information. Learn from that information and use it to make your code/organization/workflows/etc obvious enough that you stop getting stupid questions.
PS. Here's an inspirational video on the importance of asking the stupid question.