A Tech Writer's Guide to Procrastination

• They aren't done coding the feature.

  Ok, this is a trick. This excuse isn't as good as it sounds. Unfortunately, it's the job of a technical writer to document about things that don't currently exist. And which, in all probability, won't exist in the form in which they were described to us. Oh, no. Those dastardly programmers are always adding extra features, or slacking off and not adding features, but do they tell the writers? No, they don't. Never. We have to discover these things, either by using the product, or by eavesdropping on bathroom conversations. Then we spring upon the programmers with a victorious yell and force them to explain what the hell they did. Preferably after they leave the bathroom.

  No, a better excuse is "The spec is still in discussion." Functional and design specs are always being argued over, so this is almost always true. Even...no, especially after the mythical "code freeze" date. Of course, by then, you really should have written something, if only to have something to be suitably aggrieved about when they finally code the feature.

• If I don't fix this now, it will be impossible to fix later when I (convert the doc to PDF/convert the doc to HTML/generate the help files).

  This is a good one. This is an excuse that allows you to spend days changing the font of a document for no particular reason other than that you've developed a sudden hatred of Arial, with all of its rounded edges and cartoonish look, mocking the seriousness and silent authority of Times.

  Or maybe you have a real reason, as I do. The docs that I inherited, and then based my other documents off of, had a scarcity of notational conventions. One font to demarcate screen names and screen elements just doesn't work. But coming up with new fonts isn't real work, and I doubt that anyone will notice the changes, or the fact that by going through the docs to apply these new fonts I've fixed a handful of consistency problems. Nope, this is just busywork, pure and simple. But, see, if I don't do it now, it will be much more difficult to fix later. Much, much more difficult.

So, what can you do to procrastinate?

• Well, the font and style change that I described is a good activity, and one that can take hours or even days, depending on the size of your doc set.
• Visit...no, pore over the FrameMaker and RoboHelp websites. After all, these sites have extensive "Knowledge Base" sections that somehow manage to address all sorts of arcane features and things that you would never, ever do with the products, but never, ever manage to solve a problem that you will actually encounter. So the solution, as I see it, is to search their sites before you have a problem to solve. After all, there's a chance, however slight, that you'll find some information that will help you solve a major problem at a later date. No one can prove that this won't happen.
• Visit sites related to the FrameMaker and RoboHelp, no matter how indirectly. Hey, sometimes the solutions to problems are hard to find, or there might be a better way to solve a problem, or you might find sudden revelation in Seanbaby's in-depth examination of the Superfriends, or in the description of a particularly nifty starship model. Again, no one can conclusively prove that it won't happen.

Columns by Harlock