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:"Robert A. Goff" <outlaw -at- RT66 -dot- COM> Date:Fri, 10 Feb 1995 18:11:49 -0700
It seems to me in this discussion that there is a subtle difference between
Susan's point:
>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.
and Mean Green's statement:
>> 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.
Susan pointed out stuff that any beta tester might, and we seem to have
consensus that a writer should also be a tester. But Mean Green's
description of the situation sounds as if he requested and got the changes
to the product specificially to make it easier to produce the
documentation, and I don't think that's our job at all.
<<<<<<<<<>>>>>>>>>
Bob Goff
outlaw -at- rt66 -dot- com
<<<<<<<<<>>>>>>>>>
PLEASE MAKE A NOTE
OF MY NEW E-MAIL ADDRESS!
