Are you really ready to ask questions

Please stop asking stupid questions!!

The statement

This article is based on “Stop Ask Questions The Stupid Ways” and “How To Ask Questions The Smart Way”, combining The two and cutting out a large number of statements for brevity. Some personal references have also been added, and links to the original text will be provided in the article

Stop Ask Questions The Stupid Ways

Github Chinese translation address github.com/tangx/Stop-…

How To Ask Questions The Smart Way

Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen

This guide is copyrighted by Eric S. Raymond, Rick Moen.

Original website: www.catb.org/~esr/faqs/s…

Github Chinese translation address github.com/ryanhanwu/H…

Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu

Introduction to the

When you ask a technical question, whether you get a useful answer in the end often depends on how you ask it and ask it. This guide will teach you how to ask the right questions to get the answers you want.

The first thing you should understand is that people love challenging questions, or good questions that stimulate their thinking. If we weren’t, we wouldn’t be the people you want to ask. If you give us a good question to chew over and over again, we will thank you very much. Good questions are incentives and gifts. Good questions can improve our understanding and often reveal issues that we were never aware of or thought about before. To people, “Good question!” A sincere compliment.

Still, people have a bad habit of facing simple questions with disdain or arrogance, which can sometimes make us seem hostile to the novice or ignorant, but it’s not.

We make no secret of our contempt for those who refuse to think, or do what they have to do, before asking questions. Those people are time killers — they just want to take, never give, and consume the time we could use with more interesting questions or people who deserve more answers. We call such people losers (for historical reasons, we sometimes spell it lusers).

We know this, and we never expect everyone to be interested in these technical issues that fascinate us. That said, our style of answering questions to people who are genuinely interested and willing to take the initiative to solve the problem isn’t going to change, nor should it. If even that changes, we’re less effective at doing what we do best.

We are (for the most part) voluntary, taking time out of our busy lives to answer questions, and are often inundated with them. So we ruthlessly filter out topics, especially those that look like losers, in order to use our time more productively to answer winners’ questions.

If you resent our attitude, condescension, or arrogance, put yourself in our shoes. We’re not asking you to bend to us — in fact, most of us are more than happy to communicate with you on an equal footing, and as long as you make a small effort to meet the basics, you’re welcome to join the discussion. But it is not efficient for us to help those who are not willing to help themselves. It’s okay to be ignorant, but not to be an idiot.

So you don’t have to be technically good to get attention, but you do have to exhibit traits that will lead you to be good at it — smart, thoughtful, observant, willing to actively participate in problem solving. If you can’t do the things that make you special, we recommend spending some money on a technical support service contract (or training) with a commercial company, rather than asking other individuals to help you for free.

If you decide to turn to us for help, of course you don’t want to be seen as a loser, much less one of the losers. The best way to get quick, effective answers right away is to ask questions like a winner — smart, confident, with a mind to solve problems, and only occasionally needing a little help on a specific problem.

This article takes ** “How To Ask Questions The Smart Way” as The main line, intersperses some other suggestions and some examples encountered in The work, mainly describes The whole process of a question through chapters such as before The question, when you Ask The question, after you get The answer, reflection summary and so on. I hope you can get some help.

Are you really ready for this?

What the hell? What happened? How to do? Help!! Please!!
Your Google Your Google Your Google Did you Google it yourself Didn’t they call you Google

Before you ask any questions

Before you ask a technical question in an email, news group or chat room, do the following:

1. Try searching for answers from old posts on forums where you are going to ask questions. 2. Try an Internet search to find out. 3. Try reading the manual to find out. 4. Try reading the Frequently Asked Questions (FAQ) file for answers. 5. Try checking or experimenting on your own to find out. 6. Ask your powerful friends for answers. 7. If you're a developer, try reading the source code to find out.Copy the code

When you ask questions, show that you have done the above; This will help establish that you are not a free-for-nothing, time-wasting questioner. It’s even better if you can include what you learned in the process of doing the above, because we’re more likely to answer questions from people who show they can learn from the answers.

Using a few strategies, such as first googling every error message you encounter (search Google forums and web pages), you’re more likely to come up with a file or mailing list clue that can solve the problem. Even if nothing comes up, it’s a good thing to add to a mailing list or newsgroup asking for help that I did a Google search for the following sentence and didn’t find anything useful, even if it’s just an indication of what search engines can’t do to help. Doing so (along with searched strings) also allows other people with similar problems to be directed to your question by the search engine.

Don’t worry. Don’t expect a few seconds of Google search to solve a complex problem. Read the FREQUENTLY Asked Questions document (FAQ) again, relax, sit comfortably, and take some time to think about it before reaching out to an expert. Trust us, they can tell from your questions how much reading and thinking you’ve done, and you’re more likely to get answers if you come prepared. Don’t throw out all your questions because your first search didn’t come up with any answers (or too many).

Prepare your questions and think them over carefully, because a hasty question will get a hasty answer, or no answer at all. The more you show that you did something to solve the problem before asking for help, the more likely you are to get substantial help.

Be careful not to ask the wrong question. If your question is based on false assumptions, someone will probably be thinking stupid questions in their head… “While responding with meaningless literal explanations in the hope that you will learn from the answer to the question rather than the one you want to get.

Never think you’re good enough to get the answer. You’re not. You’re not. After all, you’re not paying anything for this service. You’ll earn an answer on your own by asking thoughtful, interesting, intellectually stimulating questions — one that has the potential to contribute to a community’s experience, rather than just passively extracting knowledge from others.

On the other hand, showing that you’re willing to do something about finding answers is a great place to start. Can anyone give us a hint? What’s missing from my example? And where I should check it is easier to get answers than please post the exact process I need. Because you’ve shown that you have the ability and determination to get it done as long as someone points you in the right direction.

What you need to know before asking questions

  1. You know,FreeThe correct translation isfreeRather thanfree.
  2. You know, people who are willing to answer questions, they’re lovely people.
  3. You know, ask the people who help youpayIs a noble act. Even if the person answering isn’t in it for the money.
  4. You know,Buying time is common sense. If you can’t agree, either your wallet is poor or your mind is poor.
  5. It’s not you or your boss who pays the other person’s salary.
  6. Remember, you are the grandson when you ask the question, and the man who helps you is the grandfather.
  7. Understand that the other person has nothing to lose by not answering your questions.
  8. You know,Describe exactly one thingIt’s a basic survival skill. How to ask questions
  9. You know,searchIt’s a basic survival skill, and if you can’t learn to Google, you’re probably not cut out for your industry.
  10. You know,EnglishIt’s a basic survival skill, and if you don’t know English, you may not be really suited for your industry.

When you ask a question

Children in kindergarten know to be polite

Could you tell me... Problem Description... thank youCopy the code

Please and thank you for your attention or attention. Let everyone know that you appreciate them taking the time to help for free.

If you have a list of problems to solve, being polite will certainly increase your chances of getting a useful response.

Being humble is no substitute for your lessons

Some people know they shouldn’t ask rude or arrogant questions and demand an answer, but they choose the other extreme — groveling: I know I’m just a pathetic rookie, a jerk, but… . This is confusing and useless, especially when accompanied by vague descriptions of the real problem.

Don’t waste your time and mine with primitive primate tricks. Instead, describe the background conditions and your problem situation as clearly as possible. This positions you better than kowtowing.

Sometimes web forums have a section for beginners to ask questions. If you really think you have a beginner’s question, go there, but don’t grovel.

Cut out meaningless question sentences

Avoid ending a question with a nonsensical statement, such as can someone help me? Or is there an answer? .

First of all: If you didn’t describe the question very well, asking this question is gilding the lily.

Second: Because asking this question is gild the lily, people will get annoyed with you — and will often show their contempt with logically correct, but meaningless answers like yes, someone can help you or no, there’s no answer.

In general, avoid yes-or-no, yes/no, yes/no questions unless you want a yes-or-no answer.

Choose your questions carefully

Choose your questions carefully. If you do one of the following things, you are likely to be ignored:

  • Post your questions on a forum that doesn’t fit the topic.
  • Post very preliminary questions in forums that explore advanced technical issues; And vice versa.
  • Cross-post the same question on too many different news groups.
  • Send a personal email to someone who is neither an acquaintance nor obligated to solve your problem.

Note: don’t ask very basic questions in an advanced technical group, or they’ll just refer you back to the document or search for it. Let’s say you’re in a Netty application group asking basic Java syntax questions

Describe the problem

When asking a question, learn to describe the question correctly.

  • Use meaningful and descriptive headings

  • Use clear, correct, precise and grammatically correct sentences

  • Send the question in an easy-to-read and standard file format (think about it in the other direction, as you want to be the message recipient, and re-examine your format for legibility)

  • List problem symptoms in chronological order (some problems occur at a certain time interval)

  • Describe the problem accurately and talk about it

  • Do not use the help that chatter ceaselessly, kneel beg, urgent (not to mention save a life !!!! Such a headline would be reflexively ignored) to waste the opportunity.

Think of him as your boss and you’re giving him a report. To use the most refined words and pictures, to each other to explain the ins and outs of a matter.

  • Describe the symptoms of your problem or Bug carefully and clearly.
  • Describe the environment in which the problem occurred (machine configuration, operating system, application, and related information) and provide the distributor’s distribution and version number (e.g.Fedora Core 4,Slackware 9.1, etc.).
  • Describe how you researched and understood the question before asking it.
  • Describe the diagnostic steps taken to determine the problem before asking questions.
  • Describe any recent hardware or software changes that might be relevant.
  • Provide as much as possibleRecreate the controlled environment of the problemMethods.

Try to anticipate what your boss might ask you, and answer any questions they might have before you ask them.

You know, you’re not my girl, and I don’t have time to guess what you want.

Remember, the more conditions you give others, the faster your problems will be solved. Because this is not a puzzle game.

  1. May I have a question aboutwhatThe problem.
  2. I want to achieveWhat kind ofEffect, but I did it this wayWhat kind ofThe problem.
  3. The error log issuch. (toLearn toDraw keywords)
  4. I’ve triedwhatMethods to solve.
  5. I tried to searchwhatThe keyword. I found it in thereThese urlsTried but failed to solve the problem.
  6. I am usingwhatOperating system, what is the version number.
  7. I am usingwhatSoftware, what is the version number.
  8. thank you

Don’t think you need to say thank you only after someone has helped you.

Stupid question: Help! My laptop doesn’t display properly!

Smart questions: mouse cursor distortion in X.org 6.8.1, MV1005 chipset.

Smarter problem: X.org 6.8.1 mouse cursor in MV1005 chipset – distorted.

Avoid the xy – problem

  • Reference address: xyproblem.info/

Y Problem said

  1. The questioner wants to solve the original problem X and feels that solving the extended problem Y will solve problem X
  2. The questioner offered a solutionYThe request of
  3. The responder helps the questioner solve problem Y. (Wasted time for both respondent and questioner)

Ultimately, however, problem Y may not be an appropriate solution to problem X

Therefore, to avoid creating such a forum, the questioner needs to learn to accurately describe his underlying problem at the beginning of the problem.

Avoid big, empty questions

The bigger the question, the less anyone will answer it. Avoid embarrassing questions.

  1. Does anyone in the group know Java?You’ll be able to dissuade anyone who tries to help you
  2. Does anyone in the group know MyBatis?It’s less of a problem, but it’ll dissuade everyone
  3. Is there a big shot here? Student: I have a question?Do you think you’ll get an answer

Don’t ask a hypothetical question before asking it. The more specific the question, the more people will try to answer it.

Learn when to texture

The other party sent a large screen of text code, this is a fart problem

Learn when to circle important points

Don’t assume that other people’s frequencies are in sync with yours and just throw out a picture and an expression like this.

At work, the person you @ will probably ask more about the situation. But in IM chat groups, there is no such luck.

Is the following difficult?

@xxx, I cannot access the Git repository. The environment is: what the environment is.Copy the code

Learn when to post

For problems that require the recipient to reproduce according to certain conditions, not only screenshots but also necessary parameters such as text should be provided.

For example, if you only give a screenshot to the backend during the front-end and back-end interworking, how can the backend reproduce the parameters in the screenshot? In this case, text version parameters, domain name and other necessary parameters must be provided.

What is a retarded question

Don’t claim to find a Bug

When you have a problem using software, don’t claim to have found a Bug unless you are very, very well founded. Tip: Unless you can provide a source code patch to fix the problem, or regression tests to show that the behavior in the previous release was incorrect, you probably won’t be completely sure. The same applies to web pages and files, if you find a Bug in the file, you should be able to provide a fix or replacement file in place.

Remember, there are plenty of other users who don’t have the same problems that you might have found when you read a file or searched the web (you did that before you complained, right?). . This also means that it’s more likely that you’ve made a mistake than the software itself.

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, and even if you are right, you may offend some of them. This is especially true when you’re screaming about bugs in your title.

When asking questions, even if you’re privately confident that you’ve found a real Bug, it’s best to make it sound like you did something wrong. If there is a Bug, you will see it in the reply. This way, if there is a real Bug, the maintainer will apologize to you, which is better than annoying people and then owing them an apology.

Describe the symptoms, not your guesses

Telling hackers what you think caused the problem is not helpful. (If your reasoning is so valid, do you need to ask for help?) “So make sure you tell them exactly what the symptoms are, not your explanations and theories; Let the hackers speculate and diagnose. If you think it’s important to state your guess, make it clear that it’s just your guess and describe why it doesn’t work.

Stupid question

I have encountered a series of SIG11 errors when compiling the kernel, I suspect a fly line on the motherboard of the line, this situation should be how to check the best?

Smart question

My assembly PC is FIC-PA2007 motherboard with AMD K6/233 CPU (Via Apollo VP2 chipset), 256MB Corsair PC133 SDRAM memory, when compiling the kernel, SIG11 errors occurred frequently in the first 20 minutes after the startup, but never in the first 20 minutes. Rebooting didn’t work either, but shutting it down worked for another 20 minutes overnight. All the memory has been replaced. It doesn’t work. The standard compilation record for the relevant part is as follows… .

Since this seems too much for many people to work with, here’s a reminder: All the diagnosticists are from Missouri. The official motto of the State Department is: Let me see. (Congressman Willard D. Vandiver, 1899: Coming from a country of corn, cotton, burdocks, and Democrats, eloquents can neither persuade nor satisfy me. I’m from Missouri. You have to show me. This is not a suspicion on the part of the diagnosticist, but a real and useful need to see what is as consistent as possible with the original evidence you see, rather than your guesses and generalizations. So be generous and show us!

Describe the goal, not the process

If you want to figure out how to do something (as opposed to reporting a Bug), describe your goal at the beginning, and then state the specific steps you are stuck on.

People who often seek tech help have a higher goal in mind, and they get stuck on a particular path they think will get them there, and then come asking for directions, not realizing that the path itself is problematic. It turned out to be a lot of work.

Stupid question

How can I get hexadecimal RGB values from a drawing program’s color picker?

Smart question

I’m trying to replace the color table of an image with a color code of my choice. The only way I know is to edit each table slot, but I can’t get the hexadecimal RGB value from a drawing program’s color picker.

The second is smarter, and you may get a response that suggests another, more appropriate tool.

Articulate your problems and needs clearly

Endless questions are an almost endless black hole of time. The people most likely to give you useful answers are also the people who are the busiest (busy because they have to do most of the work themselves). Such people have an aversion to the black hole of incontinence, so they tend to have an aversion to rambling questions.

If you specify what you need the respondent to do (provide Pointers, send a piece of code, check your patches, etc.), you’re most likely to get a useful answer. This sets a limit on time and energy that the respondent can focus on helping you. That’s great.

To understand the world in which experts operate, think of expertise as an abundant resource, and time to recover as a scarce one. The less time you ask for from them, the more likely you are to get answers from really professional and busy experts.

So, defining your question in such a way that it minimizes the amount of time the expert has to spend identifying your question and answering it, is a technique that can be quite helpful in helping you with your answer-but it’s usually not the same as simplifying the question. Therefore, if I want to better understand X, could you please give me some advice? Can you explain X? For the better. If your code doesn’t work, it’s usually wise to ask someone else to look at what’s wrong, rather than ask someone else to fix it for you.

When you ask questions about your code

Don’t ask someone to debug your broken code without giving you a clue where to start. Post a few hundred lines of code and say: It doesn’t work and you’re completely ignored. Post just a few dozen lines of code and say: After line seven, I expected it to show

, but

is more likely to get you a response.

The most effective way to describe procedural problems is to provide the most concise version of the bug-demonstration test case. What is the simplest test case? That’s the problem in miniature; A small snippet of a program shows just enough of the program’s unusual behavior to contain no other distractions. How to make the simplest test case? If you know which line or piece of code is causing the abnormal behavior, copy it and add enough code to reproduce the condition (e.g., enough for the code to be compiled/translated/processed by the application). If you can’t narrow the problem down to a specific block, make a copy of the code and remove the parts that don’t affect the behavior that caused the problem. In short, the smaller the test case, the better.

In general, it’s not easy to get a fairly lean test case, but it’s a good habit to always try to do it first. This approach helps you understand how to solve the problem on your own — and even if your attempts are unsuccessful, hackers will see that you put effort into trying to get an answer, which can make them more willing to work with you.

If you just want someone to Review the code, say so at the beginning of the letter, and be sure to mention which areas you think need special attention and why.

After the problem is solved

When the problem is solved, add a brief footnote

When the problem is resolved, send a note to everyone who helped you, letting them know how the problem was resolved and thanking them again. If the problem is getting a lot of attention on a newsgroup or mailing list, it’s appropriate to post a note there.

Ideally, reply to the message on the topic of the original question and include a clear indication in the title that it has been corrected, resolved, or some other equivalent. On a busy mailing list, a potential respondent who sees the discussion string problem X and problem X – solved knows that there is no time to waste (unless he finds problem X personally interesting) and can use that time to solve other problems.

The footnotes don’t have to be long or in-depth; Simple hello, the original line is out of the problem! Thank you — Bill is better than saying nothing. In fact, unless the conclusion is really technical, a short and cute summary is better than a long one. Explain how the problem was solved, but don’t necessarily repeat the process.

For deep problems, Posting a summary of the debug log is helpful. Describe the end state of the problem, say what fixed the problem, and then identify avoidable blind spots. Avoiding blind spots should come after the correct solution and other summary material, rather than turning this information into a detective story. Make a list of people who have helped you and you will make more friends.

In addition to being polite and informative, this type of supplement can also help others benefit from searching mailing lists/news groups/forums for real solutions to your problems.

At the very least, this supplement helps give everyone involved the satisfaction of solving a problem. If you’re not a technologist or hacker yourself, trust us, this feeling is very important for the gurus and experts you turn to for help. Unanswered questions can be frustrating; Hackers are eager to see the problem fixed. Give the good guys what they want, and you’ll reap the rewards the next time you ask.

Think about how you can prevent others from having similar problems in the future. Ask yourself if it would help to write a document or add a FREQUENTLY asked Question (FAQ). If so, send them to the maintainer.

This kind of good follow-through is actually more important than traditional etiquette among hackers, and it’s how you earn your reputation by being nice to others, which is a very valuable asset.

Summarize problem

I look at myself every day

Try to summarize and reflect on the shortcomings in describing the problem and seeking the answer, and try to change it

  • Is this the first time I’m asking this question? (Repeated difficulty of the same question indicates no progress.)
  • Were you asked to look at the document? (If so, it’s because I didn’t read the document, missed it, was it unclear, or couldn’t understand it at my level)
  • Is asking a question being asked to Go to Google? (If so, it’s because I didn’t search, or didn’t find it, how did others find it?)
  • Was the question asked to describe it again? (Is it because I did not clearly describe the problem, or for other reasons? Could you please deal with it in advance next time?)
  • Do you already know the solution when pressed to describe the problem again? (If so, can you describe the problem in more depth next time?)
  • What methods have I tried to solve this problem? What methods did the solver use? (Find the difference)

Try to summarize the problem:

Try to summarize the questions and answers to see if there is a pattern. Don’t try to memorize the answers in your head. Your mind doesn’t remember the answers. Summary of the scheme is a lot, you can often find how to sum up.

How to interpret the answer

RTFM and STFW: How do you know you’ve totally screwed up

There is an old and sacred tradition: if you receive a response from RTFM (Read The Fucking Manual), The respondent thinks you should Read The Fucking Manual. Of course, basically he’s right and you should read it.

RTFM has a young relative. If you receive a response from STFW (Search The Fucking Web), The respondent thinks you should Search The Fucking Web. That person is probably right, so do a search. (To put it mildly, Google is your friend!)

In the forum, you may also be asked to climb the forum’s old text. In fact, someone might even be keen to provide you with discussion threads that have previously addressed this problem. But don’t rely on such solicitation. Do a search before asking.

Usually, the person who answers with one of these will give you a brochure or a website that contains the information you need, and they are reading it as they type it. These responses mean that the respondents think

  • The information you need is readily available;
  • You can learn more by searching for this information yourself than by pouring it down your throat.

You shouldn’t feel bad about it; By hacker standards, he has shown a degree of interest in you without turning a blind eye to your requests. You should thank him for his grandmotherly kindness.

If you still don’t understand

If you don’t understand the response, don’t immediately ask for an explanation. Try to understand his response as you would if you were trying to solve a problem on your own (using manuals, FAQs, the Internet, and other experts around you). If you really need an explanation, show that you’ve learned something from it.

For example, if I answer you: It looks like Zentry is stuck; You should clear it first. “And then, here’s a bad follow-up question: What is zentry? A good way to ask this is: oh, I read the instructions, but only the -z and -p parameters mention zentries, and neither clearly explains how to remove it. You mean which one of these two? Or am I missing something?

The wrong question to ask

Here are a few classic dumb questions, and what hackers are thinking when they don’t answer them:

Question: Where can I find X programs or X resources?

Question: How do I make Y out of X?

Question: How do I set up my shell prompt?

Question: Can I convert AcmeCorp files to TeX format using the Bass-O-Matic file conversion tool?

Problem: my program/setup /SQL statements are useless

Question: I’m having a problem with my Windows computer. Can you help me?

Problem: my program won’t work, I think there is something wrong with system tool X

Question: I am having problems installing Linux (or X), can you help me?

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


Question: Where can I find X programs or X resources?

Answer: Right where I found it, idiot – at the end of the search engine. Oh my god! Is there anyone who can’t use Google?

Question: How do I make Y out of X?

Answer: If you want to solve Y, don’t ask in a way that might not be appropriate. This kind of question shows that the questioner is not only completely ignorant of X, but also confused about the problem Y is trying to solve. He is also imprisoned by the specific situation. It’s best to ignore such people until they figure things out.

Q: How do I set up my shell prompt?

Answer: If you are smart enough to ask this question, you should be smart enough to go to RTFM and find out for yourself.

Question: Can I convert AcmeCorp files to TeX format using the Bass-O-Matic file conversion tool?

Answer: Just try and see. If you had tried, and you knew the answer, you wouldn’t have wasted my time.

Problem: my {program/setup /SQL statement} doesn’t work

Answer: That’s not a question. I’m not interested in a question that requires me to ask you twenty questions to figure out your real problem — I have better things to do. When I see this kind of question, I usually have one of three reactions

  • Do you have anything to add?
  • That’s too bad. I hope you can fix it.
  • What the hell do I care?

Question: I’m having a problem with my Windows computer. Can you help me?

Answer: Yes, get rid of Microsoft’s junk and switch to an open source operating system like Linux or BSD.

Note: If the program has official Windows or interacts with Windows (like Samba), you can ask Windows-related questions. Just don’t be surprised to hear that the problem is caused by the Windows operating system and not the program itself. Because Windows generally sucks, and that’s usually true.

Problem: my program won’t work, I think there is something wrong with system tool X

Answer: It is entirely possible that you are the first person to notice an obvious flaw in the system call and function library files used repeatedly by thousands of users, or more likely that you have no basis at all. Extraordinary claims require extraordinary evidence, and when you make such claims you must back them up with clear and detailed documentation of defects.

Question: I am having problems installing Linux (or X), can you help me?

Answer: no, I can only find the problem by working on your computer myself. Go to 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 Linux distribution, it may be appropriate to ask questions on its mailing list, forum, or local user group. At this point, the exact details of the problem should be described. Until then, search carefully for Linux and all suspected hardware keywords.

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

Answer: Wanting to do so shows you are a scumbag; Looking for a hacker to help you means you’re an idiot!

Good questions and dumb questions

Finally, I’ll show you how to ask smart questions by giving some examples; When two ways of asking the same question are put together, one is foolish and the other is wise.

Stupid question:

Where can I find information about Foonly Flurbamatic?

This is no more than STFW’s answer.

Smart questions:

I googled “Foonly Flurbamatic 2600” but found nothing useful. Who knows where to find information on programming such a device?

This problem has been STFW, it seems that he is really in trouble.

Stupid question:

The source code I retrieved from project Foo didn’t compile. Why is it so bad?

He felt it was someone else’s fault, the arrogant questioner.

Smart questions:

The project foo code does not compile under Nulix 6.2. I’ve read the FAQ, but there’s nothing in it about Nulix. This is a record of my compilation process. What did I do wrong?

The questioner has pointed out the circumstances, read the FAQ, and listed the errors, and it’s worth noting that he’s not blaming anyone else for the problem.

Stupid question:

I have a problem with my motherboard. Who can help me?

A hacker’s usual response to such questions is: Ok, want a pat on the back and a diaper change? And then press the Delete key.

Smart questions:

I tried X, Y, and Z on the S2464 motherboard, but nothing worked, so I tried A, B, and C. Notice the weirdness when I try C. Apparently Florbish is grommicking, but with surprising results. What causes grommicking in general on Athlon MP motherboards? Does anyone know what tests I should run next to find out what’s wrong?

This guy, on the other hand, deserves an answer. He showed the ability to solve problems rather than wait for answers to fall into his lap.

In the last question, note the subtle but important difference between telling me the answer and giving me a hint as to what more diagnostic work I should be doing.

In fact, the latter question originated from an actual question posted on the Linux Kernel mailing list (LKML) in August 2001. I (Eric) was the one who asked the question. I have observed this unexplained locking phenomenon on the Tyan S2464 motherboard and the list members have provided important information on how to solve this problem.

By the way I ask questions, I give people something to chew on; I try to make it easy for people to participate and be drawn in. I showed that I was as competent as they were and invited them to discuss it with me. I show respect for their valuable time by telling them about the detour I’ve taken so they don’t waste any more.

Later, when I thanked everyone and appreciated the good discussion, one member of the Linux kernel mailing list said he felt my problem was solved not because I was a celebrity on the list, but because I asked the question in the right way.

A hacker is, in a way, an intellectual but impersonal fellow; I believe he is right. If I ask questions like a beggar, no matter who I am, someone will annoy me or be ignored. He suggested THAT I write this down, which led directly to this guide.

If you don’t get an answer

If you still don’t get an answer, please don’t think we feel unable to help you. Sometimes the person who sees your question doesn’t know the answer. Not responding doesn’t mean you’re being ignored, though admittedly the distinction is hard to make.

In general, simply Posting questions repeatedly is a bad idea. It will be seen as meaningless hoopla. Be patient, the person who knows the answer to your question may live in a different time zone, be asleep, or your question may not have been organized in the first place.

You can get help from other sources, which are often better suited to the needs of beginners.

There are many online and local user groups made up of passionate software enthusiasts (even if they may never have written any software themselves). Often people form such groups to help each other and help newbies.

In addition, there are many business companies, large and small, that you can turn to for help. Don’t feel bad about having to pay for help! After all, if your car’s engine cylinder seal blows — and it probably does — you still have to take it to the garage and pay for the repair. Even if the software doesn’t cost you anything, you can’t expect tech support to always be free.

For popular software like Linux, there are at least tens of thousands of users for each developer. It is impossible for one person to handle calls from tens of thousands of users. Keep in mind that even if you do pay for this assistance, you’re paying a pittance compared to what you’re buying for comparable software (often closed source software is much more expensive and less informative than open source software).

How to better answer questions

Be nice. The stress of a problem often makes a person seem rude or stupid, which is not the case.

Respond privately to first-time offenders. There is no need to publicly shame those who make honest mistakes. A true novice may not even know how to search or where to find common questions.

If you’re not sure, say so! A wrong reply that sounds authoritative is worse than none. Don’t give directions just because it’s fun to sound like an expert. Be humble and honest and set a good example to questioners and colleagues alike.

Don’t stand in his way if you can’t help him. Don’t joke about the actual steps, as you might ruin the user’s Settings – some poor idiot will take it as a real command.

Ask tentative rhetorical questions to elicit more details. If you do it well, the questioner can learn something — and so can you. Try to turn dumb questions into good ones. Remember we were all beginners once.

While RTFM is a legitimate complaint to those slackers, pointing out the file’s location (even if it’s just a suggested Google search term) would be better.

If you decide to answer, please give a good answer. Instead of suggesting clunky workaround when others are using the wrong tool or method, recommend better tools and redefine the problem.

Answer the question positively! If the questioner has done A lot of research and shows that he has tried X, Y, Z, A, B, C and got no results, it doesn’t help to say try A or B or try X, Y, Z, A, B, C and attach A link.

Help your community learn from the problem. When responding to a good question, ask yourself how can you change the relevant file or FAQ so you don’t have to answer the same question again? , and then send a patch to the file maintainer.

If your answer is based on research, show off your skills rather than delivering results. After all, it is better to teach a man to fish than to give him fish.

The appendix

Send problems using easy-to-read and standard file formats

If you make a question artificially hard to read, it will probably be ignored, and people will prefer to read a question that is easy to understand, so:

  • Use plain text instead of HTML (it’s not hard to turn off HTML).
  • Using MIME attachments is usually ok if there is actual content (such as the accompanying source code or patch) and not just a template generated by the mail program (such as just a copy of the content of the letter).
  • Don’t send a single line of text that wraps into multiple lines (this makes it difficult to respond to part of the text). Assume that your reader is reading emails on a terminal 80 characters wide, and set your line break point to less than 80 characters.
  • However, do not set fixed widths for special files (such as log file copies or session records). The data should be included as is to give respondents confidence that they are seeing the same thing as you.
  • Do not use it in English forumsQuoted-PrintableMIME encoding sends messages. This encoding may be necessary for Posting non-ASCII languages, but many mail programs do not support it. When they deal with line breaks, those are scattered throughout the text= 20Symbols are ugly and distracting, and can even destroy the meaning of the content.
  • Hackers should never, ever be expected to read documents written in closed formats such as Microsoft Word or Excel files. Most hackers react the same way you would if someone dumped steaming pig manure on your doorstep. Even if they could handle it, they hated it.
  • If you’re sending email from a Windows computer, turn off Microsoft stupidSmart quotesFunction (choose [Options] > [Edit] > [Auto Correction Options], checkSmart quotesCheckbox) to avoid spamming your email.
  • In the forum, do not abuseemoticonsandHTMLFunctions (when they are provided). An emoji or two is usually fine, but loud colored text tends to make you look incompetent. Excessive use of emojis, colors and fonts can make you look like a giggling little girl. This is usually not a good idea, unless you are only interested in sex and not the answer.

If you use email programs with a graphical user interface (such as Microsoft Outlook or something similar), be aware that their default Settings don’t necessarily meet these requirements. Most of these programs have a checklist-based view source command that checks messages in the send folder to make sure they are plain text files without any strange characters.