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: RTFineM From:Caryn Rizell <caryn -at- HPPTC95 -dot- ROSE -dot- HP -dot- COM> Date:Thu, 6 Oct 1994 13:30:29 PDT
Forgive the ignorance, but:
What is RTFMing?
I think I came in on the middle of this discussion, so
probably missed the meaning.
Please let me in on this new term!
Caryn Rizell
> > Patrick Brian O'Connell said:
> > "OK, time for a show of hands.
> > Who doesn't RTFM for the tools they use -- unless absolutely
> > necessary -- but writes manuals for other ones (IMHO all
> > programs are tools of one kind or another) notwithstanding?
> I've just joined the discussion, but are we drawing a distinction between
> not RTFMing for tools we use and calling Tech Support instead, or not
> RTFMing for the tools we use and experimenting with them to learn the facts
> instead? In the former case, we might deserve a wrist slap; in the latter,
> so long as the tool permits safe experimentation, I don't see a reason for
> us to be ashamed, even if we do write manuals for other tools.
> My response is part of my evolving perception of the task to which a tech
> writer is charged, which I'd call a "journey to design." In my work for
> three wildly-different companies in five years, I've found my position to
> be always in a progression from production-stage work (furiously writing a
> handbook of product functions before it is shipped) through
> development-stage work (writing the handbook while the product is being
> completed, using a style guide or old handbook to satisfy design questions)
> to design-stage work (crafting the product to suit its intended use, based
> on experience gained from bad design I observed in the first two stages).
> The design-stage work is curious in that I try to make the need for a
> manual obsolete and the product functions self-evident. After a fashion, I
> try to *eliminate* the manual. Should I be ashamed?
> -------------------------------
> Quod erat demonstrandum
> Erik Harris
> ewh -at- plaza -dot- ds -dot- adp -dot- com (weekdays)
> TrinityPlc -at- aol -dot- com (home)
