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: Reading a draft "for content only" From:"Less is more." <yvonne -at- VENUS -dot- SMARTSTAR -dot- COM> Date:Thu, 9 Feb 1995 09:31:33 -0800
Vince Putman <PUTMV -at- MAIL -dot- SYNTRON -dot- COM> said:
> Hey Rosemarie, and all others who fail to acknowledge the folly of
> *developers*, of any heritage, of any education, for any reason, who
> edit sentences when they have been asked to review for technical
> content. That's what Glen, myself, and many others have been trying
> to communicate. This issue is absolutely central to our profession.
... flame omitted ...
> If your job is to edit
> the English content given to you, then you are not the developer, and
> you should not edit the technical content. Likewise, the developer
> needs to leave the grammar to you and review for content only. Clear?
Often I don't get much English content to edit, just some software to try out.
So, I do edit the technical content, and I do make comments to the developers
about changes I believe should be made to the technical content. No, I am not
a developer, but I am responsible to help my company create the best product
(software and documentation) possible.
If developers find grammar problems, I'm secure enough to listen to them and
either fix it or explain to them why it isn't a problem.
Saying that developers can't comment on certain parts of a document fosters
an "us vs. them" attitude that isn't productive. Documenters and developers
are interdependent. Things work best if we all respect each other's opinions
and expertise. By that I mean that the person with the expertise gets final
say (doc on doc issues, devlopment on development issues), but expressing
opinions should not be restricted.
If you foster an environment of mutual respect rather than of mutually
exclusive responsibilities, you can convert those developers who nit-pick
grammar for negative reasons like resentment. Unless you work in a mil-spec
environment (not the ideal setup, IMHO), you don't need to prevent developers
from spotting the occasional typo.
