Occupational hazard of techie tech writers

[Carl Stieren <carls -at- CYBERUS -dot- CA>]

Hello Colleagues,

Are you a techie tech writer or are you someone who manages techie tech writers?
If so, what do you think of this analysis:

Anyone who is really into technology, and who becomes a technical writer,
has advantages and one big occupational hazard:

Advantages:

* ability to understand complex systems
* ability to learn how to use the functionality  of new software even when
parts of specs are missing
* ability to analyze a system and reduce it to its basic concepts
* ability to compare totally new methods or functions to existing languages,
protocols, systems

Occupational hazard:

* inability to explain software or functionality to a beginner (sometimes
even the inability to realize that you NEED to explain the software to a
beginner)

This all began with Plato. It's all his fault. Above his academy, there was
the inscription, "Let no one ignorant of geometry enter." The academies and
the universities that followed all copied this prejudice - you couldn't
enter university in Europe without knowing Latin until sometime in the 19th
century. 

Fortunately, there were other (preparatory) schools teaching geometry - and
Latin. Nowadays, no one is teaching every user of advanced software the
needed subjects (for example, basic programming concepts, true
object-oriented programming, principles of SGML, even TCP/IP).

We're told we can assume a certain level of knowledge, but unfortunately,
every one of our users is going to have forgotten some of the basic concepts
necessary to use any advanced software. And each person's forgotten concepts
are different from another's. Therefore, we have to include those concepts
somewhere in our documentation. We can't take too long explaining them or
other users will get impatient (not to mention our supervisors, who are
paying our salaries to document our products, not basic concepts).

Therefore, there's a problem. Any brilliant technical writer who's into
technology and hasn't done a lot of technical writing is going to produce,
as a first draft of a first project, a document that will fail usability
testing.

How can we avoid this situation? 

...or even correct it once it happens?


- Carl Stieren

---------------------------------------------------------------------

*/ "Glücklich ist, ver vergisst, was noch nicht zu ändern ist."  /*
*/                           - Johann Strauss, Die Fledermaus    /*

---------------------------------------------------------------------
Carl Stieren .............................email: carls -at- cyberus -dot- ca
Technical Writer and Designer.............<deep in Silicon Tundra>
Ottawa, Ontario, CANADA...................<1 hr 40 min from Montreal>


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