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:More about paradigms From:Peggy Thompson <THOMPSONP -at- A1 -dot- OSTI -dot- GOV> Date:Thu, 18 Mar 1993 14:55:00 EST
A few additional thoughts about a technical writing paradigm
(not my thoughts; besides, I don't really think in terms of a
In The Art of Technical Documentation (Digital Press, 1992),
Katherine Haramundanis suggests there are 3 types of technical
1. Marketing materials - intended to convince or persuade
2. Reporting materials - present facts with no intended
persuasive or instructional slant
3. Instructional materials - can both instruct and train (may
also describe a product for the user)
In Technical Writing: Structure, Standards, and Style
(McGraw-Hill, 1982), Robert W. Bly and Gary Blake suggest that
the "primary goal of technical communication is to transmit
information; its secondary goal is to persuade."
To quote Bly and Blake further: "All technical documents have a
selling job to do. Papers and articles promote a company's
technical expertise and capabilities or support a university's
request for grants. Product information sells equipment. Reports
help scientists and engineers sell their projects to company
managment. The quality of a technical proposal can influence the
outcome of contract award."
Then there's Ernst Jacobi in Writing at Work (Hayden Book Co.,
1976), who writes, "Good writing, all good writing, is
problem-oriented. There is a problem lurking in some form or
shape behind every piece of writing--newspaper column, novel,
play, technical manual. The problem is the crux--the writer must
always be aware of it, whether he states it in so many words or
leaves it implicit."
So what are we doing when we write technical material--selling,
solving a problem? A little of both? Does discussion such as this
help, or does it obscure the forest with trees? Don't we all ask
ourselves when we write, in essence, what does my reader need to
know and how can I convey that as clearly and simply as possible?
(That last query comes is as close to a paradigm as I get when
writing computer documentation.)
SAIC - Oak Ridge, TN
thompsonp -at- a1 -dot- osti -dot- gov