Technical Knowledge Re: Benchmarking Technical Documentation

Subject: Technical Knowledge Re: Benchmarking Technical Documentation
From: edunn -at- transport -dot- bombardier -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 24 Jul 2001 17:30:42 -0400



Andrew Plato wrote:

>>Maybe you can gloss over some of the more esoteric aspects of the "How."
>>But a basic understanding of how something works is necessary to
>>documenting it properly. It should never be "optional."

Looks like we've resurrected the how technical is technical enough thread.

Andrew, I think you are often a little too tough on people that already have all
the technical knowledge they require. I challenge anybody who's worked up about
all those non-technical writers out there to come up with just one post that
says basic understanding of the topic is "optional".

As I document the operation of a subway car, and how to engage the propulsion
system, I need no knowledge what-so-ever about the processes involved with high
voltage DC to 3-phase high power AC inversion. Nor do I need to know anything
about the software complexities of how wheel slip and slide calculations are
made and how the IGBT transistors are controlled to modulate power output.

While I have an understanding of these issues, I can quite effectively document
the inputs required by the operator and the results they will experience while
operating the train without that understanding. I could even go a very long way
into documenting how to maintain and repair these systems without that
knowledge. Surprisingly I can also give them detailed operational instructions
without knowing the first thing about the railroad's operating rules and
regulations (although when we don't have that information we have to be rather
global with the "Established regulations take precedence" warnings).

I have yet to see anyone argue something to the effect that I don't require at
least an understanding of where the voltages go in, where they come out, and
where they remain live even when unplugged. Which is what whomever is identified
as anti-technical seems to be accused of. Now the more knowledge I gain about my
subject matter the better off I am and the quicker I may grasp what I have to
document. But also, I have no need of learning enough to design a train from the
ground up (although as a mechanical engineering graduate I suppose I have).

To bring all this to an example given, the knowledge about the intricate details
of watch operation may interesting, but if my boss says "We need a user manual
right away, they need to know how to put it on and tell time." I couldn't give a
rat's *** what makes the hands go round or if it's waterproof if I don't have
the time or budget to find out. If I obsess about how it works I'm just as bad a
writer as those that obsess about process or format.

Eric L. Dunn



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

Learn about tools and technologies for user assistance developers at
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.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.


Previous by Author: Salary - ARRRGGHHH!
Next by Author: Content and Format (RE: Benchmarking Technical Documentation)
Previous by Thread: Re: Slightly OT: Creative gift to team for meeting beta date
Next by Thread: Content and Format (RE: Benchmarking Technical Documentation)


What this post helpful? Share it with friends and colleagues:


Sponsored Ads