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: H/W v S/W difficulty From:Richard Lippincott <rlippinc -at- BEV -dot- ETN -dot- COM> Date:Tue, 15 Nov 1994 13:39:07 EST
Jan Boomsliter said:
>It never made sense to me that hardware writers were put on a pedastal
>(by software writers, and others, in hardware or hardware-and-software
WOW! Do I wish I had sent a resume to -your- company this time last year.
I was job hunting in the metro Boston area, thus most of the opportunities
were in software documentation. I continued to run into an attitude of
"Oh, you wrote (shudder) hardware documentation. Well, I suppose we can have
the office disinfected after you're done with the interview."
>I think hardware is a piece of cake; you can get your hands on it.
Not when your hardware is flying night-strike missions over Baghdad, a
problem I faced in January and February 1991. (Actual conversation summary:
"Rick, we need you to revise fan blade erosion limits due to the sand
problems on the engine." "Sure boss, show me a fan blade." "I can't, it's
In another case, I was required to complete an aircraft structural repair
manual a full nine months before the first aircraft rolled out the hangar
door. There simply was -no- hardware to look at.
Jan's statement -could- be turned around: "I think software is a piece of
cake, I've got a computer at my desk and it runs the software." Is this
a fair statement?
>Understanding software requires more than general knowledge.
In order to write documentation for transport aircraft, I had to become
knowledgable in structures, corrosion control, non-destructive inspection
methods, electronics, aerodynamics, hydraulics, and sheet-metal work. In the
morning, I might be writing about an engine start procedure, in the afternoon
I might be tracing through a multi-sheet wiring diagram in order to figure out
what happens when a flight computer receives a specific input. When I walked
into that job, my knowledge of aerospace was far above "general knowledge,"
I quickly learned that it wasn't even close to what I had to master in order
to do my job.
(Honest, Jan? A -pedastal-? Woof. Does that mean you'll buy lunch?)
rlippinc -at- bev -dot- etn -dot- com