Re[2]: Reading a draft "for cont...

[Vince Putman <PUTMV -at- MAIL -dot- SYNTRON -dot- COM>]

     To:        RSMH, (Name unknown)

     You got the point but perhaps not the objective.  We sometimes need to
     be "confrontational and divisive" for a worthy cause.  In a perfect
     world, people, as you say "should try to find a way to work together,
     while respecting each others area of expertise."

     In our real world we often do not respect each other but you are
     right, we "should try to find a way to ..."  Amen.  However, the
     objective is to get the cotton-picken job done, and the objective of
     this thread is to better understand what interferes with the process.

     Your point about rushing a draft out for review so some kind of manual
     can be sent with the product is well taken.  It is the real world of
     TechWriters.  Many companies hire Writers who never understand any
     process nor the subject they are expected to write about.  They also
     call themselves TechWriters, and the job does not get done, but they
     create a reputation for all of us. Right?


        Vince Putman             | Avoid polishing the fire truck
        putmv -at- mail -dot- syntron -dot- com   | while the building burns down!
        713-647-7139 Houston, TX | Aka, Eschew Gratuitous Obfuscation



______________________________ Reply Separator _________________________________


Subject: Re: Reading a draft "for cont...
Author:  RSMH -at- AOL -dot- COM at INTERNET_MAIL
Date:    2/10/95 11:50 AM



I've been following this thread regarding developer reviews, and I think most
people are missing the point.

When I pass a draft to the development team, the manual is often in progress.
I am ofen under pressure to get a draft together, so it can go out for Beta,
or because the marketing people feel that the product has to go out quickly.
Consequently, I end up rushing a draft to the technical experts so they can
be certain I understand the underlying technical aspects of the product.
While I don't begrudge them the right to review the manual for other areas, I
feel that this is my job, and I will pick up those kinds of errors in future
iterations. In the interest of time and division of labor, I am asking them
to review for content, and let the writers worry about making it neat and
tidy.

As far as technical writers commenting on the interface or how the software
works, I often make these contributions, and I don't see it as stepping on
developer's territory. Many times the development people just don't put
themselves in the place of the average user. As a technical writer, I see
that as part of my job. In the process of communicating the procedures to
the user, certain things just pop out at me, and I compile these
suggestions and send them to the developer. As one writer suggested, it's
the responsible thing to do.

I honestly think this entire discussion is getting much too confrontational
and divisive. Developers and documentation people have to work hand in
glove, and should try to find a way to work together, while respecting each
others area of expertise.