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.
OK. I've decided, based on a lot of the lurking discussions lately, that I
am going to attempt to be more involved in this list in order to learn more.
Anyway, Phil Levy wrote:
"After all, don't we tech writers spend a lot of time
and get paid a lot of money for seeking information
that already exists?"
Can I have that job?
No. I get paid to CREATE information that does not currently exist (and when
I say doesn't exist, I mean it doesn't exist either in a file or in
someone's head). That's the whole point - the developers can't offer much
help in writing user documentation for two reasons:
1) Each developer only knows his specific piece of the software, and the
majority know very little about how it relates to the entire program as a
whole, and
2) Each developer knows the application from the back end - how the code
works - not from the front end, how the end user is going to work with the
software to complete his daily tasks.
As one of the managers said, in reference to little-ole-me, "that woman
knows more about this program than anyone in this room" (while in a room
full of development staff). Now, that isn't true - I know more about what I
need to know to write the documentation than anyone else. I am the missing
piece in the puzzle - the person who puts it all together for the end user.
The person who understands how part A interacts with part B, and how part C
affects both of those functions. It isn't about the code. It's about how the
user uses it.
I've never worked in an organization where information was "fed" to me
through specs or SMEs. I may be misinterpreting Phil's original statement,
but this is what popped into my head when I read it. I do have some
resources I can use - but I use them to bounce ideas of off and work through
issues that we usually determine to be bugs in the software. I don't use
them to do my job for me.
And this perspective and new SME-like status has led to something else: more
opportunities beyond traditional documentation. Early on, I became something
of one-woman quality control department, because I'm the first real tester
of new releases. I'm now also getting a chance to be involved in the design
of new applications. As Connie Giordano stated "Which means writers may have
to do what I've been researching and advocating for awhile: transform
ourselves into user support/product design specialists." Exactly.
Karen R. Casemier
Senior Technical Writer
Provia Software Inc.
616.974.8729
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.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.
