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.
Subject:Re: Definition of Tech Writer, was STC is broken From:"Gene Kim-Eng" <techwr -at- genek -dot- com> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 2 May 2008 16:34:18 -0700
No, if you have a driver's license it doesn't automatically mean
you can just take an Indy car out. Someone with years of
experience racing Indy cars can't just jump behind the controls
of a combine harvester or the NASA Crawler, either. But it's
all still "driving."
The distinction being described here is merely the difference
between two highly specialized forms of very technical writing.
No, I wouldn't argue that anyone with experience as a "technical
writer" can easily make a jump to writing business or finance
documentation or vice versa, but there are any number of types
of science, engineering, medical, etc., writing that also require
highly specialized knowledge and backgrounds to work at their
most advanced levels as well.
What I see happening in this discussion is that there are a lot
of people here who seem to believe that technical writers can
easily jump from any "technical" subject to any other, so any
subject that is sufficiently different from what they do, have
done or can do that they can't make that easy jump must not
be "technical writing" simply because they can't do it.
> I think the distinction you've identified is real. Here's my example:
>
> I was working in a phone company as lone tech rider, documenting a
> complex network re-engineering project. They liked my work, and I was
> in
> thick with programmers, project managers, and the business class.
>
> Then one day, the Oracle team asked me to document their Financials.
> Oracle Financials, that would be a business writing task, wouldn't it?
> Long story short, the work never materialized because while I could
> document Oracle database applications, I didn't have any experience
> with
> Financials.
>
> This anecdote illustrates the constant objection I have to the
> "Communicator" job title: communications are not jello, and I don't
> work
> by dissolving a batch of information and pouring it into a mold. What
> I
> have to do as a technical writer is artisanal, like blowing glass, or
> throwing a clay pot on a wheel. The "communicator" model, IMHO, wants
> to claim that I have a push-button labeled Communicate--just wind me
> up,
> point me at the work, push my button, et voila!
>
> The point is inevitable: I can be a born communicator and a technical
> writer, a web developer and creative marketing copy writer, a medical
> device writer with 21CFR11 requirements, a SOX writer, a green-belt
> Six
> Sigma PM, an official of the STC, a policy and procedure writer, an
> journalist, science writer, and an avid correspondent in Esperanto and
> a
> double-handful of other languages in which I also translate scientific
> journals, and still, it does not follow that I am the embodiment of
> the
> specification for a drop-in communicator who can do any technical
> writing task.
>
> Disclaimer:
> My example illustrates that I agree with Lauren on this point, but
> someone will point out that even Oracle Financials writing is
> artisanal.
> To that point, I say "I have a driver's license. Can I take your Indy
> car out for a few laps, I want to set a speed record in the Unskilled
> Novice class?" IOW, communication and tech writing, even in a Venn
> diagram, don't automatically overlap where the non-trivial aspects are
> concerned.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
