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:Figurative language From:Ben Kovitz <apteryx -at- CHISP -dot- NET> Date:Wed, 24 Mar 1999 14:21:47 -0700
Robert Maxey wrote:
>>>>I've searched the archives, but found little on personification.
>
>Go here:
>
>http://www.netcore.ca/~gibsonjs/figlang.htm
>
>The site will explain personification and other figurative language
>constructs.
Er, I just read this page, and it's *awful*. The author just doesn't get
the difference between literal and figurative language. Pointless and
confusing, and not recommended for people who don't already understand the
topic that this page is trying to teach.
While the relevance of this to technical writing is borderline at best, let
me recommend a wonderful book for those who are interested:
I do not believe that figurative language has a large role to play in most
technical communication. It's appropriate for inventing new terminology,
sometimes for tutorials, and not much else. Well, it does have a large
role to play in marketing copy, even for technical products. Some of us
occasionally get asked to do that kind of writing, since sometimes we are
the only people in the company who simultaneously understand the product,
the users, and how to put things into words.
However, I believe that getting some experience with figurative writing can
still be useful even for someone doing straight tech writing. The reason
is that it loosens you up. The Quinn book is ostensibly about how to
categorize the various figurative devices. But you don't have to go far
into it to see that he really doesn't care what you call them or even if
you call them anything. What the book really does is open your eyes to the
power and flexibility of language.
It's easy, especially when writing very similar technical documents over a
long time, to fall into a rut. While I strongly oppose creativity in
technical writing for the sake of "being creative" or "expressing your
individuality", it's easy to overlook other forms of expression that would
be much better suited to the audience and the material. Exploration of the
furthest outskirts of language (notice the metaphor?) shows you how much
you can do without losing comprehensibility, and that the duckspeak style
of many technical documents does not aid clarity, but harms it.
