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: New slant: professionalism From:George Mena <George -dot- Mena -at- ESSTECH -dot- COM> Date:Fri, 24 Apr 1998 09:49:23 -0700
Dear Jane Bergen,
You write:
How many people have you run into who, when you tell them you're
a technical writer, laugh about "those computer manuals that no one can
understand"? Those are the legacy of early tech writers who wrote mil
specs...
And I reply:
Defend yourself. I object to your statement. In my opinion,
you don't know what you're talking about. From where I sit, the folks
that wrote some of the early computer manuals are the ones who were the
idiots. Speaking as one of those "early tech writers" who once wrote a
lot of mil-spec based documentation, I feel I can tell you're a
Joanie-Come-Lately to this business. I say this because I feel your
position is based in ignorance. And I have no patience at all with
ignorant people.
To enlighten you, most mil-spec based documentation must be
clear, concise and easy to read, as the audience is typically comprised
of enlisted men and women, most of whom have only a high school
education. Only a few have a couple of years of junior college under
their belts, and even fewer actually finished college.
You need to understand that the mil-spec documentation you
denigrate is not only used to maintain and repair a major weapon system,
but that the documentation is also used in training classrooms at
American military bases around the country. The mil-spec documentation
in fact performs double duty as both textbook for the student and
technical reference manual for the experienced bench test technician,
especially the ones who have *volunteered* to serve with pride and
distinction in the American military.
You also need to understand that before *any* technical manual
on military hardware is ever released to its audience, it is subjected
to the most stringent type of usability testing imaginable. This
usability testing comes in the form of validation and verification
(val/ver) reviews. These reviews, which are held at military
installations where the hardware is actually used, typically last a
minimum of two weeks. Attendees include the manufacturer's
representative, civilian engineering representatives from the
organization responsible for depot-level maintenance of the hardware,
the enlisted men and women who must actually work on the hardware and
the technical writer handling the manual's creation or revision.
The val/ver review must, by design, take at least two weeks. It
takes that long to go through *every* word, *every* paragraph, *every*
piece of art in *every* chapter of the manual. Further, *every*
assembly procedure and *every* test and troubleshooting procedure is
actually performed by the enlisted men and women whose jobs it is to
make sure the hardware is kept up and running for field use.
Also, the val/ver review does not end at 5 o'clock, especially
if the civilian engineer and the tech writer decide to get together over
dinner to discuss the day's specifics, as I did with my engineering
contact. I made sure that I got together with the civilian aerospace
engineer from Alameda Naval Air Station for dinner to hammer out a lot
of things that had been discussed. These were working dinners which
often also saw us carry over the discussions past dinner to the hotel
rooms we had.
When the val/ver review is concluded, the real work begins back
at the office. The engineer I worked with started to figure out how to
achieve cost savings to the Navy (and, by extension, to American
taxpayers, which we were and are) by taking the very hard and very
serious examinations at large subassemblies of the hardware. Some of
the large subassemblies had been labeled as "throwaway" items. Upon
further examination, however, it was discovered by the engineer that
these "throwaway" items could in fact be refurbished by base personnel
in the machine shops!
Being the excellent engineer he is, Mike got on the phone to me
and started filling me in on what he had found. He asked me how hard it
would be to get this additional information into print. Being the lead
writer on the project, I told him there would be no problem with that
and got my supervisor to reluctantly agree with it (he was hoping our
flexibility and versatility would help keep our company in good stead
with the Navy, a good business practice).
By the time we were done, we had a manual that actually made
sense to the great North American bluejacket on every aircraft carrier
in the Navy, and a system known as an air refueling store assembly could
now be properly maintained and repaired at last. (An aside: an air
refueling store assembly, also known as a "buddy store", allows a
carrier-based jet to act as a flying gas station for other jets to
refuel in-flight. A pretty necessary commodity on a long mission, the
B-25 bombers that flew off the deck of the USS Hornet in April 1942
could've used a flying gas station so that they could've avoided
crashing into the Sea of Japan four months after Pearl Harbor had been
bombed by the Japanese. The mission was to bomb Tokyo, which these
brave men did. Those who survived and who were able to crash land on
mainland China instead wound up being delivered by the Chinese
Resistance to Claire Chennault's Flying Tigers so they could fly and
fight again. And Col. Chennault needed every combat plane, fighter or
bomber, that he could get his hands on. A full squadron of B-25's
would've been very welcome.)
As both a technical writer and as an Air Force veteran, I find
your statement completely offensive, Jane Bergen.
No apology you might consider rendering will ever be adequate
enough to suit me, so don't try to give one.
George Mena
> -----Original Message-----
> From: Jane Bergen [SMTP:janeber -at- CYBERRAMP -dot- NET]
> Sent: Thursday, April 23, 1998 9:07 PM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Re: New slant: professionalism
>
> Well, since I spun off this thread, I'll jump back in. My
> flame-retardant long johns are holding up pretty well so far.
>
> On Thursday, April 23, 1998 2:40 PM, Lisa Comeau
> [SMTP:lmcomeau -at- HOTMAIL -dot- COM] wrote:
> > I think Dick has a valid point, but, realistically, how many
> > companies
> > are going to be willing to PAY for a person who understands ALL
> > facets
> > of the technology they are writing about, AND can communicate the
> > information they know to others with absolutely NONE of the same
> > knowledge?
>
> I think Dick made some valid points. How many people have you run
> into who, when you tell them you're a technical writer, laugh about
> "those computer manuals that no one can understand"? Those are the
> legacy of early tech writers who wrote mil specs or who understood
> the technology but failed as communicators. In my experience (maybe
> I'm just fortunate to live in a city that worships technology [tongue
> in cheek, folks]) more and more employers are realizing the value of
> good documentation (including online help, web-related help delivery
> systems, etc.) and are willing to pay for it. Tech writers are having
> a heyday here in Dallas right now.
>
> > My current situation is that I don't have a communications degree,
> > but I
> > do have a Bachelor of Arts with a major in English, minor in
> > sociology ,
> > an Information Technology Specialist's designation, and have been
> > instructing computer applications for 2 years. Now I am an
>
> (snip)
>
> > Does that mean that I am not a technical writer because I don't
> have
> > a
> > degree, or does that make me a professional tech writer because I
> > take
> > more pride in my work than a diploma?
>
> If the necessity of a degree is all that you inferred from my post,
> then I failed as a communicator. It's not about "a degree" but rather
> about approaching technical communication as a profession rather than
> a job where you learn while you're doing it. It's possible, and quite
> a few people do it, to do the same thing the same way for thirty
> years and call yourself anything. But as I said before, the proof is
> in the product. If it's good, then great. I just have not seen that
> to be true in my lifetime.
>
> So no, Lisa, you don't need a degree in technical communication to be
> professional, but you do need to keep learning and growing. There are
> other avenues that I mentioned (conferences, workshops, etc. for
> example). It's not always comfortable or convenient, but that's what
> people do to be considered professional.
>
> Wayne Douglass said "If this is what it takes, I'll keep my amateur
> status" in response to my original post. I'm not sure what exactly he
> objected to, and he's probably not the only one...but it's not about
> "amateur status." It's about those of us who care enough to make the
> effort to further technical communication as a profession rather than
> a job that a secretary can do (which is what started this whole
> snowball anyway) and to make it easier for ALL of us to get paid and
> treated like professionals.
>
> Jane
> Jane Bergen, Technical Writer
> (writing from home so a different email address)
> janeber -at- cyberramp -dot- net
>
> &^~~~
> Send commands to listserv -at- listserv -dot- okstate -dot- edu (e.g., SIGNOFF
> TECHWR-L)
>