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.
I'd like to add that even when you find a patient SME, they can
sometimes be obnoxious bullies, especially when they're stressed.
I agree with a lot of what Ned said about having a technical bent of
mind if you're doing technical writing, and being careful with the
content: simplification and/or tidying can produce incredibly
incorrect or incomplete statements. It definitely wouldn't hurt to
have a background in the field you're writing about, and would make it
much easier to deal with SME's and get your work done. But it wouldn't
be absolutely necessary under all conditions.
Good luck,
Kathleen
On Wed, Apr 9, 2008 at 9:33 PM, Ned Bedinger <doc -at- edwordsmith -dot- com> wrote:
> 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 kathleen -at- writefortheuser -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit http://lists.techwr-l.com/mailman/options/techwr-l/kathleen%40writefortheuser.com
>
>
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/ for more resources and info.
>
>
>
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-
