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: Contractor and CorelDRAW From:Brent -dot- Jones -at- Level3 -dot- com To:techwr-l -at- lists -dot- raycomm -dot- com Date:Fri, 6 Oct 2000 10:06:29 -0600
Rick Vantour wrote in response to anon:
> I too am a contractor and someday hope to have the nerve of
> others I hear about who stroll in to client sites and demand
> that the client change their doc and illustration plan
> because they find a particular tool difficult to use.
I've always felt that learning and using pub tools is (or at least should
be) the most trivial part of what a seasoned contract technical writer does.
It should be a *given* that the technical writer either already knows a tool
such as CorelDraw or can learn it quickly enough that the time required is
transparent to his or her work on the project.
If I'm a contractor and want to be successful, I should already have a
current working knowledge of the tools my market (i.e. prospective clients)
will most probably have, or should be prepared to get up to speed damn quick
on one I haven't come across. That means Frame, Word, Acrobat, CorelDraw,
Visio, etc. In my experience, companies hire contractors because they need
people who can come into a situation, appraise what needs to be done
quickly, and get to work with the tools at hand. No two-week dead space
start-up period where I'm learning where the best break room snack machine
is, or getting my workstation and cubicle set up *just* the way I like it,
or learning their docpub app, or waiting for the client to order and install
the docpub app I prefer to use.
The caveat, of course, is that I can do a client a great service by
recommending tools and processes that they could implement to improve
product quality and efficiency. But this should only be done with the intent
of helping the client, not making my life easier or hiding the fact that
I've been too lazy to learn the basic tools of my trade.
It also indicates to me that there was a serious disconnect somewhere in the
hiring process. In my experience, when companies hire technical writers they
focus almost exclusively on the tools the technical writer can use, often
almost to the detriment of the really important stuff, like is the writer
smart, intellectually engaged, and a good writer. How'd the contractor anon
discusses get hired for a project involving the latest version of CorelDraw
when he or she wasn't familiar enough with it to get right to work?
The upshot is that anon's contractor should suck it up and use the tool
everyone else is using, and welcome it as a chance to get his or her skills
current on yet another oft-used technical writing tool.
brent -dot- jones -at- level3 -dot- com