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:Editing comments too harsh? From:Betsy Perry <betsyp -at- VNET -dot- NET> Date:Mon, 9 Sep 1996 11:35:53 -0400
In my recent performance review, my manager said there have been complaints
about my editing comments being too harsh. ...
Has anyone encountered this problem?
What do you do to *not* tread too heavily on engineer egos?
I've developed a canned speech that I give whenever I hand over a
reviewed document to a software engineer.
"Editing is like code review: painful, instructive, and necessary.
Every working writer gets edited; that includes me, and I don't like
it any more than you do. Whenever I receive an edit, I go someplace
private, read it, and blow my top. The editor always makes at least
one completely unreasonable change that destroys the entire meaning of
a paragraph. Unfortunately, the editor also always discovers at least
one completely erroneous paragraph that has no meaning at all.
"The purpose of an edit is to help make the document more clear; it is
not intended personally, any more than a code review. Go away and
read this, then come talk to me if there are any changes you don't
understand or you'd like to argue with. It's your document; what you
The important point to get across is that you *don't* intend any
reflection on the person's writing; all you care about is clarity, and
your changes are there to improve clarity.
When editing non-professional writers, it is vital to tailor your edit
to the audience. If a document is badly organized, for instance, I may
focus my edit only on organization, and ignore copyediting issues
entirely. After all, if the ideas aren't expressed, it doesn't matter
how bad the grammar is; if a document is intended for internal use
only, spelling matters far less than content. After an engineer
trusts me, I can start teaching him/her about the niceties of
that/which and the serial comma; my first goal is to get his or ideas
her thoughts captured on paper.
This method has worked well for me; my engineers often ask me for reviews,
and one even wrote me a thank-you letter when he left the company!
Elizabeth Hanes Perry betsyp -at- vnet -dot- net
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-