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: Developers From:John David Hickey <jdavid -at- FARABI -dot- COM> Date:Thu, 17 Dec 1998 16:14:47 -0500
> 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?
I remember posting advice about this entitled "To aspiring Technical
Writers" to this list a week ago, but I guess I should'nt have limited my
target audience so much. All of us run into this at one time or another.
When my SME did this on a draft I gave him, I considered each grammatical
"suggestion" he made, but ignored most of them. Like others have mentionned,
the SME may not be qualified to write, so you need to make a judgement call
on the edits. But don't just ignore them all flat out... He may have noticed
a honest-to-gosh error.
My SME also made some structural suggestions. In my professional opinion,
these structural changes were not good suggestions, so I ignored them. But
because they came up alot, I decided to discuss them with the SME. Notice, I
said "discuss" and not "confront".
And we worked it out between us, although we had to agree to disagree in the
end. And there were no managers involved and no petty arguing. Be tough, but
consider where the criticism is coming from.
Developers can get tough to deal with sometimes, but if you deal with them
calmly and rationally, you'll get much farther ahead. In actual fact, if it
comes to blows, it's your project leader who makes the final decision.
That's what I'm thinking when I choose to ignore a suggestion to make
everything more passive. "But PL, I asked him to check the technical
accuracy of the document and he tried to correct my grammar." In the end, if
the developer pushes too hard, s/he's gonna look like the idiot.
Be Stubborn, Wise, and Comprimising.
Be seeing you,
Lone Writer at Farabi Technology Corp. (Montreal, Quebec)
They say the pen is mighter than the sword.
But if you miss a deadline, you'd better bring the sword.
Do not confuse my opinons with my employer's.
Each exists in blissful ignorance of the other.