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: couple of questions... writers as programmers From:Michelle Nichols <michelle -at- CARVM3 -dot- VNET -dot- IBM -dot- COM> Date:Tue, 7 Nov 1995 13:07:03 GMT
In <199511070512 -dot- XAA08588 -at- server -dot- iadfw -dot- net>,
Jane Bergen <janeb -at- iadfw -dot- net> writes:
>Anybody care to jump into the midst of what I suspect is more
>political than practical at our company? I need to know...bad news or
>good news.
I have heard that many software companies have started to believe that
technical writers should also be able to program. Managers and other
programmers believe that we should be able to write our own examples
and be experts at using the entire product.
Technical writing is a specialized skill. Many of us have earned one or
more degrees and learned the theory and application of this skill. We have
worked hard to get into good standing by producing usable documentation,
working with teams of highly technical programmers.
With the current climate of down-sizing, right-sizing, cost-cutting, whatever
you care to call it, managers and programmers are looking to technical
writers to "pick up the slack," as if writing cannot be all that difficult
or time consuming to do. We don't get paid to do two jobs, so why should
we accept such an assignment?
I am not saying that we should not wash our hands completely of the
programming skills. We must understand the concepts, theory, and
basic application of what our programmers do, so that we can talk
intelligently with them about the product and then write intelligently
about it as well. We also must understand our product from a USER'S
point of view and be able to convey the concepts and tasks clearly
and effectively (that's what I am trained to do anyway, right?)
However, I argue that I do not have to be a programmer to accomplish
this goal.