Re: Tool knowledge versus Task knowledge

[Tom Johnson <johnsont -at- FREEWAY -dot- NET>]

I tend to agree with Eric's post, but I would like to add something.
Technical writers need to be expert information gatherers. If you are not
one of those, you aren't a technical writer. You may be a desktop
publisher, technical editor or a weight holding down a chair, but you are
not a technical writer. The ability to gather information is indispensable.
It will help you learn software, it will help you deal with reluctant SMEs,
it will help you troubleshoot printing problems. College should be teaching
people how to learn for themselves. We can't learn to teach unless we first
know how to learn.

So often, we are eager on this list to share our knowledge and technogeek
tidbits. It is nice to know we've helped someone else out. BUT, we've
become conditioned to coming to this list first for almost any type of
question and now we (probably) have people who are at a loss if they can't
get the information here. I think we should work more towards telling
people what information resources are available instead of spoon-feeding
them information. Sorry if that sounded like a rant. I've been guilty of
the same thing.

Of course, there is a lot of knowledge we all have in our heads that can't
be found in books. I'm grateful for those of you out there who regularly
share your wisdom with those of us who haven't had your life experiences.

Now, if you'll excuse me, I need to do some research.

Tom Johnson
Traverse City, MI.
I think it is time for a new .sig

business johnsont -at- starcutter -dot- com
personal thomasj -at- freeway -dot- net

On Thursday, October 01, 1998 3:54 PM, Eric J. Ray [SMTP:ejray -at- RAYCOMM -dot- COM]
wrote:
> Taking a quick break from real work for a stint on the
> soapbox... (I'll freely admit that what I have to say seems
> to be internally inconsistent, but I'll stand behind the whole
> thing.)
>
> The people who pointed out the folly in teaching a specific
> tool based on what is in use (today or tomorrow) in industry are
> completely right--the essence of a good technical communicator
> isn't the ability to use Frame, build Web sites, or design Winhelp.
> The essence of a good technical communicator is to identify
> what information the audience needs, to get that information,
> to put that information into a form that the audience can and
> will use, and to deliver that information. Getting bogged down
> in the tools used to perform misses the point of technical
> communication and cannot be good for anyone in the tech
> comm food chain. (It also probably leads directly to the
> job ad I saw today looking for someone who
> is proficient in FrameMaker, Photoshop, and RoboHelp
> to develop documentation for Company ABC. Oh, and
> the position pays $10/hour for a non-entry-level job.)
snip>
> These aren't the best examples, but they illustrate, I
> think, the confusion that often results from not knowing
> the details of the technologies we use to deliver
> information.
>
> I'm not necessarily advocating that everyone turn into
> a techie geek--one per office usually suffices ;-) --but
> I'd be interested in other people's comments and input
> on these issues. Many of us have better things to
> do than to bone up on arcane techno-trivia, and if you're
> using the Web to do so, you're handicapped in the first
> place by questionable sources and information that
> proports to be authoritive but isn't. However, I've
> found that the techno-trivia I've acquired over the years
> has been infinitely more valuable to me as a technical
> writer than I'd ever have imagined.
>
>Eric


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=