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.
Engineers are OK - was The Worst Thing About Contracting
Subject:Engineers are OK - was The Worst Thing About Contracting From:Chris Despopoulos <cud -at- ARRAKIS -dot- ES> Date:Mon, 19 Apr 1999 10:40:56 +0200
Uh, ho... Can't keep quiet about this one, either... I'm
sure it's in the FAQ and archives, too.
I'm not sure who said this, but here is a typical complaint
about being a writer amongst engineers...
Then again, I know quite a few people, tech
authors, who've wandered onto
"turfs" in staff work. Usually the "We're
developers/programmers/analysts
and you're a writer. We're far more important.
You'll work with the
information we give you 'cos we know what you need
to know because we could
do your job and would if our own weren't so
important..." hence writers end
up with hours of input on "this is how it works"
not "this is how you use
it".
To address the last point first, I think of that as the
job. You take input from Engineering, Mktg, Sales, and Tech
Support, and turn it into a description of how to use the
product. In fact, it's rediculous to assume every engineer
(or maybe ANY engineer) really knows how to use the
product. Engineers by nature must specialize - WITHIN the
domain of the product. For example, do you think the
engineers who code the line-break algorithms for FrameMaker
really know how to design a book? If they do, then maybe
tech writers really aren't important after all... Any
engineer can do our job. I believe the same holds for other
products... except maybe IDEs and compilers.
Anyway, if you don't want to know how it works (usually for
a sub-set of the product), then why are you asking an
engineer? How it works is his/her life... what else do you
honestly expect to learn? For real-world use, ask somebody
with a history of contacting the real-world users.
Are engineers more important than writers? A silly
question. But you could ask how important their time is...
at the moment that you are interviewing them (usually near a
deadline, right?). Whatever it appears to be, the true
message usually is, "Please figure out as much of this as
you can... I have hairy deadlines to meet, too." I would
never claim engineers are social geniuses. So the message
is sent in an annoying package... so what? I have found
that if I assume the message is an appeal to save the
engineer as much time as possible, then he/she will respond
favorably to the degree that she/he can. When I can get the
information nowhere else, the engineer usually understands,
and delivers.
I have yet to find an engineer who doesn't care about the
product. These people invest at least as much as you do in
the product, and hope for its success, just like you. They
all know that people must use the product in order to
succeed. I have yet to find an engineer who did not respond
positively to an appeal for usability.
It discredits our profession to throw up our hands in
disgust and just mutter "engineers!" It credits our
profession if we accomodate ALL of our customers - the users
AND the teams of people who are working to make the product
happen. Our job is to ADD VALUE to the knowledge we extract
from our peers. Professionalism is all about getting beyond
the bullshit.
So maybe I have been working in a bell jar all these
years...