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.
Most posters on this thread, myself included, do not disagree, and probably
vehemently agree with this philosophy. My point is slightly different--you
don't have to learn the intimate details of a particular language in order
to be a "technical" technical communicator. Understanding of the subject
matter isn't limited to a programming language, it also encompasses industry
knowledge, research skills, tools knowledge, design knowledge, and
understanding of how your particular audience learns to use your particular
product.
Pity the original poster's friend who refused to try ... but don't lump
every communicator into a category of "technical" or non-technical and tell
us we're unemployable cause we don't know Java or the-language-of-the-month.
I love learning new things, but most of what I tend to learn is
business-related, rather than programming language-related, mainly because
my focus is on end-user doc and usable product design. Other writers need
and want to learn the mechanics, more power and much respect to them.
I know some of the concepts of XML and XSLT, and intend to learn more. I
couldn't develop the application, because my brain doesn't work that way.
But I know enough to combine it with what the user needs the application to
do and with what the industry requires to be done to produce extremely
useful UI, functional specs that developers can work from, test plans that a
QA analyst can follow, and user documentation (on-line and print) that
supports what my audience needs to know. My end users don't need to know
how Java works in order to understand an error message, they need an error
message that tells them what's wrong and how to fix it, a tutorial that
tells the how and why, or on-line help that walks through the procedure.
I hope that's technical enough ;) It sure has been for my employers!
Connie Giordano
-----Original Message-----
From: Swallow, William [mailto:WSwallow -at- courion -dot- com]
Sent: Monday, July 09, 2001 1:33 PM
To: TECHWR-L
Subject: Damnit Jim, I'm a technical writer, not a writer!
:: 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*)
*** 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.
