TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Last Word from Here re FE/EIT (semi-long) From:George Mena <George -dot- Mena -at- ESSTECH -dot- COM> Date:Fri, 8 May 1998 11:27:12 -0700
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
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
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
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:
Method of Solution
The Mechanics of Materials
Stress and Strain
Thin-Walled Pressure Vessels
AC Circuits / Single Phase
AC Circuits / Three Phase
Static Electric Fields
Static Magnetic Fields
The Periodic Table
General Trends in the Periodic Table
Atomic Structure and the Properties of the Elements
Properties of the Family of Elements
Thank you all for your time and your contributions. =D
Technical Writing Consultant
George -dot- Mena -at- esstech -dot- com