How To Ask Questions The Smart Way (2024)

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

1. Try to find an answer by searching the archives of theforum or mailing list you plan to post to.

2. Try to find an answer by searching the Web.

3. Try to find an answer by reading the manual.

4. Try to find an answer by reading a FAQ.

5. Try to find an answer by inspection or experimentation.

6. Try to find an answer by asking a skilled friend.

7. If you're a programmer, try to find an answer by readingthe source code.

Be sensitive in choosing where you ask your question. You arelikely to be ignored, or written off as a loser, if you:

Hackers blow off questions that are inappropriately targeted inorder to try to protect their communications channels from beingdrowned in irrelevance. You don't want this to happen to you.

The first step, therefore, is to find the right forum. Again,Google and other Web-searching methods are your friend. Use them tofind the project webpage most closely associated with the hardware orsoftware giving you difficulties. Usually it will have links to a FAQ(Frequently Asked Questions) list, and to project mailing lists andtheir archives. These mailing lists are the final places to go forhelp, if your own efforts (including readingthose FAQs you found) do not find you a solution. The project pagemay also describe a bug-reporting procedure, or have a link to one; ifso, follow it.

Shooting off an e-mail to a person or forum which you are notfamiliar with is risky at best. For example, do not assume that theauthor of an informative webpage wants to be your free consultant.Do not make optimistic guesses about whether your question will bewelcome — if you're unsure, send it elsewhere, or refrain fromsending it at all.

When selecting a Web forum, newsgroup or mailing list, don'ttrust the name by itself too far; look for a FAQ or charter to verifyyour question is on-topic. Read some of the back traffic beforeposting so you'll get a feel for how things are done there. In fact,it's a very good idea to do a keyword search for words relating toyour problem on the newsgroup or mailing list archives before youpost. It may find you an answer, and if not it will help youformulate a better question.

Don't shotgun-blast all the available help channels at once, that'slike yelling and irritates people. Step through them softly.

Know what your topic is! One of the classic mistakes is askingquestions about the Unix or Windows programming interface in a forumdevoted to a language or library or tool portable across both.If you don't understand why this is a blunder, you'd be best off notasking any questions at all until you get it.

In general, questions to a well-selected public forum are morelikely to get useful answers than equivalent questions to a privateone. There are multiple reasons for this. One is simply the size ofthe pool of potential respondents. Another is the size of theaudience; hackers would rather answer questions that educate manypeople than questions serving only a few.

Understandably, skilled hackers and authors of popular software arealready receiving more than their fair share of mis-targeted messages.By adding to the flood, you could in extreme cases even be the strawthat breaks the camel's back — quite a few times, contributors topopular projects have withdrawn their support because collateraldamage in the form of useless e-mail traffic to their personal accountsbecame unbearable.

Search, then ask on Stack Exchange

In recent years, the Stack Exchange community of sites has emerged asa major resource for answering technical and other questions and iseven the preferred forum for many open-source projects.

Start with a Google search before looking at Stack Exchange; Googleindexes it in real time. There's a very good chance someone hasalready asked a similar question, and the Stack Exchange sites areoften near the top of the search results. If you didn't find anythingthrough Google, search again on the specific site most relevant toyour question (see below). Searching with tags can help narrow downthe results.

If you still didn't find anything, post your question on theone site where it's most on-topic. Use theformatting tools, especially for code, and add tags that are relatedto the substance of your question (particularly the name of theprogramming language, operating system, or library you're havingtrouble with). If a commenter asks you for more information, edit yourmain post to include it. If any answer is helpful, click the up arrowto upvote it; if an answer gives a solution to your problem, click thecheck under the voting arrows to accept it as correct.

Stack Exchange has grown to over 100 sites, but hereare the most likely candidates:

Several projects have their own specific sites, including Android,Ubuntu, TeX/LaTeX, and SharePoint. Check the Stack Exchange site foran up-to-date list.

Your local user group, or your Linux distribution, may advertisea Web forum or IRC channel where newbies can get help. (Innon-English-speaking countries newbie forums are still more likely tobe mailing lists.) These are good first places to ask, especially ifyou think you may have tripped over a relatively simple or commonproblem. An advertised IRC channel is an open invitation to askquestions there and often get answers in real time.

In fact, if you got the program that is giving you problems froma Linux distribution (as is common today), it may be better to ask in thedistro's forum/list before trying the program's project forum/list. Theproject's hackers may just say, “use ourbuild”.

Before posting to any Web forum, check if it has a Searchfeature. If it does, try a couple of keyword searches forsomething like your problem; it just might help. If you did a generalWeb search before (as you should have), search the forum anyway; yourWeb-wide search engine might not have all of this forum indexedrecently.

There is an increasing tendency for projects to do user supportover a Web forum or IRC channel, with e-mail reserved more fordevelopment traffic. So look for those channels first when seekingproject-specific help.

In IRC, it's probably best not to dump a long problemdescription on the channel first thing; some people interpret thisas channel-flooding. Best to utter a one-line problem descriptionin a way pitched to start a conversation on the channel.

When a project has a development mailing list, write to themailing list, not to individual developers, even if you believeyou know who can best answer your question. Check the documentationof the project and its homepage for the address of a project mailinglist, and use it. There are several good reasons for thispolicy:

If a project has both a “user” and a“developer” (or “hacker”) mailing list orWeb forum, and you are not hacking on the code, ask in the“user” list/forum. Do not assume that you willbe welcome on the developer list, where they're likely to experienceyour question as noise disrupting their developer traffic.

However, if you are sure your question isnon-trivial, and you get no answer in the “user”list/forum for several days, try the “developer” one.You would be well advised to lurk there for a few daysor at leastreview the last few days of archived messages, to learn the localfolkways before posting (actually this is good advice on any private or semi-privatelist).

If you cannot find a project's mailing list address, but onlysee the address of the maintainer of the project, go ahead and writeto the maintainer. But even in that case, don't assume that themailing list doesn't exist. Mention in your e-mail that you tried andcould not find the appropriate mailing list. Also mention that youdon't object to having your message forwarded to other people. (Manypeople believe that private e-mail should remain private, even ifthere is nothing secret in it. By allowing your message to beforwarded you give your correspondent a choice about how to handleyour e-mail.)

On mailing lists, newsgroups or Web forums, the subject headeris your golden opportunity to attract qualified experts' attention inaround 50 characters or fewer. Don't waste it on babble like“Please help me” (let alone “PLEASE HELPME!!!!”; messages with subjects like that get discarded byreflex). Don't try to impress us with the depth of your anguish; usethe space for a super-concise problem description instead.

One good convention for subject headers, used by many tech supportorganizations, is “object - deviation”. The“object” part specifies what thing or group of things ishaving a problem, and the “deviation” part describes thedeviation from expected behavior.

The process of writing an “object-deviation”description will help you organize your thinking about the problem inmore detail. What is affected? Just the mouse cursor or othergraphics too? Is this specific to the X.org version of X? To version6.8.1? Is this specific to Fooware video chipsets? To model MV1005? Ahacker who sees the result can immediately understand what it is thatyou are having a problem with and the problem youare having, at a glance.

More generally, imagine looking at the index of an archive ofquestions, with just the subject lines showing. Make your subjectline reflect your question well enough that the next person searching thearchive with a question similar to yours will be able to follow thethread to an answer rather than posting the question again.

If you ask a question in a reply, be sure to change the subjectline to indicate that you're asking a question. A Subject line thatlooks like “Re: test” or “Re: new bug” isless likely to attract useful amounts of attention. Also, pare quotationof previous messages to the minimum consistent with cluing in newreaders.

Do not simply hit reply to a list message in order to start anentirely new thread. This will limit your audience. Some mail readers,like mutt, allow the user to sort by thread and then hide messages ina thread by folding the thread. Folks who do that will never see yourmessage.

Changing the subject is not sufficient. Mutt, and probably other mailreaders, looks at other information in the e-mail's headers to assignit to a thread, not the subject line. Instead start an entirely newe-mail.

On Web forums the rules of good practice are slightly different,because messages are usually much more tightly bound to specificdiscussion threads and often invisible outside those threads.Changing the subject when asking a question in reply is not essential.Not all forums even allow separate subject lines on replies, andnearly nobody reads them when they do. However, asking a question in areply is a dubious practice in itself, because it will only be seen bythose who are watching this thread. So, unless you are sure youwant to ask only the people currently active in thethread, start a new one.

Finishing your query with “Please send your replyto... ” makes it quite unlikely you will get an answer. If youcan't be bothered to take even the few seconds required to set up acorrect Reply-To header in your mail agent, we can't be bothered totake even a few seconds to think about your problem. If your mailprogram doesn't permit this, get a better mailprogram. If your operating system doesn't support any e-mailprograms that permit this, get a better operating system.

In Web forums, asking for a reply by e-mail is outright rude,unless you believe the information may be sensitive (and somebodywill, for some unknown reason, let you but not the whole forum knowit). If you want an e-mail copy when somebody replies in the thread,request that the Web forum send it; this feature is supportedalmost everywhere under options like “watch this thread”,“send e-mail on answers”, etc.

We've found by experience that people who are careless andsloppy writers are usually also careless and sloppy at thinking andcoding (often enough to bet on, anyway). Answering questions forcareless and sloppy thinkers is not rewarding; we'd rather spend ourtime elsewhere.

So expressing your question clearly and well is important. Ifyou can't be bothered to do that, we can't be bothered to payattention. Spend the extra effort to polish your language. Itdoesn't have to be stiff or formal — in fact, hacker culturevalues informal, slangy and humorous language used with precision.But it has to be precise; there has to be someindication that you're thinking and paying attention.

Spell, punctuate, and capitalize correctly. Don't confuse“its” with “it's”, “loose” with“lose”, or “discrete” with“discreet”. Don't TYPE IN ALL CAPS; this is read asshouting and considered rude. (All-smalls is only slightly lessannoying, as it's difficult to read. Alan Cox can get away with it,but you can't.)

More generally, if you write like a semi-literate boob you willvery likely be ignored. So don't use instant-messaging shortcuts.Spelling "you" as "u" makes you look like a semi-literate boob to savetwo entire keystrokes. Worse: writing like a l33t script kiddie hax0r isthe absolute kiss of death and guarantees you will receive nothing butstony silence (or, at best, a heaping helping of scorn and sarcasm) inreturn.

If you are asking questions in a forum that does not use yournative language, you will get a limited amount of slack for spellingand grammar errors — but no extra slack at all for laziness (andyes, we can usually spot that difference). Also, unless you know whatyour respondent's languages are, write in English. Busy hackers tendto simply flush questions in languages they don't understand, andEnglish is the working language of the Internet. By writing inEnglish you minimize your chances that your question will be discardedunread.

If you are writing in English but it is a second language foryou, it is good form to alert potential respondents to potentiallanguage difficulties and options for getting around them.Examples:

If you make your question artificially hard to read, it is morelikely to be passed over in favor of one that isn't. So:

If you're using a graphical-user-interface mail client such asNetscape Messenger, MS Outlook, or their ilk, beware that it mayviolate these rules when used with its default settings. Most suchclients have a menu-based “View Source” command. Usethis on something in your sent-mail folder, verifying sending of plaintext without unnecessary attached crud.

Do the best you can to anticipate the questions a hacker willask, and answer them in advance in your request for help.

Giving hackers the ability to reproduce the problem in acontrolled environment is especially important if you are reportingsomething you think is a bug in code. When you do this, your odds ofgetting a useful answer and the speed with which you are likely to getthat answer both improve tremendously.

Simon Tatham has written an excellent essay entitled How toReport Bugs Effectively. I strongly recommend thatyou read it.

You need to be precise and informative. This end is not servedby simply dumping huge volumes of code or data into a help request.If you have a large, complicated test case that is breaking a program,try to trim it and make it as small as possible.

This is useful for at least three reasons. One: being seen toinvest effort in simplifying the question makes it more likely you'll get an answer, Two: simplifying the question makes it morelikely you'll get a useful answer. Three:In the process of refining your bug report, you may develop a fix or workaround yourself.

When you are having problems with a piece of software, don'tclaim you have found a bug unless you are very,very sure of your ground. Hint: unless you canprovide a source-code patch that fixes the problem, or a regressiontest against a previous version that demonstrates incorrect behavior,you are probably not sure enough. This applies to webpages anddocumentation, too; if you have found a documentation“bug”, you should supply replacement text and which pagesit should go on.

Remember, there are many other users that are notexperiencing your problem. Otherwise you would have learned about itwhile reading the documentation and searching the Web (you did do thatbefore complaining, didn't you?). Thismeans that very probably it is you who are doing something wrong, notthe software.

The people who wrote the software work very hard to make it workas well as possible. If you claim you have found a bug, you'll beimpugning their competence, which may offend some of them even if youare correct. It's especially undiplomatic to yell “bug”in the Subject line.

When asking your question, it is best to write as though youassume you are doing something wrong, even if youare privately pretty sure you have found an actual bug. If therereally is a bug, you will hear about it in the answer. Play it so themaintainers will want to apologize to you if the bug is real, ratherthan so that you will owe them an apology if you have messed up.

Some people who get that they shouldn't behave rudely orarrogantly, demanding an answer, retreat to the opposite extreme ofgrovelling. “I know I'm just a pathetic newbie loser,but...”. This is distracting and unhelpful. It's especiallyannoying when it's coupled with vagueness about the actualproblem.

Don't waste your time, or ours, on crude primate politics.Instead, present the background facts and your question as clearly asyou can. That is a better way to position yourself than bygrovelling.

Sometimes Web forums have separate places for newbie questions. If youfeel you do have a newbie question, just go there. But don't grovel thereeither.

It's not useful to tell hackers what you think is causing yourproblem. (If your diagnostic theories were such hot stuff, would yoube consulting others for help?) So, make sure you're telling them theraw symptoms of what goes wrong, rather than your interpretations andtheories. Let them do the interpretation and diagnosis. If you feelit's important to state your guess, clearly label it as such anddescribe why that answer isn't working for you.

Since the preceding point seems to be a tough one for many people tograsp, here's a phrase to remind you: "All diagnosticians are fromMissouri." That US state's official motto is "Show me" (earned in1899, when Congressman Willard D. Vandiver said "I come from a countrythat raises corn and cotton and co*ckleburs and Democrats, and frothyeloquence neither convinces nor satisfies me. I'm from Missouri.You've got to show me.") In diagnosticians' case, it's not a matter ofskepticism, but rather a literal, functional need to see whatever isas close as possible to the same raw evidence that you see, ratherthan your surmises and summaries. Show us.

The clues most useful in figuring out something that went wrongoften lie in the events immediately prior. So, your account shoulddescribe precisely what you did, and what the machine and softwaredid, leading up to the blowup. In the case of command-line processes,having a session log (e.g., using the script utility) and quoting therelevant twenty or so lines is very useful.

If the program that blew up on you has diagnostic options (suchas -v for verbose), try to select options that will add usefuldebugging information to the transcript. Remember that more is notnecessarily better; try to choose a debug level that will informrather than drowning the reader in junk.

If your account ends up being long (more than about four paragraphs),it might be useful to succinctly state the problem up top, thenfollow with the chronological tale. That way, hackers will knowwhat to watch for in reading your account.

If you are trying to find out how to do something (as opposed toreporting a bug), begin by describing the goal. Only then describethe particular step towards it that you are blocked on.

Often, people who need technical help have a high-level goal inmind and get stuck on what they think is one particular path towardsthe goal. They come for help with the step, but don't realize thatthe path is wrong. It can take substantial effort to get pastthis.

The second version of the question is smart. It allows ananswer that suggests a tool better suited to the task.

Hackers believe solving problems should be a public, transparentprocess during which a first try at an answer can and should becorrected if someone more knowledgeable notices that it is incomplete orincorrect. Also, helpers get some of their reward for beingrespondents from being seen to be competent and knowledgeable bytheir peers.

When you ask for a private reply, you are disrupting both theprocess and the reward. Don't do this. It's therespondent's choice whether to reply privately— and if he or she does, it's usually because he or she thinksthe question is too ill-formed or obvious to be interesting toothers.

There is one limited exception to this rule. If you thinkthe question is such that you are likely to get many answers thatare all closely similar, then the magic words are “e-mail me and I'llsummarize the answers for the group”. It is courteous to try and save the mailing list or newsgroup a flood of substantially identicalpostings — but you have to keep the promise to summarize.

Open-ended questions tend to be perceived as open-ended timesinks. Those people most likely to be able to give you a useful answerare also the busiest people (if only because they take on the mostwork themselves). People like that are allergic to open-ended timesinks, thus they tend to be allergic to open-ended questions.

You are more likely to get a useful response if you areexplicit about what you want respondents to do (provide pointers,send code, check your patch, whatever). This will focus their effort and implicitly put an upper bound on the time and energy a respondent must allocate to helping you. This is good.

To understand the world the experts live in, think of expertiseas an abundant resource and time to respond as a scarce one. The lessof a time commitment you implicitly ask for, the more likely you areto get an answer from someone really good and really busy.

So it is useful to frame your question to minimize the timecommitment required for an expert to field it — but this isoften not the same thing as simplifying the question. Thus, forexample, “Would you give me a pointer to a good explanation ofX?” is usually a smarter question than “Would you explainX, please?”. If you have some malfunctioning code, it isusually smarter to ask for someone to explain what's wrong with itthan it is to ask someone to fix it.

Don't ask others to debug your broken code without giving a hintwhat sort of problem they should be searching for. Posting a fewhundred lines of code, saying "it doesn't work", will get you ignored.Posting a dozen lines of code, saying "after line 7 I was expecting tosee <x>, but <y> occurred instead" is much more likely toget you a response.

The most effective way to be precise about a code problem is toprovide a minimal bug-demonstrating test case. What's a minimal testcase? It's an illustration of the problem; just enough code toexhibit the undesirable behavior and no more. How do you make aminimal test case? If you know what line or section of code isproducing the problematic behavior, make a copy of it and add justenough supporting code to produce a complete example (i.e. enough thatthe source is acceptable to the compiler/interpreter/whateverapplication processes it). If you can't narrow it down to aparticular section, make a copy of the source and start removingchunks that don't affect the problematic behavior. The smaller yourminimal test case is, the better (see the section called “Volume is not precision”).

Generating a really small minimal test case will not always bepossible, but trying to is good discipline. It may help you learnwhat you need to solve the problem on your own — and even whenit doesn't, hackers like to see that you have tried. It willmake them more cooperative.

If you simply want a code review, say as much up front, and besure to mention what areas you think might particularly need reviewand why.

Hackers are good at spotting homework questions; most of us havedone them ourselves. Those questions are for you to work out, so that you will learn from the experience. It is OK toask for hints, but not for entire solutions.

If you suspect you have been passed a homework question, butcan't solve it anyway, try asking in a user group forum or (as a lastresort) in a “user” list/forum of a project. While thehackers will spot it, some of the advanced usersmay at least give you a hint.

Resist the temptation to close your request for help withsemantically-null questions like “Can anyone help me?” or“Is there an answer?” First: if you've written yourproblem description halfway competently, such tacked-on questions areat best superfluous. Second: because they are superfluous, hackersfind them annoying — and are likely to return logicallyimpeccable but dismissive answers like “Yes, you can behelped” and “No, there is no help for you.”

In general, asking yes-or-no questions is a good thing to avoidunless you want a yes-or-noanswer.

That's your problem, not ours. Claiming urgency is very likelyto be counter-productive: most hackers will simply delete suchmessages as rude and selfish attempts to elicit immediate and specialattention. Furthermore, the word 'Urgent' (and other similar attemptsto grab attention in the subject line) often triggers spam filters - your intended recipients might never see it at all!

There is one semi-exception. It can be worth mentioning ifyou're using the program in some high-profile place, one that thehackers will get excited about; in such a case, if you're under timepressure, and you say so politely, people may get interested enough toanswer faster.

This is a very risky thing to do, however, because the hackers'metric for what is exciting probably differs from yours. Posting fromthe International Space Station would qualify, for example, butposting on behalf of a feel-good charitable or political cause wouldalmost certainly not. In fact, posting “Urgent: Help me save the fuzzy baby seals!” will reliably get you shunned or flamedeven by hackers who think fuzzy baby seals are important.

If you find this mysterious, re-read the rest of this how-torepeatedly until you understand it before posting anything atall.

Be courteous. Use “Please” and “Thanks foryour attention” or “Thanks for yourconsideration”. Make it clear you appreciate the timepeople spend helping you for free.

To be honest, this isn't as important as (and cannot substitutefor) being grammatical, clear, precise and descriptive, avoidingproprietary formats etc.; hackers in general would rather get somewhatbrusque but technically sharp bug reports than polite vagueness. (Ifthis puzzles you, remember that we value a question by what it teachesus.)

However, if you've got your technical ducks in a row,politeness does increase your chances of getting a usefulanswer.

(We must note that the only serious objection we've receivedfrom veteran hackers to this HOWTO is with respect to our previousrecommendation to use “Thanks in advance”. Some hackersfeel this connotes an intention not to thank anybody afterwards. Ourrecommendation is to either say “Thanks in advance” firstand thank respondents afterwards, or expresscourtesy in a different way, such as by saying “Thanks for yourattention” or “Thanks for yourconsideration”.)

Send a note after the problem has been solved to all who helpedyou; let them know how it came out and thank them again for theirhelp. If the problem attracted general interest in a mailing list ornewsgroup, it's appropriate to post the followup there.

Optimally, the reply should be to the thread started by theoriginal question posting, and should have ‘FIXED’,‘RESOLVED’ or an equally obvious tag in the subject line.On mailing lists with fast turnaround, a potential respondent who seesa thread about “Problem X” ending with “Problem X -FIXED” knows not to waste his/her time even reading the thread(unless (s)he personally finds Problem X interesting) and cantherefore use that time solving a different problem.

Your followup doesn't have to be long and involved; a simple“Howdy — it was a failed network cable! Thanks, everyone. -Bill” would be better than nothing. In fact, a short and sweetsummary is better than a long dissertation unless the solution hasreal technical depth. Say what action solved the problem, but youneed not replay the whole troubleshooting sequence.

For problems with some depth, it is appropriate to post asummary of the troubleshooting history. Describe your final problemstatement. Describe what worked as a solution, and indicate avoidableblind alleys after that. The blind alleys shouldcome after the correct solution and other summary material, ratherthan turning the follow-up into a detective story. Name the names ofpeople who helped you; you'll make friends that way.

Besides being courteous and informative, this sort of followupwill help others searching the archive of the mailing-list/newsgroup/forumto know exactly which solution helped you and thus may also helpthem.

Last, and not least, this sort of followup helps everybody whoassisted feel a satisfying sense of closure about the problem. If youare not a techie or hacker yourself, trust us that this feeling isvery important to the gurus and experts you tapped for help. Problemnarratives that trail off into unresolved nothingness are frustratingthings; hackers itch to see them resolved. The goodwill thatscratching that itch earns you will be very, very helpful to you nexttime you need to pose a question.

Consider how you might be able to prevent others from having thesame problem in the future. Ask yourself if a documentation or FAQpatch would help, and if the answer is yes send that patch to themaintainer.

Among hackers, this sort of good followup behavior is actuallymore important than conventional politeness. It's how you get areputation for playing well with others, which can be a very valuableasset.

There is an ancient and hallowed tradition: if you get a replythat reads “RTFM”, the person who sent it thinks youshould have Read The f*cking Manual. He or she is almost certainly right.Go read it.

RTFM has a younger relative. If you get a reply that reads“STFW”, the person who sent it thinks you should haveSearched The f*cking Web. He or she is almost certainly right. Go searchit. (The milder version of this is when you are told “Google isyour friend!”)

In Web forums, you may also be told to search the forumarchives. In fact, someone may even be so kind as to provide a pointerto the previous thread where this problem was solved. But do not relyon this consideration; do your archive-searching before asking.

Often, the person telling you to do a search has the manual orthe web page with the information you need open, and is looking at itas he or she types. These replies mean that the responder thinks (a)the information you need is easy to find, and (b) you will learn moreif you seek out the information than if you have it spoon-fed toyou.

You shouldn't be offended by this; by hacker standards, yourrespondent is showing you a rough kind of respect simply by notignoring you. You should instead be thankful for this grandmotherlykindness.

If you don't understand the answer, do not immediately bounceback a demand for clarification. Use the same tools that you used totry and answer your original question (manuals, FAQs, the Web, skilledfriends) to understand the answer. Then, if you still need to ask forclarification, exhibit what you have learned.

For example, suppose I tell you: “It sounds like you'vegot a stuck zentry; you'll need to clear it.” Then: here's abad followup question: “What's azentry?” Here's a good followupquestion: “OK, I read the man page and zentries are onlymentioned under the -z and -p switches. Neither of them says anythingabout clearing zentries. Is it one of these or am I missing somethinghere?”

Much of what looks like rudeness in hacker circles is notintended to give offense. Rather, it's the product of the direct,cut-through-the-bullsh*t communications style that is natural topeople who are more concerned about solving problems than makingothers feel warm and fuzzy.

When you perceive rudeness, try to react calmly. If someoneis really acting out, it is very likely a senior person on thelist or newsgroup or forum will call him or her on it. If that doesn't happen and you lose your temper, itis likely that the person you lose it at was behaving within thehacker community's norms and you will beconsidered at fault. This will hurt your chances of getting theinformation or help you want.

On the other hand, you will occasionally run across rudeness andposturing that is quite gratuitous. The flip-side of the above isthat it is acceptable form to slam real offenders quite hard,dissecting their misbehavior with a sharp verbal scalpel. Be very,very sure of your ground before you try this, however. The linebetween correcting an incivility and starting a pointless flamewar is thinenough that hackers themselves not infrequently blunder across it; ifyou are a newbie or an outsider, your chances of avoiding such ablunder are low. If you're after information rather than entertainment,it's better to keep your fingers off the keyboard than to risk this.

(Some people assert that many hackers have a mild form of autismor Asperger's Syndrome, and are actually missing some of the braincircuitry that lubricates “normal” human socialinteraction. This may or may not be true. If you are not a hackeryourself, it may help you cope with our eccentricities if you think ofus as being brain-damaged. Go right ahead. We won't care; welike being whatever it is we are, and generallyhave a healthy skepticism about clinical labels.)

Jeff Bigler's observations abouttact filtersare also relevant and worth reading.

In the next section, we'll talk about a different issue; the kind of “rudeness” you'll see when you misbehave.

Q: Where can I find program or resource X?

Q: How can I use X to do Y?

Q: How can I configure my shell prompt?

Q: Can I convert an AcmeCorp document into a TeX file usingthe Bass-o-matic file converter?

Q: My {program, configuration, SQL statement} doesn't work

Q: I'm having problems with my Windows machine. Can you help?

Q: My program doesn't work. I think system facility X is broken.

Q: I'm having problems installing Linux or X. Can you help?

Q: How can I crack root/steal channel-ops privileges/read someone'se-mail?

Stupid:Where can I find out stuff about the Foonly Flurbamatic?

This question just begs for "STFW" as areply.

Smart:I used Google to try to find “Foonly Flurbamatic 2600” onthe Web, but I got no useful hits. Can I get a pointer toprogramming information on this device?

This one has already STFWed, and sounds like there might be a realproblem.

Stupid:I can't get the code from project foo to compile. Why is it broken?

The querent assumes that somebody else screwed up. Arrogant git...

Smart:The code from project foo doesn't compile under Nulix version 6.2. I've read the FAQ, but it doesn't have anything in it aboutNulix-related problems. Here's a transcript of my compilationattempt; is it something I did?

The querent has specified the environment, read the FAQ, is showingthe error, and is not assuming his problems are someone else'sfault. This one might be worth some attention.

Stupid:I'm having problems with my motherboard. Can anybody help?

J. Random Hacker's response to this is likely to be “Right. Do youneed burping and diapering, too?” followed by a punch of the deletekey.

Smart:I tried X, Y, and Z on the S2464 motherboard. When that didn't work,I tried A, B, and C. Note the curious symptom when I tried C.Obviously the florbish is grommicking, but the results aren't what onemight expect. What are the usual causes of grommicking on Athlon MPmotherboards? Anybody got ideas for more tests I can run to pin downthe problem?

This person, on the other hand, seems worthy of ananswer. He/she has exhibited problem-solving intelligence rather thanpassively waiting for an answer to drop from on high.