Intro to Computer Systems

Chapter 1: Introduction

Asking Good Questions

This is an excerpt from "How to Ask Questions the Smart Way", by Eric S. Raymond.

Before You Ask...

Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:

When you ask your question, display the fact that you have done these things first; this will help establish that you're not being a lazy sponge and wasting people's time.

Take your time. Do not expect to be able to solve a complicated problem with a few seconds of Googling. Read and understand the FAQs, sit back, relax and give the problem some thought before approaching experts. They will probably be able to tell from your questions how much reading and thinking you did, and will be more willing to help if you come prepared. Don't instantly fire your whole arsenal of questions just because your first search turned up no answers (or too many).

Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.

When You Ask

Choose your forum carefully

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

People tend to blow off questions that are inappropriately targeted in order to try to protect their communications channels from being drowned 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 to find the project webpage most closely associated with the hardware or software giving you difficulties. Usually it will have links to a FAQ (Frequently Asked Questions) list, and to relevant mailing lists and their archives. These mailing lists are the final places to go for help, if your own efforts (including reading those FAQs you found) do not find you a solution.

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

When selecting a Web forum, newsgroup or mailing list, don't trust the name by itself too far; look for a FAQ or charter to verify your question is on-topic. Read some of the back traffic before posting 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 to your problem on the newsgroup or mailing list archives before you post. It may find you an answer, and if not it will help you formulate a better question.

Use meaningful, specific subject headers

On mailing lists, newsgroups or Web forums, the subject header is your golden opportunity to attract qualified experts' attention in around 50 characters or fewer. Don't waste it on babble like "Please help me" (let alone "PLEASE HELP ME!!!!"; messages with subjects like that get discarded by reflex). Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description instead.

One good convention for subject headers, used by many tech support organisations, is "object - deviation". The "object" part specifies what thing or group of things is having a problem, and the "deviation" part describes the deviation from expected behavior.

Stupid: HELP ME! HDD

Smart: hard disk spindle speeds?

Smarter: choosing a hard disk - not sure about spindle speeds

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

Write in clear, grammatical, correctly-spelled language

Expressing your question clearly and well is important. If you can't be bothered to do that, others on the forum may not be bothered to pay attention. Spend the extra effort to polish your language. It doesn't have to be stiff or formal, but it has to be precise; there has to be some indication that you're thinking and paying attention.

Make your best effort to spell, punctuate, and capitalise correctly. For example, don't confuse "its" with "it's", "loose" with "lose", or "discrete" with "discreet". Don't TYPE IN ALL CAPS; this is read as shouting and considered rude.

Avoid instant-messaging shortcuts when asking for help. Spelling "you" as "u" makes you appear lazy, all just to save two entire keystrokes.

Be precise and informative about your problem

Volume is not precision

You need to be precise and informative. This end is not served by 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.

  1. Being seen to invest effort in simplifying the question makes it more likely you'll get an answer.
  2. Simplifying the question makes it more likely you'll get a useful answer.
  3. In the process of refining your bug report, you may develop a fix or workaround yourself.

Describe the goal, not the step

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

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

Stupid: How do I make a Socket-478 CPU work on a Socket-479 motherboard?

Smart: I'm trying to build a desktop computer with low power consumption. I already have a Socket-478 processor, but the only motherboards I've found that are built with laptop chipsets are built for Socket-479. Can I make a low power system with my CPU and one of those motherboards?

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

Follow up with a brief note on the solution

Send a final reply after the problem has been solved. If the problem attracted general interest in a mailing list or newsgroup, it's appropriate to post the followup there.

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 sweet summary is better than a long dissertation unless the solution has real technical depth. Say what action solved the problem, but you need not replay the whole troubleshooting sequence.

For problems with some depth, it is appropriate to post a summary of the troubleshooting history. Describe your final problem statement. Describe what worked as a solution, and indicate avoidable blind alleys after that. The blind alleys should come after the correct solution and other summary material, rather than turning the follow-up into a detective story. Name the names of people who helped you; you'll make friends that way.

Besides being courteous and informative, this sort of followup will help others searching the archive of the mailing-list/newsgroup/forum to know exactly which solution helped you and thus may also help them.