Email tip: When asking for help with a problem, also mention what you’ve already tried


When you ask a question, you should also mention what steps you've already taken when attempting to solve it on your own.

First of all, it saves the people who decide to help you with your problem from exploring lines of investigation which you've already tried (and which you know don't work). "I tried setting the timeout to 60 seconds before issuing the call, but it still failed with the error ERROR_NETWORK_UNREACHABLE."

Second, it cuts down on noise on the discussion list.

Try setting the timeout to a higher value.

"I already tried that; it didn't work."

Third, it demonstrates that you cared enough about the problem to try to solve it yourself. It's surprising how many questions come in from people who didn't even make the slightest effort to solve their problem on their own. "When I issue the command show active, it shows the active tags. How do I filter it to show only active tags that I created?"

This is explained in the online help: show active -?. If the online help is unclear, please describe what you're having trouble with and we'll work to improve the documentation.

"Thanks! The explanation in the help is just fine."

(Yes, that was an actual response.)

Comments (21)
  1. Marquess says:

    "I’ve waited three days for an answer, and then I decided ‘To hell with it!’ and just read the manual."

  2. nathan_works says:

    such a great setup for a "social skills of a thermonuclear device"…

  3. RCGodward says:

    I already tried to RTFM but it didn’t work.

  4. 104 says:

    these are very practical tips… a small suggestion: could you create a category for them like "askingforhelp"? in total, it will become a complete guide for beginning / annoying devs.

  5. dave says:

    Second, it cuts down on noise on the discussion list.

    You obviously belong to better lists than I do.

  6. GSerg says:

    I seem to have the exactly opposite problem.

    I write a question for a discussion group. I re-read it and think, nah, this question will make the reader think I’m struggling with the widely known issue ABC. So I add: Please note it’s not the issue ABC because conditions X and Y are not met in my case.

    OK, I re-read the whole thing again and add yet another clarification: Also note that XYZ solution does not apply here because of GHI.

    The process repeats several times. Finally I’m happy with the result so I post the question.

    Very quickly I get a response — You’re a n00b, it’s a widely known issue ABC! RTFM!

    I respond — please read my question again. I described why ABC does not apply here.

    I then get another answer (often from the same person): Try XYZ then.

    Again, I reply — please read my question again. I described why XYZ won’t help me.

    Several posts later we finally achieve a point where everybody has finally read my question in full and actually understood it. But at that point they are so pissed off for being told to read my question again several times that they are not willing to help anymore.

  7. Joshua says:

    That’s rich!

  8. mikeb says:

    Another possible flip side to this is that if the person asking the question goes into too much detail about what was tried already  there’s a risk that potential experts might succumb to TL;DR syndrome (possibly responsible for the responses GSerg saw).

    This isn’t to say that someone asking a question shouldn’t do his homework and indicate such in the question, but queries that go on for pages might ‘encoursge’ a lack of interest.

  9. Roman says:

    This topic is covered in the following article "How To Ask Questions The Smart Way"( http://www.catb.org/~esr/faqs/smart-questions.html )

    Worth to read it, as it helps to solve many problems, without external help.

  10. Joe White says:

    In this post, shouldn’t “I already tried that; it didn’t work.” be a hyperlink to your previous post?

    [Good call. Done. -Raymond]
  11. a random passerby says:

    @Joe White: +1

  12. Michael G says:

    I’ve tried nothing, and I’m all out of ideas!

  13. 640k says:

    It’s the manufacturer’s responsibility to solve problems caused by bugs, non-intuitive interfaces and low quality documentation. The user should not be forced to work a round the bugs and crappy software by it’s own.

    As a developer I always think about how I would want the user experience to be. And usually I, as a programmer, could do better. No matter if it’s less bugs, better UI, better documentation or something else that has to low quality.

    I have to say most developers doesn’t want anything else than to make good software, but don’t have the resources, time or tools to make a better product. Very seldom is software flawless, perfect. Don’t try to think software in general is good. It’s not.

    The manufacturer should not try to hide these defects from the user, a bug report are a perfect opportunity to make the product better. The bugs are still there, even if the developer cannot reproduce or fix the flaws, the bad experience are still there even if you make the user switch to another product.

  14. Roger says:

    The "Smart Questions" page Roman pointed out is where I send people, although it sadly has a bit of an attitude and is more geared to the web of 8 or so years ago.  What is hilarious is just how many people then email the authors of that for help.  (It was the first link in the help/support page of an open source product I did.)

    "How to report bugs effectively" by Simon Tatham is also excellent.  Choice quote "Give the programmer some credit for basic intelligence: if the program really didn’t work at all, they would probably have noticed. Since they haven’t noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. "

  15. 640k says:

    > Give the programmer some credit for basic intelligence…

    No, usually the developer is a clueless junior who doesn’t have the most basic programming skills. Sometimes they lie straight to your face: "haven’t ever seen this bug before".

  16. Cheong says:

    @GSerg: For your kind of problem, there’s known to be some community members who just skim through the questions and see if they can answer be searching the web, in order to gain some real world experience on certain kind of technology. When you post questions that you’ve already searched the web for, don’t be surprised if they run out of suggestions quickly. In your situation maybe there just isn’t anyone experienced enough to solve your problem. Perheps it’s a good time to try paid support options.

    IMO, it’s actually considered to be a nice thing to have someone deal with dumb questions and gain experience, while those experienced can focus on those question which requires greater expertise to solve. Just that for most of the time when I see a thread with long discussion, I’d consider someone has committed to solve it and skip reading it completely unless the topic attracts me. (e.g.: It’s a subject that I’m likely to encounter in the future and I have not much experience at.)

  17. GWO says:

    If the "show active -?" magic is clearly documented somewhere obvious, that’s a fair point.  Otherwise, how is the user supposed to know how to get help?

  18. Adam says:

    The only problem I find with this approach is people who use a support script to address problems still have to go through the script.  

    I find its best to let them ask and then just say that you’ve tried it.  If you are unlucky, they won’t be happy with that and will insist you do it again.

    This tends to occur with broadband providers here in the UK.

  19. David Walker says:

    I have trouble along the same lines as GSerg sometimes… If a problem is complex, and I have tried lots of possible solutions, I document them in my question so that responders will know that I have tried them.

    But then the problem description gets long and perhaps boring, so I get responses like GSerg gets.  

    Just yesterday, I reported a bug on an internal system, and was asked what version something was in.  I gave that information again, even though it was in the original bug report.  

    You don’t want to be rude to people who are trying to help, so you have to be courteous when you say "I already said I tried that solution and it didn’t work, you idiot"… so there’s sometimes a fine line between including every piece of information about the problem, and making it so long that you get TLDR for responses…

  20. Falcon says:

    I try to avoid TL;DR syndrome by practising TL;DR;DR.

Comments are closed.