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 am in the process of investigating tech writing jobs, and I have had
several
>> people in the business state that the future (and near future at that) of
tech
>> writing is primarily in contract work.
>I've heard this also. I would be interested--and perhaps others would also
>be--in learning more about the experiences of those who are involved in
>contract work.
This trend disturbs me. It reflects the continuing (and perhaps increasing?)
perception that documentation is something that is done at the end of a
project, quickly, by someone with "wordsmithing skills", little technical
knowledge, and no necessary knowledge of the product being documented.
IMNSHO, the technical writer (at least for software products) is an essential,
integral part of the production team, and in order to document a product
effectively, needs to be involved in all aspects of a project, from reviewing
design specifications, to QA and hands-on testing.
I have seen (and had to fix) too many manuals that were badly written,
inaccuracte, and incomplete thanks to contractors. NOT because the contractors
themselves were inherently incompetent, but because they were not given
sufficient time, access to the product, or respect.
This is a trend we should resist. One problem, though--contractors make way
better money for the most part than employees. The low pay for employees is,
I think, part of the respect problem.
