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 little machoist antler-crashing From:"Chuck Petch, Editor" <PETCH -at- GVG47 -dot- GVG -dot- TEK -dot- COM> Date:Fri, 12 Nov 1993 08:36:44 -0700
Brian Daley writes:
"If you're writing theory of operation for hardware designed by your company
and technology is just a pile of information you don't understand, then you
need to be led step by step by your engineer through his schematic diagrams
in order to write your theory. You're more of a time drain on him, so the
tech writing profession suffers a lack of respect because we can't do the
things to make the company more efficient."
I can read a schematic as well as the next person and have good recognition and
understanding of many of the circuits our company uses, but I would never
presume to just go through a schematic alone and assume that I understood it
well enough to explain it to others. I've seen sharp engineers take over
projects from other engineers and have to be led through the schematic to gain
a full understanding of it. The same goes for reading someone else's code.
Interviews are necessary, no matter how technically aware you are; anything
less is presumptuous.
In my experience, a skillful writer with a degree in writing and some general
background in technology can quickly learn the product and write a superior
manual because that kind of writer can communicate precisely, smoothly, and in
a way that makes sense for a particular audience. Technical types who become
writers almost invariably assume that a general command of language will make
them an adequate writer (a form of arrogance in some cases). Yet they have
little or no training in audience analysis, organization, transition devices,
punctuation, grammar, editing for concise expression, levels of style, graphic
design and page layout, and so on. These are the skills that make for good
communication. The result of technical writing without training in these skills
is predictable: a technically correct manual that is difficult to read and even
more difficult to understand and use. Yet the technical person doesn't even
see--isn't even aware--of the shortcomings because he or she has not been
trained in the subtleties of good writing.
If you want good communication, hire someone trained in the art of
communication!
(Man, am I getting intense or what? It's just that I have seen this kind of
arrogance from technical types over and over again, and I've also seen the
lousy writing that results. Excuse me while I slip away to the restroom and
splash some cold water on my face...)
---------------------------------------------------------------------------
Chuck Petch, | "Get your facts first, and then you can distort
Technical Editor | them as much as you please."
"Petch -at- gvg47 -dot- gvg -dot- tek -dot- com" | -Mark Twain
---------------------------------------------------------------------------