Re: Being an Expert

Subject: Re: Being an Expert
From: Chris Gooch <chris -dot- gooch -at- lightworkdesign -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 16 Aug 2002 15:01:32 +0100

Gang -

On the subject of "do you have to know your stuff".

Compare this, from Meg Golding on the "Difference between trainers and
tech writers" thread:

The bottom line is that trainers -- or anyone with customer "touch" for that
matter -- are in a great position to help write practical procedures. In my
current position, I wrote a user's guide that I still regard as
inferior...mainly because I don't see how customers use the product, don't
see how they learn to install it, and don't hear their questions about the
product. All of these add to improving the documentation.

And this, from Tom Green on the "Being an expert" thread:

>...a very important part of our (tehcnical writers who are not tech
>role, I think. We sometimes, because of our lack of knowledge or because we

>are not as close, can pick out something that a whole room full of experts
>sometimes miss.

Can anyone see the problem here?

Now, this is what I think you need to be a good technical writer (it's what
I strive toward, rather than what I necessarily achieve!):

1) The ability to understand the product/technology you are writing

2) The ability to place yourself in the shoes/mindset of a customer who
does not understand the product technology.

3) The ability, somehow, to bridge that gap

and finally

4) The ability to understand what the customer wants to achieve using
the product (this helps you do 3) effectively).

Now, I'm not saying this is easy. The reason most engineers do not write
particularly effectively is that they can do 1), but not 2) and therefore
3). But likewise a writer who is able to do 2), and even 4), but not 1),
will also produce writing that, whilst perhaps perfectly useful to many
will not be as effective as that produced by someone who can do all of
1), 2), 3) and 4).

Or to sum it up: to be a good writer, you should know your subject, _but_
also know your reader. Importantly, you need to know what is important,
what the reader will need to know, what they don't know yet, and therefore
set a course for the reader from point a to point b.

Or: try and see both the individual trees, and also the wood at the same
time. I'm sure there's some sort of Zen saying which would be even more

But basically, the "ignorance is good" standpoint _always_, in any context
at all, just seems plain wrong to me. I remember similar discussions as
a student -- humanities/arts types claim scientists are reductionist,
seeing only the parts and not the whole, whereas scientists point out
that understanding of details can only enhance the understanding of
the whole. The trick being just not to lose sight of the bigger picture.
( I say "just"....)

So there you go, science, zen and technical writing. It's too hot in
my office this afternoon and my perl script won't work! is it nearly
time for the pub yet??

Christopher Gooch, Technical Author
LightWork Design, Sheffield, UK.
chris -dot- gooch -at- lightworkdesign -dot- com

Save up to 50% with RoboHelp Deluxe. Get 2 great products for 1 low price!
You'll get RoboHelp Office PLUS RoboDemo, the software demonstration tool
that everyone's been talking about. Check it out and save!

TECHWR-L is supported by ads and sponsorships...and donations.
You can help maintain the TECHWR-L community with donations

You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: RE: Why ISO 9000 really sucks
Next by Author: Re: XML
Previous by Thread: RE: Being an Expert
Next by Thread: RE: Being an expert

What this post helpful? Share it with friends and colleagues:

Sponsored Ads