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.
Nick made a lot of worthwhile points, and made them better than I would. Below
are a couple of his comments I wanted to expand a bit. One positive and one
--- "Klasovsky, Nick" <nklasovsky -at- nordson -dot- com> wrote:
> ....what frustrates me is technical writers
> with degrees/certificates in TW/TC who are completely clueless. Believe me,
> I've seen plenty. I've spent 22 years writing and illustrating technical
> manuals for industrial equipment (hardware, if you please) and I've seen the
> Degreed writers that apply for and accept jobs writing hardware manuals who
> don't know how to read blueprints, don't know how to use a screwdriver, and
> refuse to learn.
To me, the key statement above is "refuse to learn." Learning new things is
such an important part of being a Technical Writer. I know that as a
reader/user of technical documentation, I get very frustrated with instructions
that were obviously 'written' by someone who never DID what they're telling me
to do. I can put up with the occasional 'creative' use of the English language,
but if the information is bogus or incomplete, that is hard for me to deal
with. Documentation that is wrong, especially because the writer didn't make
sure the information was correct, is worse than useless.
And I think such documentation generally comes from writers who are unwilling
to learn about what they're allegedly writing about.
> Degreed writers that can't design the first graphic for a hardware manual.
I dunno about this one, Nick. I do draw some flows from time to time, but
that's about the extent of my graphics capabilities. I am tempted to say that
graphics abilities are far removed from verbal skills (but I don't have
anything to back that up other than my own limitations <g>). One of the losses
I personally lament in the evolution of Technical Communication is what appears
to me to be the demise of the Technical Artist. With the advent of the PC and
such programs as Visio, the writer seems to be expected to do everything in a
document, especially the graphics. (If I were Dr. McCoy of the old Star Trek
television series, I would be complaining to the Captain: "I'm a writer,
dammit, not an artist!")
That doesn't mean I don't try my best a graphics, layout, design, and
execution, but I recognize that I do a much poorer job than a competent
Technical Artist (or whatever title is more appropriate) would do. I worked
with one early in my career. She was a pain in the butt, but she was a
competent Technical Artist.
Save $600: Create great-looking Help files and software demos with
RoboHelp Deluxe. Get RoboHelp and RoboDemo - our new demo software - for one
low price. OR Save $100 on RoboHelp Office in June with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
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.