Last Word from Here re FE/EIT (semi-long)

[George Mena <George -dot- Mena -at- ESSTECH -dot- COM>]

Folks, we've had some very worthwhile contributions on what it means to
be a technical writer.  Here are the ones that rang true for me:

From Mark Baker:
We *create* information products on the use of technology.  We are part
of the research and development process, not an afterthought or an
add-on.  We are co-creators with the engineering staff, not translators
of their solo creative effort.

From Robert McMartin:
We are all part of more than one culture, we can converse with the
engineers/programmers in language that they understand and we understand
how they think.

From Janice Gelb:
In fact, some of the information often isn't in *anybody's* head until
the writer thinks to ask a question and someone has to solve that
problem. In no way is a scenario like this translation -- it's, as
someone else put it nicely, "getting into the user's head" and providing
them with information accordingly.

From Kathy Stanzler:
I agree that it really makes no difference WHAT you're documenting...
What we do really does make or break the product, whatever it may be,
because without good documentation, the user can't effectively use the
product, or can't use it at all.

From Bill Swallow:
I not only write, but I also design the document, envision the online
interface, design the interface, build it, create all the graphics,
perform the usability testing and monitor the installation of the
product.

From Christa Hutchings:
AND develop documentation plans and sell them to management.  AND create
or otherwise obtain illustrations and graphics, AND interview and hire
contractors and other TWs when needed, AND decide on bindings, print
shops, etc., AND work with manufacturing to develop a process for
getting the printed manuals or CDs in the box with the product...

===

To understand the language the engineers and the programmers understand
is also part of being a technical writer.

To close out my original contentions on tech writer-in-training
programs, I'm including part of the Table of Contents of the book
"Fundamentals of Engineering Review", 2d edition, edited by Merle C.
Potter (Great Lakes Press, copyright 1986; ISBN 0-9614760-0-3).  This
book offers a complete review for the Fundamentals of
Engineering/Engineer-In-Training (FE/EIT) examination.  "The objective
of the review is to pass the Fundamentals of Engineering examination...
your first step towards becoming a registered engineer," Dr. Potter
writes in the preface.  "The point is not to gain once again a
proficiency in all those subject areas that you have not been directly
involved with."

I believe that for us tech writers, this means not to go back and rehash
how to develop document plans, create PDFs and the like, but how we make
sure we have an understanding of some of the core competencies our
subject matter experts (mostly the engineers and the programmers) have.
This way, the engineers and the programmers will feel like they're
talking with someone who can actually understand what it is they're
trying to say.

Mike Huber is right when he says "Some companies will have high or
unrealistic expectations..."  And while he's also correct when he says
"what is enough is what the particular employer is willing to settle for
and what the particular writer can learn,"  I find a better question is
not necessarily "What can we learn?", but rather "What should we already
know?"

But enough talk.  What's presented below is some of what engineers in
different fields must know as they pursue their goals of becoming
registered engineers.  Let's use this as food for thought in developing
a realistic framework for what the registered technical writers of
tomorrow must also know.

Here's the excerpt:

====

Computer Science
        Analog Computing
                Method of Solution
                Time Scaling
                Magnitude Scaling
                Operation Modes
        Digital Computing
                Number Systems
                Combinational Logic
                Sequential Logic
                Operating Systems
                Programming
                Data Communications

The Mechanics of Materials
        Stress and Strain
        Beams
        Torsion
        Columns
        Combined Stress
        Thin-Walled Pressure Vessels
        Composite Sections

Electrical Theory
        Circuits
                DC Circuits
                AC Circuits / Single Phase
                AC Circuits / Three Phase
                DC Transients
        Static Electric Fields
        Static Magnetic Fields
        Electronics
                Diodes
                Op-Amps

Chemistry
        Atoms
                The Periodic Table
                General Trends in the Periodic Table
                Atomic Structure and the Properties of the Elements
                Properties of the Family of Elements
                Molecules
                Chemical Reactions
===
Thank you all for your time and your contributions. =D

George Mena
Technical Writing Consultant
George -dot- Mena -at- esstech -dot- com