TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: RTFM From:Joyce Flaherty <flahertj -at- SMTPGW -dot- LIEBERT -dot- COM> Date:Sat, 23 Mar 1996 20:29:55 EST
Robert, this is more to do with what kind of learner one is than what
you or I believe is the better way. Learners (not to be confused with
how one learns) are either holistic or serialistic. No matter how
good your argument, you cannot convince me, a serialistic learner, to
read any more than the overview before I go directly to the topic of
interest. BTW, that's why we write overviews. If everyone RTFM'd,
then we would need to write only the intros.
Furthermore, you mention people writing C code as if it were BASIC
with dreadful results. I am a programmer turned writer. I played
with BASIC and wrote in IBM Assembler and C. Guess what I didn't
read? Guess what wasn't around to read? If I followed your
advice, I might still have my nose in the UNIX OS books.
Today I wear a few hats, including the (Visual C++ and Visual Basic)
developer's hat. Surely you know what I didn't read.
Truce? This thread isn't that interesting.
joyce flaherty
flahertj -at- smtpgw -dot- liebert -dot- com
______________________________ Reply Separator _________________________________
Subject: RTFM
Author: robert -at- plamondon -dot- com at INTERNET
Date: 3/19/96 7:49 AM
Joyce Flaherty writes:
>For the record, I have never *plowed through* a manual or manual set
>in my life. I'm a voracious reader, but I read books that describe
>processes conceptually. I know what tasks an application pkg should
>perform. If the how-to is not obvious from the interface, then I go
>to the book. This approach works for me.
This approach works fine if the product in question is something
that you already fully grasp from a conceptual level. It works
less well if the product is innovative in approach (or just plain weird),
or when the tasks to be performed with the product are outside your normal
field of expertise. I have seen people attempt to use Interleaf as if it
were PageMaker, by trying to map PageMaker concepts onto Interleaf. I've
seen people try to use Adobe Illustrator as if it
were MacDraw. I've seen people try to write C code as if it were
BASIC. The results were uniformly dreadful.
-- Robert
--
Robert Plamondon, President/Managing Editor, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139