RE: Learning quickly

[SIANNON -at- VISUS -dot- JNJ -dot- com]

[snippage]
>  My question...how is this done. Does it mean that the writer 
>  must simply be brilliant and extremely smart (as is my case :-) ) 
>  or does it mean that someone must know a technique or skill 
>  on how to do this?

The former is helpful, the latter is essential, whether they consider it a 
technique or not. (technique often comes from, or is shaped by, instinct 
and the way you naturally learn--many folks therefore don't think of it as 
something formal or deliberate)

[more snippage]
>  Or does it mean that before you put Word-One on paper, that you 
>  must spend days and days pondering every spect of the subject?

Good lord, no.  ...there simply isn't time.  Also, visual learners often 
work best by drawing, diagramming or outlining what they are trying to 
grasp.

[snippage of example resulting in easier Helpfile generation]
>  Does any of this make sense?

Yes.

There are a couple steps I can see in the process of learning for the 
purpose of writing about a topic:
     1 -- gather input (data on topic)
     2 -- identify the knowledge needed to produce the expected output 
     3 -- organize data received into those categories
     4 -- digest the data, and see if it provides the information needed
          (gap analysis)
     5 -- return to SMEs and repeat as necessary to build understanding,
          fill gaps and flesh out details

My comments on each step:
1 -- Herein lies the people skills and scrounge factor. Knowing the 
questions to ask improves the data received, but sometimes you can't 
identify those questions until after the initial pass.

2 -- The knowledge needed usually manifests as categories derived from 
doctype templates -- if you have no template, you will need to identify 
what these categories are anyway, to know what you are including in your 
doc.  This doesn't need to be as complex as a document plan, nor as formal 
as a written document. It can occasionally present a challenge, though, if 
you hit an environment without consistent documentation processes (which is 
often why we are hired to begin with), and have to ask other SMEs what 
content is expected in that document type _at_that_company_.
     For example, a while back I had been given 10 vague, half-defined 
categories as section headers for a System Maintenance Procedures doc, 
without any indication of what needed to be *in* those categories, and the 
SMEs were disputing some of what I thought needed to be included because 
they were equating the vaguest, lowest common denominator with "less work" 
(which is not always the case and not always up to what the regulatory 
bodies need/expect).

3 -- I'm a visual learner, so when I wade into a concept, I often try to 
draw or diagram the relationships of elements of the concept.  Depending on 
the subject, this may result in anything from an outline listing all menu 
items, to process flows and command paths, to floorplans and network 
diagrams.

4 -- I highly recommend multiple-pass approaches, where you start by trying 
to gain an overview, and then drill down.  Some design documents I've read 
(by established consulting companies, even, though I have reason to believe 
they were generated by programmers, not writers) have given me a headache 
by the seventh page, because they go straight to detailed data grids 
without explaining what the system is supposed to do (is it a human machine 
interface, a data processing application, or a coffeemaker?) nor what the 
contents of those grids pertain to in real life.

5 -- This is where the donuts come in handy!   :) 



Shauna Iannone
--------------
"Don't worry about it."  *twitch*twitch*

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you 
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of 
your book. What are you waiting for? http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
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.