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: The Technical Writing Field From:Sandy Harris <sandy -at- storm -dot- ca> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 28 Jun 2001 11:55:28 -0400
george -dot- m -dot- hook -at- accenture -dot- com wrote:
> I'm a novice at technical writing, ... I still need some help with the basics.
> I've been reviewing job descriptions here and there, and some of the terms
> are still vague to me.
>
> For example (and I know this is very basic):
>
> Must be able to interpret technical information and write clear
> documentation (does this mean strictly technical manuals and books and
> such, or does the term go beyond that definition?)
The input technical information you have to interpret can be almost
anything -- comments or email from developers, a program specification
(possibly in some formal notation), a requirements document or other
information on what the product is supposed to do, debugging messages
from a prototype product, results of experimenting with it yourself or
watching others do so, source code, blueprints, a specification of the
protocol your product implements or the data it reads or generates, the
legislation or other standards it must comply with, ... -- anything, or
any combination.
Whatever form it takes, the information you get may be incomplete or
outdated ("The spec? Oh, we haven't updated that in months. Too busy
developing the product."), and you have to chase more info.
Whatever input you get, you need to chase down the rest and end up
with clear documentation. Depending on the product and the audience,
that often means it has to be clear to people who neither know nor
care about the sort of information you started from.
A common problem is what to do when your input sources contradict
each other. The current design doesn't match the spec, or violates
the protocol document, or the marketing material about the product
appears unrelated to the actual design. or ... My solution is usually
to point the problem out, in writing, to the manager involved, then
duck. My experience is that such pointers are often not appreciated
or acted on. Anyone got a better way?
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
