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.
