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:Ckarification (was Real Offense) From:DowningLst -at- aol -dot- com To:TECHWR-L -at- lists -dot- raycomm -dot- com Date:Thu, 9 Mar 2000 21:54:19 EST
I wanted to clarify one point and respond to one of Andrew Plato's
First, when I spoke of writers who spend too much time debating theory,
methodology, etc., and too little time on their jobs, I did *not* mean to say
that everything you learn in an academic program is hogwash. I found
everything I learned quite valuable. Rather, I was thinking of Ecclesiates
-- i.e., there is a time to debate theory and a timer to refrain from
debating theory and get down to business.
Now, to turn from Ecclesiates to Plato --
<<They should focus on teaching technologies that will help writers
understand the complex designs, products, and services they must document.
For example - I think ALL tech writers in the computer industry should be
forced at gunpoint to take a C++ and SQL class (or something similar).
Writers who know how programs are written and databases are used are 1000
times more qualified to write about those things. >>
I must confess I have a reservation about that. If it would really work the
way Andrew believes it would -- and *only* that way, it'd be a great idea.
But there is a danger, which is that too much of such training could give a
writer the wrong orientation. The end user doesn't need or want to know
about such things as file structures, parameters types, function calls, etc.,
etc. The end user wants to know "How do I use this program to do my
resume/term paper, etc." If the technical know-how helps the writer answer
these questions, great. If it leads the writer to hit end users with details
they don't need, that's not so hot.
(If you respond and want me to see it immediately, your best bet is to send
or copy it off-list to DavidDowning -at- users -dot- com)