How to ask questions intelligently

Introduction

In the world the kind of answers you get to your technical questions depends on how you ask the questions and the difficulty of developing the answer. This guide will teach you how to ask so you can get a satisfactory response.
The first thing you must understand is that hackers actually like complex problems and good questions that make them think about them. Otherwise we would not be here. If you give us an interesting question will be grateful, good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have received or who otherwise would not have noticed. Among hackers, "Good question!" be understood as a sincere compliment.
Despite this, hackers have a reputation for meeting simple questions with hostility or arrogance. Sometimes it seems like we're hostile to newbies and the ignorant. But that is not really true.
What we are, in a way unapologetically, is hostile to people who seem unwilling to think or do their homework before asking questions. People like that are time sinks - they take without giving back, they waste time we could have spent on another question more interesting and another person more worthy of a response. People of this type we call them "losers" (and for historical reasons we sometimes spell it "lusers".
We are, by far, volunteers. We steal time busy lives to answer questions, and sometimes overwhelm us. So we filter unabated. In particular, we dismiss the questions of what appear to be losers to take the time to dedicate to answer questions in a more efficient, with the winners.
You do not want to be one of the losers. Nor want to look like any of them. The best way to get a quick and efficient response is to ask a winner - as a person with intelligence, confidence and evidence that need help with a particular problem.


Before you ask

Before asking a technical question by email, a newsgroup or forum of a website, do the following:
  1. Try to find an answer by reading the manual.
  2. Try to find an answer by reading the FAQs
  3. Try to find an answer by searching the web.
  4. Try to find the answer by asking a friend with more experience.
When you ask your question, the fact that you've done all this, this will help establish that you are not a lazy sponge and you're just wasting the time of others. Better yet, what you learn from these things. We like to meet people who have proven to be able to learn from the answers.
Prepare your questions. Think about it. Precipitated questions get hasty answers, or none at all. The more you do to show that you put thought and effort into solving your problem before asking for help, the closer you actually get.
Be careful not to make the wrong question. If you make one that is based on faulty assumptions, Random Hacker will surely respond with something literal and useless while thinking "Stupid question ...", and hoping that the experience of getting a response to what you asked exactly once of what you need to know will teach you a lesson.
Never assume you are entitled to an answer. You do not. You are not, if you want to ask a question of substantial, interesting, and thought-one that implicitly contributes to the experience of the community rather than merely passively demanding knowledge from others.
Moreover, a good start is to make clear that you can and want to participate in the process of developing the solution. "Does anyone have any clues?" "What's missing from my example?" and "Is there a site I should have checked?" are more likely to be answered than "Please post the exact procedure I should follow," because you're making it clear that you are truly willing to complete the process if someone can simply point you in the right direction.

When You Ask

Choose your forum carefully

Be careful when choosing where you ask your question. Surely you will ignore or strike out a loser if:
  • post your question in a forum that is out of place (off topic)
  • post a very basic question in a forum where advanced technical questions are expected, or vice versa
  • post the message at the same time very different groups of notice (cross-posting)
Hackers rule out inappropriate questions to try to protect their communications channels insubstantial. There are multiple reasons for that.

Write clearly respecting the spelling and grammar

We know from experience that careless and sloppy writers also feel so disorganized and amateurish (often enough to bet on it, however). Reply to careless and sloppy thinkers is not rewarding, we'd rather spend our time elsewhere.
Therefore, it is important to express your question clearly. If you can not be bothered to do that, we can not be bothered to pay attention. Spend the extra effort to polish your language. There has to be stiff or formal - in fact, hacker culture values ​​informal speech, slang and funny language used with precision. But it has to be precise, it has to be some indication that you're thinking and paying attention.
Spelled correctly. Do not confuse "its" with "it's" or "loose" with "lose." Do not TYPE IN ALL CAPS, this is read as shouting and is considered rude. " If you write like an idiot half illiterate probably ignore you. Writing like a l33t script kiddie hax0r is the absolute kiss of death and guarantees you will receive nothing but stony silence (or, if you're lucky, a lot of scorn and sarcasm).
If you ask in a forum that does not use your native language, you get a limited amount of slack for your grammar and spelling errors - but no extra at all for sloppy (and they usually know the difference.) Also, unless you know the languages ​​of those you meet, write in English. Busy hackers tend to simply flush questions in languages ​​they do not understand, and English is the working language on the net. When writing in English you minimize the chances that your question without reading discarded.

Send questions in formats that are easy to understand

If you make your question artificially hard to read, is more likely to be ignored in favor of one that is not. Therefore:
  • Send the email in plain text, not HTML.
  • Do not send mail in text displays consist of a single line * multiple times. (This makes it difficult to respond only to parts of the message.)
  • Do not send messages encoded as Quoted-Printable MIME, all those = 20 scattered through the text are ugly and distracting.
  • Never, ever expect hackers to read closed proprietary document formats like Microsoft Word. Most hackers react to it the same way that you react to a pile of steaming pig manure dumped on your doorstep.
  • If you send mail from a Windows machine, turn off the stupid "Smart Quotes" (smart quotes) from Outlook. This is to avoid sprinkling garbage characters through your mail.

Use meaningful, specific title

In the mailing lists or newsgroups, the message header is your golden opportunity to attract qualified experts' attention in around 50 characters or less. Do not waste it on babble like "Please help me" (from "HELP ME PLEASE!" And not speak). Do not try to impress with the depth of your trouble, you better use that precious space for a concise description as possible of the problem.
Stupid:
HELP! The video does not work on my laptop!
Smart:
Misshapen mouse cursor with XFree86 4.1, video chipset foo MV1005

Be precise and informative about your problem

  • Describe the symptoms of your problem or bug carefully and clearly.
  • Describe the environment in which it occurs (machine, OS, application, foo).
  • Describe the research you did to try to narrow down a possible answer to the problem before asking the question.
  • Describe the diagnostic steps you took to try and try to solve the problem yourself before you asked the question.
  • Describe any recent changes in your computer or software configuration that might be relevant.
Do the best you can to anticipate the questions a hacker will ask, and answer them before your request for help.
Simon Tatham has written an excellent essay entitled How to Report Bugs Effectively . I heartily recommend you read it.

Describe the symptoms of the problem, not your assumptions

It is not helpful to tell the hackers what you think is causing you the problem. (If your diagnostic theories were as reliable, would you be asking for help from others?) For this, make sure you're telling them the symptoms of what is wrong and not your interpretations or theories. Let them do the interpretations and pronounce his diagnosis.
Stupid:
Sig11 I get errors while compiling the kernel, and I suspect that may have broken a thread in one of the circuits on the motherboard. What is the best way to check that?
Smart:
My K6/233 assembled by me with a motherboard FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Corsair PC133 SDRAM starts getting frequent errors sig11 about 20 minutes after it started during the course of kernel compiles, but never for the first 20 minutes. Rebooting does not restart the clock, but powering down at night together. Skip all the RAM to the swap partition has not helped. Then I put the relevant part of a typical compile session.

Describe your problem symptoms in chronological order

The most useful clues to find out what went wrong is often found in the events immediately prior. Therefore, you should accurately describe what you did, and what made the machine, until the fateful moment. For command-line processes, having a record of the meeting (eg, using the script utility) and quoting the relevant twenty or so lines would be very useful.
If the program in question has diagnostic options (like-v for verbose), try to think carefully about selecting options that will add useful debugging information to the transcript.
If your message ends up being long (more than four paragraphs), it may be helpful to discuss the issue briefly at first and then do it chronologically. In this way, hackers will know where to look to read your message.

Do not ask people to reply by mail privately

Hackers believe solving problems should be a public and transparent process during which a first attempt to answer can and should be corrected if someone more knowledgeable notices that the answer is incomplete or incorrect. Also, get some of their reward for responding to seen to be competent and knowledgeable enough by their peers.
When you request a private reply, you are disrupting both the process and the reward. Do not do that. Election of the respondent is done in private - and if so, usually because he thinks the question is too obvious or ill-considered to be interesting for others.
There is a limited exception to this rule. If you think you can get a lot of responses very similar to the type of question, then the magic words are "send me the answers by e-mail and I'll summarize for the group." It is considered polite to save the mailing list or newsgroup answers a lot of essentially the same - but obviously you have to keep the promise to summarize.

Avoid pointless questions

Resist the temptation to close your query with semantically null questions like "Can anyone help me?" or "Is there an answer?" First, if you've written your problem description halfway competently so, such questions no more are added, at best, superfluous. Second, because they are superfluous, hackers find them annoying - and responses are likely to return logically impeccable but dismissive like, "Yeah, can help" or "No, no help for you."

Courtesy never hurts, and sometimes even help.

Be polite. Use "Please" and "Thanks in advance." Make it clear you appreciate the time people spend helping you for free.
Be honest, this is not as important as (and can not substitute for) being grammatical, clear, precise and descriptive, avoiding proprietary formats, etc., hackers prefer, in general, the bug reports to the sudden but technically polite vagueness. (If this puzzles you, remember that we value a question by what we teach).
Anyway, if you got your expertise in a raffle, education will increase your chances of receiving a useful reply.

Concludes with a brief note on the solution

Send a note after having solved the problem for all those who helped you, let them know how it came out and thank them again your help. If the problem attracted general interest in a mailing list or newsgroup, then it is appropriate to issue the note there.
The note does not have to be long and developed a simple "Howdy - it turns out that it was a failed cable. Thank you all. - Jose Luis" is better than nothing. In fact, a short and sweet summary is better than a long dissertation unless the solution has real technical depth.
Besides being courteous and informative, this sort of monitoring helps everyone who attended will feel a sense of closeness to the problem satisfactorily. If you're not a hacker, créete that this feeling is very important to the gurus and experts you help. The unresolved problems are just frustrating, the hackers to see them resolved. The good karma that scratching that itch will make you very, very helpful you the next time you need to pose a question.

How to interpret the answers

RTFM and STFW: How To Tell You've Seriously Screwed

There is an ancient and hallowed tradition: if you get a reply "RTFM", the person who sent it thinks you should have read the fucking manual. Almost certainly will be right. Go read.
RTFM has a younger relative. If you get a reply "STFW", who sent it thinks you should have Searched The Fucking Web. Almost certainly be right. Go search.
Often the sender of these responses is contemplating the manual or the website in question as you type. These responses mean that he thinks that (a) the information you need is easy to find, and (b) learn more if you seek out the information than if you give it to "spoon-fed.
This should not offend, according to the standard of hackers, he is showing you some respect (although harsh, did not deny it) by simply not ignore. You should thank him for his kindness.

If you do not understand ...

If you do not understand the answer, do not immediately bounce back a demand for clarification. Use the same tools you used to try and answer your original question (manuals, FAQs, the Web, skilled friends) to understand the answer. If you need to ask for clarification, show what you have learned.
For example, suppose I tell you: "It sounds like you have a zentry stuck, need to release it." Then:
Here's a bad question, "What is a zentry?"
Here's a good question: "Okay, I read the man page and zentrys only mentioned under the-z-p. In none of them mention anything about freeing the zentrys. Is one of these or me I missing something? "

On Not Reacting Like A Loser

There is a good chance that you'll screw up once in the hacker community forums - in ways detailed in this article, or similar. And they will tell you exactly how you screwed up, possibly with colorful asides. In public.
When this happens, the worst thing you can do is whine about the experience, claim to have been verbally assaulted, demand apologies, mourn, hold your breath, threaten lawsuits, complain to the heads of people, leaving the toilet seat, etc. Instead, this is what you do:
Get over it. It's normal. In fact, it's healthy and appropriate.
The community standards are not self-sustaining: it keeps people actively applying them, visibly, in public. Do not whine that all criticism should be sent by courier, that's not how this works. Nor is it useful to insist that you have been personally insulted when someone says that one of your claims was erroneous, or that their views differ. Those are loser attitudes.
There has been hacker forums where, out of a sense of hyper misled, have been banned from entering participants can send any fault-finding messages from others, and been told "Do not say anything if not to help the user. " The exodus of more experienced participants to other places were to descend into babble no sense and have lost their usefulness as technical forums.
Overly "friendly" (that way) or useful: Pick one.
Remember: When that hacker tells you that you were wrong, and (no matter how gruffly) tells you not do it again, his acting out of concern to (1) you and (2) your community. It would be much easier for him to ignore you and filter. If you are not able to be grateful, at least a little dignity, do not complain and do not expect to be treated like a fragile doll just because you're a newcomer with a theatrically hypersensitive soul and delusions of entitlement.

Questions Not To Ask

Here are some stupid questions that have already become classics along with what hackers are thinking when they do not answer.
Q: Where I can find program X?
Q: I have problems with my Windows machine. Can you help?
Q: I have problems installing Linux or X. Can you help?
Q: How I can become root / steal channel operator privileges / read someone's email?
Q: Where I can find program X?
A: In the place where I would have found it, asshole - the other side of a search engine .. God, yet nobody knows how to use Google?
Q: I have problems with my Windows machine. Can you help?
A: Sure. Throw this crap from Microsoft and install Linux.
Q: I have problems installing Linux or X. Can you help?
R: No. Need to physically access your machine to resolve it. Go ask your group of local Linux users for that.
Q: How I can become root / operator privileges steal a channel / read mail from someone else?
A: You're a creep for wanting to do those things and a moron for asking a hacker to help you.

Good and Bad Questions

Finally, I will illustrate with examples how to ask questions intelligently, I have pairs of questions on the same problem, one asked another stupid way and wisely.
Stupid: Where I can find information about Funli Flurbamático?
This question is clamoring for a "STFW" in response.
Smart: I used Google to try to find something on the "Funli Flurbamático 2600" on the Web, but have not obtained satisfactory results. Does anyone know where I can find programming information on this device?
It has already STFWado, and it sounds as if he had a real problem.
Stupid: I could not compile the code from project foo. Why is it broken?
Assume everyone the same thing happens. How arrogant.
Smart: The code from project foo does not compile under Nulix version 6.2. I've read the FAQ, but nothing appears Nulix related problems. I Here's a transcript of my attempt to compile, is it something I did wrong?
Specified by the environment, has read the FAQ, has shown the error and not assuming his problems are someone else's fault. This guy might be worth some attention.
Stupid: I have problems with my motherboard. Can anyone help me?
The response of a hacker any of this would be something like "Okay. Need burping and changing diapers you?" followed by a slight pressure on the Delete key
Smart: I tried X, Y and Z S2464 motherboard with the motherboard. When that did not work, I tried A, B and C. Look at this curious symptom when I C. Obviously florbeador is gromiqueando, but results are what one might expect. What are the common causes of gromiqueo in multiprocessor boards? Does anyone know any more proof that you can take to figure out the problem?
This person, moreover, seems worthy of a response. He has shown his intelligence in an attempt to solve the problem instead of waiting for an answer to drop from the sky.
In the last question, notice the subtle but important difference between demanding "Give me an answer" and "Please help me to get an idea of ​​what additional diagnostics I can take to catch a glimpse of light."
In fact, the way to the last question is closely based on a real incident happened in August 2001 on the mailing list Linux kernel. I (Eric) was the one who asked then. I was seeing mysterious lockups on a Tyan S2464 motherboard. The list members supplied the critical information needed to solve the problem.
In raising the question as I did, it gave people something to chew on, I made it easy and attractive for them to get involved. Demonstrated respect for the abilities of my colleagues and invited them to consult as a peer. Also demonstrated respect for the value of your time by telling them the blind alleys that I had already run.
After all, when I gave them all the graces and remarked how well the process had worked, a member of the mailing list Linux kernel remarked that he thought it was not because I tuvera a "name" in that list, but because I question the right way.

0 comments:

Post a Comment