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: What tools to learn... From:Glen Accardo <glen -at- SOFTINT -dot- COM> Date:Mon, 27 Feb 1995 10:34:07 -0600
E-mail glen -at- softint -dot- com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text/plain; charset=US-ASCII
> When we hire people, we request tools knowledge. We are not stupid, and we
> are not a bad company. We also look at writing samples, give a writing test
> (I hated this idea until I learned how incredibly revealing it can be!!),
> and try to assess the candidate's technical aptitude.
> When a pubs department uses a desktop publishing package, a LARGE percentage
> of the writer's time (as much as 40-50 percent at times) is spent on the
> production of the book.
> Tsk-tsk to some of you. Posting to this list that "writing skills are
> paramount" is the ultimate platitude. A Tech Writer who can't write won't
> even get through the door here.
Everything Bob said is correct. Companies are interested in making a profit
from a product. We are both interested in meeting the same needs, and
probably meeting them with the same types of people. We do, however,
differ in our approach to getting the right person.
* Writing samples tell me if you can write, illustrate, make manuals.
You must be able to explain what you did and how -- equivelant to
Bob's writing test. I ABSOLUTELY MUST KNOW IF YOU CAN WRITE!!!!!
* I can make DTP painless -- at first. Typing in Word or FrameMaker
or whatever is the same. The difference comes in designing docs,
solving problems with the packages, and doing large projects from
scratch with them. I don't expect any of that from entry-level
people. But, when I look at people for contract positions, I look
very closely at those skills because they will greatly influence
a person's ability to get a job done right -- and fast.
* I can't hire a perfect, all-knowing candidate (cheaply). I absolutely
must invest in teaching a new hire something. So where do I compromise?
- Teaching a new DTP package is trivial. As Bob said, once you know
one, the second isn't much of a problem, and the third is near
trivial. Like I said, I want you to be knowledgable in making
manuals; FrameMaker is a bonus.
- Teaching DTP is more of a pain, but can be done -- under certain
circumstances. If you've used Word to make large manuals, at least
you understand the issues involved, and you aren't starting from
- Teaching someone to write is painful, time-consuming, and in many
cases, impossible. I won't do it. You must be able to show that
you can write like I want manuals written -- or very close to it.
- If you've never written a manual, I have a lot to teach you --
issues, skills, etc. ad nauseum. Even if your grammar is perfect,
you still have a LONG way to go before you are productive.
* Given the above (and a gazillion other factors) I need to decide if
you are worth hiring. To aid in making this decision, I make sure
that you understand what I need done (while trying not to tell you
what I want you to do and keeping a rather open mind). I ask how
you can fit into that frame work. Things go from there. I mix and
match complimentary skills.
glen accardo glen -at- softint -dot- com
Software Interfaces, Inc. (713) 492-0707 x122
Houston, TX 77084