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: inductive or deductive? From:"Charles P. Campbell" <cpc -at- SWCP -dot- COM> Date:Tue, 18 Oct 1994 10:15:40 -0600
Ann Stewart's question about induction and deduction got me to
thinking about the work of editors in technical settings: are editors
used as effectively as they might be? I don't think so.
What's your experience?
Ann wondered,
Aren't scientists trained to use deduction in their analyses?
Doesn't this also apply to engineers?. . . Any ideas?
Induction and deduction have different meanings in problem-solving
and in composition.
In problem-solving, induction moves (or so the folklore goes) from
specifics to generalities, from data to conclusions. Deduction begins
with generalities then draws conclusions about whether specifics fit
the general rule. (Rule: cars won't start if the battery is dead or
disconnected. My car won't start. Therefore . . .) Actually, as
Ann observed, scientists use a combination of induction and deduction
in their reasoning.
In composition, "induction" means that the writer leads the reader as
it were by the hand through the entire reasoning process from problem
formulation through data analysis to conclusion. "Deductive" organi-
zation starts with the conclusions, because that's what the reader
is usually interested in, and then orders the data so as to support
the conclusions.
People trained in science and engineering, in my experience, often
resist ordering their writing with the conclusions first. One of the
hardest "sales" jobs I ever had was to convince a bunch of PhD
chemists in a company's R&D division that management would find their
reports more useful if they put first, in a summary, the information
management wanted. The chemists, trained in the "inductive"
format of the academic scientific article, felt that they might be
falsifying or oversimplifying if they didn't drag the reader through
the whole analytic process.
Editors could help in such situations because, as reader advocates,
they are likelier than subject-focused scientists and engineers
to understand the needs of readers. Too often, though, the subject-
focused folks dictate the content, order, and manner of documentation.
The result, I think, can be overdocumentation: voluminous reports
and manuals that no one can or will read, let alone act upon. This
situation provides lots of work for technical editors, but often
work of a fairly low order.
What do you who are editing technical documents find?
=================================================================
Chuck Campbell, PhD cpc -at- nmt -dot- edu
Technical Communication Program 505-835-5284
Humanities Department, New Mexico Tech
Socorro, NM 87801
=================================================================