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.
Re: Have to know Programming to be able to write about it? -- NO
Subject:Re: Have to know Programming to be able to write about it? -- NO From:Chris <cud -at- telecable -dot- es> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 27 Feb 2003 10:12:25 +0100
Do you have to know economics to write about it?
Do you have to know politics to write about it?
Do you have to know art or music to write about it?
(I don't know much about science, but I know what I like.)
Technical writing is very much like journalism. To get a job as a
journalist in any of the above subjects you need more than writing
skills - you *must* have a background. Granted, the local county paper
might construe your being a contractor as a background in economics - if
that's the best they can do. And also granted, with that limited
background you may very well grow into a decent economic reporter. But
you probably won't get that interview with Greenspan. And if you did,
what would you ask - what would you report?
If you're documenting a product, you need to *know* that product. You
are not just describing what's in the box. You are trying to get at the
best-use scenarios. How can you know what those are if you don't know
the product?
If you're documenting systems in general, you need to *know* systems in
general. Otherwise, how will you be able to interpret the system specs?
How will you prioritize the information for different classes of users?
If you are documenting an API, you need to *know* programming.
Unfortunately, companies don't always have the opportunity to use a
programmer/writer (or writer/programmer). But there are always
questions such as: What happens to variables when the dll relinquishes
control? What are the peculiar issues of memory management for this
API? What is the best-use scenario? And on and on. You don't need to
know the *answers* to these questions to be qualified to write. But you
do need to know the questions. And you need to know when you have
gotten an answer, and what that answer really means. The more you know,
the better (more efficient) your interviews, and the more the developers
will like you.
If you can learn what you need to learn without formal training, bully
for you. I personally support that approach. If you want to take a
course or two, bully for you. I support that approach, too. If you
just don't want to know, then bully for you - so long as you are working
reasonably close to the bounds of your knowledge.
Just my two centimos...
--
Chris Despopoulos, maker of CudSpan Freeware...
Plugins to Enhance FrameMaker & FrameMaker+SGML http://www.telecable.es/personales/cud/
cud -at- telecable -dot- es
LAST CHANCE for this steal of a deal! Purchase RoboHelp X3 by February 28
and receive $100 mail-in rebate and FREE WebHelp Merge Module ($339 value)!
RoboHelp, the Industry Standard in Help Authoring, has won over 55 industry
awards. For more information please visit: http://www.ehelp.com/techwr-l2.
"RoboHelp X3 is simply remarkable." - George Bell, Techno-Vision Systems
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.