It is not the first time that I share some text of the Hacker culture and movement. Remember that, although this movement starts in the field of computing, it encompasses an attitude and personality type that enjoys learning and developing their skills.
The Hacker movement has its origin between 1950-1960, and for many, it reaches 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 are still fully relevant in the current era.
This is the case of a text excerpt that I want to share, extracted from the original “How to ask questions” of 2001 Eric S. Raymond. Here is the link to the original text and the link to the translated text by Jose M. Fernández from which this excerpt is taken
How to ask smart questions
In the world of hackers, the type 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 you can get a satisfactory answer.
The first thing you have to understand is that hackers like really complicated problems and good questions that make them think about them. If not, 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 that we may not have perceived or on which we would not have otherwise focused.
Among hackers, “Good question!” should be understood as a sincere compliment.
Despite this, hackers have the reputation of facing simple questions with hostility or arrogance. Sometimes it seems as if we are hostile to beginners or ignorants. But that’s not really true.
What we are, in an unapologetic way, is hostile to people who seem not to want to think or do their homework before asking questions. People of this type are time sinks—they take without giving in return, waste the time we could have dedicated to another more interesting question, and with another person more deserving of an answer. We call people of this type “losers” (and for historical reasons we sometimes 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 the questions of those who seem to be losers to save the time we dedicate to answering questions more efficiently, with the winners.
You don’t want to be one of the losers. You don’t want to look like one either. The best way to get a quick and efficient answer is to ask like a winner—as a person with intelligence, self-confidence, and hints that you need help with a particular problem.
Before asking
Before asking a technical question by email, on a news group, or on a website’s 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 and that you are only wasting other people’s time. Even better, highlight what you have learned from these things. We like to answer people who have proven themselves capable of learning from the answers.
Prepare your question. Think about it. Hasty questions receive hasty answers, or none at all. The more you do to demonstrate that you have given thought and effort to solving your problem before asking for help, the closer you will be to actually receiving it.
Be careful not to ask the wrong question. If you ask one that is based on wrong assumptions, Random Hacker will surely answer you with something literal and useless while thinking “What a stupid question…”, and hoping that the experience of getting an answer to what you have asked exactly instead of what you need to know will teach you a lesson.
Never assume that you are entitled to an answer. You are not. You will earn an answer if you earn it by asking a substantial, interesting question that makes you think—one that implicitly contributes to the community’s experience rather than passively requesting 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 clues?” “What’s wrong with my example?” and “Is there a page I should have consulted?” 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 just points you in the right direction.
Write clearly respecting spelling and grammar
We know from experience that careless and messy writers also think disorderedly and messily (often enough to bet on it, nevertheless). Answering careless and messy thinkers is not rewarding; we would be better off using our time anywhere else.
For this reason, 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 advantage of the extra effort to polish your language. It doesn’t have to be anything stiff or formal—indeed, the hacker culture values informal speech, jargon, and comic language used with precision. But it has to be precise; there has to be some indication that you are thinking and paying attention.
Spell correctly. Do not confuse “its” with “it’s” or “loose” with “lose”. Do NOT WRITE EVERYTHING IN CAPITAL LETTERS, that reads as if you are shouting, and is considered rude. If you write like a semi-literate fool, you will probably be ignored. Writing as a hax0r script kiddie of l33t is the absolute death knell and guarantees that you will receive nothing but a sepulchral silence (or, if you are lucky, a lot of contempt and sarcasm).
If you ask in a forum where your native language is not used, you will get a limited number of warnings for your grammatical and spelling errors—but none added for your messy arguments (and yes, we usually know the difference). Besides, unless you know the languages of those who respond to you, write in English. Busy hackers tend to dismiss questions in languages they do not understand, and English is the working language on the network. When writing in English, you minimize the chances of your question being dismissed unread.
Use specific and meaningful titles
In email lists or news groups, the message header is your golden opportunity to attract the attention of qualified experts in about 50 characters or less. Do not waste them on babbling like “Please help me” (we won’t even talk about “PLEASE HELP ME!!!”). Do not try to impress us with the depth of your distress; better use that precious space for the most concise possible description of the problem.
Stupid: HELP! The 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 did to narrow down a potential answer to the problem before asking the question, 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 useful to tell hackers what you think is causing the problem. (If your diagnostic theories were so reliable, would you be asking for help from others?) Therefore, make sure you are only telling them the symptoms of what is going wrong and not your interpretations or theories. Let them carry out the interpretations and pronounce their diagnosis.
Stupid: I get SIG11 errors during the kernel compilation, and I suspect that a thread on one of the circuits of the motherboard may have broken. What is the best way to check that?
Smart: My K6/233 assembled by me with a FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Corsair PC133 SDRAM is starting to have frequent SIG11 errors about 20 minutes after starting it during kernel compilations, but never during the first 20 minutes. If I restart, the clock does not reset, but if I turn it off overnight it does. Passing all the RAM to the swap partition has done nothing. Below, I put the relevant part of the log of 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 in the events immediately before. 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 your message ends up being very long (more than four paragraphs), it may be useful to comment on the problem briefly at the beginning and then do it chronologically. This way, the hackers will know where to look when reading your message.
Do not ask to be answered by email privately
Hackers believe that solving problems should be a public and transparent process during which a first attempt at an answer can and should be corrected if someone more knowledgeable perceives that the answer is incomplete or incorrect. In addition, they get part of their reward for answering by seeing that they are competent and knowledgeable enough from their peers.
When you ask for a private response, you are interrupting both the process and the reward. Do not do that. It is the responder’s choice to answer privately—and if they do, it is usually because they think the question is too obvious or poorly posed 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 to the question type, then the magic words are “send me the answers by email and I will summarize them for the group”. It is considered courteous to save the email list or news group a large amount of substantially identical responses—but you obviously have to keep the promise to summarize them.
Avoid insubstantial 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 the description of your problem competently, those added questions are, at least, superfluous. Second: being superfluous, hackers find them annoying—and they will probably return answers of impeccable logic, although 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 “Thank you in advance”. Make it clear that you appreciate the time that 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 correct reports of concrete errors to polite vagueness. (If this leaves you upset, remember that we value a question for what it teaches us).
Anyway, if you got your technical knowledge in a tombola, education will increase your chances of receiving a useful answer.
Conclude with a brief note about the solution
Send a note after solving the problem to everyone who helped you; let them know how it all turned out and thank them again for their help. If the problem attracted general interest in an email list or news group, then it will be appropriate to post the note there.
The note does not have to be long or developed, a simple “Pepe - that turns out to be the cable that was failing. Thanks to everyone. - Jose Luis” will be better than nothing. In fact, a short and pleasant summary is better than a long dissertation unless the solution requires some technical depth.
In addition to being courteous and informative, this kind of follow-up helps everyone who assisted you to feel a satisfying sense of closeness to the problem. If you are not a hacker, believe that feeling is very important for the gurus and experts you asked for help. Problems that end unsolved are frustrating; hackers want to see them solved. The good karma that relieves that itch will help you a lot the next time you need to ask a question.
How to interpret the answers
There is an ancient and revered tradition: if you get “RTFM” (Read The Fucking Manual) as an answer, the person who sent it thinks you should have read the fucking manual. Almost certainly, they are right. Go and read.
RTFM has a younger sibling. If you receive “STFW” (Search The Fucking Web) as an answer, the person who sends it thinks you should have Searched The Fucking Internet. Almost certainly, they are right. Go and search.
Often, the person who sends one of these answers is looking at the manual or web page in question while writing. These responses mean that they think (a) the information you need is easy to find, and (b) you will learn more if you search for the information yourself than if you are given it to “digest” with a spoon.
This should not offend you; by hackers’ standards, they are showing you some respect (although rough, let’s not deny it) by simply not ignoring you. You should be thankful for the extreme kindness.
If you don’t understand…
If you don’t understand the answer, do not immediately return the 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: “It sounds like you have a stuck zentry; you will need to free it.” Then, here is a bad question: “What is a zentry?”
Here is a good question: “Okay, I read the manual page and zentries are only mentioned under the -z and -p variables. None of them say anything about releasing the zentries. Is it one of these or am I missing something?”