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:"Doc" <doc -at- vertext -dot- org> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 14 Aug 2002 12:19:10 -0400
Thank you Jane --
I was working on volume three of my rebuttal when you summed it up nicely.
I had my writers cultivate something that Zen practitioners cal a beginner's
mind. I wanted them to approach the documentation from an informed but naive
point of view. It is not an easy thing to do. But I consider TWs to be user
advocates and that skill requires a step back from expertise. Our job is not
to understand what the programmers are doing, but what the user will do with
it. If the user is a programmer you STILL cannot assume that their level of
expertise is the same as yours.
If you're an expert you don't ask questions. You base your reading of the
code and interpretation of the purpose of the code on your own knowledge of
how things should work. If you want to argue this point, first ask yourself
how many times you have seen programmers make faulty assumptions about how
the whole thing fits together and have to redo their code.
I have seen it too often. I saw a major commercial software project come to
a screeching halt four weeks before gold when it turned out that the
programmers working on an independent but critical module had totally
misinterpreted the code, hooks, and even the intent of the rest of the
product.
Problems in communication? Certainly!
Problems with project management? Absolutely!
But underlying it was the assumption that the expert programmers in the
independent group could understand how the code would be used by reading it.
The InfoDev group (that's me and my writers) had raised the alarm two months
earlier while going through our standard task walk-through. Even though we
only had a prototype and a PFS to work with, we could tell that things were
not lining up properly. Our warnings were ignored. The product shipped six
months late. But the QA and SWE team leads both asked to be included in our
walkthrough sessions from then on.
I don't read code. I can, but I don't. People who worked for me who did read
code were moved out of writing and into QA or SWE where they were much
happier than working for ...
Grumpy, dopey, sneezy, unhappy, wakeful, and certainly not bashful,
-Doc
---------------------------------------------------------------------------
David 'Doc' Lettvin
VerText
"Versatile Text for reusability and globalization" http://www.vertext.org
vox: +1.978.468.1105
fax: +1.775.248.0508
"Jane Carnall" <jane -dot- carnall -at- digitalbridges -dot- com> wrote in message news:165279 -at- techwr-l -dot- -dot- -dot-
> 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.
Snip
> 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.