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.
Ignorance isn't the issue. By having someone show you, the writer,
something you didn't previously understand, you are now no longer
ignorant. You now understand it. But, you are still not necessarily an
expert and you may tend to write it on a level more apt to appeal to
someone else (who also may not be an expert).
I hold that you don't have to be an expert in the field that you're
writing about. All you need is a way to understand something (a patient
designer or engineer - whatever) and the ability to put it into
understandable words... Period! It's the command of the language that
you have to have.
A good technical writer does not need to have a degree in the field he
or she is writing about. I am proof. My music education degree taught me
very little about the alignment procedures of the stereo input module on
a mixing console, or how to find the satellite imagery for your weather
show. But I learned.
That's all I said in the first place.
From: techwr-l-bounces+mschmidt=weathercentral -dot- tv -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+mschmidt=weathercentral -dot- tv -at- lists -dot- techwr-l -dot- com]
On Behalf Of Combs, Richard
Sent: Wednesday, August 09, 2006 11:19 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: RE: Breaking into the tech writing job market
Gene Kim-Eng wrote:
> My experience has been that most over-written documentation is the
> result of writers not having sufficient technical knowledge of the
> product and its users' needs to be able to look at input received from
> developers with a critical eye toward what the user is really going to
> require for a specific operation and cut out or move what is
Precisely. There was a time in my tech writing career when I'd: (1) get
highly technical material from an SME; (2) not really understand what it
said because I didn't know much about the subject; (3) assume that it
would make sense to someone who knew more about the subject; (3) shrug
and "fix" the writing, and call it done.
The assumption in step (3) was almost always false, and that crap was
usually just as incomprehensible to experts in the field as it was to
me. I now know that I can't clearly communicate something without
understanding it myself first.
Ignorance of the subject matter is *never* an advantage. John P. is
correct: if you're ignorant of your subject, you can *only* write like a
novice; if you're knowledgeable of your subject _and_ a skilled tech
writer, you can write (knowledgeably) *for* a novice -- as well as for
an expert, or someone in between.
Allow me to reprise a couple of choice quotes from a ghost of the
"You cannot, under any circumstances, produce intelligent and useful
documentation if you don't understand the content."
"...Ignorance is not a valuable commodity regardless of how you spin it.
You don't impress people with your astounding ability to NOT understand
-- Andrew Plato
Richard G. Combs
Senior Technical Writer
richardDOTcombs AT polycomDOTcom
rgcombs AT gmailDOTcom