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.
"Beth Agnew" <Beth -dot- Agnew -at- senecac -dot- on -dot- ca> wrote in message news:212011 -at- techwr-l -dot- -dot- -dot-
>
> Well, of course that is just your opinion. Knowing the "why" behind what
> you're doing with the material is indeed valuable and should not be so
> quickly dismissed. We have numerous examples of people who knew content
> but not technique -- that's why we moved away from SMEs (computer
> engineers, for example) writing technical documentation in the first
> place. Although they had initmate in-depth knowledge of the subject
> matter, they did not know how to deliver that information in readable
> fashion. Hence the pervasisve belief that "technical documentation is
> hard to understand".
Technical documentation is hard to understand because of three general faults:
information overload, mis-shapen information, information underload. All of
these stem from a lacking of some type. While some engineers and analysts might
suffer from bad communication skills, overwhelmingly the problem isn't poor
communication skills but a profound lack of subject matter knowledge.
Communication skills are to a tech writer as a hammer is to a carpenter. I
possess a hammer, but I am not a carpenter. Thus the possession of hammer does
not make a person a carpenter. Rather the skill at which a person puts that
hammer to use to make something.
Every human every born has communication skills. Some better than others. Thus,
the existance of communication skills in a technical writer does not make a
person a technical writer. Rather that person's ability to use those
communication skills to produce something is what defines them as a technical
writer. Comm skills are useless without subject matter.
Like a hammer is useless without wood, nails, and glue. Hence, to be a good
carpenter, you must have a deep understanding of wood, nails, and glue. And to
be a good technical writer you must have a deep understanding of the subject
matter.
As such, in the real world, 75% or more of a writer's time is (should be)
dedicated to learning the material and explaining concepts.
This is in stark contrast to writing programs and PhD programs where 90% or
more of the time is dedicated to teaching "communication skills." As such,
graduates from these programs usually have an adjustment period where they must
reorient their work priorities from communication and tool skill issues to
subject matter issues.
This doesn't make those programs bad in any way. It just means that completion
of such a program does not necessarily make a person a better tech writer. Some
graduates never make it through that adjustment period and continue to misplace
their priorities in the workplace.
Andrew Plato
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
