Re: being too picky?

Subject: Re: being too picky?
From: Berk/Devlin <armadill -at- earthlink -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 27 Jun 2000 01:05:58 -0700

On Mon, 26 Jun 2000 12:02:39 -0700 (PDT), Becca Price <becca_price -at- yahoo -dot- com> wrote:

... when people ask me whether I'm an expert in a given
subject, I usually say "no, but I'm an expert at
asking questions."

Respectfully, I need to disagree a little at least. There are some areas of technical writing in which being a quick study and asking intelligent questions does not cut it. It just takes too long. Being an expert makes you faster and significantly more effective (and, therefore, much more highly paid).

I have been a C programmer since 1981. I have programmed in C++ since 1985. I have programmed in Java for two years now. When I look at program code, I KNOW what it means. I can usually figure out just by eyeing it if a code example actually does what the text description says it does. (It's amazing how often it does not.) I KNOW what code I can change (and not cause it to fail to compile) and I know how to compile and build it to make sure my assumptions are true.

Most technical writers who have not programmed professionally cannot possibly do that. What I do is say "Should that semi-colon really be a semi-colon? Shouldn't it be a colon?" Or, "Look at this loop here. It seems endless to me."

It's possible a non-programmer might come up with questions like this. But, when non-programmer eyes have to review 300 pages of documentation, 40% of which is code, in two weeks, those eyes start glazing over in minutes.

Recently I found quite a few three-year-old bugs in manuals, almost always in code samples. Why? Because in these places, which are the parts my users need the most, most self-taught/good-question-asking tech writers can't go.

I also often found many (glaring) grammatical errors in those same manuals. My theory about this is that wading through subject matter that was Greek to the writer made it impossible for the writer to concentrate on even the stuff he or she was ok at, like grammar and spelling.

For end user documentation, yes, I agree that good questions and the ability to learn quickly will make you successful most of the time.

Not in MY niche, however.

On the web at *** Armadillo Associates, Inc.
~Extremely-technical technical documentation that developers use.~

Previous by Author: SI system A -- Ampere
Next by Author: Re: Re Fair Cut
Previous by Thread: Re: being too picky?
Next by Thread: Re: being too picky?

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

Sponsored Ads