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.
Ali Ferguson wrote:
> Hi all-
> I sent an email out a few days ago about my pilot study for technical
> editing (see below). Please, please help me! I need more responses in
> order to develop a good questionnaire.
Glad you asked, now I can get this off my chest. Sorry if it isn't what
you're looking for, but every word of it is true and I expect you to
take it to heart, share it with your class, acknowledge me as the
source, and never pretend you were never told.
Variable:
Your variable is "direct experience or study in the technical field
where you want to work."
The minimum, to me, is a degree in the technology you'll be documenting
or editing. Direct experience isn't more valuable than study, but can
qualify you if, for example, you went to work instead of college, or
changed careers after college.
Explanation:
Documentation is NOT fundamentally about writing and editing skills, so
your training should, likewise, not be fundamentally about those things.
Documentation is 95% (to pick a number) about the subject that is
being documented, and to that same degree, about understanding the
subject matter, and being able talk efficiently and productively to
experts in the the subject. Writing it all down correctly is hard
enough, but having to do so without understanding it will turn you into
a criminal. The penalty is real and tangible, described below.
If I were to undertake your implied challenge, and design a class of
technical documentation workers, I'm afraid I have bad news: I would
turn the existing standard on its head. My inverted standard would
eliminate candidates who want to be a language person who edits or
writes, but have no interest in becoming a technical person.
The base requirement would now be FIRST that technical editors
demonstrate technical aptitude not just for language, but for ENGINEERED
systems, which is a whole 'nother thing apart from an aptitude for
language, IMHO.
Thus, the course of study for technical writing and editing would focus
on math/science/engineering. You'd have a double major when you add in
the usual requirement for coursework in instructional design and language.
Do you get my drift? The work is about the naked subject matter.
Though your contribution will be to dress it up in language, your
background has to position you to understand the subject matter first.
Otherwise, you're going to end up drawing on your langauge skills too
much ('this word or that synonym' decisions), making millions of
suggested changes, over the course of a career, that don't account for
the specialized context in which language is applied. An immaculately
written and edited document that is technically wrong has no value.
Please don't get me wrong and think I'm saying something like "Technical
editors have to be engineers first, and only then could they take over
the engineer's editing duties. You don't have to be a certified
engineer, though being fully qualified as an engineer wouldn't prevent
you becoming an editor.
I realize that curious people have to study a subject before deciding
that it really isn't a career for them. Those Math/Science/Engineering
students who decide they'd rather work the words than the numbers are
the editors and writers I would likely hire first.
That's one side of the coin for me, which I think of as "predictors of
success."
The other side is ultimately about how you can make yourself comfortable
and at home in a technical workplace, over the long haul. In this view,
the workplace is where you go and spend 8 hours a day doing the actual
work of writing and editing. I am concerned with how you fit in, how you
are seen, respected, and responded to by co-workers.
I'd be open to variations on background and education if you could
convince me that you will work out well on this side of the coin, but
I'm pretty well convinced that technical workplaces attract technical
people and are healthy for technical people, but are not really any
place worth being if you don't have the inner gee.
I say this because I know that even the most mild mannered nerds, the
ones who wears Hush Puppies, pocket-protectors, calculator belts, and
fanny packs at the office, have an inner beach bully who will kick sand
in your face if you don't understand what s/he's saying to you. When in
Rome, do as the Romans. You're on their beach!
When they have to explain everything to you, as a prerequisite and a
requirement for you to begin to effectively produce edited copy, you'll
find out just how asleep their bully was.
And once you're known this way, getting those explanations will become
much harder for you.
Being cut off by your SMEs is a stress that a qualified technical editor
might never feel, even in the course of a career. If it has come to that
for you, consider yourself to be out in the scrub brush, off the track.
You have to take responsibility for it.
I think many technical writers and editors today, many of whom were
hired according to their title and not their qualifications, have
changed careers rather than face that kind of stress for long. It can be
debilitating, a problem that leads to burn out, which is probably how
most of the changelings came to the decision to get out.
Most employers would not let it go on for long in any case, though I
think most realize that in the short term, SME-induced stresscan be a
powerful motivator that awakens critical thinking skills in anyone,
especially those qualified writers and editors who haven't kept up with
the changing context in which the rest of the technical staff is working.
If you love your work, in the sense that Joseph Campbell used to say
"Follow your bliss", then keeping up with the engineers is fun for you.
We all, and some more than others, fall behind and suffer from overwork,
distractions, and boredom with our jobs; but when it is a chronic
problem, you'll be unhappy enough that punching out seems like a great
idea. Do it, is my advice. And don't even start down the technical
editing road if you aren't blissed by these ideas.
I mean every word of this as positive reinforcement for those people who
are good candidates. To them I say "See you on the job." To everyone
else, it's "See you on the internet."
Boy, I feel much better now. :-)
Ned Bedinger
doc -at- edwordsmith -dot- com
>
> "I am currently doing a pilot study for my Technical Editing Class. I am
> interested in knowing what practicing technical editors believe are the most
> important skills/qualities necessary for becoming a successful technical
> editor. For this question, please just provide a brief response about what
> you think are the most important skills a technical editor must possess.
>>From the answers to this open-ended question, I will then identify the
> variables for successful editing and develop a more fine-tuned survey."
>
> Thank you in advance!
> Ali
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
