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.
RE: Help on Coordination between Engineers and Technical Witers
Subject:RE: Help on Coordination between Engineers and Technical Witers From:"Tammy Cravit" <tammy -dot- lists -at- warmfuzzy -dot- com> To:"'TECHWR-L'" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 26 Feb 2004 09:39:28 -0800
John Posada wrote:
> too technical, how do you write about it? Shouldn't you at
> least be at the level where you'll know enough about what
> they are talking about to know if they are discussing a
> feature you don't know about?
I think there's a balance point here, though I was also troubled by the same
statement that John quoted in his posting.
A number of years ago, I did some contract software quality assurance for
Adobe (the product was Acrobat 3.0 for UNIX, which dates things even though
I don't remember the year). As such, I attended the UNIX development team's
weekly engineering meetings, and we both had access to the same bug-tracking
database.
Now, granted, some of what was talked about at the these meetings went over
my head. I didn't need to know about the inner workings of the COS Object
System[*] to satisfactorily test the application. On the other hand,
knowing enough about them to understand what the developers were working on
and what stuff was likely to have become broken was definitely helpful to me
in my goal of testing the application.
I think that what happens sometimes with non-developers is that they go to
these development meetings and become so lost in a sea of techie jargon that
they give up. And I think that's a problem. On the other hand, I worked hard
when I was doing QA to get to know the developers well enough that I could
go to them and say, "could you tell me a little bit about the relationship
between the AVDoc[*] and PDDoc[*] layers?" and they were willing to explain
it to me.
I agree with John that a certain level of technical knowledge is important.
But I think it's equally important to be willing to ask questions, to build
bridges with the tech people, and to be involved in the process. I know I
couldn't have been effective as a QA Engineer, and I know I can't be
effective as a technical communicator, without fostering and building
communication channels with the developers
Tammy
PS: For the curious, the [*]'d terms are defined in the Adobe Acrobat SDK
Documentation.