The Wisdom of Asking Questions

The copyright of this guide's English version belongs to Eric S. Raymond and Rick Moen.

Original URL: http://www.catb.org/~esr/faqs/smart-questions.html

This article also has a Traditional Chinese version.

Introduction#

In the world of hackers, whether you receive useful answers when you pose a technical question often depends on how you ask and follow up. This guide will teach you how to ask the right questions to get satisfactory answers.

Not just hackers, open source software is now quite popular, and you can often get answers from other experienced users, which is a good thing; users tend to be more tolerant of the common problems faced by newcomers than hackers. However, treating experienced users as hackers and communicating with them using the methods outlined in this guide is also the most effective way to receive satisfactory answers from them.

First, you should understand that hackers love challenging questions or good questions that stimulate their thinking. If we weren't like this, we wouldn't be the ones you want to ask. If you give us a good question that is worth chewing over, we will be very grateful to you. A good question is an inspiration, a great gift. Good questions can enhance our understanding and often expose issues we have never realized or thought about before. For hackers, a "good question" is a sincere and strong compliment.

That said, hackers have a bad reputation for disdain or arrogance towards simple questions, which sometimes makes us seem hostile towards newcomers and the ignorant, but that's not the case.

We do not shy away from expressing our contempt for those who are unwilling to think or who do not do their homework before asking questions. These people are time killers—they only want to take and never give, consuming our time that could be spent on more interesting questions or more deserving people. We call such people losers (due to historical reasons, we sometimes spell it as lusers).

We realize that many people just want to use the software we write, and they have no interest in learning the technical details. For most people, computers are just tools, a means to an end. They have their own lives and more important things to do. We understand this and never expect everyone to be interested in the technical questions that fascinate us. Nevertheless, our style of answering questions is directed towards those who are genuinely interested and willing to actively participate in solving problems, and that will not change. If that changes, we would be reducing our efficiency in doing what we do best.

We (to a large extent) volunteer our time from busy lives to answer questions and are often overwhelmed by inquiries. Therefore, we ruthlessly filter out certain topics, especially discarding those that seem like losers, in order to use our time more efficiently to answer winners questions.

If you dislike our attitude, feeling that we are high and mighty or too arrogant, consider this from our perspective. We do not ask you to submit to us—in fact, most of us are very willing to communicate with you as equals, as long as you make a small effort to meet basic requirements, we will welcome you into our culture. But helping those who are unwilling to help themselves is inefficient. Ignorance is fine, but pretending to be ignorant is not.

So, you do not need to be technically savvy to attract our attention, but you must demonstrate qualities that show you can guide yourself to become savvy—being perceptive, having ideas, being observant, and being willing to actively participate in solving problems. If you cannot do these things that set you apart, we suggest you spend some money to hire a commercial company for technical support instead of asking hackers for free help.

If you decide to seek our help, of course, you do not want to be seen as a loser, nor do you want to be one. The best way to get quick and effective answers is to ask like a winner—smart, confident, and with a problem-solving mindset, only occasionally needing a bit of help on specific issues.

Before Asking#

Before you prepare to ask a technical question via email, community, or social media, please do the following:

Try searching for answers in old articles on the forum where you are preparing to ask.
Try searching online to find answers.
Try reading the manual to find answers.
Try reading the FAQ to find answers.
Try checking or experimenting on your own to find answers.
Ask knowledgeable friends nearby for answers.
If you are a developer, try reading the source code to find answers.

When you ask a question, please indicate that you have made the above efforts; this will help establish that you are not a time-wasting asker. It would be even better if you could express what you have learned during these efforts, as we are more willing to answer questions from those who show they can learn from the answers.

Employ certain strategies, such as first using Google to search for the various error messages you encounter (search both Google Groups and the web), as this is likely to lead you directly to documents or mailing list threads that can solve your problem. Even if you do not find results, adding a note in mailing lists or newsgroups that says, "I searched Google for the following phrases but found nothing useful," is a good idea, even if it only indicates what the search engine could not help with. Doing this (along with the strings you searched) also helps others who encounter similar problems to be directed to your question by the search engine.

Do not rush; do not expect a complex problem to be solved with a few seconds of Google searching. Before seeking help from experts, read the FAQ again, relax, sit comfortably, and take some time to think about the problem. Trust us, they can tell from your question how much reading and thinking you have done, and if you come prepared, you are more likely to get answers. Do not throw all your questions out just because your first search did not yield answers (or yielded too many).

Prepare your question and think it through carefully, as hasty questions can only lead to hasty answers or no answers at all. The more you can demonstrate the effort you put into solving the problem before seeking help, the more likely you are to receive substantial assistance.

Be careful not to ask the wrong question. If your question is based on incorrect assumptions, a typical hacker (J. Random Hacker) will likely think to themselves, "stupid question..." while responding with a meaningless literal explanation, hoping you will learn from the answer to the question (rather than the answer you wanted).

Never assume you are entitled to an answer; you are not. You are not. After all, you have not paid for this service. You will have to earn an answer by asking meaningful, interesting, and thought-provoking questions—a question that has the potential to contribute to the community's experience, rather than just passively seeking knowledge from others.

On the other hand, indicating that you are willing to do something in the process of finding an answer is a very good start. Asking, "Can someone give me a hint?" "What am I missing in this example?" and "What should I check?" is more likely to get a response than "Please post the exact process I need." Because you show that as long as someone points you in the right direction, you have the ability and determination to complete it.

When You Ask#

Choose the Right Forum#

Be careful in choosing the venue where you ask your question. If you do any of the following, you are likely to be ignored or seen as a loser:

Posting your question on a forum that is off-topic.
Posting very basic questions in forums discussing advanced technical issues; and vice versa.
Repeatedly cross-posting the same question in too many different newsgroups.
Sending private emails to people who are neither acquaintances nor obligated to solve your problem.

Hackers will filter out questions that are in the wrong venue to protect their communication channels from being flooded with irrelevant content. You do not want that to happen to you.

Therefore, the first step is to find the right forum. Again, Google and other search engines are your friends; use them to find the websites most relevant to the software or hardware problems you are encountering. Usually, there are links to FAQs, mailing lists, and related documentation there. If your efforts (including reading the FAQ) yield no results, there may still be a bug-reporting process or link on the website; if so, check it out.

Sending emails to strangers or forums is often the riskiest thing to do. For example, do not assume that an author of a content-rich webpage will want to act as your free consultant. Do not be overly optimistic about whether your question will be welcomed—if you are unsure, send it elsewhere or do not send it at all.

When choosing forums, newsgroups, or mailing lists, do not trust the names too much; first, check the FAQ or charter to see if your question is on-topic. Before posting, skim through existing topics to get a feel for the culture there. In fact, searching the history of the newsgroup or mailing list for keywords related to your question is an excellent idea; you might find the answer. Even if not, it can help you formulate a better question.

Do not "spray" all help channels like a machine gun; that is as annoying as shouting. Take it one at a time.

Clarify your topic! One of the most typical mistakes is to ask about Unix or Windows operating system interfaces in a forum dedicated to cross-platform portable languages, suites, or tools. If you do not understand why this is a big mistake, it is best not to ask anything until you figure out the differences.

In general, asking questions in carefully chosen public forums is more likely to yield useful answers than asking the same question in private forums. There are several reasons to support this: one is the number of potential responders, and the other is the size of the audience. Hackers are more willing to answer questions that can help many people.

It is understandable that seasoned hackers and authors of popular software are overwhelmed by too many off-topic messages. Like the last straw that breaks the camel's back, your addition may push the situation to extremes—there have been instances where authors of popular software have withdrawn from supporting their software due to the unbearable influx of useless emails in their personal inboxes.

Stack Overflow#

Search, then ask on Stack Exchange.

In recent years, the Stack Exchange community has become a primary channel for answering technical and other questions, especially those related to open source projects.

Because Google indexing is instantaneous, search Google before looking at Stack Exchange. There is a high chance someone has already asked a similar question, and the Stack Exchange sites often appear among the top search results. If you do not find any answers on Google, then look at the specific relevant topic sites. Searching with tags can help narrow down your search results.

Stack Exchange has grown to over a hundred sites, and here are some of the most commonly used ones:

Super User is for asking general computer questions; if your question is not related to coding or programming, but rather about network connections, come here.
Stack Overflow is for asking programming-related questions.
Server Fault is for asking server and network management-related questions.

Websites and IRC Forums#

Local user groups or the Linux distribution you are using may be promoting their web forums or IRC channels, offering help for newcomers (in some non-English-speaking countries, newcomer forums may still be mailing lists). These are good places to start asking questions, especially when you feel the issues you are encountering may be relatively simple or common. Sponsored IRC channels are open and welcoming places for questions, usually providing immediate responses.

In fact, if the problems with the program only occur in the version provided by a specific Linux distribution (which is common), it is best to ask questions in that distribution's forum or mailing list first before asking in the program's own forum or mailing list. (Otherwise) the hackers of that project may simply respond with "Use our version."

Before posting in any forum, check if there is a search function. If there is, try searching for a few keywords related to your question; this might help. If you have already done a general web search (which you should), search the forum again; the search engine may not have indexed all the content of that forum yet.

Providing user support through forums or IRC channels is becoming increasingly common, while email is mostly reserved for communication among project developers. Therefore, it is best to seek assistance related to the project in forums or IRC first.

When using IRC, it is best not to post long problem descriptions; some call this channel flooding. It is better to start the conversation with a one-sentence problem description.

Step Two, Use Project Mailing Lists#

When a project provides a developer mailing list, ask questions to the list rather than to individual members, even if you are sure that one of them can best answer your question. Check the project's documentation and homepage to find the mailing list and use it. There are several good reasons to adopt this approach:

Any question good enough to ask an individual developer will also benefit the entire project group. Conversely, if you think your question is too stupid for the entire project group, that is not a reason to harass individual developers.
Asking the list can distribute the burden on developers; individual developers (especially project leaders) may be too busy to answer your question.
Most mailing lists are archived, and those archived contents will be indexed by search engines. If you ask a question to the list and receive an answer, others can find your question and answer through web searches in the future, thus avoiding the need to ask again.
If certain questions are frequently asked, developers can use this information to improve documentation or the software itself to make it clearer. If you only ask privately, no one can see the full context of the most common questions.

If a project has both "user" and "developer" (or "hacker") mailing lists or forums, and you are not touching the source code, then ask in the "user" list or forum. Do not assume you will be welcomed in the developer list; those people will likely see your question as noise interfering with their development.

However, if you are sure your question is special and there have been no replies in the "user" list or forum for several days, you can try asking in the "developer" list or forum. It is advisable to observe for a few days before posting to understand how things work there (in fact, this is a good idea for participating in any private or semi-private lists).

If you cannot find a project's mailing list and can only find the email address of the project maintainer, feel free to email them. Even in this case, do not assume (project) mailing lists do not exist. In your email, state that you have tried but could not find a suitable mailing list, and mention that you do not mind if your email is forwarded to others (many people believe that even if there is nothing secret, private emails should not be made public. By allowing your email to be forwarded, you give the relevant person the option to handle your email).

Use Meaningful and Descriptive Titles#

In mailing lists, newsgroups, or forums, a title of about 50 characters is a good opportunity to grab the attention of seasoned experts. Do not waste this opportunity with vague titles like Help!, Please!, Urgent (let alone something off-putting like Help me!!!!—titles like this will be reflexively ignored). Do not expect to impress us with the severity of your pain; instead, use this space to provide a very simple and concise description of your question.

A good title example is a Goal -- Difference style description, which many technical support organizations use. In the Goal part, indicate which item or group of items is problematic, and in the Difference part, describe where the behavior deviates from expectations.

Stupid question: Help! My laptop won't display properly!

Smart question: The mouse cursor in X.org 6.8.1 is distorted on a brand MV1005 graphics card.

Even smarter question: The mouse cursor in X.org 6.8.1 is distorted in the environment of a brand MV1005 graphics card.

Writing a Goal -- Difference style description helps you organize your detailed thoughts about the problem. What is affected? Is it just the mouse cursor or other graphics as well? Does it only occur in the X version of X.org? Or only in version 6.8.1? Is it specific to a certain brand of graphics card? Or just the MV1005 model? A hacker should be able to glance and immediately understand your environment and the problem you are encountering.

In summary, imagine you are searching through an archive discussion thread that only displays titles. Making your title better reflect the problem will allow the next person searching for similar issues to focus on this discussion thread without having to ask the same question again.

If you want to ask a question in a reply, remember to modify the content title to indicate that you are asking a question; a title that looks like Re: Test or Re: New bug is unlikely to attract enough attention. Additionally, appropriately quoting and trimming previous content without affecting coherence can provide clues for new readers.

For discussion threads, do not simply click reply to start a brand new discussion thread, as this will limit your audience. Some email reading programs, like mutt, allow users to sort by discussion thread and hide messages by folding them; those who do this will never see your message.

Simply changing the title is not enough. Mutt and some other email reading programs also check other information beyond the email title to assign it to a discussion thread. So it is better to send a completely new email.

In web forums, good questioning methods are slightly different because threads are tightly coupled with specific information and often cannot be seen outside the thread, so asking questions by replying rather than changing the title is acceptable. Not all forums allow separate titles in replies, and doing so generally means no one will look at it. However, asking questions by replying is inherently ambiguous, as they will only be read by those currently viewing that title. Therefore, unless you only want to ask questions among the current active participants in that discussion thread, it is better to start a new thread.

Make Questions Easy to Reply To#

Ending your question with Please reply to... will likely lead to no response. If you find it troublesome to spend a few seconds setting a reply address in your email client, we find it equally troublesome to spend a few seconds thinking about your question. If your email program does not support this, get a better one; if your operating system does not support such an email program, get a better one.

In forums, asking for replies via email is very rude unless you believe the information in the reply may be sensitive (and someone may, for some unknown reason, only want you to know the answer). If you just want to be notified by email when someone replies to the thread, you can request the web forum to send you notifications. Almost all forums support features like Track this thread, Email me when there are replies, etc.

Use Clear, Correct, Precise, and Grammatically Correct Statements#

From experience, we find that careless askers are often careless in writing code and thinking (I can guarantee that). Answering careless questions is not worth it; we would rather spend our time elsewhere.

Correct spelling, punctuation, and capitalization are very important. Generally, if you find it troublesome to do this, we also find it troublesome and do not want to care about your question. Spend a little extra effort to consider your wording; it does not have to be too stiff or formal—in fact, hacker culture values the accurate use of informal, colloquial, and humorous language. But it must be accurate and show signs that you are thinking and paying attention to the problem.

Correctly spell, punctuate, and capitalize; do not confuse its with it's, loose with lose, or discrete with discreet. Do not use all caps, as this is considered rude shouting (all lowercase is not much better, as it is hard to read. Alan Cox might get away with it, but you won’t).

More colloquially, if you write like a semi-literate newbie, you are likely to be ignored. Also, do not use abbreviations or leet speak in instant messaging, such as shortening 的 to d, as this will make you look like a newbie trying to save a few keystrokes. Worse, if you write like a child drawing symbols, you are definitely asking for trouble; you can be sure no one will pay attention to you (or at most, you will receive a lot of criticism and ridicule).

If you are asking questions in a forum where English is not your native language, you can make some spelling and grammar mistakes, but you must not be careless in your thinking (yes, we can usually tell the difference). Also, unless you know the language of the responders, please write in English. Busy hackers will generally delete messages written in languages they do not understand. English is the lingua franca on the internet, and writing in English minimizes the chances of your question being deleted before it is even read.

If English is your second language, it is good to inform potential responders that you may have language difficulties:
[Note: The following is provided for use]

English is not my native language; please excuse typing errors.

English is not my native language; please excuse my typos or grammar mistakes.

If you speak $LANGUAGE, please email/PM me;
I may need assistance translating my question.

If you speak a certain language, please email/PM me; I need someone to help me translate my question.

I am familiar with the technical terms,
but some slang expressions and idioms are difficult for me.

I am familiar with technical terms, but I find slang or idiomatic expressions difficult to understand.

I've posted my question in $LANGUAGE and English.
I'll be glad to translate responses, if you only use one or the other.

I have posted my question in a certain language and English; if you respond in only one language, I will be happy to translate it into the other.

Use Easily Readable and Standard File Formats to Send Questions#

If you make your question difficult to read, it will likely be ignored; people prefer to read understandable questions, so:

Use plain text instead of HTML (turning off HTML is not difficult).
Using MIME attachments is usually acceptable, as long as they contain real content (such as attached source code or patches), rather than just the email program's generated template (like a copy of the letter's content).
Do not send a block of text that is just one line but will wrap into multiple lines when automatically wrapped (this makes it very difficult to reply to parts of the content). Imagine your reader is reading the email on a terminal that is 80 characters wide; it is best to set your line break points to less than 80 characters.
However, do not set fixed widths for some special files (such as logs or session records). The data should remain intact, allowing responders to be confident they are seeing the same thing you are seeing.
In English forums, do not send messages using Quoted-Printable MIME encoding. This encoding may be necessary for posting non-ASCII languages, but many email programs do not support it. When they handle line breaks, the =20 symbols scattered throughout the text are both unsightly and distracting, and may even disrupt the semantic content.
Absolutely, never expect hackers to read documents written in closed formats, such as Microsoft Word or Excel files. Most hackers react to this like you would if someone dumped steaming pig manure on your doorstep. Even if they could handle it, they would hate doing so.
If you are sending emails from a Windows computer, turn off Microsoft's stupid smart quotes feature (from [Options] > [Spelling] > [AutoCorrect Options], uncheck the smart quotes checkbox) to avoid spreading garbage characters throughout your email.
In forums, do not abuse emoticons and HTML features (when provided). One or two emoticons are usually fine, but flashy colored text tends to make people think you are incompetent. Overusing emoticons, colors, and fonts can make you look like a silly little girl. This is usually not a good idea unless you are only interested in sex rather than answers.

If you are using a graphical email program (like Microsoft Outlook or similar), be aware that their default settings may not meet these requirements. Most of these programs have a menu-based View Source command; use it to check the emails in your sent folder to ensure you are sending plain text files without any strange characters.

Describe the Problem Accurately and Substantively#

Carefully and clearly describe the symptoms of your problem or bug.
Describe the environment in which the problem occurs (machine configuration, operating system, application, and related information), providing the vendor's distribution and version number (e.g., Fedora Core 4, Slackware 9.1, etc.).
Describe how you researched and understood the problem before asking.
Describe the diagnostic steps you took to identify the problem before asking.
Describe any recent hardware or software changes that may be relevant.
Provide a method to reproduce the problem in a controlled environment whenever possible.

Try to anticipate how a hacker might question you and preemptively answer the questions they might have before you ask.

Among the above points, when you report what you believe may be a problem in the code, giving hackers an environment in which they can reproduce your problem is especially important. When you do this, your chances of receiving effective answers and the speed at which you receive them will greatly increase.

Simon Tatham has written an excellent article titled "How to Report Bugs Effectively." We strongly recommend you read it as well.

Be Concise and Precise#

You need to provide precise and substantive information. This does not mean you should simply transcribe a pile of error codes or data into your question. If you have a large and complex test case that reproduces the program's crash, try to trim it down as much as possible.

Doing this serves at least three purposes:
First, it shows that you have made an effort to simplify the problem, which increases your chances of receiving a response;
Second, simplifying the problem makes it more likely that you will receive useful answers;
Third, in the process of refining your bug report, you are likely to find the solution or a workaround yourself.

Do Not Claim to Have Found a Bug Lightly#

When you encounter a problem using software, unless you are very, very sure, do not claim to have found a bug. Hint: unless you can provide a source code patch that solves the problem or provide regression tests to show that the behavior was incorrect in a previous version, you are likely not completely certain. This also applies to web pages and documents; if you (claim to) find a bug in a document, you should be able to provide a correction or alternative document for the relevant location.

Remember, there are many other users who have not encountered the problem you discovered; otherwise, you would have found it while reading the documentation or searching the web (you did those before complaining, right? 50). This also means it is very likely that you are mistaken rather than the software itself being at fault.

The people who write software work very hard to make it as perfect as possible. If you claim to have found a bug, you are questioning their abilities; even if you are right, you may offend some of them. This is especially serious when you shout "bug" in the title.

When asking questions, even if you are privately very sure you have discovered a real bug, it is best to write as if you made a mistake. If there really is a bug, you will see this in the replies. This way, if there is indeed a bug, the maintainers will apologize to you, which is always better than annoying others and then owing them an apology.

Humility Cannot Replace Your Homework#

Some people understand that they should not ask rudely or arrogantly and demand answers, but they choose the other extreme—humility: I know I’m just a pathetic newbie, a loser, but.... This is both annoying and unhelpful, especially when accompanied by vague descriptions of the actual problem.

Do not waste our time with primitive primate tricks. Instead, describe the background conditions and your problem situation as clearly as possible. This is better than being overly humble.

Sometimes web forums have sections specifically for beginners to ask questions; if you genuinely believe you have encountered a beginner's problem, go there, but do not be overly humble.

Describe Symptoms of the Problem Rather Than Your Guesses#

Telling hackers what you think caused the problem is not helpful. (If your reasoning is so effective, why would you need to seek help from others?) Therefore, make sure you tell them the symptoms of the problem exactly, rather than your explanations and theories; let the hackers speculate and diagnose. If you think stating your guesses is important, clearly indicate that these are just your guesses and describe why they do not work.

Stupid question

I keep getting SIG11 errors while compiling the kernel; I suspect a wire is touching the motherboard's traces. How should I check for this?

Smart question

My assembled computer has an FIC-PA2007 motherboard with an AMD K6/233 CPU (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM memory, and I frequently encounter SIG11 errors while compiling the kernel, occurring after 20 minutes of booting, but never in the first 20 minutes. Restarting does not help, but shutting down overnight allows it to work for another 20 minutes. All memory has been replaced with no effect. The standard compilation log for the relevant part is as follows...

Since the above point seems difficult for many to cooperate with, here is a saying to remind you: All diagnostic experts come from Missouri. The official motto of the U.S. State Department is: Show me (from Congressman Willard D. Vandiver's speech in 1899: I come from a state that produces corn, cotton, burrs, and Democrats; eloquence neither convinces me nor satisfies me. I come from Missouri; you have to show me.) For diagnosticians, this is not a doubt but a real and useful demand to see something as closely aligned with the original evidence they see as possible, rather than your guesses and inductive conclusions. So, show us generously!

List Symptoms in Chronological Order#

The series of actions leading up to the problem often provides the most helpful clues for identifying the issue. Therefore, your description should include your steps and the machine and software's responses until the problem occurs. In command-line processing, providing a log of actions (e.g., generated by running a script tool) and quoting several lines (like 20 lines) of the log will be very helpful.

If the crashing program has diagnostic options (like the verbose switch -v), try selecting those options that add debugging information to the logs. Remember, more does not equal better. Try to select an appropriate debugging level to provide useful information rather than drowning the reader in garbage.

If your description is lengthy (like over four paragraphs), summarizing the problem at the beginning and then detailing it chronologically can be helpful. This way, hackers will know what to pay attention to when reading your logs.

Describe Goals Rather Than Processes#

If you want to figure out how to do something (rather than report a bug), describe your goal at the beginning, then state the specific steps you took that led to your blockage.

People who frequently seek technical help often have a higher-level goal in mind, and they get stuck on a specific path they thought would lead them to that goal, then come to ask how to proceed, without realizing that the path itself is problematic. As a result, it can take a lot of effort to resolve.

Stupid question

How can I get the hexadecimal RGB values from a color picker in a certain drawing program?

Smart question

I am trying to replace a color table in an image with my selected colors; the only method I know is to edit each color block, but I cannot figure out how to get the hexadecimal RGB values from a certain drawing program's color picker.

The second way of asking is smarter; you might receive a response like Consider using another more suitable tool.

Do Not Request Private Email Replies#

Hackers believe that the process of solving problems should be public and transparent, and if more experienced individuals notice incompleteness or inappropriateness, the initial reply can and should be corrected. At the same time, the helper can receive some reward, which is their ability and knowledge being recognized by their peers.

When you request private replies, both the process and the reward are halted. Do not do this; let responders decide whether to reply privately—if they do, it is usually because they believe the question was written so poorly or superficially that it would not interest others.

There is a limited exception to this rule: if you are sure that your question may attract a lot of similar replies, then the magical phrase to use is Email me, and I will summarize the replies for the forum. Trying to rescue mailing lists or newsgroups from a flood of similar replies is very polite—but you must keep your promise.

Clearly Express Your Question and Needs#

Vague questions are an almost endless time sink. The people most likely to give you useful answers are usually the busiest (they are busy because they are doing most of the work themselves). Such people are quite averse to unrestrained time sinks, so they tend to dislike vague questions.

If you clearly state what you need the responder to do (such as provide guidance, send a piece of code, check your patch, or other), you are most likely to receive useful answers. This sets a limit on the time and effort required, allowing the responder to focus on helping you. This is great.

To understand the world of experts, think of professional skills as abundant resources, while the time for replies is a scarce resource. The less time you ask them to dedicate, the more likely you are to receive answers from truly professional and busy experts.

So, define your question in a way that minimizes the time experts need to spend identifying your problem and answering it; this technique is very helpful in obtaining useful answers—but this technique is usually different from simplifying the problem. Therefore, asking I want to better understand X; could you point me to some good documentation? is usually better than asking Can you explain X to me? If your code does not work, asking someone to look at where the problem is usually wiser than asking someone to fix it for you.

When Asking About Code#

Do not ask others to debug problematic code without giving a hint about where to start. Posting hundreds of lines of code and saying, It doesn't work will likely lead to you being completely ignored. Posting just a few lines of code and saying, After line seven, I expect it to display <x>, but it actually shows <y> is more likely to get you a response.

The most effective way to describe programming problems is to provide the smallest possible bug-demonstrating test case. What is the smallest test case? It is the essence of the problem; a small snippet of code that exactly demonstrates the abnormal behavior of the program without including other distracting content. How to create the smallest test case? If you know which line or segment of code causes the abnormal behavior, copy it and add enough code to reproduce the situation (for example, enough to allow that code to be compiled/interpreted/processed by the application). If you cannot narrow the problem down to a specific block, copy the code and remove parts that do not affect the problematic behavior. In short, the smaller the test case, the better (see the section on being concise and precise).

In general, obtaining a reasonably concise test case is not easy, but it is always a good habit to try to do so first. This approach can help you understand how to solve the problem yourself—and even if your attempt is unsuccessful, hackers will see that you have made an effort in trying to obtain answers, which can make them more willing to collaborate with you.

If you just want someone to review your code, state that at the beginning of your message, and be sure to mention which parts you think need special attention and why.

Do Not Post Homework Questions#

Hackers are very good at spotting which questions are homework-style questions; most of us have solved such problems ourselves. Similarly, these problems are for you to resolve; you will learn from them. You can ask for hints, but do not ask for complete solutions.

If you suspect you have encountered a homework-style question but still cannot solve it, try asking in user groups, forums, or (as a last resort) in the project's user mailing list or forum. Although hackers will see through it, some experienced users may still provide you with hints.

Eliminate Meaningless Questions#

Avoid ending your questions with meaningless phrases like Can anyone help me? or Is there an answer to this?.

First: If your description of the problem is not good, asking this is redundant.

Second: Since this is redundant, hackers will find it annoying—and will often respond with logically correct but meaningless answers to express their disdain, such as: Yes, someone can help you or No, there is no answer.

In general, avoid yes-or-no, true-or-false, or have-or-have-not type questions unless you want a yes-or-no type answer.

Even If You Are Urgent, Do Not Write "Urgent" in the Title#

This is your problem, not ours. Declaring it "urgent" is likely to backfire: most hackers will simply delete rude and selfish attempts to gain immediate attention. More seriously, the word "urgent" (or other attention-seeking titles) is often filtered out by spam filters—you hope to see your question, but the person may never see it.

There is a half-exception to this: if you are in a very high-profile place that excites hackers, it may be worth doing so. In this case, if you have time pressure, it is polite to mention that, and people may be interested in responding more quickly.

Of course, this is risky, as hackers' points of excitement are often different from yours. For example, sending such a title from the NASA International Space Station (International Space Station) is fine, but doing so for self-satisfied charitable acts or political reasons is definitely not. In fact, posting something like Urgent: Help me save this fluffy little seal! will surely get you ignored or annoy hackers, even if they think the fluffy little seal is important.

If you find this hard to believe, it is best to read the rest of this guide a few more times until you understand before posting.

Being Polite Is Never a Mistake and Sometimes Very Helpful#

Be polite, using please and thank you for your attention or thank you for your care. Let everyone know you appreciate their time spent helping you for free.

To be frank, this point is not more important than being clear, correct, precise, and grammatically correct, nor can it replace those. Hackers generally prefer to read somewhat brusque but technically clear bug reports rather than polite but vague ones. (If this confuses you, remember we evaluate the value of questions based on what they can teach us.)

However, if you have a string of questions to resolve, being polite will certainly increase your chances of receiving useful responses.

(We have noticed that since the publication of this guide, the only serious feedback from seasoned hackers has been about the preemptive thanks. Some hackers feel that Thanks in advance implies that no further thanks are necessary. Our advice is to either say Thanks in advance then thank the responders afterward, or express gratitude differently, such as using Thank you for your attention or Thank you for your care.)

After the Problem is Resolved, Add a Brief Follow-Up#

After your problem is resolved, send a note to everyone who helped you, letting them know how the problem was solved, and thank them once again. If the problem attracted widespread attention in the newsgroup or mailing list, it is appropriate to post a note there.

The ideal way is to reply to the original topic with this message and include a title that clearly indicates Resolved, Solved, or other equivalent markers. In a busy mailing list, a potential responder seeing the discussion thread Problem X and Problem X - Resolved will understand that they do not need to waste time (unless they personally find Problem X interesting), thus freeing up time to solve other problems.

The follow-up does not need to be long or in-depth; a simple Hi, it turned out to be a faulty network cable! Thanks everyone – Bill is better than saying nothing. In fact, unless the conclusion is truly technical, a short and sweet summary is better than a lengthy one. Explain how the problem was resolved, but there is no need to recount the entire process of solving the problem.

For deeper issues, posting a summary of the debugging logs is helpful. Describe the final state of the problem, explain what resolved it, and only then point out the pitfalls that could have been avoided. The part about avoiding pitfalls should be placed after the correct solution and other summary materials, rather than making this information into a detective novel. Listing the names of those who helped you will help you make more friends.

In addition to being polite and substantive, this type of follow-up also helps others searching the mailing list/newsgroup/forum find the actual solution to your problem, allowing them to benefit as well.

At the very least, this follow-up helps everyone who participated in assisting you feel a sense of satisfaction from the resolution of the problem. If you are not a technical expert or hacker, trust us, this feeling is very important for those masters or experts you sought help from. Unresolved problems can be disheartening; hackers are eager to see problems resolved. Good people get rewarded; satisfy their desires, and you will reap the benefits when you ask next time.

Think about how to prevent others from encountering similar problems in the future, and ask yourself if writing a document or adding a FAQ would be helpful. If so, send them to the maintainers.

In hacker culture, this kind of good follow-up is actually more important than traditional etiquette and is a valuable asset in how you earn a reputation by treating others well.

How to Interpret Answers#

RTFM and STFW: How to Know You Have Completely Messed Up#

There is an ancient and sacred tradition: if you receive a response of RTFM (Read The Fucking Manual), the responder believes you should go read the fucking manual. Of course, they are basically right; you should go read it.

RTFM has a younger relative. If you receive a response of STFW (Search The Fucking Web), the responder believes you should have searched the fucking web. That person is likely right as well; go search. (A more gentle way to say this is Google is your friend!)

In forums, you may also be asked to browse the old posts. In fact, someone may even kindly provide you with previous threads that solved this problem. But do not rely on this kindness; you should search old posts before asking.

Typically, those who respond with one of these two phrases will provide you with a manual or a URL containing the information you need, and they are reading while typing these words. These responses mean the responder believes

The information you need is very easy to obtain;
You will learn more by searching for this information yourself than by being spoon-fed.

You should not be upset by this; by hacker standards, they have shown a certain degree of concern for you without ignoring your request. You should thank them for their grandmotherly kindness.

If You Still Don't Understand#

If you do not understand the response, do not immediately ask the other person to explain. Like when you previously tried to solve the problem (using manuals, FAQs, the web, and knowledgeable friends), first try to understand their response. If you really need the other person to explain, remember to show that you have learned something from it.

For example, if I respond to you: It seems like zentry is stuck; you should clear it first., then this is a very bad follow-up question response: What is zentry? A good way to ask would be: Oh~~~ I looked in the documentation, but only the -z and -p parameters mentioned zentries, and neither clearly explains how to clear it. Which of these are you referring to, or did I miss something?

Handling Rude Responses#

Many behaviors that seem rude in hacker circles are not meant to offend. Instead, they are direct and to-the-point communication styles that prioritize solving problems over making people feel comfortable and vague.

If you feel offended, try to respond calmly. If someone has truly crossed the line, the veterans in the mailing list, newsgroup, or forum will likely call them out. If this does not happen and you get angry, the words of the person you are angry with may seem normal in hacker culture, and you will be seen as the one in the wrong, which will hurt your chances of obtaining information or help.

On the other hand, you may occasionally encounter genuinely rude and annoying behavior. In contrast to the above, it is acceptable to hit back hard at real offenders, using sharp language to thoroughly rebut them. However, be very, very sure before acting. Correcting rude comments is a fine line away from starting a meaningless flame war; hackers often cross the line themselves. If you are a newbie or an outsider, the chances of avoiding such reckless opportunities are not high. If what you want is information rather than wasting time, it is best not to put your hands on the keyboard to avoid taking risks.

(Some people assert that many hackers have mild autism or Asperger's syndrome, lacking the nerves needed to lubricate normal human social interactions. This may be true or false. If you are not a hacker, you might think we are crazy, but it can help you cope with our quirky behavior. Just go ahead; we do not care. We like being the way we are and are usually skeptical of labels for illnesses).

Jeff Bigler's observations and summaries related to this are also worth reading (tact filters).

In the next section, we will discuss another issue when you misbehave and the offense you may receive.

How to Avoid Playing the Loser#

In hacker community forums, there may be times when you mess up—either in the way described in this guide or similarly. And you may be told publicly how you messed up, perhaps with some colorful language in the attack.

After such an event, the worst thing you can do is to wail about your experience, claim to be verbally attacked, demand an apology, scream, sulk, threaten legal action, complain to their employer, forget to close the toilet lid, etc. Instead, you should:

Tough it out; it is normal. In fact, it is healthy and reasonable.

Community standards do not maintain themselves; they are upheld by participants actively and publicly enforcing them. Do not cry that all criticism should be sent via private email; it does not work that way. When someone comments that one of your statements is incorrect or presents a different view, insisting that you are being personally attacked is of no benefit; these are all loser attitudes.

There are other hacker forums that, misled by high etiquette requirements, prohibit participants from posting any messages that criticize others' posts and claim, If you do not want to help users, shut up. As a result, thoughtful participants leave in droves, and this only turns them into meaningless chatter and useless technical forums.

Exaggerating, you have to choose between friendliness (in the above manner) or usefulness. Pick one.

Remember: when a hacker says you messed up and (no matter how harshly) tells you not to do it again, they are acting out of concern for you and their community. For them, ignoring you and filtering you out of their lives is easier. If you cannot manage to be grateful, at least show some dignity; do not wail loudly, and do not expect others to treat you like a fragile doll just because you are a dramatic, super-sensitive soul and a newcomer who thinks you are entitled.

Sometimes, even if you did not mess up (or only messed up in their imagination), some people will attack you for no reason. In such cases, complaining will really mess things up.

These troublemakers are either incompetent people who think they are experts or psychological experts testing whether you will truly mess up. Other readers will either ignore them or deal with them in their own way. You do not need to worry about these troublemakers getting themselves into trouble.

Do not let yourself get caught up in flame wars; it is best to ignore most flame wars—of course, this is after you have verified that they are merely flame wars and do not point out where you messed up while cleverly hiding the actual answer to the problem (which is also possible).

Questions That Should Not Be Asked#

Here are some classic stupid questions, along with what hackers think when they do not respond:

Question: Where can I find the X program or X resource?

Question: How do I do Y with X?

Question: How do I set my shell prompt?

Question: Can I convert AcmeCorp files to TeX format using the Bass-o-matic file converter?

Question: My program/settings/SQL statement does not work

Question: My Windows computer has a problem; can you help me?

Question: My program is not running; I think system tool X has a problem

Question: I have a problem installing Linux (or X); can you help me?

Question: How can I hack the root account/steal OP privileges/read someone else's email?

Question: Where can I find the X program or X resource?

Answer: Right where I found it, idiot—on the other side of the search engine. Good grief! Is there really anyone who does not know how to use Google?

Question: How do I do Y with X?

Answer: If you want to solve Y, do not suggest a method that may not be appropriate when asking. This question indicates that the asker is not only completely ignorant of X but also confused about the problem Y is trying to solve, and their thinking is constrained by a specific situation. It is best to ignore such people until they figure out the problem.

Question: How do I set my shell prompt??

Answer: If you are wise enough to ask this question, you should also be wise enough to RTFM and figure it out yourself.

Question: Can I convert AcmeCorp files to TeX format using the Bass-o-matic file converter?

Answer: Try it and see. If you have tried, you already know the answer, so do not waste my time.

Question: My {program/settings/SQL statement} does not work.

Answer: This is not a question; I am not interested in asking you twenty questions to find out what your real problem is—I have more interesting things to do. When I see such questions, my reactions usually fall into one of three categories:

Do you have anything to add?
Too bad; I hope you can figure it out.
What does this have to do with me?

Question: My Windows computer has a problem; can you help me?

Answer: Sure, throw away Microsoft's garbage and switch to an open-source operating system like Linux or BSD.

Note: If the program has an official version for Windows or interacts with Windows (like Samba), you can ask questions related to Windows, just do not be surprised if the response indicates that the problem is caused by the Windows operating system rather than the program itself, as Windows is generally so bad that this statement is usually true.

Question: My program is not running; I think system tool X has a problem.

Answer: You could very well be the first person to notice a significant flaw in a system call or library file that has been used repeatedly by thousands of users; more likely, you are completely unfounded. Extraordinary claims require extraordinary evidence; when you make such claims, you must have a clear and detailed defect report to back it up.

Question: I have a problem installing Linux (or X); can you help me?

Answer: No, I would need to physically work on your computer to find the problem. Go find your local Linux user group for practical guidance (you can find a list of user groups here).

Note: If the installation problem is related to a specific Linux distribution, it may be appropriate to ask in its mailing list, forum, or local user group. In this case, describe the exact details of the problem. Before doing so, carefully search using Linux and all suspected hardware as keywords.

Question: How can I hack the root account/steal OP privileges/read someone else's email?

Answer: Wanting to do this indicates you are a despicable person; seeking a hacker's help shows you are an idiot!

Good Questions vs. Stupid Questions#

Finally, I will illustrate how to ask smart questions by presenting two ways to ask the same question, one stupid and the other wise.

****Stupid question****:

Where can I find information about the Foonly Flurbamatic?

This way of asking is likely to receive a response like STFW.

****Smart question****:

I searched Google for "Foonly Flurbamatic 2600," but did not find useful results. Does anyone know where to find programming information for this device?

This question has already STFW, and it seems they are genuinely having trouble.

****Stupid question****

The source code I got from the foo project won't compile. Why is it so bad?

This arrogant asker thinks it is all someone else's fault.

****Smart question****

The foo project code does not compile under Nulix 6.2. I have read the FAQ, but it does not mention any issues related to Nulix. Here is the log of my compilation process; what am I doing wrong?

The asker has indicated the environment, read the FAQ, listed the errors, and has not shifted the blame onto others; their question is worth addressing.

****Stupid question****

My motherboard has a problem; who can help me?

A hacker's typical response to this type of question is: Sure, do you want me to pat you on the back and change your diaper too? and then hit the delete key.

****Smart question****

I have tried X, Y, and Z on the S2464 motherboard, but nothing worked; I also tried A, B, and C. Note the strange phenomenon when I tried C. Clearly, florbish is grommicking, but the results are unexpected. What are the usual causes of grommicking on Athlon MP motherboards? Does anyone know what further tests I should conduct to identify the problem?

This person is worth answering from another perspective. They demonstrate the ability to solve the problem rather than waiting for answers to fall from the sky.

In the last question, note the subtle yet important distinction between Tell me the answer and Give me insights on what further diagnostic work I should do.

In fact, the latter question originated from a real inquiry made in August 2001 on the Linux kernel mailing list (lkml). I (Eric) was the one who asked the question. I observed this inexplicable locking phenomenon on the Tyan S2464 motherboard, and members of the list provided crucial information to resolve the issue.

By the way I asked my question, I provided something for others to chew on; I managed to make it easy for people to engage and be drawn in. I showed that I had the same capabilities as them and invited them to explore with me. By telling them the paths I had taken to avoid wasting their time, I also demonstrated respect for their valuable time.

Afterward, when I thanked everyone and appreciated the good discussion experience, a member of the Linux kernel mailing list remarked that he felt my question was resolved not because I was a famous person on the list, but because I asked the right way.

Hackers, in a sense, are knowledgeable but lack human warmth; I believe he was right. If I had asked like a beggar, no matter who I was, I would have annoyed some people or been ignored by them. He suggested I take note of this, which directly led to the creation of this guide.

If You Do Not Get an Answer#

If you still do not receive an answer, do not assume we think we cannot help you. Sometimes, it is simply that the person who sees your question does not know the answer. No response does not mean you have been ignored, although it is undeniable that this distinction can be difficult to discern.

In general, simply reposting the question is a bad idea. This will be seen as meaningless noise. Be patient; the person who knows the answer to your question may live in a different time zone, may be sleeping, or your question may not have been organized well from the start.

You can seek help through other channels, which are often more suited to the needs of beginners.

There are many online and local user groups composed of enthusiastic software enthusiasts (even if they may have never personally written any software). People often form such groups to help each other and assist newcomers.

Additionally, you can seek help from many commercial companies, regardless of their size. Do not feel frustrated that you have to pay to get help! After all, if your car's engine cylinder head gasket blew—completely possible—you would still have to take it to a repair shop and pay for the repairs. Even if the software cost you nothing, you cannot expect technical support to always be free.

For popular software like Linux, each developer corresponds to at least thousands of users. It is simply impossible for one person to handle help requests from thousands of users. Keep in mind that even if you have to pay for this assistance, compared to similar software you have purchased, what you pay is negligible (technical support costs for closed-source software is usually much higher than for open-source software, and the content is not as rich).

How to Better Answer Questions#

Be kind in attitude. The pressure from questions often makes people seem rude or stupid, but that is not the case.

Reply privately to first-time offenders. There is no need to publicly shame those who honestly make mistakes; a true newbie may not even know how to search or where to find FAQs.

If you are unsure, be sure to say so! An authoritative-sounding incorrect reply is worse than no reply at all; do not give others the wrong direction just because it sounds fun to sound like an expert. Be humble and honest, setting a good example for both the asker and your peers.

If you cannot help, do not hinder them. Do not joke about actual steps; that could ruin the user's setup—some poor fool might take it as a real command.

Ask probing questions to elicit more details. If you do well, the asker may learn something—you may too. Try to turn stupid questions into good questions; remember we were all newbies once.

While it is legitimate to complain to lazy people with RTFM, it is better to point out where the documentation is (even if it is just suggesting Google search keywords).

If you decide to answer, provide a good answer. Do not suggest clumsy workarounds when others are using the wrong tools or methods; recommend better tools and redefine the problem.

Answer positively! If the asker has already done extensive research and indicated they have tried X, Y, Z, A, B, C but have not succeeded, responding with Try A or B or Try X, Y, Z, A, B, C with a link is of no use.

Help your community learn from the problems. When responding to a good question, ask yourself, How can I modify the relevant documentation or FAQ to avoid answering the same question again?, and then send a patch to the document maintainers.

If you are answering after doing some research, show your work rather than just handing over the results. After all, teaching someone to fish is better than giving them a fish.

If you need basic knowledge about how personal computers, Unix systems, and networks work, refer to Basic Principles of Unix Systems and Networks.

When you publish software or patches, try to follow Software Release Practices.

Acknowledgments#

Evelyn Mitchel contributed some examples of stupid questions and inspired the writing of the section on How to Better Answer Questions, and Mikhail Ramendik provided some particularly valuable suggestions and improvements.