TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Why We Need Good Software Manuals From:Kent Newton <KentN -at- METRIX-INC -dot- COM> Date:Tue, 23 Jan 1996 12:30:00 PST
On 22 Jan 1996 06:47:53 -0600, Michael Andrew Uhl wrote:
-- snipped --
>An essential part of learning to be a good writer is the habit of
>reading. Consequently, good technical writers read habitually. Among
>the things they read are software manuals, usually for the tools
>they use to do their jobs. As Shauna Jeanne pointed out, most
>software users avoid reading manuals. On the other hand, the
>successful technical writers I know read these manuals quite
>carefully. [I'm not trying to imply that they or I actually
>*enjoy* reading them... ;-) That would make us nerds... ;-)]
>Voila, we become experts. We can define software "experts" as those
>who have actually read significant parts of the user manual and
>understand how to perform all the basic operations and then some.
>Many people have asked me, including technical writers--ugh!, "How
>do you know so much about ***?" I'll be the first to admit, I am
>less than a genius. I also tell them that I sure didn't go to a
>training class--way too expensive. And then I let them try to figure
>out how I did it.
-- snipped --
I know many tech writers who fail to read the documentation for the
software they use to produce their documentation. When we switched from
Word to Frame, I took the Frame manual home and read it cover to cover.
Of course, I didn't retain everything, but I got a very good grasp on
how to use it. The other writers in our organization didn't bother: they
just dove in. When they have a question, instead of looking in the
manual, they seek me out for an answer. I have become the *de facto*
expert on the system (even though I fought the switch to Frame).
It's a shame when a technical writer won't even read a technical manual.
Besides learning to use the product, it is good research to see how
other writers solve thorny problems, what new tricks are being used, and
how complex material can be organized. I think it would be a natural
reaction for every tech writer to read (or at least skim) any
documentation he can get his hands on -- especially for the software he