The real thing with e-mail etc is that one ought treat it as an electronic inbox, and not something to dance to every beck and call.

One works on a variety of tasks, rifling the inbox for the next task. It's the same with inbox stuff. You might assess incoming tasks for urgency and importance, but if you jumped to every task as it hits the desk, ye'd never get nothing done.

It should be remembered that efficency and effectiveness generally are unrelated.

Efficiency is something that can be measured: responces to calls, forms processed, etc, the sort of thing you can count. It's pretty easy to do this sort of thing, and often the PHBs will take some metric and use it as a measure of activity. Because of this, one often sees things like proformance indicators, and the process and often salary, becomes connected to the indicator. The industry stops being what it is and starts producing 'red beans' for the bean counters. The indicator changes, and one produces blue beans.

Effect is something that is about getting the right job done, both for the customer and for the system. It's not even about what the customer wants, since this supposes that it is the role of the customer to diagnose the problem and the solution, and simply ask for the solution to happen. One needs to think of what happened with the system that responded to cyclone Katrina in New Orleans, which the responce was based on customer wants, rather than pre-assessment by those who should have done this. A call for help is an indicator to a problem, not a proposed solution.

Of course, even though an indicator might be proportional to effect in the wild, when it is proportional to money, the indicator becomes more important to the effect. A doctor, who might have an indicator on consultations, will split several illnesses to several consultations. On a help desk, one is more intent on creating calls, then on providing effect. A call that seeks three problems would be terminated at the first, and new calls needed for the second and third. Also, the process might be extended to several calls to create extra indicator traffic.

In the main, help desk traffic is not a really good indicator of effect, since there are things that effect this. Response time, time to fix, etc, all serve to alter traffic, in some cases, it might be better served by the section guru rather than the help desk. The effectiveness of the guru's solutions may well impede the help desk's overall issues, since it might make matters worse.

One should also note that recording the help calls is also an impediment. It serves no effect, and in many cases, might take as much to make happen as the call does in nature. One might answer say, 90% of the calls first up, yet spend more than 50% of the times making the necessary beans for the counter. A good deal of issues can be condensed into a few batch files (yes, i did this: system configuration is a good candidate for script files), so that while the call is terminated relatively fast, the actual recording might be tedious.

My experience of help desk is that particularly Microsoft rograms (eg Word, Access, Windows), use common names, which makes them very hard to grep for in the system. This reduces the effectiveness of any sort of 'search the job tables' for help. To this end, i used Wart, Abcess, Windoze, much to the annoyances of the PHBs.

Still print because my copy of vproof (proof-reader proggie) does not really work on the screen.

I make use of style sheets as much as possible. This allows for example, either block or first-line indent. With a style-sheet set down to character-level, one can use single or double-spaces freely at the end of a sentence. The markup language I wrote (KML, see, eg http://www.os2fan2.com/ makes use of a chacter-level style sheet that replaces eg `t and `T by th,TH or , respectively, eg 'the polygloss' vs 'the polygloss as nature intended', both derive from the same source KML file.

One uses also two kinds of paragraph (p) and (pp), to create leading vs following paragraph. The pp-style paragraph can have either first-line indent (traditional) vs blank-line block style.

Don Knuth described Literate Programming in which the program is embedded in comments, one using a preprocessor to write the program. The preprocessor runs as a command processor, using the source as a batch file. One gets a properly sorted batch file as output. Because of this, one can overcome limitations of the programming language, use pre-processor variables etc, and produce several linked files etc.

Documentation is relatively straight forward, since one writes what one wants to get, limitations, API and examples by way of a wish-list, and then create the routines that make this happen. You can write a tight section like "File I/O", for fileopen() and fileclose() along with getline(), putline(), etc, without exposing the filenames to all of the subroutines. I've written a program to write Web pages in it, for example, http:\\www.os2fan2.com\pgloss\index.html and its attendent pages. It's pretty elegant really.

The temptation of LP is to use it to solve a problem per source, a note that Jon Bentley (Pearls of Programming) noted. LP is about sorting problems: however, the sort of problems that Knuth sought to solve are complete things in an educational setting, not bits of problems in the real world. None the less, I use it to write terse batch files etc, where the LP source is the help file too.