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: A Tech Writer's Background From:Megan Shult <Megan_Shult -at- HYSOFT -dot- COM> Date:Wed, 30 Aug 1995 15:28:47 -0400
On Tue, 29 Aug 1995, Connie Winch wrote:
> The opinion: Salespeople sell, Programmers program, Engineers
> engineer. And Writers write. The technical information that
> a Technical Writer needs to know can be learned.
At my company, writers are the original jack-of-all-trades. Our
slogan would be more like: salepeople sell, programmers program,
engineers engineer, and writers write/design/test/prototype/mediate/
spec/build etc. :)
Stuart wrote:
>Seems like we should
>move beyond the historically limited idea of technical writer.
Amen.
Granted, we use integrated design teams, so I'm coming
from a slightly different perspective than someone who is separate
from the development process. But I find it invaluable to
work within the broader conception of what a technical writer
does. Writers bring to our development process the perspective
of the user; in thinking about the challenges we'll face documenting
a feature, we often uncover inherent problems in the design itself.
In writing the specs from which the programmers work, we gain
a product expertise that makes the writing process quicker, easier,
and more accurate. In helping to design and prototype, we
are immersed in the product from day one.
Does it take time away from my writing? Definitely. But it doesn't
take away my expertise in the documentation process, and it
also has three substantial advantages:
1. It exposes me to other aspects of writing. Spec writing is an
interesting exercise with its own set of challenges.
2. It improves my ability to produce coherent, in-depth
documentation in a shorter time period.
3. The expertise gains is invaluable when working with the
other areas that traditionally have been resistant to 'working
with doc' -- programming in particular.
