Re: What to look for in a technical editor

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

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

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.

--Rick Lippincott
Lockheed Martin
Saugus, MA


Robohelp X3, from eHelp, lets you quickly and easily create
professional Help systems for all your Windows and Web-based
applications, including Net.

Order RoboHelp X3 in May and receive a $100 mail-in rebate, PLUS
free RoboScreenCapture and WebHelp Merge Module.

Order RoboHelp today:

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 for more resources and info.

Previous by Author: Re: Word to PDF
Next by Author: RE: Style - Arms Length
Previous by Thread: RE: What to look for in a technical editor
Next by Thread: RE: What to look for in a technical editor

What this post helpful? Share it with friends and colleagues:

Sponsored Ads