RE: What to look for in a technical editor

["David Locke" <dlocke -at- texas -dot- net>]

What I want to see in a technical editor is twofold: the ability to make
style decisions rather than choices, the ability to enforce those choices,
communicate those choices, and review those choices only when the
environment for the decision has changed; and the ability to improve my
writers.

I have only worked two places where we had writers. In the first place, the
editor would oscillate through style choices like no tomorrow. As a writer,
you couldn't count on your stuff getting through the editor, because the
editor changed their mind constantly. The next editor there focused on
making us better writers. I could go to her with a messy issue and we would
talk about it. She would ask a question. I would go away and write a better
passage. She was the best editor I ever worked with. By improving the
writers, she improved the writing. In the second place, the editor would
have made a perfectly good editor at a general publisher. She would enforce
the MS style guide, so her incursions into the technical created more
problems than they were worth. I had to review her markups before the
writers applied them and we would have to discuss the markups, because most
of them made things worse, not that she changed technical content. Policy
edits were the main point there. Even so, my department had different
agreements with the lawyers than the department whose content she normally
edited. Having our own style guide would have cut through some of these
problems. So I'll take the blame for those issues.

Know that there is a difference between an editor and a technical editor.
Believe what you want about the technical content or not issue. Absent that
an editor and a technical editor are still not the same.

It's a matter of where you work and what your processes are that determine
what the editor will do. I expect my writers to validate what they are
writing about as or before they write it. If my writers validate the
operation of the software, then the editors don't need to. And, I expect the
writers to be accurate, so that the technical reviewers only find things
that the writers couldn't see during validation like loading a memory
object, and then loading the GUI from the memory object rather than the
source of the values directly. Validation can uncover this behavior, but not
if you've never seen it in your product line before. Anyway, the technical
review comments shouldn't affect more than 5% of the content. And, I expect
that my writers learn write, on the mechanics end of the job, like the
editor expects. A redline is more than a change that needs to be made to the
text. It is an opportunity for the writer to improve. The writer must see
the redlines if they are to improve themselves.

I remember when I was an editor in a high volume editing shop. We were the
publishing arm of a huge organization where the SMEs were engineers and
scientists. The editors were, typically, former school teachers who had no
technical background. I am not arguing this. This was real world. We fixed
mechanics. We did not alter technical content. We controlled the text. The
technical author never touched text. There were times when we changed things
to improve them only to have the engineers direct us to put it back the way
it was. This was not due to the injection of technical inaccuracy. It was
more a matter of expectations and technical review processes. That was real
world as well. The documentation was secondary to a culture of training, so
the content distributional strategy was to focus on training and not on
documentation as a means of reducing training. The management established
the processes and the skills distribution. It served the purpose.
Organizations will determine those purposes and processes.

I usually work in startups. You are it. Once they get big enough for an
editor, I've been there too long. If I have to hire an editor, I know which
editor I will hire. Experience taught me what to look for. Soft skills
always matter.

David



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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: http://www.ehelp.com/techwr-l

---
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.