Re: Value of technical writers - Sort Of.

Subject: Re: Value of technical writers - Sort Of.
From: Bernie McCann <BernieMc -at- AOL -dot- COM>
Date: Sun, 3 Jan 1999 14:11:22 EST

In a message dated 03/01/99 1:16:49 AM Eastern Standard Time,
LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU Tom <eagles -at- CONNECTION -dot- COM> writes:

<< And whose fault is that? The tech writer's fault?
Should she become an engineer first? From which
discipline? Electrical? What if her next job is
civil? Should she go back to school again? What if
the job after that involves writing proposals for
a mechanical contractor? Should she buy a gun and
shoot herself or spend her next six years in trade
school to become a plumber/refrig tech/HVAC
specialist to properly cover the bases? >>

One has to assume from this statement that Tom believes that it is not the
fault of Technical Writers, but fails to place any blame. So much that is
written in the English language, is intended to be found "between the lines"
(It is one of the quirks that makes our language enjoyable) but this should
not be the case in technical writing.

If the Technical Writer is a qualified professional, then, it would be her
fault because she should know better, but if she is unqualified to know this,
then, we should blame the person who hired her to carry out the task.

Yes, Tom, if it requires becoming an engineer, or a taking six-year course, so
be it, but in most cases this will be unnecessary. On the other hand, simply
adopting the journalistic philosophy, i.e., It'll be OK as long as I know what
questions to ask, will, undoubtedly, create a poor quality publication.

As I have often said, the term technical writer is frequently misunderstood.
It is (in my opinion) a generic term, and should be used with caution. We
should be known as, either; engineering, scientific, software, hardware or
marketing, etc., writers, and be very cautious about straying into 'terra
incognita'.

Eric's statements are worth repeating:

the technical expertise
that a tech writer needs is NOT necessarily how to code
the application, design the interface, fix the car, or
whatever. It's in having a sufficiently developed
BS detector to tell what's likely to be legitimate and
what's not. All of the (in my opinion inane) engineer
superiority discussions aside, it's fairly unlikely that an
individual who is completely prepared to design a
circuit board or code a database backend is going to
be doing the documentation on the project rather than
doing the project development.
.... and ....
I don't need to know if the
info I get from a developer is completely accurate or
not, at least not on the first pass. I need to be able
to assess how credible the information is and if it
meets the WIML test. If the info sounds like it's from
left field, I've got more research to do. If it's plausible
in the context of the system, application, and technology,
I'm off and running until the first review pass.

(By the way, what is "WIML"?)

Until we come to terms, ourselves, with these definitions, how on earth can we
expect the world of the head hunters to play a useful role in our profession
and, perhaps, teachers to teach (Although I do not consider the latter as a
great problem, currently).

Bernie


From ??? -at- ??? Sun Jan 00 00:00:00 0000=



Previous by Author: Re: Bad translations?
Next by Author: Re: Version/Documentation Control Software
Previous by Thread: Re: Value of technical writers - Sort Of.
Next by Thread: Re: Value of technical writers - Sort Of.


What this post helpful? Share it with friends and colleagues:


Sponsored Ads