The wisdom of asking questions

Intermediary transaction http://www.aliyun.com/zixun/aggregation/6858.html ">seo diagnose Taobao guest cloud host technology Hall

in the hacker world, what answers can you get when you ask a technical question? Depending on how difficult it is to dig out the answer, it depends on how you ask. This guide is designed to help you improve your questioning skills to get the answers you want most.

First you have to understand that hackers only prefer difficult tasks, or they can inspire good questions about their thinking. If not, what are we doing here? If you have a good question that deserves our repeated chewing and pondering, we will be grateful to you. The good question is that motivation, a gift, can improve our understanding and often exposes problems that we have never known or thought about before. For hackers, "good question!" "is a great compliment from the heart.

Although hackers have a reputation for contempt for simple problems and unfriendly, sometimes it seems that we are hostile to the novice and the poor, but that is not the case.

We don't want to hide our contempt for such people-they don't want to think, or they don't do what they're supposed to do before they ask questions. Such people will only kill time-they are willing to take, never give, and consume our time, and we could have spent time on more interesting questions or more deserving respondents. We call such people "losers" (for historical reasons, we sometimes spell it "lusers").

We are largely volunteers who take time out of busy life to answer questions and are often overwhelmed by questioning. So we ruthlessly filter out some of the topics, especially those who look like losers, so that we can use time more efficiently to answer winners ' questions.

If you think we are too arrogant attitude to make you uncomfortable, let you wronged, you might as well put yourself in the thinking. We are not asking you to give in to us--in fact, most of us like the Fair trade, and as long as you give a little effort to meet the minimum requirements, we will welcome you to join our culture. But it makes no sense to let us help those who are unwilling to help themselves. If you can't accept this "discrimination," we suggest you spend some money on a technical support agreement with a business firm. Don't ask the hacker for help.

If you decide to turn to us for help, you certainly don't want to be seen as a loser, much less a loser. The best way to get an effective answer right away is to ask as a winner--smart, confident, problem-solving, and only occasionally need a little help on a particular issue.

　
= Before asking questions =

Before you ask for technical questions via email, newsgroups or chat rooms, check to see if you have:

1. Read through the manual and try to find the answer yourself.
2. Find answers in the FAQ (a well maintained FAQ can be exhaustive:).
3. Search online (personal recommendation google~~~).
4. Ask your friends who are proficient in this way around you.

When you ask a question, start by stating what you have done before, and this will help to build your image: You are not a beggar who wants nothing but a vain effort to waste others ' time. If the questioner can learn something from the answer, we are more than happy to answer his question.

Thoughtful thinking, preparing your questions, hasty questions can only be answered hastily, or no answer at all. The more you show your efforts to solve problems before you ask for help, the more you can get substantial help.

Be careful not to ask the wrong question. If your problem is based on false assumptions, the average hacker (J.) Random Hacker usually answers you with meaningless literal explanations, thinking "stupid questions ..." and hoping that you will learn from the answers to questions rather than the answers you want.

Never think you are qualified to get the answer. After all, you have not paid for the service. You have to "earn" an answer by presenting a meaningful, interesting, and stimulating question-a question that potentially contributes to the experience of the community, not just a passive request for knowledge from others-to earn the answer.

On the other hand, it is a good start to show that you are willing to do something in the process of finding an answer. "Who can give a hint?" "and" What is missing in my example? "and" Where should I check? It's easier to get answers than "please post the exact process." Because you appear as long as someone is pointing the right direction, you have the ability and determination to complete it.

= How to ask questions

-Choose Forum Carefully
Carefully choose the occasion of the question. If, as described below, you are likely to be ignored or seen as losers:

1. Post your questions in a irrelevant forum
2. Posting of very elementary questions in forums exploring advanced techniques;
3. Cross-posting in too many different newsgroups

-appropriate, grammatically correct, spelled correctly
We have learned from experience that careless writers are often sloppy thinkers (I'm sure they are). It is not worth answering the careless questions, we would rather spend our time elsewhere.

Correct spelling, punctuation, and capitalization are important.
More generally, if your questions are written like a functional illiteracy, you are likely to be overlooked.

If you're asking questions in a Non-native speaker forum, you can make a few spelling and grammatical mistakes--but you can't think about horse Tigers (yes, we can figure out the difference)

-Use a rich, descriptive, accurate title
In a mailing list or newsgroup, the topic title within about 50 words is the golden opportunity to capture the attention of senior experts. Stop "helping" (not to mention "help"),!!!!!. "It's a disgusting thing to waste this opportunity." Don't try to impress us with your pain, don't use a space to replace the description of the problem, even if it's a very short description.

Stupid question: Help! My laptop can't be displayed properly!
Smart question: XFREE86 4.1 mouse cursor deformation, fooware MV1005 display chip.

If you ask a question in response, remember to change the title of the content to indicate that there is a problem. A problem that looks like "Re: Test" or "Re: A new bug" is difficult to give enough attention to. In addition, quote and subtract the contents of the previous text, leaving clues to the new reader.

-Accurate description, large amount of information

1. Carefully and clearly describe the symptoms.
2. Provide the environment in which the problem occurs (machine configuration, operating system, application, and anything else).
3. How do you study and understand this problem before you ask a question?
4. Indicate what steps you have taken to resolve the question before you ask.
5. List any hardware or software changes that have recently been made that may be affected.

Try to imagine how a hacker would ask you questions and give them an answer in advance.

Simon Tatham has written an excellent essay entitled How to Report bugs effectively. It is strongly recommended that you read it too.

-no more words.
You need to provide accurate and effective information. This is not to ask you to simply extract tons of error codes or data completely into your questions. If you have large and complex test conditions, try to trim it as small as possible.

The use of this is at least three points. First, show that you have worked hard to simplify the problem, which will increase your chances of getting an answer; second, simplifying the problem increases your chances of getting a useful answer; Third, in refining your bug report, you may be able to identify the problem or make corrections yourself.

-Just the symptom, not the conjecture.
Tell the hackers how you think the problem is causing little help. (If your inference is so effective, do you want to ask someone else for help?) So be sure that you tell them the symptoms of the problem without adding to your own understanding and inference. Let the hackers diagnose them.

Stupid question: I encountered the SIG11 error again and again in the kernel compilation, I suspect that a flying line is on the main board line, how to check the best way?
Smart question: I made a set of k6/233 system, the motherboard is fic-pa2007 (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM, in the kernel compiled frequently produce SIG11 error, from the boot 20 minutes after this situation, boot It never happened in the first 20 minutes. Restarting is no use, but the shutdown can work for 20 minutes a night. All memory has been replaced, no effect. The typical compilation records for the related section are as follows ....

-List symptoms in chronological order
The most helpful clues to finding a problem are often a sequence of actions before a problem occurs, so your instructions should include the procedure and the computer's response until the problem arises.

If your description is long (more than four paragraphs), it will help to outline the problem at the beginning, followed by chronological detail. So the hackers know what to look for in your instructions.

-Understand what you want to ask.
Rambling questions almost endless time black holes. The people who can give you the most useful answers are the busiest (they are busy doing most of the work themselves). Such people are not too cold to the uncontrolled black hole, so they can be said to be not very cold about rambling questions.

If you articulate what needs to be answered (provide advice, send a piece of code, check your patch or something else), you are most likely to get useful answers. This will set a limit of time and energy so that the respondents can concentrate on helping you, which is very effective. To understand the world in which experts live, think of professional skills as abundant resources, and the time to reply is a scarce resource. The less time you need to solve your problem, the more you can get the answer out of a busy expert.

Therefore, optimizing the structure of the problem, minimizing the time that experts need to solve it, can be very helpful-which is usually different from simplifying the problem. Therefore, ask "I want to better understand x, can you give me some hints?" "It's usually better than asking," Can you explain x? Better。 If your code doesn't work, it's much wiser to ask what's wrong with it than to ask someone to change it for you.

-Don't ask questions that should be solved by yourself.
Hackers are always good at distinguishing which problems should be resolved by you, because most of us have solved them ourselves. Again, these problems are up to you, and you'll learn from them. You can ask for a hint, but don't ask for a complete solution.

-Remove meaningless questions
Don't end your questions with meaningless words like, "Can someone help me?" "or" Is there an answer? ”。 First of all: If your description of the problem is not very appropriate, this question is superfluous. Second: Because the question is superfluous, hackers will get tired of you-and often use logically correct answers to show their contempt, for example: "Yes, someone can help you" or "no, no answer."

-Modesty is never harmful, and it's always helpful.
Be polite, use the word "please" and "Thank you first". Let everyone know that you are thankful that they have spent their time and duty to help. However, if you have a lot of problems to solve, politeness will increase your chances of getting useful answers.

(We note that since the publication of this guide, the only serious flaw feedback from the senior hackers is the one that has been thanked beforehand.) Some hackers feel that "thank you first" is the implication that you will not thank anyone anymore. Our suggestion is: Thank you all. ）

-After the problem is resolved, add a short description
After the problem has been solved, send a note to all those who have helped you to let them know how the problem is resolved and thank them once again. If the issue is causing widespread concern in newsgroups or mailing lists, you should put a supplemental note there. The supplement does not have to be long or very deep; the simple phrase "Hello, it turns out that the network cable is out of the question!" Thank you,--bill. "Better than nothing." In fact, short, cute summaries are better than long academic papers unless the conclusions are really technical. Explain how the problem is solved, but the process of solving the problem will not be repeated. In addition to expressing politeness and feedback, this supplement helps others to search the mailing lists/newsgroups/forums for complete solutions that you have helped, which may be useful to them as well. At last (at least?) , this supplement helps all those who have provided help to get satisfaction from it. If you're not a veteran or a hacker, trust us, which is very important to the mentor or expert you turn to for help. Long delays are frustrating; hackers are eager to see the problem resolved. The good people have the best news, satisfy their desire, you will taste the next time a new problem.

-Still don't understand.
If you don't understand the answer, don't ask for an explanation right away. Understand it as you did when you tried to solve the problem yourself (using a manual, FAQ, network, the master around you). If you really need an explanation, remember to show that you've learned something. For example, if I answer you: "It seems like Zentry is blocked; you should clear it first." "And then: a bad follow-up question:" What is Zentry? " "The wise question should be this:" Oh ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Or am I missing something? ”

= Think twice before asking

Here are a few classic silly questions and the hacker's thoughts in refusing to answer:

Question: Where can I find the X program?
Question: My program/configuration SQL declaration is not used
Question: I have a problem with Windows, can you help me?
Question: I have a problem installing Linux (or x), can you help me?
Question: How can I crack the root account/steal OP privileges/read other people's emails?

Question: Where can I find the X program?
Answer: Just where I found it, stupid--the one on the search engine. Oh, my God! Does anyone else use Google?

Question: My program (Configuration, SQL Declaration) is not used
Answer: That's not a problem, I'm not interested in finding out your real problem-if I ask you 20 questions to find out-I have more interesting things to do.

When I see this kind of problem, my reaction is usually no more than the following three kinds:

1. Do you have anything to add?
2. Bad, I hope you can handle it.
3. What kind of bird do I have?

Question: I have a problem with Windows, can you help me?
Answer: Yes, throw away the soft trash, change Linux.

Question: I have a problem installing Linux (or x), can you help me?
Answer: No, I have to do it myself on your computer to find fault. Go to your local Linux user group for hands-on guidance (you can find a list of user groups here).

Question: How can I crack the root account/steal OP privileges/read other people's emails?
Answer: If you want to do this, you are a despicable person, you want to find a hacker to help you, that you are an idiot!

= good problem, bad problem =

Finally, I would like to give some examples to illustrate how to ask questions intelligently, the two ways of asking the same question are put together, one is stupid, the other is wise.

Stupid question: Where can I find information about Foonly flurbamatic?
This kind of method of asking is to want "STFW" such answer.

Smart question: I googled "foonly flurbamatic 2600" with Google, but found no useful results. Who knows where to find information on the programming of this device?
The problem has been stfw, and it seems that he is really in trouble.

Stupid question: The source code I found from the Foo project cannot be compiled. Why is it so bad?
He thinks it's all somebody else's fault, this arrogant guy.

Smart question: Foo Project code cannot be compiled with Nulix version 6.2. I've read the FAQ, but there's no mention of Nulix-related issues. This is the record of my compilation process, what do I do wrong place?
He speaks the environment, he reads the FAQ, he points out the mistake, and he doesn't put the blame on someone else, and this guy deserves attention.

Stupid question: My motherboard has a problem, who will help me?
Ordinary hackers usually answer such questions by: "OK, do you want to pat your back and change your diapers?" , and then press the DELETE key.

Smart question: I tried x, y, and z on the S2464 motherboard, but it didn't work, and I tried A, B, and C again. Please note the strange phenomenon when I try C. Apparently there was a contraction in the band transfer, but the results were unexpected. What are the common causes of side-band leaks on multiprocessor motherboards? Who's got a good idea? What should I do next to find out?
This guy, from another point of view, is worth answering. He showed the ability to solve problems rather than wait for the sky to fall.

In the final question, pay attention to the subtle and important distinction between "tell me the Answer" and "enlighten me on what I should do to diagnose the job". In fact, the latter problem stems from a real question on the Linux kernel mailing list in August 2001. I am (Eric) The person who raised the question. I have observed this unexplained locking phenomenon on the Tyan S2464 motherboard, and the list members provide important information to address that problem.

By my way of questioning, I gave you something to ponder over, and I made it easy for people to get involved and be attracted to it. I have shown myself to have the same abilities as them and invite them to explore with me. I told them the detours I had made to avoid wasting their time, a respect for the value of others ' time. Later, when I thanked everyone and appreciated the program (meaning that the discussion in the mailing list-the translator) worked very well, a member of the Linux Kernel Mail column (LKML) said the problem was resolved not because I was a "celebrity" in the list, but because I asked questions in the right way. We hackers are, in some ways, knowledgeable but impersonal fellows, and I believe he is right, and if I ask a question like a beggar, whoever I am, I will annoy or be ignored by others. He advised me to write down the matter and give some guidance to the people who wrote the guide.

= Can't find the answer to do

If you still don't get the answer, please don't think we can't help you. Sometimes people who just see your problem don't know the answer. No response does not mean you are neglected, although it is undeniable that the difference is difficult to distinguish.

In general, a simple repetitive posting problem is a bad idea. This would be seen as meaningless noise.

You can get help through other channels, which are usually more suitable for beginners. There are many online and local user groups, composed of avid software enthusiasts (even if they may never have written any software themselves). Usually people form such groups to help each other and help beginners.

Also, you can ask a lot of business companies whether they are big or small (Red Hat and Linuxcare are the two most common examples). Don't be frustrated that you have to pay to get help! After all, if your car's engine cylinder seals explode-and that's probably the case-you'll have to take it to the repair shop and pay for the repairs. Even if the software does not cost you a penny, you cannot insist that technical support is always free.

For popular software, like Linux, each developer will have at least tens of thousands of users. It is impossible for a person to handle calls from tens of thousands of users. You know, even if you're going to pay for help, you're not paying as much as you have to buy the same kind of software (usually the technical support cost of the closed source software is far higher than the open source software and the content is not so rich).