Detailed explanation of questioning skills?

In the online world, what kind of answer can you get when you ask a technical question? It depends on the difficulty of digging out the answer and the way you ask questions. This guide is designed to help you improve your questioning skills to get the answers you want most. ...

I don't want to hide my contempt for those who don't want to think or finish what they should do before asking questions. Such people only murder time-they just want to take it away, never give it to us, and waste our time for no reason, when we could have spent it on more interesting questions or people who are more worthy of answering. We call such people "losers" (for historical reasons, we sometimes spell them "lusers").

Before asking questions

Before asking technical questions by email, newsgroup or chat room, please check whether you:

1. Read through the manual and try to find the answer yourself.

Find the answer in FAQ (a well-maintained FAQ can cover everything:).

3. Search online (personally recommend Google ~ ~ ~).

4. Ask a friend who is good at this.

When asking questions, first explain what you have done before; This will help to establish your image: you are not a beggar trying to get something for nothing, and you don't want to waste other people's time. If the questioner can gain something from the answer, we are more willing to answer his questions.

Think carefully and prepare your questions. A hasty question can only get a hasty answer, or there is no answer at all Before asking for help, the more you show your efforts to solve the problem, the more substantial help you can get.

Be careful not to ask the wrong questions. If your question is based on a wrong assumption, J. Random Hacker will usually answer you with a meaningless literal explanation, thinking that "stupid question …", hoping that you can learn something from the answer to the question (not the answer you want).

Never think you are qualified to get the answer, you are not qualified. After all, you didn't pay any price for this service. You must "win" an answer by yourself, by asking a meaningful, interesting and inspiring question-a question that has a potential contribution to the experience of the community, rather than just passively seeking knowledge from others.

On the other hand, this is a very good start, which shows that you are willing to do something in the process of finding the answer. "Who can give some hints?" "What is missing from my example?" And "where should I check?" It is easier to get the answer than "please post the specific process". Because as long as someone shows you the direction, you seem to have the ability and determination to finish it.

How to ask questions

-Choose the forum carefully

Carefully choose the occasion for asking questions. If you are described like this, you are likely to be ignored or considered a failure:

1. Post your questions on irrelevant forums.

2. Publish very elementary questions and discuss advanced skills in the forum; vice versa

3. Cross-posting in too many different newsgroups

-Proper words, correct grammar and correct spelling.

We find from experience that careless writers are usually careless thinkers (I am sure). It's not worth answering a careless person's question. We'd rather spend our time elsewhere.

Correct spelling, punctuation and capitalization are very important.

More generally, if your question is written like a semi-illiterate, you are likely to be ignored.

If you ask questions in a non-native forum, you can make some mistakes in spelling and grammar-but you must not be careless in your thinking (yes, we can make the difference clear).

-Use meaningful and accurate titles.

In a mailing list or newsgroup, a topic title of about 50 words or less is a golden opportunity to attract the attention of senior experts. Don't use the nagging "help" (not to mention "help!" ! ! ! ! "Waste this opportunity. Don't try to impress us with your pain, and don't replace the description of the problem with spaces, even if it is extremely short.

Stupid question: Help! My laptop doesn't work properly!

Clever title: XFree86 4. 1 mouse cursor deformation, Fooware MV 1005 display chip.

If you ask a question in your reply, remember to modify the title of the content to indicate that there is a problem. It is difficult to pay enough attention to a problem that looks like "Re: test" or "Re: new bug". In addition, quote and delete the content of the previous article, leaving clues for new readers.

-The description is accurate and informative.

1. Describe the symptoms carefully and clearly.

2. Provide the environment where the problem occurs (machine configuration, operating system, application programs, etc.).

3. Before asking questions, explain how you studied and understood this question.

Before asking questions, explain what steps you have taken to solve them.

5. List any recent hardware and software changes that may have an impact.

Try to imagine how a hacker will ask you questions and give him an answer in advance when asking questions.

Simon Tatham wrote an excellent paper entitled How to Report Bugs Effectively. I strongly suggest you read it, too.

-There's nothing to say

You need to provide accurate and effective information. This is not to ask you to simply put a lot of error codes or data into your problem. If you have a huge and complicated test condition, cut it as small as possible.

This has at least three advantages. First, show that you have made efforts to simplify the question, which can increase your chances of getting the answer; Second, simplifying questions increases your chances of getting useful answers; Third, in the process of improving the bug report, maybe you can find the problem yourself or correct it.

-Only symptoms, not guesses

It doesn't help to tell the hacker how you think the problem is caused. If your inference is so effective, do you need to ask others for help? ), so be sure to tell them the symptoms of the problem, don't add your own understanding and inference. Let the hacker diagnose it.

Stupid question: I get SIG 1 1 errors again and again in kernel compilation. I suspect there is a flying wire on the motherboard. How should I check this situation best?

Clever question: I made a K6/233 system, the motherboard is FIC-PA2007 (via Apollo VP2 chipset) and 256MB pirate ship PC 133 SDRAM. In kernel compilation, SIG 1 1 errors often occur, which started 20 minutes ago and never appeared within 20 minutes before startup. It's no use restarting, but you can work for 20 minutes a night by turning it off. All the memories have been changed without any influence. Typical compilation records of relevant parts are as follows.

-List symptoms in chronological order

The most helpful clue to find the problem is often a series of operations before the problem occurs. Therefore, your explanation should include the operation steps and the reaction of the computer until the problem appears.

If your explanation is long (more than four paragraphs), it will be helpful to briefly describe the problem at the beginning and then elaborate in chronological order. So hackers know what to look for in your instructions.

-I know what you want to ask.

The endless question is an almost endless black hole of time. The people who can give you the most useful answers are also the busiest people (they are busy because they have to finish most of the work by themselves). Such people are not very interested in the unrestrained black hole of time, so they can be said to be not very interested in rambling problems.

If you clearly state what the respondent needs to do (provide advice, send a piece of code, check your patch or something else), you are most likely to get a useful answer. This will set an upper limit of time and energy, so that respondents can concentrate on helping you, which is very effective. To understand the world in which experts live, we should imagine professional skills as rich resources and rewards.

Time is a scarce resource. The less time it takes to solve your problem, the more you can get answers from busy experts.

Therefore, optimizing the structure of the problem and minimizing the time required for experts to solve the problem will be of great help-this is usually different from simplifying the problem. So, ask "I want to know X better, can you give me some hints?" It's usually better than asking, "Can you explain X?" Much better. If your code doesn't work, ask what's wrong with it, instead of letting someone else replace it.

It is much wiser for you to review.

-Don't ask questions that should be solved by yourself

Hackers are always good at distinguishing which problems should be solved by themselves; Because most of us have solved this problem ourselves. Similarly, these problems should be solved by you, and you will learn something from them. You can ask for hints, but don't ask for a complete solution.

-Get rid of meaningless questions

Don't end the question with meaningless words, such as "can someone help me?" Or "Is there an answer?" . First of all: if your description of the question is not appropriate, it is even more unnecessary to ask. Secondly: Because asking this question is unnecessary, hackers will get tired of you-they usually use logically correct answers to express their contempt, such as "Yes, someone can help you" or "No, there is no answer".

Humility never hurts, and it often helps a lot.

Be polite and use "please" and "thank you in advance" more often. Let everyone know that you appreciate their time and obligation to help. However, if you have many unsolved problems, politeness will increase your chances of getting useful answers.

(We have noticed that since the publication of this guide, the only serious defect feedback given by experienced hackers is thanks in advance. Some hackers think that the implication of "thank you first" is that you will never thank anyone again. Our suggestion is: thank you. )

-After the problem is solved, add a brief explanation.

After the problem is solved, send a note to all those who have helped you, let them know how the problem was solved, and thank them again. If the problem causes widespread concern in newsgroups or mailing lists, supplementary explanations should be posted there. Supplementary explanations do not need to be long or deep; A simple sentence "Hello, it turns out that there is something wrong with the network cable! Thanks-Bill "is better than nothing. In fact, unless the conclusion is really technical, a short and lovely summary is better than a lengthy academic paper. Explain how the problem is solved, but there is no need to repeat the process of solving the problem. In addition to being polite and giving feedback, this supplement helps others search for complete solutions that have helped you in mailing lists/newsgroups/forums, which may also be useful to them. Finally (at least? ), this supplement

It helps all those who have helped get satisfaction from it. If you are not an old hand or a hacker yourself, trust us. This feeling is very important for tutors or experts who seek help. Problems that have not been solved for a long time can be frustrating; Hackers are eager to see the problem solved. Good people are rewarded, satisfy their desires, and you will taste the sweetness next time you send new questions.

-Still don't get it

If you don't quite understand the answer, don't ask the other person to explain immediately. Understand the problem as you tried to solve it yourself before (user manual, FAQ, Internet, experts around you). If you really need an explanation, remember to show that you have learned something. For example, I answered you, "It seems that zEntry is blocked; You should clear it first. " Then: a bad follow-up question: "what is zEntry?" An ingenious question should be like this: "Oh ~ ~ ~ I see help, but only two parameters -z and -p mention zEntry and there is no clear explanation yet:

Think twice before asking.

Here are some classic stupid questions and what hackers think when they refuse to answer them:

Question: Where can I find the X program?

Problem: My program/configuration /SQL statement is useless.

Problem: There is something wrong with my window. Can you help me?

Problem: I have a problem installing Linux (or X). Can you help me?

Question: How to crack the root account/steal the OP permission/read other people's emails?

Question: Where can I find the X program?

Answer: Right where I found it, idiot-the other side of the search engine. Oh, my God! Is there anyone who can't use Google?

Problem: My program (configuration, SQL statement) is useless.

Answer: Not a problem. I'm not interested in finding out your real problem-if I have to ask you twenty questions to find it-I have more interesting things to do.

See this kind of problem, my reaction is usually nothing more than the following three:

1. Do you have anything to add?

That's too bad. I hope you can fix it.

3. What does this have to do with me?

Problem: There is something wrong with my window. Can you help me?

Answer: Yes, throw away the soft garbage and switch to Linux.

Problem: I have a problem installing Linux (or X). Can you help me?

Answer: No, I can only find the problem on your computer by myself. Please go to your local Linux user group for practical guidance (you can find a list of user groups here).

Question: How to crack the root account/steal the OP permission/read other people's emails?

Answer: if you want to do this, you are a despicable person; Ask a hacker to help you explain that you are a θ θ θ θ!

Good question, bad question

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

Stupid question: where can I find information about foonly fluent?

//This question is nothing more than an answer similar to "STFW".

Smart question: I googled "foonly fluent 2600" and found no useful results. Who knows where I can find the programming information of this kind of equipment?

//This question has been passed by STFW. It seems that he is really in trouble.

Stupid question: the source code I got from the FOO project can't be compiled. Why is it so bad?

//He thinks it's all someone else's fault, this arrogant guy.

Smart question: FOO project code can't be compiled under Nulix 6.2. I have seen the FAQ, but there is nothing about Nulix in it. This is a record of my compilation process. Did I do something wrong?

//He explained the environment, read the FAQ, pointed out the mistakes, and didn't blame others for the problems. This guy deserves attention.

Stupid question: There is something wrong with my motherboard. Who will help me?

//The common hacker's answer to this kind of question is usually: "OK, shall I pat you on the back and change your diaper?" , and then press the delete key.

Intelligent question: I tried X, Y and Z on the S2464 motherboard, but none of them worked. I tried a, b and c again. Please pay attention to the strange phenomenon when I try C. It is obvious that the sideband transmission has shrunk, but the result is unexpected. What are the common causes of sideband leakage in multiprocessor motherboards? Who has a good idea? What tests should I do next to find out the problem?

//This guy, on the other hand, is worth answering. He showed the ability to solve problems instead of waiting for answers to fall from the sky.

The last question, pay attention to the subtle and important difference between "tell me the answer" and "enlighten me and point out what else I should do in diagnosis". In fact, the latter question originated from a real question on the Linux kernel mailing list in August 200 1 year. I (Eric) am the one who asked this question. I observed this unexplained locking phenomenon on Tyan S2464 motherboard, and the list members provided important information to solve this problem.

Through my way of asking questions, I gave you something worth pondering; I make it easy for people to participate and be attracted. I showed my ability as well as theirs and invited them to discuss with me. I told them about the detour I took in order not to let them waste their time. This is a kind of respect for the time value of others. Later, when I thanked everyone and praised the program for running very well, a member of the Linux kernel mailing list (lkml) said that the problem was solved not because I was a "celebrity" in this list, but because I asked questions in the right way. We hackers, in a sense, are knowledgeable but impersonal guys; I believe he is right. If I ask questions like a beggar, no matter who I am, I will definitely annoy some people or be ignored by them. He suggested that I write it down and give some guidance to the person who wrote this guide.

What if I can't find the answer?

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

Generally speaking, it is a bad idea to simply repeat the posting problem. This will be regarded 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, which are made up of enthusiastic software lovers (even though they may never have written any software themselves). Usually people form such groups to help each other and novices.

In addition, you can ask many commercial companies for help, no matter how big or small they are (Red Hat and LinuxCare are the two most common examples). Don't be depressed, you have to pay to get help! After all, if the cylinder sealing ring of your car engine bursts-which is entirely possible-you must take it to the garage and pay for the repair. Even if the software doesn't cost you a penny, you can't 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 one person to handle the help calls of tens of thousands of users. You know, even if you have to pay for help, what you pay is insignificant compared with the similar software you want to buy (usually the technical support cost of closed-source software is much higher than that of open-source software, and the content is not so rich).

My personal principle is not to answer questions within one line, such as' Does anyone understand JSP? I only read questions such as topics.