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.
> I'm probably going to get beaten up for this one, but why is everyone so
> intent on getting a developer's respect?
Why should we think that every individual tech writer and every individual
work situation requires the same relationship with engineers/developers?
I work closely with a small group of software engineers in the development
group of a relatively-independent product center in a medium-sized company.
The product I document is technologically advanced and very (perhaps overly)
complex. The writers I replaced either could not or did not make the
effort to understand the product and its underlying technology. I was lucky
to attend training the second week I was on the job where I could ask
intelligent questions and offer alternate explanations to demonstrate that
I can handle the technology. (Of course, I am probably not an example of
the majority of tech writers. I am trained as a Computer Scientist, but
I have never worked as an engineer, always as a consultant, trainer,
training developer, support person, or technical writer.) I want to be on
the team with the developers. I think I am and can be.
> The customer/user's respect is
> what I want -- if I'm getting that who cares what everyone else thinks?
The users are my audience and my clients. (It can be complicated. My
documents probably need to address the needs of our field technical staff
and 3 classes of users: implementers, administrators, and operators.) I
need to find out if my documents meet their need and help them to use the
software effectively. (This is a big, important job.) I need to represent
their point-of-view on the development team. (I believe that technical
communicators always find themselves in the middle.) The development team
knows that I understand their problems as well as the users' and that I must
press for easier-to-understand systems (if only because I have to explain
> don't work for developers or trainers or supporters or managers or funders.
> I work for users. ...
I work for the development organization. They pay me and I have a manager
who helps me set priorities. If I think priorities should be one way, I
have to convince him. (Have you ever worked on a "technology-driven"
product produced by engineers who set their own priorities?) If I think a
project warrants additional resources (like another writer), I need to "make
a business case." If he is not "user-centered" enough, I must try to
influence him (or look for another job). If I was collected royalties on
computer books I had written for Sams or McGraw-Hill, I would be working
for the users.
> correaj -at- sdsc -dot- edu
> I represent only myself.
Product Center Writer
Boole & Babbage Network Systems
fred -at- boole -dot- com