Re: Value of technical writers - Sort Of.

[Bernie McCann <BernieMc -at- AOL -dot- COM>]

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=