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.
1. Most academic programs for practical fields include tools as a part of the training - carpenters are taught to use their saws, sanders, chisels, et cetera, properly during their training. Programmers are taught to use the various development suites (Visual Studio, for example) as they go. However, technical writing programs do *not* teach tools (or skimp on them). Since companies don't want to waste time teaching you how to use the tool of your trade, you have to learn it on your own. I see many technical writers who are totally unaware of this situation (I was one of them), so I make sure to tell newbies that they must start now learning - and keeping up with changes in - the tools.
2. The nature of tech writing has changed. In the past, there were few writers and many products, so tools *weren't* an issue - writers could get jobs on the strength of their writing skills/knowledge alone. Today, all those English majors (of which I am one) found out they could make money with their degree and started billing themselves as tech writers. At the same time, the choice of tools was narrowed to handful. Thus, it is not difficult for the writer to figure out what may be used - and learn those tools.
3. As the tech writing field has matured, companies have developed expectations of what they want. They no longer trust people who *say* they can use - or quickly learn - some tool (perhaps they were burned by a writer who *said* they can use a tool, but don't really (I'm stepping in after one of these people) and end up causing all kinds of problems (as with my company)).
4. In a sluggish market, tools become the means to weed out potential candidates. Why should the company hire Johnny Lately who doesn't know RoboHelp when Susie Sunshine already knows the product? Even though Johnny might have used ForeHelp and can easily switch to the new interface, the company doesn't want to take the chance. I can't count the number of positions that I've lost because the recruiters were so stuck on a pre-defined menu that they wouldn't even listen to my qualifications or proof that I learn tools quickly.
And if the position is a contract position, the writer might not have time to learn the product.
Learning tools is not the same as applying the theory of delivery format (an equation most people make). Just because you know what goes into making a help file doesn't mean that you can launch RoboHelp and be productive. You have to learn the jargon, menu system, and development windows - as well as the program's limitations and expectations. Those are completely different from *knowing* how to write and organize the help topics - and can only be learned through use.
Of course, knowing the delivery format well *does* aid in learning the program (at least you know what to look for).
The trick to tools, of course, is getting familiar enough with different interfaces so that you *can* move easily between the familiar and unfamiliar. You must also demonstrate that you can do this.
My point is that you have to have a starting point. And since there just aren't very many major tools out there, take the time to familiarize yourself with them - and actually do some projects for your portfolio. Prove to the recruiter that you *know* both application and theory.
--- dmbrown -at- brown-inc -dot- com wrote:
>I've never gotten a job because I knew how to use RoboHelp or any other help authoring tool.
>
>I've gotten jobs because I knew how help worked[1]--what files were needed, which ones could be adjusted by hand, how they fit together, how to connect them to the application, how to fix them when the authoring tool screwed them up, and so on.
>
>Once you understand the delivery format, learning *any* decent tool to create it should be a triviality. If it's not, then the tool's too complicated.
>
>If you don't understand the delivery format, though, the client will inevitably end up paying you to sit on hold, waiting for the tool vendor's tech support.
_____________________________________________________________
Jeff Hanvey: http://www.jewahe.net
_____________________________________________________________
Select your own custom email address for FREE! Get you -at- yourchoice -dot- com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Experience RoboHelp X3! This new RoboHelp release combines single sourcing,
print-quality documentation, conditional text and much more, into the most
monumental release of RoboHelp ever! http://www.ehelp.com/techwr-l
Enhance, optimize and automate your FrameMaker-to-PDF workflow with TimeSavers:
Define all PDF features in your source FrameMaker files ONCE, distill MANY.
Bookmark Controller, Link Controller, UnBloat & more : http://www.microtype.com
---
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.
