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:Thu, 4 Jan 1996 08:05:10 GMT
Susan W. Gallagher writes:
> merrill -at- hyperion -dot- pdial -dot- interpath -dot- net writes:
Gary Merrill responds to my post thusly:
>Funny, Gary... I've been in the profession for almost 13 years now,
>and I've never met a writer or worked with a writer who preferred
>being isolated from the development team.
In that case, you've been lucky.
>>> As a part of the development team, we're resigned to be players,
>>> never leaders. While it's possible that a writer could effectively
..
>If this had been the case, I would have been much more comfortable
>with the situation. The "team" that I was a (nominal) part of
>was extremely autocratic in nature. The purpose of my post was to
>find situations in which this "team" structure worked well. It did
>not work well for me. I do not live in a perfect world.
Yes. None of us do. But you made a general and unqualified claim
about what happens to writers "As a part of the development team ...".
You did *not* say "I was resigned to be a player ...", but rather
what you *did* say was that writers in such a circumstances
*are* resigned to be players and never leaders. It is this
general claim to which I was responding -- not your
particular experience. If the purpose of your post was as you
now choose to describe it, and your claim was intended only
to refer to your own experience, then I suggest that this
was quite poorly expressed.
>>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.
>Why do you, as a programmer, suppose that you have a better feel
>for the user interface than I, as a writer, do? Technical writers
I would hope that a professional writer would be able to read
a bit more carefully. Nowhere did I either state or imply
that I "have a better feel for the user interface" than you
do. I was responding to your quite direct claim that a
writer (apparently, qua writer) *does* have such a better feel.
>>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.
>Funny, I've worked with programmers about whom you could
>say the same. ;-)
As have I. Again, this was in response to your view that
the writer has, in this arena, a privileged perspective.
>And this is what I was wondering, whether such "correctly
>organized teams" really exist. Rather than belittling me for my
>observations about a bad experience, why can't you contribute
>positively to the discussion with a description of your "good"
>experiences?
I am not belittling you for your observations about a bad
experience. I'm belittling you for making general claims
that are just as indicative of an unfortunate attitude about
programmers as are the ones you complain that programmers
hold about writers. And I have made several very positive
comments about the role of a writer in the development process.
If you would like to see another programmer's view of the
proper role of the writer (quite elegantly expressed and one
to which I subscribe), take a look at pp. 34-37 of David
Flanagan's _Motif Tools: Streamlined GUI Design and Programming
with the Xmt Library_ (O'Reilly & Assoc., 1994). In fact,
this is suitable for copying and posting on bulletin boards
around your company.
>The purpose of my post was to see whether others would confirm my
>bad experiences or counter with good experiences of their own, Gary.
>Your contribution is of dubious value.
It's obvious that this single experience has made you extremely
bitter, and that you are prepared to generalize on the basis of it.
In any event, my own response referred to experiences of my
own -- both good and bad -- and explicitly mentioned one
particularly rewarding experience involving such a team.
I'm sure that others *can* confirm your bad experiences,
just as many other programmers will confirm *my* bad experiences
with (some) writers. But I, in fact, countered with a good experience,
however dubious you find its value to be. Given the argumentative
tone of your original remarks and the broad generalizations
you made about development teams and the relative roles and abilities
of writers and programmers, it is at this point quite disingenuous
of you to suggest that my own response was inappropriate. Your
posting was polemical, and the response was appropriate.
But what is the point? *My* point is that the team approach to
development (in which the writer is involved from the very beginning
in an active manner) not only *can* work but is the way in which
things *should* be done. But it requires two things from *all*
members of the team: competence and cooperation. It *cannot*
work in the presence of the sort of "us versus them" attitude
that you appear to have. Sure, it's okay for you to bash developers
as being insensitive, autocratic louts. But the mere suggestion
that some writers are less than competent brings howls of protest.
You want the programmer to share development of his product with
the writer, but you are concerned about giving up "ownership" of
the documentation. You want someone to tell the programmer to
listen to you and implement your suggestions, but you regard it
as outrageous that the programmer should have a similar say in
the documentation. That won't work.
I have (in fact quite recently) *begged* for a writer to be assigned
to the development team that I am currently on. We need good
documentation and we need good online help when we release
our (internal) product. I urged that this was more important than
adding another developer to the staff. Without it, the documentation
will be done by the developers if it is done at all, it will be rushed, and
it will hardly be of the highest quality. In fact, I have been arguing
for well over a year that we hire a writer to work full time on our online
help. But none of this is going to happen because the documentation
and help are not viewed as being of such importance. This is a serious
mistake. Believe me I know the value of a good technical writer
(gee, I live with one) and the value of good documentation. And I
know how well the integrated team approach can work with such a
writer.