RE: being too picky? (long)

["John Locke" <mail -at- freelock -dot- com>]

Sorry if I came across as little harsh in my earlier post.

> This is another situation where I thought to myself, "I'm
> probably the only
> person who will read this and even be aware of the difference between the
> two words."  It felt like I was wasting ten minutes of the poor
> developer's
> time haggling over something that none of the users would have
> thought twice
> about had I failed to catch it and fix it.

To answer your question, Megan, I would say, no, you're not being too picky.
You're doing your job. If you let sloppy writing through, you just add to
the pile of poorly written, unintelligible documentation that our profession
is known for. You are adding value to your product. Someone will appreciate
it.

Imagine your reader, a new user of the product you're writing about. She
reads a slightly inaccurate description of the product, then has to spend
time figuring out what you really meant, adding time, confusion, and
possibly accidents or false starts.

Isn't better to get it right the first time?

When I'm editing, if I own the final document, I make the changes as seem
appropriate. Changes I'm uncertain about, I go ahead and make, and then make
a note to specifically verify its accuracy. More often than not, it's sloppy
writing rather than technical jargon.

Not all engineers are illiterate. If you make crappy documents, you're
guaranteeing that nobody will get any use out of them. If you have a tiny
audience of people "in the know," it's still helpful for them to have a
clearly written, completely accurate document--for training new people if
nothing else.

If you fail to catch and fix the problems, who will? And if your employers
don't appreciate that, there are plenty around in this job market who do.
Being picky about word choice, especially when it has a major impact on the
meaning, is what we do--it's our job.

John Locke
http://www.freelock.com