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.
RE: Appealing to or introducing Tech Comm "best practices"
Subject:RE: Appealing to or introducing Tech Comm "best practices" From:"George F. Hayhoe" <george -at- ghayhoe -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sun, 24 Oct 1999 12:38:28 -0400
<SOAPBOX = ON>
Andrew Plato said:
<<No two tech writers can ever agree on a standard - because
standards are power and power is attractive. He/she who
creates the standard ("best practice" call it what you will)
often exerts control with those standards. Standards are
all to often tools of control and not tools of value.
<<The other reality that is hard for many tech writers to
accept - there are NO standards. Just because someone
writes a book does not mean they have any greater insight
into the universe of tech writing than some entry level
nobody at Consolidated Loser Electronics in Scuttleflab,
NJ.>>
Andrew offers two approaches to standards here: politics and
ego. Neither corresponds to reality as I've experienced it.
I'm always pleased when we discuss topics on this listserve
that are of greater significance than which tool is better
than another or what we think of a certain software company
near Seattle. I'm glad we have philosophical discussions
because some amount of navel-gazing is very helpful to
developing our sense of professionalism as well as our skill
at what we do. Despite Andrew's insistence to the contrary,
I don't believe that anyone can simply apply his or her
backside to a chair and JUST DO IT and produce a reasonably
good product without understanding what IT is and how IT
works. (Well, perhaps it's possible, just as it's supposedly
possible for a chimp with a word processor to turn out a
Shakespearean sonnet.)
If we deny the validity of approaching what we do
methodologically, if we deny the existence of standards,
then we're really asserting that the products we make are
the result of accident or magic. I don't think that either
of these views of our craft squares with reality, or that
either advances our profession, especially given the fact
that most of the people we work with are engineers and
scientists. Their world is founded upon methodology and
principles that ensure the predictability of results. When
the expected results don't occur, the scientist or engineer
analyzes what happened and discovers either that the
methodology and principles weren't correctly applied, or
that they were flawed in some way. The result is a better
understanding of the methodology and principles, or an
improvement upon them. In other words, the scientist or
engineer is able to explain rationally why the U.S. Space
Shuttle works reliably virtually all of the time, as well as
why the _Challenger_ exploded.
The same thing is true of the communication products we
build. We can--or should be able to--explain why they
perform or fail to perform as expected. I'm not saying that
technical communication is rocket science. The principles
and methodology that underlie what we do are less well
understood and perhaps essentially less certain than those
of science and engineering because they rely to a large
extent on subjective human behavior rather than the laws of
the physical world. But that doesn't mean that they don't
exist or that they're invalid.
I don't know about anyone else, but I can't afford to
reinvent my craft each time I start a project, or rely on
native genius, or trust to luck or magic. My experience has
shown me that there are ways of performing tasks--as well as
principles underlying those tasks--that produce reliable
results. Those methods and principles aren't graven in
stone; our understanding of them is evolving and is open to
the contributions of all, whether they've written a book or
are new to the field. But the principles and methods do
exist, and they produce reasonably reliable results when
correctly applied. When the results aren't what I expected,
I analyze the process to see what went wrong--and learn from
doing so.
