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: technical Writing Skills From:"Susan W. Gallagher" <sgallagher -at- STARBASECORP -dot- COM> Date:Fri, 10 Feb 1995 13:26:22 -0800
> On Wed, 8 Feb 1995 15:40:46 GMT, Mean Green Dancing Machine (aahz -at- netcom -dot- com)
> wrote :
> > part because I was able to get the programmer to change the product
> > design in certain ways that made it easier to document.
To which Matt Harmon replied:
> Meaning no disrespect but, shouldn't a good technical writer be able to
> get around any aspects that make a product difficult to document? This is
> what's always been expected of me (English major, Computer Information Systems
> minor and documentation specialist for a local computer/network project).
> No-one ever said this job was easy--that's why tech writers are
> compensated as they are.
Just because a good tech wirter *can* get around any aspects that
make a product difficult to document doesn't mean "s/h/it" *should*
;-) (you can read that with or without the slashes)
Well organized and well written documentation can point out subtle
flaws in a process. By making that documentation appear to be less
well written or less well organized, we can attempt to hide product
flaws. In the environment in which we work, this *may* be necessary --
but this may not necessarily be the best approach.
For example...
In a text-based program I once documented, I wrote the procedure
for a routine. I then copied that procedure and started making
changes to it for a similar function elsewhere in the program.
Then I noticed that the exit routines were different for the
two sections of the program -- a difference that was totally
unnecessary. I could have just changed the docs and let it go.
But I went to the programmer and showed him what I'd found and
he changed the program instead -- very willingly, I might add.
In a gui product I documented, I asked why the option buttons
that activated a text field were under the field instead of
on top of it. They got moved.
A good technical writer can add value to a product in lots of
different ways -- not just with words.
Sue Gallagher
StarBase Corp, Irvine CA
sgallagher -at- starbasecorp -dot- com
