Monday, April 19, 2010

How to ask questions in a technical forum

How to ask questions in a technical forum

Technical forums (such as web-based forums or Usenet newsgroups) are among the very best places to get specific technical questions answered because many of the people answering questions in technical forums are very knowledgeable about the specific topic and like sharing that knowledge.

Of course, without forum participants, there is no forum, so new forum participants are welcome. That said, there are a group of reasons why some forum participants do not get their questions answered (or not answered quickly or meaningfully). My purpose here is to educate technical forum participants on the best way to ask questions so that their questions will have a higher probability of being answered in a meaningful and timely way.

Acknowledgements: Raymond Chen (The Old New Thing), Eric Raymond (How to Ask Questions the Smart Way), and Eric Lippert (Fabulous Adventures in Coding).

For no particular reason, I'm calling the forum question-answerers Ted. (Ted might be a forum moderator or someone who is knowledgeable about a particular topic.)

1. Search before you ask

Don't be helpless. For example, if you need to know how to list services in PowerShell, use a search engine. If you post a question that is easily answered by a quick search, Ted may give a response that is designed to help you help yourself. (Ted may also simply ignore the question because he might feel like you're asking him to do your work for you. See #5.)

2. Ask in the appropriate forum

You should only ask questions that are relevant to the forum. For example, don't ask a WSUS question in a scripting forum. If you're not sure where you should post your question, try to find out (see #1). If you don't do this, your question might be ignored, or you'll probably be told you're asking in the wrong place. This wastes both your time (because you're not getting your question answered) and Ted's time (either because he has to read your question before deciding to ignore it or because he has to type a "you're not asking in the right place" response).

If you can't find the relevant forum, give some indication that you're not helpless. For example: "I'm looking for information about how to use the quimflob object in a VBScript script. I searched for 'quimflob object vbscript', but I couldn't find anything relevant. Does anyone know whether I can use this object in VBScript?" In other words, try to illustrate that you're not just asking Ted to do your work for you.

3. Use a meaningful subject line

Your subject line should be as specific as possible and summarize the question. Subject lines such as "please help" or "newbie question" are not helpful because you're forcing Ted to open the question in order to read it. Ted will probably prioritize questions with meaningful subject lines ahead of questions with meaningless subject lines simply because they're more interesting.

Subject lines such as "HELP REQUIRED QUICKLY" or "NEED URGENT HELP ASAP" contribute nothing of substance to your question and probably won't get you a faster answer. Ted may even find this rude, because you're implying that your question should have priority over everyone else's.

4. Don't make Ted guess

Remember that Ted can't read your mind. If you don't provide enough information, Ted ends up 1) guessing (if you're lucky, he guesses right), 2) ignoring your question, or 3) asking for more information. Where applicable and when possible, make sure to include the exact error message.

Here's an example of a "guessing game" question:

Subject: IE
Question: IE is hanging from my script. Is there any solution for it.

Here's an example of how you should ask instead:

Subject: Internet Explorer hangs when I quim or flob in my script
Question: When I use the following code, Internet Explorer seems to become unresponsive. I tried both quimming and flobbing, but both of these approaches caused the error message '800a4005: The object has farbled'. I searched for that error code and error message but I didn't find anything that relates to this specific situation. What am I doing wrong? [Code sample follows]

Corollary 1 to the "guessing game" question: Don't forget to ask your question.

Corollary 2 to the "guessing game" question: Be clear about the antecedents to your pronouns. For example: "When I use the get-flob cmdlet in PowerShell v1, it throws an error when my script runs on a different machine. Is this normal?" Possible response: "Is what normal?" (First of all, what is the exact error message? Does the error always happen, or does the error only happen on one machine but not another? What are the differences between the machines? etc...)

5.  If something doesn't work, you have to say how it didn't work

There is not much to say here other than what Raymond Chen already said. Just saying "it didn't work" conveys almost no useful information.

6. Ted is not your personal consultant

Ted is often a volunteer and answers questions in his free time; he is not your personal consultant. Ted likes to help and appreciates thoughtful questions, but remember that he's not obligated to do your work for you.

For example, consider the following request: "I need a script that quims the flobs." Possible response: "OK; go ahead and write it, then." Why should you avoid this kind of request? First, the request is not a question (see #4). Second, you're explicitly asking Ted to do your work for you. Third, we all understand the importance of quick solutions, but if Ted is feeling generous and gives you a script that quims the flobs, you're not really learning anything. Numerous times I've seen Ted post a generous response such as this, only to have the original poster continue to request ongoing technical support for the script and/or ongoing requests to add features to it. After experiencing this a few times, Ted will probably start to feel less generous.

7. Describe the goal, not the attempted solution

Sometimes, when all you've got is a hammer, everything starts to look like a nail. For example: "We have a script to add a domain group to the local Administrators groups on our computers but it doesn't work on Windows Vista and later. How can we get this script to work?" The real question is not how to make the script work, but how to manage the members of the local Administrators groups on domain computers. The answer is to use the Restricted Groups feature in Group Policy. Here's another example of this principle.

8. Have appropriate expectations

Remember that there's no guarantee that 1) you will get an answer to your question, 2) you will like the answer you get, and 3) what you want to do is even possible. A technical forum does not come with a service-level agreement. (Preemptive response: Yes, I know Raymond is talking about e-mail, but the principle applies.)

9. If your question is answered, don't forgot to follow up

If your question has been answered (or you have at least been pointed in the right direction), don't forget to post a follow-up message that your question has been answered. Thanking Ted for his time and expertise is also appropriate.

[Update 22 March 2011: Added #5]

Monday, April 12, 2010

Dr. Ed Roberts dies

Dr. Ed Roberts, founder of MITS in Albuquerque, died Thursday, April 1, 2010. Dr. Roberts created the Altair 8800 computer and, in my opinion, sparked the personal computer revolution. He was 68. CNET article:

Wednesday, December 2, 2009

Disabling the command prompt does NOT increase security

There is a configuration setting in the Windows operating system called "Disable the command prompt." It "prevents users from running the interactive command prompt, cmd.exe. This policy also determines whether batch files (.cmd and .bat) can run on the computer. If you enable this policy and the user tries to open a command window, the system displays a message explaining that a policy prevents the action" (copied and pasted from the Microsoft documentation).

This setting is a holdover from Windows 95/98 (which had no security), but it is completely pointless on Windows NT/2000/XP/2003/Vista and later. I can't think of a single good reason to disable the command prompt. Why? Because cmd.exe is a program, not a security boundary.

In the Windows operating system, a security boundary prevents a program from doing something, or prevents data from going somewhere, without authorization. If a user opens a command prompt (i.e., starts the cmd.exe program), the cmd.exe program is running as that user, just like any other program the user runs. The cmd.exe program does not somehow give the user the ability to do things they can't do otherwise. The user's account is the security boundary, not the command prompt.

I have seen many requests for technical help in various forums, and sometimes the answer to a problem involves typing commands at a command prompt. Occasionally, I will see a reply like: "That won't work, because we have disabled the command prompt." My suspicion is that some administrators think that disabling the command prompt somehow increases security, but because this is wrong, the only thing it accomplishes in cases like this is slowing down problem solving processes (thus increasing costs).

[Update 5/13/2015] - These comments also apply to running PowerShell. (I'm not talking about PowerShell's execution policy, which is a separate issue. I am talking about just running powershell.exe or powershell_ise.exe.)

Tuesday, September 1, 2009

Unchain office computers?

Yesterday, I was pointed to an article written by Farhad Manjoo on Slate titled Unchain the Office Computers! Apparently, Mr. Manjoo has never been responsible for maintaining a corporate network. For example, at the beginning of the article, he writes that people are less productive because work they're stymied by the IT department, that class of interoffice Brahmins that decides, ridiculously and capriciously, how people should work.
By this, he seems to mean that IT is "ridiculous" and "capricious" because people some IT departments block people from installing whatever programs they want. This comment, which is itself ridiculous, reveals a large amount of ignorance. For example, on a Windows-based network, doing what Mr. Manjoo suggests requires giving all users Administrator-level control of their computers. Microsoft's official documentation says this is a bad idea and gives the reasons why. I can vouch for this with personal experience: I used to work in a large networked environment back in the Windows NT 4.0 days (1998-2000) where everyone had Administrator access, and the help desk team I worked with spent most of our day fixing user mistakes that would have been prevented if the users didn't have Administrator access. I fail to see how this will somehow increase productivity. I would argue that, in most cases, there will be a net productivity loss, particularly with unskilled users.

Mr. Manjoo's second mistake is in confusing the above issue (blocking program installation) with blocking Internet access. These are two separate issues for an organization, and should be addressed as such. He complains that all IT restrictions are arbitrary, but sometimes there's no nefarious intent by IT to prevent people from doing something--for example, suppose IT installs Internet monitoring software, but the monitoring software's default settings are too restrictive. Yes, this is a mistake IT should rectify, but my point is that not all Internet access blockages are intentional. In addition, sometimes it's simply user error. For example, I have heard complaints that "IT is blocking my web site" when in fact the user was typing an invalid web address.

My advice to Mr. Manjoo is not to write about an IT topic until he is properly informed about it. I wonder if he took the time to interview IT managers to find out the reasons for his complaints? (My guess is that he probably didn't.) Writing an uninformed article that confuses two broad issues (blocking program installation and blocking web sites) doesn't do anyone any favors and has the effect of unfairly casting IT in a bad light.

Thursday, April 19, 2007

IT Pro Townhall Meeting in Redmond

This week I've had the opportunity to take part in an IT Pro Townhall meeting up here in Redmond, which gave me the opportunity to "voice my concerns" about the Vista copy protection problem to other IT pros and even a couple of Microsoft folks. We'll see what happens from it.

In any case, I've had a great time meeting a number of people: Jeff Hicks from (Sapien), Jeffrey Snover (Windows PowerShell team), Darren Mar-Elia (, Mark Minasi (, Susan Bradley (, Mark Burnett (the LogParser book guy), and last (but not least) Karen Forster, editorial and strategy director for Windows IT Pro magazine (she's the one that recommended me to go to the event). Our last session of the day was a short sit-down with Steve Ballmer, and a few people were able to ask him some questions. It was an interesting and informative event.

Not surprisingly, licensing seemed to be a recurrent pain for us all. One participant made the suggestion that if Microsoft, internally, had to deal with their own licensing schemes that the rest of us are forced to put up with, the problem would go away...

Monday, January 29, 2007

What's in a Name?

The Altair is sometimes regarded as the first personal computer. It was sold by MITS in Albuquerque, NM, USA, and Microsoft designed the first BASIC language for it. I never owned an Altair, but since its creation set in motion a chain of events that now provides my employment I thought it was suitable to pay homage.