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.
> david -dot- locke -at- amd -dot- com wrote:
> > Being a geek has nothing to do with the degree a person has. It
> > has everything to do with how the person approaches technology. A
> > person is a geek long before they get a degree. Geeks, "Technical
> > Enthusiasts," approach towards technology differently. They model
> > the application. These are the people that don't read the manuals.
>
> I agree that geeks experiment. But I disagree that they don't read
> manuals.
The main "losing my profession" thread is interesting and something
I felt I could contribute to, but not without some deep thinking. Geek
topics, however, are much more my home ground :-).
Geeks do indeed read manuals. However, geeks tend to have learned
the hard way that the typical manual wasn't written for them (particularly
bundled products). As a one-time tech writer myself, I know exactly why
this happens (and most of that has less to do with the writer than the
circumstances most bundled docs are written in). However, the fact remains
that most manuals are written in such a way that technically competent
people will skim through them as quickly as possible, trying to locate
the specific answer they need.
One of, if not _the_ greatest virtues of most O'Reilly books is
that they assume the reader is basically competent and will go do
their homework if they need further clarification on something. Most
documentation is written in a style equivalent to the "warning"
sections of the little pamphlet that came in the box - i.e. don't
leave anything out because you might miss something. From one point
of view this is a good idea, because most users don't read the docs
like a novel, they read them like a cookbook. However, when you go
overboard, you end up cramming each detail into the book a couple
dozen times, and now you're back to square one.
> Last October, I visited the head office on my monthly visit. Several of
> the coders had just come back from the Atlanta Showcase for Linux. All
> of them returned with at least half a dozen manuals on subjects rangng
> from emacs to perl programming. From the condition of the books on
> subsequent visits, these books have not only been read, but re-read and
> poured over, with their spines cracked and their page corners turned
> down.
If I had my digital camera, I'd snap a pic of my bookshelf, which
has (after a quick count) 36 books on it. And that's not counting the
rest of the books hiding in my car, my car's trunk, my bedroom, my
living room, and probably about a dozen I unexpectedly left behind at
a job a couple years ago (and have been gradually replacing as I
needed them), or the half dozen or more I've loaned to friends.
Aside from either analytical or technological aptitude (which
might be mostly the same thing...) there are three things that make
geeks geeks.
First is an enthusiasm to understand things - every and any
thing, and technology in particular. What I find really rewarding
about being around most geeks is that, besides any given geek probably
being knowledgable about a dozen different topics, they are usually
interested in _becoming_ knowledgable about all sorts of topics, even
ones that they wouldn't normally tackle. Attitude counts for a lot in
solving any problem. Assume that a problem _can_ be solved, assume
that mastering the necessary tools and skills _is_ within your reach,
and tackle it.
Second is a lot of experience at analyzing and understanding
things, particularly technologies of course. The result of this vast
experience is that the typical geek can sit down at a completely alien
software package or pick up a completely new device and fiddle with it
until they achieve some sort of basic competence. Obviously a lot
depends on their familiarity with the problem domain - a geek who's
never done any serious financial work will probably not have much luck
deciphering a specialzied actuarial application, for example.
This also applies to learning the underlying technology. Most
programming languages are in fact not that different. One procedural
language is typically very much like another. A skilled programmer
can usually learn another language fairly quickly.
Eric Raymond (a luminary in the geek community, author of various
important Open Source essays like _The Cathedral and The Bazaar_,
editor of The Jargon File, aka _The New Hacker's Dictionary_ [MIT
Press], etc) advises most wannabe-hackers to learn at least three
fundamentally different programming languages, (procedural,
object-oriented, and functional) because they each have inherent ways
of thinking about and solving problems
(http://www.tuxedo.org/~esr/faqs/hacker-howto.html#SKILLS1).
In learning a lot of programming languages you also learn how to
learn programming languages quickly and effectively. More to the
point, once you acquire these thinking tools the hard way, the
particular dialect you express yourself in is usually relatively
trivial.
(By the way, I highly recommend checking out, http://www.tuxedo.org/~esr/writings/ to see how geeks write and think
about themselves, if nothing else).
Lastly there is a more subtle issue, what The Programmer's Stone
calls Mapping vs. Packing. I don't entirely apprehend this - this is
one of the ways in which I'm really only a psuedo-programmer, cheating
like hell to keep up :-). One of the problems is that The
Programmer's Stone claims that conventional language is
packing-oriented and inherently cannot describe mapping, and I have
yet to wade through this massive and somewhat rambling document
(http://www.reciprocality.org/Reciprocality/r0/Day1.html, especially
the section titled "The Ways of Mappers and Packers") to figure
out what they're talking about.
But what I think they're talking about is a phenomenon I've
observed in many of the proogrammers whom I recognize as being truly
creative in that weird coming-at-things-from-a-warped-perspective way.
In essence, when I set out to learn a new problem domain, I go about
it using the standard research techniques I employed as a techical
writer. Gather information, follow up leads, look for an underlying
pattern, a symetry to the problem model, and construct a coherent
picture. This works pretty well in programming, and I'm pretty good
at it even for a writer (I think), so I manage to make it work well
enough for me to keep up with the demands of programming.
However, some problems defy this attack. Some problems, I end up
banging my head against a wall until somebody else comes along and
writes a cogent, coherent book about it. Then I buy the book, inhale
it and start to figure it out. This has been bubbling away at the
back of my head for a while, because I've had pretensions of writing
such a book, but all of the technologies that I've gotten down and
dirty with early enough for the opportunity to be there have defied my
standard research techniques.
The alternative, which I've sen employed by a bunch of folks
whose programming and thinking ability I highly respect, is a sort of
autistic/meditative process of going over massive, insanely detailed
documents without trying to come to judgement or build a framework or
discern a pattern, until they have reflected enough on the topic to
truly understand it in a deep sense. This sort of thing drives me up
a wall and makes me extremely impatient, but if it's a skill that's
acquirable, I need to acquire it.
*** 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
Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See http://www.infomap.com or 800-463-6627 for more about our solutions.
---
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.
