Plucking dichotomous moving targets

Subject: Plucking dichotomous moving targets
From: John Garison <John_Garison -at- IONGATE -dot- STAFF -dot- ICHANGE -dot- COM>
Date: Fri, 23 Feb 1996 09:02:01 -0400

Several discussions lately on what are good characteristics of writer=
s, how do=20
we do what we do, and how do we handle ever-changing projects have ro=
used me=20
=66rom profound lurkdom. I believe that these are the *core* issues i=
n tech=20
writing. Always have been, always will be.

As evidence of the permanence of this condition, let me tell you abou=
t Joe=20
Chapline who spoke at the InterChange Technical Writing Conference he=
re in=20
Massachusetts in 1994 and related some of the best stories I've ever =
heard. (If=20
anyone is looking for an entertaining and informative speaker, I'll p=
rovide you=20
with his phone number.) Anyway, Joe is the very first person to make =
his living=20
as a computer technical writer. He worked for Mauckley and Eckhardt b=
ack in the=20
40s on the Eniac (which celebrated its 50th anniversary on 2/14). Joe=
was hired=20
to come up with some sort of manual to describe to people how to run,=
troubleshoot, and repair the very first computers. He tried to get br=
ight young=20
engineers and train them how to research and document this kind of in=
but soon gave up on them and hired English majors and Journalists ins=
tead. Even=20
50 years ago, it was easier to find someone who knew how to write and=
them the technical struff than it was to find someone who knew the te=
stuff and teach them how to write. I don't know that this will ever c=
Perhaps some psychologist will determine the inner workings of the ce=
that cause this, but I doubt it.

I think, too, that this fundamental difference in approach has an aff=
ect on the=20
way we work. As tech writers, we see the WHOLE product. We have to un=
in a Kantian way, why a change over 'there' has a profound effect lat=
er over=20
'here'. This assimilation of how a product works is critical to good =
Developers, however, only have to keep a smaller piece of the action =
in mind at=20
any one time. They know everything about how the print routines work,=
aren't concerned about what happens when those routines interact with=
recalcitrant operating system. As writers, we do care, and have to c=
because this is exactly the kind of thing that our readers look to us=
explain to them.

Insofar as moving targets go, I am wont to use a swamp metaphor to ex=
plain how=20
best to cope with this. Recognize that larger forces are at work her=
e, and=20
that there is little if anything you can do to control things. You ca=
however, develop superior coping mechanisms. To wit:
* Remember your objective - To drain the swamp
* Recognize that drainage happens over time - Some bits of ground wi=
ll firm up=20
before others.
* Work on dry ground whenever possible - Document those things that =
have been=20
* Be aware of quicksand - Some pieces of the project are just plain =
complicated and will take longer to finish; do not get sucked in to w=
orking on=20
them too soon - they will take all of your time and waste your energy=

* There be gators - Keep a weather eye out for unseen traps and dang=
ers, but=20
focus on the objective whilekeeping your finger on the pulse of the r=
est of the=20
* A man, a plan ... - Develop a model based on the most complex part=
of the=20
project; if your model or prototype can handle that, it can handle an=

My 2=BD worth ...

John Garison
jgarison -at- staff -dot- ichange -dot- com

Doc Manager, AT&T New Media Services, Cambridge, MA
Teacher of SW Documentation at UMass Lowell
Chair of InterChange Tech Writing Conference - see our Web site at=
( Case sensitive!

"The single biggest problem in communications is the illusion that it=
has taken=20
- Bob Marotta

My opinions are my own. They are not for sale or rent - even to my em=

Previous by Author: Re: hyphenation
Next by Author: Re: HTML and printed doc from one source file
Previous by Thread: Re: what's a senior tech writer?-Long
Next by Thread: Rule: Re: TECHWR-L Digest - 15 Feb 1996 to 16 Feb 1996

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

Sponsored Ads