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.
> > It is largely the idea that a technical
> > writer has to know as much as the SMEs going in to the job that I
> > disgree with -
As always, it's horses for courses. I don't think you would get very far documenting EDA software without a basic
grounding in electronics at the very least. I agree that you shouldn't be up to SME level, either going in or in the long term
(although there was one instance where have I ended up being the only SME for the product by dint of translating the
source material I used to write the docs, then installing the equipment and ultimately training on it too). I would certain
agree that a certain distance from the products (aka objectivity) is a good thing. You should, however, be able to think
yourself into the shoes of your readership.
Our readers are predominantly post-doctorate electronics engineers (hardware and software). Getting a TW at that level
would be asking too much, but it does mean that a new recruit usually has a pretty steep learning curve to climb. Without
a sound technical background, that curve becomes insurmountable.
The TW is expected to learn to use the software, which means becoming at least passingly familiar with C++, SystemC
and one or more hardware description languages (HDL, VHDL, Verilog). No-one expects competence, but being 'totally
naive' would be useless. You might - might - just be able to 'figure' things out, but not within any reasonable time frame.
Maybe it is a bit like investigative journalism, but you need to be able to ask the right questions to get the right answers.
In my group, we are held in pretty high esteem. Indeed, our management sees little real difference between us and the
software engineers other than the nature of our output - and with increasing online delivery even that distinction becomes a
little vague at times. We are fortunate in contributing to the development, participating in testing. It's what makes this
such a wonderful place to work :-)
Simon.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
---
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.
