Re: SACRED COWS

[Chris Welch-Hutchings <chutchings -at- NORDSON -dot- COM>]

John Gilger writes:

>It is easier to teach an engineer to write than it is to teach a "writer"
or
>"technical communicator" to understand and explain engineering principles
>and technology.

>If you want to be a good, well-paid, tech writer, get a BSEE or BSCS then
>get the hell away from those ivory towers.

I'm not sure I agree with this. I once hired a guy who had a BSEE and MA in
English. Ooh, the perfect TW candidate, you think? Read on:

This guy had been a TW for less than a year at the time and also taught
freshman English at a local college. I was a bit skeptical about his
ability to do hard-core high-tech writing (despite his BSEE), but the
Director of Engineering (my boss's boss and the final authority on hiring)
insisted he'd be a perfect tech writer for us because we were documenting
electronics equipment.

Well, to put it bluntly, the guy was lousy. He wrote like an academic -
long, expository type sentences, etc., and we couldn't get him to
understand the difference between academic and technical writing styles. He
not only refused to heed my suggestions, but would go running to the
Director of Engineering, who would back him on the basis that since he had
an advanced degree, he must be right and I was wrong - it didn't seem to
matter that everyone else in our TW group, plus the Managers of SW
Development, HW Development, Applications Engineering, etc., agreed with
me. Meanwhile, complaints about the usability of our manuals increased.

Luckily, this guy also had a lousy work ethic, finally decided tech writing
was too demanding and after seven months, moved into software engineering
at the same company. He only lasted a year at that position and left to
sail around the world on a tramp steamer.

So the moral of this story is, fancy degrees don't necessarily make a good
tech writer. What's more important (I have found over the years) is the
ability and willingness to learn and dig for information, to know how to
interview engineers, etc., how to structure documents, how to write clearly
and concisely, and also a clear sense that the *user* of your manual is
more important (to you) than the engineers and programmers who designed the
dang thing you're documenting.

Chris



-------------
Original Text