Re: TW on the development team (long)

[Gary Merrill <merrill -at- HYPERION -dot- PDIAL -dot- INTERPATH -dot- NET>]

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
timely fashion.

>  But...

>  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
that.

>  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.

----------
Gary Merrill