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.
Jason wrote:
>1. Do you need to be an electrical engineer to tell someone how to use
>their VCR?
>2. Do you need to be an expert in networking protocols and
>programming to explain to users how to use their e-mail programs?
IMNSHO, to effectively document a product you need to gain an understanding
of the product *one level deeper* than the user will need. Such
understanding means you aren't out at the farthest edge of your knowledge
when you are explaining something. It also helps you to know what *not* to
include for the audience in question.
Because different audiences need different levels of information, that "one
level deeper" also varies.
I'm not saying you need to have higher expertise in the audience's field of
expertise--just about the product in question.
For example, I document an OS and API for DSP chip programmers. Am I an
expert on DSP algorithms? Not at all. But, I do need to understand fully how
the OS schedules tasks and measures time in order to explain this to them.
Did I know this stuff before I started working for this client? No, I
learned by asking the SMEs questions, reading material on similar products,
and talking with typical users about how they use such products. What did I
have before that: curiosity, technical knowledge of other software systems
(mostly databases and OO systems), and enough programming knowledge to read
C and ask questions in the SMEs language.
So, no you don't need to be an electrical engineer to document a VCR, but
you should know enough about how VCRs work to ask the SMEs questions about
potential problems. (You say the clock gets set automatically. How does it
find out the time--from the cable signal? So, that means if someone is
receiving via broadcast only, this wouldn't work, right?)
And, no you don't need to be an expert in networking protocols. But, you
should know enough to be able to reassure them about some simple things. (My
parents just asked me if they would lose e-mail messages sent to their ISP
address while their computer was unplugged. Parents can be *so* enlightening
about *real users*.)
Regarding the "What *is* enough?" thread, I noticed the following quote from
a book called "The 500-Year Delta" in a Donna Dowdney's paper on "Necessary
Skills for Technical Communicators":
"In 1960, the average person needed to learn one new skill a year to
prosper in the workplace. Today, the average person needs to learn
one new skill a day."
I don't know if I'd agree the "average" person is faced with this, but
certainly technical writers are.
Yvonne DeGraw, Technical Services o Technical Writing
yvonne -at- silcom -dot- com o Online Help http://www.silcom.com/~yvonne o Web Documentation
Tel: 805/683-5784 o Database Publishing
Santa Barbara STC: http://stc.org/region8/snb
