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:Developers who think they're editors? From:"Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA> Date:Thu, 17 Dec 1998 09:53:52 -0700
Leona Magee-Dupree reported <<I gave a copy of instructions to a
developer and the developer ignored the instructions and changed the
sentences from active to passive. The developer tried to edit the
documentation. What does a technical writer have to do to get
feedback about the accuracy of a document and not "tid bits" of how
to write from someone who does not know how to write? Why do
developers do this? How should we react?>>
As I've noted before, some people simply don't like reading
instructions (it's simply not the way their minds work) and must be
approached verbally, in person, to get them to understand the
process. You may simply have a failure to communicate (i.e., the
developer doesn't understand what you require). Even when developers
do understand, it's natural to want the text to reflect their style
of writing. Technical writers and editors are by no means immune to
this desire, by the way. The important thing is to reach an
understanding that style will be fixed only once the information is
accurate, and that only the developer can check the facts.
Your reaction should always be diplomatic: First, examine the
corrections, and figure out why they made the correction. Often
you'll find a reason, and you can incorporate a change while still
preserving your style. After all, once you've stared at something
long enough, it sometimes seems perfectly logical to you--but to
nobody else in all creation--and only these comments will reveal this
problem. Second, where changes contradict corporate style guides,
simply explain that it's long since been decided that (say) passive
voice will no longer be acceptable. Most people eventually learn
which battles they can fight and win, and fighting corporate policy
isn't one of them. Third, explain that you're perfectly happy to
accept suggestions for revisions, but that reviewers are wasting
their time (and yours--but don't mention that) trying to fix things
that simply won't be fixed.
If the problem persists, you may have to speak to the person's
supervisor, but that's a last resort because it risks destroying your
future relationship with the developer and making things even worse
than they are now.
--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca
