Note: This file has moved to notablog.
Date: Fri, 16 Jan 1998 16:55:34 -0800
Reply-To: "Steven J. Owens"
Sender: "Technical Writers List; for all Technical Communication issues"
From: "Steven J. Owens"
Subject: Re: What is a TW?
Comments: To: chrisc@SYNERGYMICRO.COM
In-Reply-To: from "Christopher
Carmichael" at Jan 15, 98 02:17:20 pm
Content-Type: text/plain; charset=US-ASCII
The question was asked:
>> What really defines a TW?
>>
>> My department manager would like to believe that a good, experience TW
>> would be able to look at a pile of components and intuitively know how to
>> assemble and then operate a given product, then write the appropriate
>> instructions.
Christopher Carmichael writes:
> Gee, a doctor should be able to look at you and figure out what's wrong.
> In my experience, you're right -- and your quote below.
>
>> I need to learn about something before I'm able to write about it. I
>> mean, how would I already know about something that hasn't existed yet?
>>
>> Who is more accurate?
>
> You are. Your manager wants you to be the "jack of all trades and master
> of . . ."
In truth, you're both right - to a degree. What makes a
"technical" writer? It depends a lot on what field you're writing in.
Some fields require you to be a technical person as well as a
technical writer. Many of the things I'm about to write have caveats,
exceptions, special cases, but for the most part (I believe) they tend
to be true.
A technical writer above all must be good at communicating in the
written word - which these days also generally means being good at
working with the medium itself (rudiments of layout and design, online
help design, information architecture, document usability) in addition
to stringing words into coherent sentences and sentences into coherent
paragraphs, and paragraphs into coherent documents.
To be good at communicating, not just good at writing, you have
to be able to understand the reader's point of view. This is true
both in a methodical an analytical sense (what is the audience for
this document, how will they be using it, what are their capabilities
and constraints, what kinds of tasks will they be attempting) and in
an empathic/intuitive sense (step into their mindset and see how the
words you're writing will answer questions and then suggest the next
questions to answer).
This covers the act of writing, now what about the other half -
the stuff you're writing about?
Whether you're writing about software, computers, local
government, bridges, sports equipment, firearms, whatever, you also
have to be good at learning things. Often, you have to be good at
learning things from the ground up, from a standing start. In some
senses, a non-fiction, non-specialized writer must be a professional
student; always learning something new, always ready to tackle a new
topic area.
First you play the role of the beginner - only you have to play
it *well*, so you get the most out of your SMEs in the least amount of
time and make them feel good about it in the process. Then you turn
around and prepare the way for the beginners who will be reading your
book. You have to find the patterns in the knowledge and the patterns
in the use of the material and figure out how and where they
intersect.
Depending on the specific industry you're working in, the subject
matter you're writing about, you may find that your existing experience
gives you the grounding you need, or you may find that you can build on
your learning as you go. Or you may find that, having mastered the
information in one topic and created a manual, you then turn around
and tackle another topic and find yourself back at the start.
With technology in general, however, there are deeper, subtler
patterns that will eventually sink in. Most technologies are
comprised of systems, and continual learning about different systems
will teach you heuristics about learning about new systems.
You may develop more than one approach to a project, or you may
develop and follow your own approach that works best for you. I tend
to like to learn all I can about a technology, then selectively reveal
only the appropriate information to the user. Other writers I've
worked with and alongside prefer to learn just what the user needs to
know, relying on a mix between their judgment and the SME's judgement
about what to learn.
Both approaches have their points; a good student doesn't
necessarily waste time learning inconsequential things, but it's not
obvious which things are consequential. Either way, you have to be
good at learning in general, and if you stay in the same subject field
you should eventually learn some of the heuristics of your subject and
get good at learning those sorts of things. I'd be behind the power
curve if I tried to learn and write about government organizations
right now, because I haven't had much experience with organizational
structures and governmental acronyms (as opposed to computer acronyms
:-).