RE: Not Technical Enough

[Dan Emory <danemory -at- primenet -dot- com>]

I'm inclined to agree that this thread has run its course.
But then I see that the thread which is arguing about the
amenities, hotel costs, and architectural aspects
at the recent STC conference continues unabated.

What got me riled were several ongoing threads. One about
how newbies should become qualified by taking a
couple of courses in tech writing (even on-line courses).
Another ongoing thread discusses how some tech writer
took offense that a lowly marketing type had the nerve
to ask the tech writer for her work product to produce
some marketing fluff. Another continuing thread discusses
the difficulties writers have in getting information from
the technical types who create the products. I held my
tongue.

Then this thread popped up. I restrained myself until several
English Lit types began spouting off about their superiority
over writers with technical backgrounds. And Sarah
O'Keefe, you did cross the line, even though I may
have paraphrased what you said to carry it to its
logical conclusion.

People who exclusively write Policies and Procedures manuals
are not technical writers, they're Policies and Procedures
Writers, who, if they're qualified, ought to have some kind of
background in Business Administration.

People who specialize in writing instructional materials
(i.e,  training manuals) may or may not be technical writers,
depending on what the subject matter is, and in any event,
they should have a strong background in training.

The job titles Technical Writer and Engineering Writer may be
distinguishable, but both should be reserved for people who write
on technical subjects, and are well-grounded technically.

A good Engineering Writer, in my experience, must be capable
of writing specifications used by engineers to develop products,
and most of them are equally skilled in writing end user
documentation of all types about such products. A versatile
Engineering Writer who produces product test specifications,
for example, ought to excel at converting such specifications
into procedures in end-user documentation.

Perhaps the distinction should be that Technical Writers
only write end user documentation, not specifications, and
they often obtain much of the technical information they need
from product-specific specifications produced by Engineering
Writers. Which explains why good Engineering Writers often
excel at producing end user documentation as well, because
they are experts at extracting information from engineers, and
have a deep technical understanding of the product.

Technical Writers and Engineering  Writers both produce
documents that conform to standards and specifications.
Those standards and specifications may be strictly internal
to the company they work for, but more often also include
standards and specifications that are externally imposed.

Now, in the last decade, large numbers of technical writers
have specialized in end-user documentation describing the
GUIs of software products. Arguably, anyone who has
become computer-literate, with or without a strong technical
background, can qualify as a technical writer on such projects.

On the other hand, between early 1990 and late 1991, I
was a consultant to a company that developed the premier
Mechanical Computer-Aided Engineering (MCAE) software
product, utilizing an X-Windows GUI. The product provides
analysts and designers with powerful geometric modeling and
3D rendering tools, combined with cutting-edge finite element
analysis modeling. Loads, boundary conditions, and materials
properties are applied to the finite element meshes. A variety of
integrated solvers (e.g., structural, thermal, kinetic) are used to
evaluate the analysis model. Post-processing of solver results yields
a variety of visual presentations, utilizing advanced 3D
graphics rendering and animation techniques, to display
the effects of applied loads on the components being modeled
and analyzed.

When I was in engineering school (BSEE), a required course
in my freshman year was Strength of Materials. I wondered
then how I'd ever use that course. Well that course, plus
required courses in Analytic Geometry and Calculus,
gave me sufficient background to do the job. Using an
early version of FrameMaker, I designed a context-sensitive
on-line help system for the GUI (more than 1500 screens), and
produced the initial 500 or so pages that served as the template
for the in-house writers to finish the job. FrameViewer was
bundled with the product to provide users with access to the
on-line help.

My message is this: Those without a strong technical background
who've specialized in documenting software GUIs are going to
hit the equivalent of a gender-based glass ceiling as cutting-edge
software inevitably becomes more and more complex and
sophisticated. And the companies who develop that kind of
software product are the ones who'll need large numbers of
technical writers.

====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.