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:Re: What to look for in a technical editor From:Rick Lippincott <RJLippincott -at- compuserve -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sun, 18 May 2003 09:25:41 -0400
Andrew Plato:
>I would even go so far as to say that an editor lacking subject matter
>expertise can actually CAUSE more problems then they resolve. In the process of
>imposing stylistic consistency and "readability" a content-ignorant writer
>could change the meaning of the document, thus causing information to be
>misleading or inaccurate.
Andrew has a good point...but I'm not sure he goes quite far enough.
I think another aspect of the problem is that we're looking at this from the
wrong angle. We're talking about a "technical editor." The image this gives to
me is a person who sits at a desk, reviews the copy, and (supposedly) marks
up the technical errors. An editor who is concerned with technical accuracy.
The problem is, the quest for technical accuracy shouldn't be left to a person
called an "editor." You really need an entirely separate role, with an entirely
separate name. Take the word "editor" out of it so that there's no confusion
or expectation that the person is expected to do -any- type of language or
style checks.
What you are actually seeking is a separate position, one that I call a
"validator." The validator won't be looking at spelling, grammar, or style.
The editor won't be looking at technical accuracy.
The validator's role in the process is to take the draft copy, and perform a
set of specific, clearly defined tests to ensure that the procedures work as
written. In the case of software procedures, the validator logs onto a test
system and actually runs through the procedures. In the case of hardware
procedures, the validator gets access to the hardware and the necessary tools,
and physically does the procedures. This is known as "validation by
demonstration."
Validation by demonstration should make up the bulk of all the testing done
on the docs.
In some unique hardware cases, it may not be possible to do tasks such as
component removal and installation, but a detailed, on-site thorough examination
coupled with a step-by-step review of the procedure can often serve to confirm
the accuracy of the procedure. This is known as "validation by simulation."
And in some hardware cases, items such as tolerances, inspection limits, and
repair methods might be best determined by a line-by-line review against the
original engineering data (the blueprints). This is known as "validation by
comparison."
On completion of the validation, the writer gets back a series of clear,
specific, and detailed review comments for incorporation into the text. If the
validator has a background in technical communication (which is ideal), there is
a reasonable assurance that the comments will be in fairly good shape regarding
style, format, grammar, spelling, and the like.
This is actually a concept that I've done for a number of years, and introduced
with some success at two companies. I'm actually surprised that it hasn't been
more widely adopted. From my experience, it's the best way to ensure that the
docs work as written.
The key difference between the technical editor and the validator is that there
is an implication (at least because of the name) that a technical editor will
mainly work at a desk, conducting a passive review. A validator, on the other
hand, is a more active reviewer, with more hands-on involvement and physical
participation in the process.
What to look for in a technical editor? Don't look for one. Look for a validator.
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
