Damnit Jim, I'm a technical writer, not a writer!

["Swallow, William" <WSwallow -at- courion -dot- com>]

::  Professionally, I love to hear tech-writers insist that they're just
::  writers. It lessens the competition for me. But, on a 
::  personal level, I
::  feel a little sad for them. So far as I'm concerned, 
::  they're settling
::  for far less than they can be.

This sums up my sentiments perfectly. Though there's nothing wrong with
being a damn good writer, but there is something wrong with lacking the
willingness to expand your technical knowledge, especially if you're a
technical writer. The profession is ever-evolving. What would Darwin say
about this? ;)

Seriously, a technical writer may be measured (by their employers) by the
volumes they write and the quality of those documents (measured by internal
standards). But, a technical writer's main job (as I view it) is to
understand, and then explain. 

You simply cannot explain that which you don't understand. 

I know there has been endless debate on this list surrounding this argument,
but I strongly believe in this statement. Many writers may be successful at
turning specs and developer-speak into a functioning manual, but how many of
those writers could then talk intelligently about what they wrote? Would you
be able to stand up and defend your documents, as you might a thesis (note,
I have no idea what it's like to defend a thesis - I lack a MA/MS/PhD)? 

If we can't understand what we write, or if we ONLY understand what we
write, how do we know we're communicating the information effectively? In my
very strong opinion, if you answer your questions with "that's what the
developer/whomever said it does" or "that's what the spec says", you're not
really doing your job. Rather, if you can answer your questions with "the
spec says X and I've found X to be true with exception to conditions Y and
Z" or "I've tested this and found this to be correct", you're going a fine
job.

So, why should you learn new or more involved technologies surrounding your
job? To know. And then to deliver what you know. If, for example, the
application you're documenting is Java-based, knowing Java will allow you to
validate certain issues, such as "will it be able to do X". It will also
help you understand the product architecture, and the impact it will have on
existing business/technical infrastructures. Sure, you could ask someone
these questions and get the answers, but you'll only know as much as they
tell you, which may or may not be the right information. Knowing what it is
you're documenting will help you validate the data you assemble and will
therefore strengthen the quality and accuracy of your output, thereby
correctly educating the reader on what it is you're writing about. And
*THAT* is what technical writing is all about. (IMHO, of course. *g*)

***************** 
BILL SWALLOW 
Technical Writer 
C O U R I O N   C O R P O R A T I O N 
1881 Worcester Road 
Framingham, Mass.  01701 
T E L * 508-879-8400 x316 
F A X * 508-879-8500 
www.courion.com 
***************** 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com


---
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.