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.
I do think that if you come across documentation that creates a problem
for you, that you should report it to the company. However, it doesn't
follow that you should insert yourself in the situation and say that the
writer should be "canned" or what not. It never helps to take that
particular opportunity to debut your imitation of a catty film reviewer.
But by commenting concisely, you could actually help the writer that is
on staff to get more resources allocated or a process corrected or more
training or perhaps better assistance hired. And if they didn't hire a
writer to do it, maybe this will convince them to do so and to get it
capitalized under their business plan.
I certainly, certainly can agree that glitches and problems are not
always the writer's fault. Work is often developed under many
constraints outside of the control of the writer. But raising the flag
to the company that documentation is important to you as a customer can
actually improve the situation of the writer at the company. The key is
"as a customer." How can they argue for more resource, etc, if
"everything's okay with the customer?" How often has the writer argued
for a better process or a better design only to be told that "no one's
complained yet."