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.
Judging by the number of "Oh, yeah, well to write what I am writing
about, you need to know..." messages I received in response to my two
innocent questions (which far outnumbered the four "I get your point"
messages), it would appear that I stepped on some toes.
So, here was the point, bluntly: Not ALL technical writing requires
advanced technical knowledge. It all depends upon who your audience is
and what you are writing about.
Heck, I started out documenting software for novice users (mainframe and
PC apps). Never once had to read the code. Just played with the app --
pushed all the buttons, filled all the fields, and SPOKE to the
programmers when I had a question. Couldn't read code to save my life.
Still managed to create usable documents (if the opinions of the users
matter).
I bet some of you are now cringing. "Ack! Don't say that! It devalues
our art!." Not really. My take at the time was that the customer (who
was internal) was paying me (one person) to do all the playing and
poking, and explain it clearly in terms of their daily work, so that
they (300 people) did not have to. A pretty good investment if you add
up the $$$.
What I document now is a completely different story, but then again, it
is also a completely different who and what.
So, to all you who said "But what I write about..." , yes, yes, yes. Me
too. The point was that the coin has two sides.
Secondly, this is for those of you who (feebly) tried to explain why you
need to read the schematics for the VCR and code for the e-mail program
... if it makes you feel good, go for it. I would rather make a
3-minute phone call or quick scan of the specs and spend the rest of my
precious time making the information useful to the user.
(Then again, if it was an object-oriented, distributed, scaleable,
e-mail program for developers... sorry, just yanking your chain).
Jason
> ----------
> From: Yvonne DeGraw
> Reply To: Yvonne DeGraw
> Sent: Friday, May 8, 1998 1:16 PM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Re: Non-Technical Technical Writers
>
> 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
>
> &^~~~
> Send commands to listserv -at- listserv -dot- okstate -dot- edu (e.g., SIGNOFF
> TECHWR-L)
>
>