RE: Is this a typical technical writing environment?

["Tammy Cravit" <tammy -dot- lists -at- warmfuzzy -dot- com>]

Rick Lippincott wrote, 

> What you have to keep in mind is that when dealing with 
> engineers, you're frequently dealing with a mind that works 
> entirely differently than a tech writer's mind. 

Gee, that's news to me, and I do both software development and technical
writing. ;) (I'm gradually doing more and more of the latter and less and
less of the former).

My opinion, having been on both sides of this problem, is that the
difficulty of interaction between developers and tech writers comes largely
from a lack of shared goals. Software developers, by the nature of their
work, are highly focused on code and tend to view other stuff like
documentation as irrelevant to them. Similarly, technical writers tend to to
focus on the documentation and some have a hard time understanding why
developers don't communicate with them.

When I used to do software testing and quality assurance, I ran into a
similar problem. The developers saw the QA people as largely nuisances,
whose role was to log bugs and make more work for them. Some of the QA
people reacted to that hostility with defensiveness, and the result was that
nothing got done.

The solution I found was to very clearly and directly -- and repeatedly --
demonstrate to the developers that we were a team. I attended all of the
development team meetings, "just so I can stay in the loop about what's
happening." I wasn't shy about asking the developers, "can you explain to me
how this components works, so I can log bug information that's more useful
and meaningful to you?" I made it a point to ask developers if there was
anything they'd recently changed that would benefit from extra stress
testing. In short, I kept the lines of communication open by proactively
refusing to allow any other outcome.

It's tempting to say soemthing like what Rick posted, to explain the
difficulties in communication. Ultimately, though, we're all people, and we
need to work to communicate with the developers and others internally just
as we communicate with our audience when we write.

Rick's developers' incredulity at what he needed is indeed not unusual.
Developers often don't give much thought to what writers, or QA engineers,
need from them. That doesn't mean, though, that giving up when we hit those
barriers is a good idea. (And to be fair, I don't think Rick suggested that
it was.) As technical communicators, we have as much of a responsibility to
foster effective communication within our group as we do with the consumers
of our documentation.

Just my $0.02 worth,
Tammy