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:Nancy Paisner <nancy -at- HI -dot- COM> Date:Fri, 10 Feb 1995 17:20:54 EST
> On Wed, 8 Feb 1995 15:40:46 GMT, Mean Green Dancing Machine (aahz -at- netcom -dot- com)
> wrote :
> > Normally, I'd say writing ability is more important. However, it can be
> > critically important to have a tech writer who really understands the
> > problem domain. In my first and only job as a tech writer, my ability
> > to program in C turned out to be crucial in writing the manual, in large
> > part because I was able to get the programmer to change the product
> > design in certain ways that made it easier to document.
> 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
Just because we should be *able* to document around a bad product
doesn't mean that it isn't far, far better to improve the product, so
that it will require less 'documenting around.' If we have a chance to
make a product 'self-documenting' (yeah, I know, I've never seen a
completely self-documenting product either...), that's the ideal.
[Most users (myself included) don't want to have to use the manual
anyway - that's simply a fact of life, not a value judgment on
manuals. Humans didn't evolve reading technical manuals; nobody needs
a manual to eat, or to sleep, or to dress, or to perform a number of
other important human activities. Humans want their knowledge to be
immediate and intuitive. I love to read, and I've certainly spent my
share of hours reading technical manuals on everything from an
answering machine to a C programming environment, BUT I READ THE
MANUAL ONLY IF I CAN'T USE THE PRODUCT WITHOUT IT.]
In my opinion, the job of a writer is to make it as easy as possible
for a user to use the product, whatever it is - to be a user advocate
for the customer who isn't in on the product design process.
The most effective way to do this turns out to be getting involved in
the design process and making useful recommndations to the engineers
building the product. (Note that I don't restrict this to software,
though that's my own specialty.) I think the natural next stage for
technical writers is user interface design in general. Too many
engineers are concerned only with how to get a particular
functionality into their product, not with how the user will get the
functionality *out* of the product. Solving the second problem is our
job, and we can do it better if we show the engineers how to help us
> what's always been expected of me (English major, Computer Information System
> 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.
> Matt Harmon at
> mh1704 -at- xx -dot- acs -dot- appstate -dot- edu
> (finger this account for North Carolina Weather Forecast)