RE: Learning quickly

Subject: RE: Learning quickly
From: SIANNON -at- VISUS -dot- JNJ -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 28 Nov 2001 10:11:40

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


Previous by Author: Hidden digital signature in a graphic
Next by Author: RE: Ethics and Job-Hunting
Previous by Thread: Re: Robohelp HTML and Netscape 4.5
Next by Thread: RE: Learning quickly


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


Sponsored Ads