Hugh Sasse's Support Guide

Contents

Purpose and Intent of this Guide.

This document is a resource to help people get the best support they can, within the Physical Layer Lab, or people in Engineering wanting help with other matters I handle, such as e-mail. Its intent is to reduce frustration all round, and to facilitate my providing better support, and to save everyone's time in the long run.

How to get effective support.

Providing support to various groups within Engineering is why I am here. However, if I am to do this effectively, I can't respond instantly to every request made of me. Some of my support role involves maintenance of existing systems, keeping software up to date, and so forth, so I cannot be expected to respond instantly to your problem on the basis that you think it is urgent. It is unlikely that you will be aware of the priorities that others have for their requests which I'm trying to handle as well, so please consider carefully why your request is so important relative to theirs.

With this in mind, there are things which you can do which will enable me to provide you with better support than I could if you don't do them.

Tell me what you were trying to do (your goal).
It might be that your goal is perfectly reasonable, but you may have chosen a difficult way to achieve it. For example, under Unix many people wonder how to write a Perl program to number the lines in a file. Well, not only can cat -n do this without writing any code, but there is already a specific program called nl to do this.
Read available documentation
As a student, you may already have the information in your course outline, in email, on the Blackboard learning environment, etc. For programming problems there are a number of options. On unix you can use the man command to find out information about a program, and man -k to search for the likely manual pages. Windows comes with an extensive help system, look on the start menu for this. It may well be that the available documentation is less than helpful. It may be that you have read it, but it was entirely meaningless to you. However, it may be that the answer is right there, and you have solved the problem in parallel with whatever I'm doing in my support role already. Clearly you want other people to do this so I'm free to help you, but so do they. :-) Also Web Search engines such as duckduckgo and Google can be tremendous help in find answers to specific questions.
Ask a specific question
Specify your problem in sufficient detail so that I can't confuse it with other problems. This will save my time and, more importantly, your time, in tracking down what is wrong. If you tell me you cannot print, you can also tell me which printer you were trying to print to, from what package, and whether it worked yesterday. That way I can avoid hopeless searches in trying to replicate the problem, and I might even be able to diagnose it straight away.
Tell me which programs or packages you were using when the problem occurred.
The BBC have a habit of talking about "logging on" to a website, even where there is no need to enter a username and password. (I'd just call that "connecting".) If you tell me you can't logon to a machine, I will think you mean that you are using rlogin, ssh or telnet, and that there is a problem with entering your username and/or password. Unless you tell me you are using a web browser, I will test all the wrong things, which really doesn't help you. If you tell me which program you are using, even if you don't use accurate terminology, I still have some hope of tracking the problem down quickly.
Provide some evidence of the problem, where possible
If you can quote the error messages you have received, then, subject to them being informative (admittedly, not always the case) then I may be able to track the problem down more quickly. Also this means I know what you were doing exactly, because I have had descriptions which have been misleading in the past, so I have spent time trying to find problems that don't exist. Having the exact message allows me to search much more narrowly when looking for a solution, speeding up obtaining a solution. I may sometimes get a better understanding of what you were doing from the evidence than from your description of it. That is fair enough, because forming descriptions that are useful to support people is not always simple.
Tell me what you already tried, before contacting me.
You are more familiar with your work than I am. You will probably have encountered problems in the past and may have tried an alternative solution to your problem. If both approaches failed, then that may tell me more about the nature of the problem than if you leave out half this information.

Frequently Asked Questions Which I can't Answer.

We have run out of paper.
I do not have a consumables budget. I am in no better position to order paper than you are. Why not cut out the middle man and get your supervisor to order some for you? If they don't have a budget, then there is not much I can do about that. Sorry. We do have some for the printers in this lab, though.
I can't get this package to compile.
Well, unless you are more specific about what you did and why it failed, then I probably can't either. If you can be more specific (and you are within my department), then I may be able to help. I can't be more definite than that, though :-)

Getting support elsewhere.

It may be that I cannot help you, or I'm so swamped that you need to look elsewhere for support. Remember that those whom you work with on a daily basis may have some answers, because you work in a group of people working in the same field. If I cannot help then contact Manbir Sambhi, to arrange support from other technical support staff locally. Also there are some services provided directly to students and staff at De Montfort University by ITMS, though generally they expect support to be provided more locally where possible. Then there are sources of help external to the university.

There are internet mailing lists and newsgroups where you can get information. However, most of these points I have raised apply even more to these sources. There you are hoping to get support for free. See, for example, How to ask questions the smart way by Eric S. Raymond and Rick Moen, also available at http://davecompton.com/how_to_ask_questions_the_smart_way.htm, which is often quoted. Under no circumstances ask the authors of that document for help on the basis that you have read it. They have no obligation to us whatsoever. I have used some of its points in here, though it is somewhat more forceful in expressing them. Being more well-known than I am, I expect the authors get many more enquiries to which they can't provide useful answers without more information, so they are probably more frustrated than I get at times! So, again, DO NOT ask them for help.

A document convering similar issues, but much more gently, is How To Ask A Question On WinDev. I found this in the comments in "Don't ask us questions. We'll just ignore you."(June 05, 2006), in the Coding Horror Blog. Another is "How to Report Bugs Effectively" by Simon Tatham.

Another good document, far more friendly than HTAQTSW, is Help Vampires by Amy Hoy. This one explains how you can tell if your questions are likely to be sucking the life out of an online community and how to ask questions efectively. It also has suggestions on how to deal with people who ask you the sort of questions that suck the life out of you.

One related to debugging, (which is basically scientific method), is How to debug small programs found from [HN]. It even talks about "Rubber Ducking", why explaining your program to a rubber duck actually finds bugs, Some of that is about expressing the problem so that even a duck can understand it, so it becomes clear to you what the problem is. The point is that some of the above mentioned clarification steps may help you find the problem before you get as far as asking anyone else for their help. The article discusses this a well as many useful techniques that are more conventional.

Created 17-JAN-2005 by Hugh Sasse

Last Modified 07-MAR-2014 by Hugh Sasse
$Id: support.html,v 1.13 2013/11/29 16:32:22 hgs Exp hgs $

This document should be accessible as http://www.tech.dmu.ac.uk/~hgs/support.html or http://tinyurl.com/pb77/support.html.

This page can be revalidated.