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.
I'm not sure of the exact origin (there's a thread unto itself!), but I
think the
"technical" is there to differentiate our field from creative writing
or
journalism. If you say you're a "writer," many people assume you write
books, plays, articles, etc.
In many cases, technical writers deal with technical topics. Some
actually
do write about how a product works. Others do what you describe: help
end users understand what a product does. I know there are hundreds of
exceptions to this rule; not all technical writers handle technical
information.
When you think about it though, most job titles don't accurately
convey
what the person actually does (How many telephone operators actually
"operate" the phones?).
I'll echo what previous posters have said: the job itself is much more
important than the job title. When we introduce "new and improved"
titles,
we risk confusing hiring managers. We know what technical writers do,
and we don't need to invent inflated job titles to convey it. I'd
rather be a
technical writer and let my work speak for itself.
Rachael Buckley
Plain Old Technical Writer
>>> "Anthony Markatos" <tonymar -at- hotmail -dot- com> 11/09/99 03:31PM >>>
Question to all listserv members:
Why are we called Technical Writers? Technology is implementation; it
is
about design; it is about HOW the product works.
Our primary job is not to write about HOW the product works. It is
convey
understanding of essential end user tasks accomplished with the product
and
how those tasks interrelate. It is, in other words, conveying
understanding
of WHAT the product does to help the user achieve his/her business
goals.
We may properly digress from the WHAT and discuss the HOW, but all
effective
organization is based on the WHAT.
How can we be viewed as "adding value" instead of "a necessary cost of
doing
business" if something as basic as our agreed upon title is so
out-of-wack?
