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: You Don't Need to Know How From:Peter <pnewman1 -at- home -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 25 Jul 2001 12:55:01 -0400
Andrew Plato wrote:
>
> "Ruth Lundquist" wrote...
>
> > Completely untrue. I have know idea *how* my double oven with convection
<snip> I'm not an engineer & I have no idea how to build an oven or
what makes it
> > work. Thus far, it has not been a problem. ;-)
>
> You actually do know how your oven works. You might not know every part
> number and element, but you have intimate knowledge of how it works. Its
> just that the oven is so simple, that you take the "how" aspect for
> granted.
>
<snip> But what about a three tier client/server implementation for a
medical
> claims billing software (I actually documented a program like this once.)
> Do you have even the foggiest idea how this works. Probably not.
>
> Hence the problem. You cannot properly document complex technology unless
> you have some understanding of how it all works. This is fundamental to
> understanding what it does and why it does it that way. Watches, VCRs, and
> stoves are terrible comparisons because they're obvious and commonplace.
I notice that Andrew was careful to differentiate How something works,
from Why something works. The latter encompasses an intimate knowledge
of all of the engineering aspects.
Having said that, In a good manual one should anticipate some user
problems. Although you do not have to know every nitty gritty, one
should have a basic understanding of what they are documenting. In
Andrew's illustration, you should at least understand the concept of a
three tier client/server, (which I consider a basic microsoft
recommended methodology.) You do not need to know if the SQL statements
were properly written, but you should know what it is that they are
intended to do and if in fact, they do it. Example in Andrews example,
you should be able to articulate how a change in billing rate or payment
timing expectation, is accomplished.
--
Peter
Mailto:peternew -at- optonline -dot- net
Adapting old programs to fit new machines
usually means adapting new machines to
behave like old ones.
*** 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.
