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: A sobering encounter (So now what?) From:Sarah Stegall <sarah_stegall -at- dcprojects -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 03 Dec 2002 09:56:17 -0800
Keith, why is it always the *writer's* fault when the documentation sucks? I wish I had a dime for every time I've written, or seen, a beautifully organized and informative manual that was USELESS because the software had so radically changed in the last iteration that there was virtually no resemblance. I've seen writers ORDERED by Marketing VPs to include instructions for features that were not in the product, just because "the competition has it and we have to, too". I've struggled with projects where the engineers/developers who built the hardware left the company three weeks before I was brought on board, without so much as a diagram scribbled on the back of an envelope to document their specifications. I've had vice presidents put misspellings BACK INTO documentation after I took them out. I've been forced to "release" documentation that no one ever took the time to review despite my threats and pleading. In the end, management NEVER (can I say this again? NEVER) takes responsibility for their mistakes, and blame the writer for things that the writer could do nothing about. Turning around and blaming *ourselves* for the shortcomings of the startup/development environment is only demoralizing and divisive.
Quoting kcronin -at- daleen -dot- com:
>
> I'll endanger myself by saying this, but part of why
> companies feel that
> secretaries and engineers can write the manuals is
> that the manuals
> produced by some "real" tech writers really aren't any
> better.
>
> Whether you want to call it bad writing, misplaced
> priorities, or general
> cluelessness, the sad truth is that I've seen a LOT of
> genuinely BAD doc,
> written by "official" technical writers. They have
> helped create the
> cynical/Scroogelike mindset so many of us are
> encountering in the current
> job market.
--
Sarah Stegall
Technical Writer
sarah_stegall -at- dcprojects -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from http://www.techsmith.com/rdr/txt/twr
Find out what all the other tech writers, including Dan, already know!
Order RoboHelp X3 in December and receive $100 mail in rebate, FREE WebHelp
Merge Module and the new RoboPDF - add powerful PDF output functionality
to RoboHelp X3. Order online today at http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
