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: TW on the development team (long) From:Gary Merrill <merrill -at- HYPERION -dot- PDIAL -dot- INTERPATH -dot- NET> Date:Wed, 3 Jan 1996 01:18:25 GMT
Susan W. Gallagher writes:
> If I mentioned this trend to writers who have never had the
> opportunity to be a part of the development team, they'd be
> overjoyed at the opportunity.
Not necessarily. I know many technical writers who prefer to work
in as much isolation from developers as possible. Most frequently this
is a result of the inability of the writer to grasp technical details in a
> When we join the development team, we sign away our rights.
> As a part of the development team, we're resigned to be players,
> never leaders. While it's possible that a writer could effectively
Well, to a significant degree this is the nature of a *team*. You don't
sign away your rights. You simply acknowledge that others have similar
rights as well. And they, in turn, acknowledge your rights.
> lead a software project, especially if the main effort was an
> improvement to the user interface or if the product targeted
This, I must say, is simply a conceit. Why do you, as a writer,
suppose that you have a better feel for the user interface than
I, as a programmer, do? User interface design is really quite
complex and, in my experience, requires a great deal of trial
and error -- as well as listening to the ideas and advice of a
diverse group of potential users. I have worked with writers who
simply had no clue what the appropriate interface should (or
could) look like because they had such parochial experience.
The view of the programmer as a geek who is insensitive to the
user's needs and who is arrogant is a stereotype. The view of the
writer who is sensitive and knowledgeable about such things is
a stereotype (and a self-serving one) as well.
> We rescind our rights of ownership to our documents. We place
> ourselves directly under the control of software developers.
Not at all -- in a correctly organized team. I have worked on at least
one such team where the writer was a *major* contribution to the
development and testing of the product. Of course, she was
sufficiently competent technically to understand the product.
> There is no one who understands the communication process (such
> as a doc manager) to come to our defense when the lead programmer
> demands that we change the wording or delete a cautionary note
> because we point out a defect or cluge in the software.
Just poor managment and organization. Nothing more insidious than
> OK, granted, I had a particularly bad experience, working under
> a lead programmer who had little respect for anyone who didn't
> aspire to be a programmer themselves.
Perhaps he also had little respect for someone who claimed to be
a writer but who committed obvious errors in grammar and usage.
Although I have worked with several technical writers who were
superbly competent in their field, I have also worked with a number
of technical writers who not only have distorted the technical sense
of the draft I provided them, but mangled the English or the style into
something obviously inferior to that with which they were provided.
And I have worked with others who when given a draft about which
I said *explicitly*, "This is a rough draft. I haven't had time to polish it
or add the sort of examples and fleshing out it needs," made simple
copy-editing changes and called it a day. In terms of respect,
you most often get what you deserve.