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: Worthless Tech Comm Degrees From:"Sella Rush" <sellar -at- mail -dot- apptechsys -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 23 Mar 2000 14:45:30 -0800
On this subject that will not die, Andrew has finally crossed the border
from the land of unpalatable truth into crapdom. Of course, he has been
goaded there by our willingness to sometimes focus on the less-than-vital
aspects of our job. Not that that's an excuse.
I'm not sure why Andrew chooses to equate the inanities discussed on this
list with what is taught in the average tech comm program. It's a flawed
argument that seems to be the result of selectively choosing what to read in
a few postings.
We've all met people who, degreed or not, can't grasp intangible concepts
(such as how to communicate), and instead walk away from classes with their
heads full of the details like font size and white space. Good tech comm
people know the details and place them in context with the larger
intangibles, understanding how the pieces support the larger whole.
"Challenged" tech comm people fixate on the details because that's what they
understand, and hope by getting the details right to somehow achieve a
workable "whole".
(Thinking about white space or fonts doesn't put a person into the
"challenged" category. Trouble comes when they start thinking that white
space or font is the most important part of the process.)
About tech comm programs:
While along the degree path people will learn about whitespace, fonts, etc.,
the most important topic that Tech Comm courses can--and do--teach is how to
gather *data*, digest and process *data*, and spit out *data* in some form
that's usable to people who might actually need it.
To use Andrew's analogy, tech comm degrees do teach the hammer, the nails,
general house design concepts, ***and*** what to do with the hammer and the
nail in order to achieve a finished house. (Whether people walk away from
the program with all that knowledge is another question.)
What tech comm programs do not do is teach one specific house design and one
set of building materials, and expect it to be applicable to any aspiring
house builder regardless of the job they end up getting.
Tech comm programs more intelligently focus on communication, regardless of
the topic. The specifics are far better covered either on the job or by
choosing to take an extra class in whatever topic you're interested in.
And this is really the crux. We are responsible for our own education,
whether we get it by amassing degrees or by reading books in our off hours
or by working really hard, or all of the above. I went to a tech comm
program because I wanted to learn tech writing. I learned programming by
taking a C class, buying a book on Visual Basic and several books on
database design. I know what inheritance is because I looked it up in a
reference book and paid attention at work.
And now, a note about organization:
I don't understand how any tech writer can claim that organization of
information is unimportant, so I must be missing something in Andrew's
argument. Or maybe I'm tripping over his legendary use of hyperbole.
Information must be accurate and it must be organized in a way that usable.
Organization and accuracy are the most important aspects of tech comm, and
there's really no way to compromise on either.
Most of us have heard the Tufte story about the Challenger explosion--that
all the O-ring data needed to avert it was there in the reports, it was
simply organized in a way that made it really difficult to understand. So
no one caught it. (I have nightmares about being that tech writer.)
Here's one we can all relate to: educators decide students need to learn
algebra, trigonometry, and calculus before they graduate. Does it matter
what order the students take the classes in? If I want to take choir at a
time that conflicts with trig, can I take calculus now and pick up trig next
year? Sure, why not?
What about procedures? I have a new, rather strange phone system. To get
voice mail or use the intercom, etc., I have to push the appropriately
marked button. So why didn't it work? It took me days to find the little
statement buried in the early part of the documentation: you have to hit
the voicemail or intercom button *before* lifting the receiver. Once you
pick up the receiver, its too late.
It is not reasonable to claim that by nailing a bunch of boards together
you'll end up with a house. Even an ugly house with a leaking roof.
It seems to me Andrew is protesting the practice of taking the details of
tech comm, whether page design, organization, or tool usage, and using them
as an **excuse not to produce actual writing**. That's a valid protest.
(Although I would argue that just because certain details are discussed
regularly on this list doesn't mean that any one person is fixating on them
and losing sight of the whole picture.)
What's not valid is to claim that throwing words on a page is the only
worthwhile activity of a tech writer.
What's not valid is to claim that employers want a bunch of words and don't
care about what they say.
Sella Rush mailto:sellar -at- apptechsys -dot- com
Applied Technical Systems (ATS)
Silverdale, Washington
Developers of the CCM Database
Demo: www.apptechsys.com/demo