RE: This too is technical communication

["Lauren" <lt34 -at- csus -dot- edu>]

> -----Original Message-----
> From: techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com 
> [mailto:techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com] On 
> Behalf Of Chris Borokowski
> Sent: Friday, June 01, 2007 1:08 PM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: RE: This too is technical communication
> 
> Not if they're part of a development team. The entire
> debate has been misunderstood by some individuals,
> yourself included, in that there's a vital
> distinction:
> 
> 1) User interface
> 2) Internals
> 

I think that the problem lies in the fact that there are many technical
writers involved in many phases of the development process.  What you failed
to see in my position, is that the fact that technical writers are involved
in many disciplines does not imply that technical writing enables the writer
to become a part of the other disciplines.  Other qualifications can help a
technical writer become a part of other disciplines, but technical writing
does not cause this.

Allow me to explain further.  Documenting the "user interface" does not
qualify a technical writer to design the interface.  Documenting the
"internals" does not qualify a technical writer to develop applications.  It
is easy for technical writers to become arrogant because technical writers
document the details of many aspects of a product.  But understanding a
product well and documenting it does not by any stretch imply that the
writer can build the product.

Here is an example.  Assume that all of the premises (P#) are true.

P1:  God created the world.
P2:  I fully understand the workings of the world.
P3:  I can explain the workings of the world to people.
Therefore:  I can be God.

The point I have made again is that knowing how something works does not
qualify a person to build that something.  This does not mean that that
someone cannot be builder, but that knowledge of the workings do not qualify
a person to build.  A person can build because that person is qualified to
build.  Technical writing does not qualify a person for the position of an
architect.  The writer may be independently qualified, but not by virtue of
being a technical writer.  

Developers may have more qualifications for being systems architects because
they need to work with the designs, but that is a stretch too.  Saying that
a writer can be an architect because the writer understands architecture is
an unrealistic stretch.

> Technical writers link user to goal via product. This
> is where their information architecture skills come
> into play, much as they do in those designing
> enterprise apps.
>
> I think many here don't understand that this context
> is necessary to interpret the comments made, and so
> have taken them out of context and drawn their own
> conclusions.

Here is where you are confusing things.  You said that technical writers
require information architecture "skills."  I said that being a technical
writer does not qualify a person to be an information architect.  Although
an information architect can be a technical writer and a technical writer
may have enough skills to be an information architect.  Being a technical
writer does bestow the skills of the discipline documented upon the
technical writer.

Requiring skills from a discipline cannot qualify a person for that
discipline.  If that were true, then my experience in documenting, for
example, .NET applications would qualify me to be a programmer.  This simply
is not true.  Of course I can write code, but I am not a programmer.  I have
documented networks but I am not qualified to be a network engineer.
Documenting a discipline does not qualify me to work in that discipline.

Lauren

> 
> --- Lauren <lt34 -at- csus -dot- edu> wrote:
> 
> > Technical writers document the product that exists,
> > after it has been built
> > by developers. 
> 
 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include support for Windows Vista & 2007 
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

Now shipping: Help &amp; Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help &amp; Manual: http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.