This is not the first time I’ve shared a text from the Hacker culture and movement. Let’s remember that, although this movement started in the field of computing, it encompasses an attitude and a type of personality that enjoys learning and developing their skills.
The Hacker movement has its origins between 1950-1960, and for many, it reached its peak around 1980-1990, as the development of a movement that includes its own values and ethical code.
Despite the passage of time and evolution, many of the original documents and ideas remain completely relevant today.
This is the case with a fragment of text I want to share, extracted from the original “How to ask questions” by Eric S. Raymond from 2001. Here is the link to the original text and the link to the translated text by Jose M. Fernández from which this fragment is taken.
How to Ask Smart Questions
In the world of hackers, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer. This guide will teach you how to ask in a way that gets you a satisfactory answer.
The first thing you have to understand is that hackers like really complex problems and good questions that make them think. Otherwise, we wouldn’t be here. If you provide us with an interesting question, we will be grateful; good questions are a stimulus and a gift.
Good questions help us develop our understanding, and often reveal problems we might not have noticed or otherwise would have overlooked.
Among hackers, “Good question!” should be understood as a sincere compliment.
Despite this, hackers have a reputation for responding to simple questions with hostility or arrogance. It sometimes seems as if we are hostile to beginners or the ignorant. But that’s not really true.
What we are, in an unapologetic way, is hostile to people who seem unwilling to think or do their homework before asking questions. People of that type are time sinks — they take without giving back, wasting time we could have spent on another more interesting question and with another person more deserving of an answer. We call these people “losers” (and for historical reasons sometimes we write “lusers” looser + user).
We are, by far, volunteers. We steal time from busy lives to answer questions, and sometimes we get overloaded. So we filter relentlessly. In particular, we discard questions from those who seem to be losers in order to use the time we spend answering questions more efficiently, with the winners.
You don’t want to be one of the losers. You also don’t want to look like one. The best way to get a quick and efficient answer is to ask like a winner — like a person with intelligence, self-confidence, and hints that they need help with a particular problem.
Before Asking
Before asking a technical question by email, in a newsgroup, or on a website forum, do the following:
- Try to find an answer by reading the manual.
- Try to find an answer by reading the FAQs.
- Try to find an answer by searching the web.
- Try to find the answer by asking a more experienced friend.
When you ask your question, highlight the fact that you have already done all this; this will help establish that you are not a lazy sponge just wasting other people’s time. Even better, highlight what you have learned from doing these things. We like to answer people who have shown they can learn from answers.
Prepare your question. Think about it. Hasty questions get hasty answers, or none at all. The more you do to demonstrate that you have put thought and effort into solving your problem before asking for help, the closer you are to actually receiving it.
Be careful not to ask the wrong question. If you ask one based on wrong assumptions, Random Hacker will likely answer with something literal and useless while thinking “What a stupid question…”, and hoping that the experience of getting an answer to what you asked exactly, instead of what you need to know, will teach you a lesson.
Never assume you are entitled to an answer. You are not. You will earn an answer if you earn it by asking a substantial, interesting, and thought-provoking question— one that implicitly contributes to the community’s experience rather than passively soliciting knowledge from others.
On the other hand, a very good start is to make it clear that you can and want to participate in the process of developing the solution. “Does anyone have any hints?” “What’s missing from my example?” and “Is there a page I should have checked?” are more likely to be answered than “Please post the exact procedure I should follow,” because you are making it clear that you are really eager to complete the process if someone simply points you in the right direction.
Write Clearly, Respecting Spelling and Grammar
We know from experience that careless and sloppy writers also think in a messy and sloppy way (often enough to bet on it, however). Responding to careless and sloppy thinkers is not rewarding; we would be better off using our time elsewhere.
Therefore, it is important to express your question clearly. If you can’t be bothered to do that, we can’t be bothered to pay attention to you. Take the extra effort to polish your language. It doesn’t have to be stuffy or formal — in fact, hacker culture values informal speech, slang, and humorous language used precisely. But it has to be precise; there has to be some indication that you are thinking and paying attention.
Spell correctly. Don’t confuse “its” with “it’s” or “loose” with “lose”. Don’t WRITE EVERYTHING IN CAPITAL LETTERS, that reads as if you are shouting, it’s considered uncouth. If you write like a semi-literate fool, you will probably be ignored. Writing like a l33t hax0r script kiddie is the absolute kiss of death and guarantees you will receive nothing but a deafening silence (or, if you’re lucky, a heap of scorn and sarcasm).
If you ask in a forum where your native language is not used, you will get a limited amount of leeway for your grammatical and spelling errors — but none added for your sloppy reasoning (and yes, we usually know the difference). Also, unless you know the languages of those who will answer, write in English. Busy hackers tend to discard questions in languages they don’t understand, and English is the working language of the network. By writing in English, you minimize the chances of your question being discarded unread.
Use Specific and Meaningful Titles
In mailing lists or newsgroups, the message header is your golden opportunity to attract the attention of qualified experts in about 50 characters or less. Don’t waste it on babble like “Please help me” (let’s not even talk about “PLEASE HELP ME!!!”). Don’t try to impress us with the depth of your anguish; instead, use that precious space for the most concise description possible of the problem.
Stupid: HELP! Video doesn’t work on my laptop!
Smart: Mouse cursor distorted with XFree86 4.1, Loquesea MV1005 video chipset
Be Precise and Informative About Your Problem
Describe the symptoms of your problem or error carefully and clearly, the environment in which it occurs (machine, OS, application, whatever).
Describe the research you conducted to narrow down a possible answer to the problem before asking, the diagnostic steps you took, and try to solve the problem yourself before asking the question.
Describe any recent changes to your computer or software combination that may be relevant.
Describe the Symptoms of the Problem, Not Your Assumptions
It is not helpful to tell hackers what you think is causing your problem. (If your diagnostic theories were so reliable, would you be asking others for help?) Therefore, make sure you are only telling them the symptoms of what is wrong and not your interpretations or theories. Let them do the interpreting and make the diagnosis.
Stupid: I get SIG11 errors during kernel compilation, and I suspect a thread may have broken on one of the motherboard circuits. What’s the best way to check that?
Smart: My self-assembled K6/233 with an FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Corsair PC133 SDRAM starts having frequent SIG11 errors about 20 minutes after booting during kernel compilations, but never during the first 20 minutes. If I reboot, the clock doesn’t reset, but if I turn it off overnight it does. Moving all RAM to the swap partition didn’t help. Below, I provide the relevant part of the log from a typical compilation session.
Describe the Symptoms of Your Problem in Chronological Order
The most useful clues for figuring out what went wrong are often found in the events immediately preceding it. Therefore, you should accurately describe what you did, and what the machine did, up to the fateful moment. In the case of command-line processes, having a session log (e.g., using the “script” utility) and quoting the relevant twenty lines or so would be very helpful.
If the program in question has diagnostic options (like -v for verbose), try to think carefully about choosing options that might add useful debugging information to the transcript.
If your message ends up being very long (more than four paragraphs), it may be helpful to briefly summarize the problem at the beginning and then describe it chronologically. This way, hackers will know where to look when reading your message.
Do Not Request Private Email Responses
Hackers believe that problem-solving should be a public and transparent process during which a first attempt at an answer can and should be corrected if someone with more knowledge perceives the answer as incomplete or incorrect. Furthermore, they get part of their reward for answering by being seen as competent and knowledgeable by their peers.
When you ask for a private response, you are interrupting both the process and the reward. Don’t do that. It is the responder’s choice to do so privately — and if they do, it’s usually because they think the question is too obvious or poorly formulated to be interesting to others.
There is a limited exception to this rule. If you think you might receive a large number of very similar responses due to the type of question, then the magic words are “email me the answers and I’ll summarize them for the group.” It is considered polite to save the mailing list or newsgroup from a flood of substantially identical responses — but you obviously have to keep your promise to summarize them.
Avoid Insignificant Questions
Resist the temptation to close your query with semantically null questions like “Can anyone help me?” or “Is there an answer?” First: if you have written your problem description somewhat competently, these kinds of tacked-on questions are, at best, superfluous. Second: being superfluous, hackers find them annoying — and they will probably return answers of impeccable logic, though ignoring you, like “Yes, they can help you” or “No, there is no help for you.”
Courtesy Never Hurts, and Sometimes Even Helps
Be polite. Use “Please” and “Thanks in advance.” Make it clear that you appreciate the time people spend helping you for free.
Be honest, this is not as important as (and cannot replace) being grammatically correct, clear, precise, and descriptive, avoiding proprietary formats, etc.; hackers generally prefer technically concrete, albeit blunt, bug reports to polite vagueness. (If this leaves you perplexed, remember that we value a question for what it teaches us).
Anyway, if you got your technical knowledge from a raffle, courtesy will increase your chances of receiving a useful answer.
Conclude with a Brief Note on the Solution
Send a note after you have solved the problem to everyone who helped you; let them know how it turned out and thank them again for their help. If the problem attracted general interest on a mailing list or newsgroup, then it will be appropriate to post the note there.
The note doesn’t have to be long or elaborate, a simple “Pepe - it turns out the cable was faulty in the end. Thanks to everyone. - Jose Luis” is better than nothing. In fact, a short and pleasant summary is better than a long dissertation unless the solution requires some technical depth.
Besides being polite and informative, this kind of follow-up helps everyone who assisted you feel a satisfying sense of closure regarding the problem. If you are not a hacker, believe me, that feeling is very important to the gurus and experts you asked for help. Problems that remain unresolved are frustrating; hackers want to see them solved. The good karma you gain by scratching that itch will be very helpful to you the next time you need to ask a question.
How to Interpret Answers
There is an ancient and venerable tradition: if you get an “RTFM” (Read The Fucking Manual) response, the person who sent it thinks you should have read the fucking manual. They are almost certainly right. Go and read it.
RTFM has a younger relative. If you receive an “STFW” (Search The Fucking Internet) response, the person who sent it thinks you should have Searched The Fucking Web. They are almost certainly right. Go and search.
Often, the person sending one of these responses is looking at the manual or webpage in question while typing. These responses mean they think that (a) the information you need is easy to find, and (b) you will learn more if you find the information yourself than if it is spoon-fed to you.
This should not offend you; by hacker standards, you are being shown a certain respect (though rough, let’s not deny it) by simply not being ignored. You should thank them for their extreme kindness.
If You Don’t Understand…
If you don’t understand the answer, don’t immediately return a request for clarification. Use the same tools you used to try to solve your original question (manuals, FAQs, the Web, friends with greater skills) to understand the answer. If you need to ask for clarification, try to demonstrate what you have learned.
For example, suppose I tell you: “Sounds like you have a stuck zentry; you’ll need to clear it.” Then, here is a bad question: “What is a zentry?”
Here is a good question: “Okay, I read the manual page and zentrys are only mentioned under the -z and -p variables. Neither mentions anything about clearing zentrys. Is it one of these, or am I missing something?”
