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: Texts to Simulate "Keeping Up w/ Des From:"Eady, Sandra" <sae5 -at- CPSTB1 -dot- EM -dot- CDC -dot- GOV> Date:Tue, 24 Jan 1995 09:18:00 EST
Glen Accardo wrote:
What about the "treasure hunting" process? That is, what about the
process of beginning with a vague rumor and producing a manual? It
certainly brings out the truly grim realities of tech writing. When we
look at tech writing from this perspective, we really reassess priorities
of writing: Is layout important? Well, not if I don't have any information
All of the tech writing courses I took concentrated on information which
stood still -- "go to the library and research xxx and write about it."
In interviewing tech writers recently, I've noticed that English majors
believe the world really works that way. Journalism majors seem to know
more about digging and piecing things together and playing one source
off another to get down to the real truth.
I don't know if this is a personality trait, a statistical glitch, or
something taught in journalism school, but whatever it is, it is good
and I like it.
I feel that the most challenging part of my job as a technical writer
is the ability to keep up with the development process. I have only
had the benefit of writing documentation for a system in the production
environment twice. I have written most of my documentation by running
applications that are in the development process. Many development teams
had no specifications and I had to rely solely on my testing and interviews
to identify changes. Also, programmers don't always track changes or
remember to notify the technical writer of them. Some programmers don't
recognize the difference between changes that are transparent to the user and
should not be documented and those that should be.
Even when writing updates for an application in the production environment,
it can be tough to identify all changes when they are not reported to the
technical writer. That is why my technical writer experience has led to the
added role of quality assurance on many projects. I have more technical
background than english and grammar.