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.
Speaking as someone who was trained as an engineer and is
now writing and managing other writers...
1. Writing is more fun (at least for me).
2. Engineers who write "well enough" *and think it's
more fun than engineering are relatively rare. I
am in much more demand as an engineer who
writes than as one who doesn't oras a writer with
no engineering background.
On the subject of "chunking," it is certainly possible and
practical to do that for a product line that will be in large
scale production or will consist of multiple variations on a
base design. You create the first document the hard way,
then use it as a template that others with less knowledge
can produce future variations from by "filling in the blanks."
I've done it. But if you work in a "skunkworks" environment
where you support multiple, bleeding edge one-offs with
new technologies and techniques being developed along
with the products, the documentation for each one can
often consist of that first "hard way" document, with no
future variations that will use that template again.
As for the expense of training an engineer to write vs
training a writer to understand the content as well as an
engineer, we don't do either. It is less expensive to pay
a little more for someone who already has both engineering
and writing knowledge than to train either. It does take a
little more effort to find someone like that, because the tech
world is full of engineers who can't or don't want to write
and writers who are "technical secretaries." But paying a
little more and putting in a little more recruiting effort
upfront is not a "failure of management" if it costs less
and reduces effort in the long run.
Gene Kim-Eng
----- Original Message -----
From: "Technical Writer" <tekwrytr -at- hotmail -dot- com>
> Not at all. "doing rote work in fields you know nothing about" is about as far
> from technical writing as it is possible to get. That is more on the order of
> "technical secretaries," of whom there are an ever-increasing number, quite
> capable of handling the major portion of repetitive writing.
> My argument is simply that such a situation is a failure of management. If a
> project cannot be chunked down to the point of task completion by (almost any)
> skilled, competent technical writer, it is a failure of the BA, the PM, and
> whoever is running the IT department to do their jobs. If they had done their
> jobs, the notion of a particular technical writer being "essential" is
> ludicrous.
> It is certainly less expensive to train a competent engineer to write well
> enough (that old "satisficing" trip) than to train a technical writer to write
> about a topic that requires engineering knowledge. If the technical writer
> actual understood the topic as well as the engineer, why would he or she be
> writing about it rather than doing it?
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
