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:FWD: (Writing and) Editing as a career From:"Eric J. Ray" <ejray -at- RAYCOMM -dot- COM> Date:Tue, 13 Jan 1998 13:46:47 -0700
Name withheld upon request. Please reply on list.
*************************************************
Hey, fellow techwhirlers,
I could use your wisdom and feedback.
In my experience, I've found that many tech writers are expected
to edit their own work. Does this match your experience(s)? In my
current position, I have been instructed to edit all my own work and
submit it in a publishable state before it goes out for (subject matter
expert) SME review. We have a final step where another writer is
supposed to proofread the document, but this is after everything else
has been done. I've tried to get another writer/editor in on the
process earlier, but I've been unable to convince my department of the
value in this. While I definitely agree that a writer should strive to
edit their own work and submit it in a clear, presentable state,
submitting it in a publishable state before the technical review seems
an arduous standard to achieve, and an ill-use of time if/when the
content changes based on that review.
Also, I have been absolutely unable to communicate the idea of
drafting (i.e. working drafts) to many supervisors. So, I've just
accepted that in order to considered a good writer I must be a good
editor, too.
> Editing requires an entirely different mindset than
> writing, and you won't find many people equally good at
> both.
[snip]
> my job is to misunderstand darn near anything a normal reader would
> eventually figure out, figure out what the problem is, and
> fix it...what it means is that you have to be able to adopt
> a certain naivete towards what you're editing: as soon as
> you become proficient with the material, you start making
> the same mistakes as the author (i.e., you automatically
> understand things your readers probably won't understand),
> and it's tough to be able to distance yourself enough from
> the material to be a reader advocate. In a nutshell, that's
> editing.
This type of edit does not get done in many circumstances. When
I try to work on this type of "Does it make sense?" edit, I've often
encountered the attitude (akin to a brick wall) that if it matches the
current style that is all that matters. This is sort of like, "Well, if
it looks like documentation (because all the styles match), it must be
documentation." Perhaps this is a bit harsh, but I wonder how common
this type of documentation environment is? Have you encountered the
same thing? Is it/was it a matter of too little time in the project
schedule that created the situation?
TIA