Re: Employers' Mistaken Job Requirements

["Eric J. Ray" <ejray -at- RAYCOMM -dot- COM>]

At 04:54 PM 1/27/99 -0800, Andrew Plato wrote:
>Oh, Elizabeth.  There are so many times I have fretted about this same
>issue to the list.  The sad fact is too many writers out there are
>still obsessed with their tools and not their ability to learn and
>write about complex technologies.  Thus, the companies that hire
>writers think the measure of a good writer is his/her experience with
>Tool A or Tool B.  It never occurs to them to ask "Do you know this
>operating system?"  or "How does inheritance work? or "What does a
>router do?"

And the truly ironic aspect of this conundrum is that writers
who can effectively _learn_ about and _communicate_ about
complex technologies of any sort rarely, if ever, have
difficulties learning to use any tools at their disposal.
That's not to say that people don't hit obstacles or difficulties
when picking up a new tool, but with the resources on
the 'Net, including but certainly not limited to this list,
it's getting pretty hard to come up with a substantive
tool use problem that's not documented adequately
or addressed on the Web somewhere.

While I certainly wouldn't say that the "tools of the trade"
aren't important--if for no other reason than a reasonable
command of the tools can make writers much more productive--
picking up a new tool or ten shouldn't pose much of an
obstacle.

Veering around to something that I think would be
an outstanding interview question, and certainly
good for some interesting discussion...

How do you learn new tools (in the narrow sense),
technologies, or products? I'm not asking about learning
theories or "how it should be done" and certainly not
about how your documentation is structured.
I'm asking about your real experience and approaches
to learning new stuff on or about the job.

For example, if I'm dealing with something I can see
or manipulate, I just start tinkering with it. I'll
try creating a new document/database/service order/
or whatever, will see how the pieces fit together and
operate (in a physical sense, not in terms of computer
software), and will just try to be productive. In the
context of computer software, I will experiment with
menus, will review the preferences and options that a user
can set. I use online help rarely, if ever, and
resort to online or hardcopy documentation only when
stuck. (For me, online "help" is usually too superficial
to be useful to address the issues I get stuck on, and
I'm usually dealing with a conceptual hurdle to overcome.)

If I can't see or manipulate it--like a UNIX command
or something similar--I start with help, then go
to online docs or man pages, then hit the Web for
overview or conceptual information.

I rarely want to ask questions about the <whatever>
until I feel that I have a good grasp of the <whatever>
and how it's used. That is, I want to ask questions
of developers or engineers when I've got enough of
the fundamentals down that I can effectively use the
engineer's time and mine.

I find that identifying connections between and among
different products and technologies really allow me
to understand the technologies well enough to see
what's significant, different, or worthwhile about them.

Other thoughts? How do you learn new stuff on the job?
Eric


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Eric J. Ray    RayComm, Inc.
http://www.raycomm.com/      ejray -at- raycomm -dot- com

*Award-winning author of several popular computer books
*Syndicated columnist: Rays on Computing
*Technology Department Editor, _Technical Communication_


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=