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: Being an Expert From:"Jane Carnall" <jane -dot- carnall -at- digitalbridges -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 14 Aug 2002 15:12:23 +0100
<Very good example John, and it points out a very important part of our
role, <I think. We sometimes, because of our lack of knowledge or because we
are not <as close, can pick out something that a whole room full of experts
sometimes <miss.
I'm middle of the road on this one, and therefore likely to get knocked down
at any minute.
I think that a GOOD place for a technical writer to start on a new project
is as a non-expert - someone who doesn't know a thing about the current
project, but who DOES have a background in the same technical area. (How
wide you want to stretch the area and how vague the background can be is up
to you.) This state of non-expertness does not last.
Assuming the technical writer is intelligent, curious, and motivated, the
writer will end up with a detailed knowledge of the project that will be
DIFFERENT from the detailed knowledge that the developers have. The
technical writer may not know the gritty details of each coding decision
(though I don't believe it actually matters if s/he does) but what they WILL
spot, that a developer might not, is something like the problem John
offered: that a list of figures, the same every time, is slightly different
in just one instance. Spotting that didn't require either an expert or a
non-expert: it required a writer with an eye for detail who was looking at
ALL the strings of numbers.
Which is - sort of - my middle-of-the-road point: we shouldn't be comparing
ourselves to developers in terms of expertise. We're not developers. We're
offering an entirely different kind of expertise - and that's the point.
Jane Carnall
"Praise then darkness and creation unfinished."
Apologies for the long additional sig: it is added automatically and outwith
my control. Home: hj -dot- carnall -at- virgin -dot- net
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Save up to 50% with RoboHelp Deluxe. Get 2 great products for 1 low price!
You'll get RoboHelp Office PLUS RoboDemo, the software demonstration tool
that everyone's been talking about. Check it out and save! http://www.ehelp.com/techwr-l
---
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.
