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: You Don't Need to Know How From:edunn -at- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 26 Jul 2001 17:17:27 -0400
>>BTW: just to get in on the simple appliance, simple documentation act.
>>Just suppose that certain properties of microwave are not known world wide.
>>You can write up how to set the timer, how to defrost, how to cook popcorn.
>>But what if the technical geniuses in the lab never bothered to mention what
>>happens when you leave the aluminum foil on? Wouldn't a familiarity with
>>microwave technology be useful here?
Sorry, but we're still in the "it depends" category.
Can everyone on the list please repeat after me:
"It depends. Everything depends. Techwriting is a diverse field. Many of the
4000+ writers on this list each have a unique scenario in which they work. No
analogy can be applied to every situation, application, field, or techwriter."
For example, the term "microwave technology " covers one enormous piece of
ground. Nobody on the list has ever claimed that they don't need to know/learn
enough to use a product and communicate all the required details to the users.
If you were documenting the very first microwave oven and the guys in the lab
don't tell you not to put metal in it, you might only find out if you run tests
by putting things in the oven (the first time you reheat your coffee while
writing the docs and accidentally leave your spoon in the oven). The designers
and engineers may never have even thought about whether foil should go in the
oven or not. Initially the only way anybody knows how things work is by testing.
If the writer was in on the development of the oven and knew all about
magnetrons and microwaves, then I'd be hard pressed to understand why they
weren't engineers.
Of course "a familiarity with microwave technology" would be useful, but where
are you drawing the line in this example? Probably at a fairly simplistic level
on the face of it. You'd be documenting the interface. What buttons to press,
what input to put in, what output to expect out. The "code", or how microwave
energy is produced and correctly distributed in the oven, doesn't necessarily
have to be in you knowledge base. You can even know to replace the magnetron and
document the procedure without having any understanding of what it does or how
or why it works. Knowing not to put foil in the oven only puts you at about
equal with the average user, hardly advanced in the field.
I mean, it would be "useful" to have a helicopter to commute to work when
there's a traffic jam. Does that mean I don't bother to drive in because I
"NEED" a helicopter? No. Because I commute with my car (an inferior mode of
transportation), does that mean I don't keep trying to finally be able to get
the helicopter? No. (and I think the analogy of too much knowledge is like
getting a Formula 1 car to get to the corner store for milk has already been
used.)
Let's all take the oath to never use an analogy to try to prove some wide
ranging idea, could we please?
Specifically speaking, "Propulsion Technology" is one of the things I write
about. No matter how much you might want to protest, I do not need to learn how
to program the software or how to build an IGBT inverter. Nor do I need to learn
particle or nuclear physics to describe how electricity transformation works and
why exactly it's not a good idea to touch live 15-25 kVA terminals. Nor do I
have to have a medical background to know exactly why touching the terminals
will kill you.
For cripes sake, the only thing anybody has ever said against techwriter
knowledge (and once again I raise my challenge for someone to say/prove
otherwise) is that at some point you've learned enough to document what you have
to document, for the audience that you're trying to reach, with the budget and
deadline you have to meet.
Seeing as nailing down both the "what's being documented" and the "who's the
audience" for all of Techwr-L are each about as easy as nailing fresh pudding to
a wall, it's absolutely pointless to try and come to some conclusion involving
both variables (let's not even consider the folly when all the myriad other
variables are added).
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Learn about tools and technologies for user assistance developers at
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.