Re: Damnit Jim, I'm a Writer, not a Programmer II: The Wrath of K ahn

[kcronin -at- daleen -dot- com]

Peter wrote
> for you non-programmers. try to decipher the meaning of a statement such
> as 
> 
> fprintf(urt, "%f.6 %s " , dr, (i=0;1+%r\d;++i));
> 
> Without a basic understanding of the language, few could tell whether I
> have made a syntax error, never mind the meaning.


Yup. You're right. You know stuff I don't know. And I bet programmers who
write in whatever code that is probably enjoy the fact that their work is
inscrutable to those who are not privvy to their area of expertise. I
can't tell whether they're doing their job well or not.

Well, that's not my job.

With my job, you CAN tell whether I'm doing a good job. Just try following
my instructions. If they don't make sense, you'll know immediately.

My job is to make technology-based products comprehensible to the people
who buy and use them. If your stance is that only people who can read the
above snippet are qualified to explain the product created by that code, I
respectfully disagree.

I agree that it is ESSENTIAL that I understand what the finished PRODUCT
does, and I better understand the potentially myriad variations and rules
inherent to that product.

But I feel no more compunction to understand that non-English-based code
you  wrote than I do to learn all about the electrical wiring used to
convey this information to my computer monitor BEFORE trying to comprehend
the words you wrote.

Maybe you have time to know everything. I don't. I'm more of a subscriber
to the Henry Ford school (in case this is something you DON'T know, he
felt it more important to know where/how to FIND information than to try
to contain it all within his brain).

And I think my viewpoint is not terribly inconsistent than that of what
Andrew has called "the tender user."

I've studied code. It definitely helps. ALL knowledge helps!

But to contend that the knowledge of code ALONE makes you a more effective
technical communicator is like thinking that knowing more about music
theory will make you play the voilin better, even if you don't practice
PLAYING the darn thing.

Do both. Be technical. Be a communicator. It can only help. But I do NOT
think that means you need to be a programmer. Or fluent in code. If you're
documenting a piece of equipment used in a chemistry lab, do you need to
be a chemist?

I maintain that it is the product you're documenting that you need to be
fluent in. VERY fluent.

But I regard an excessive emphasis on the sort of technical knowledge
required by the INVENTORS of the technology being documented to be beyond
the scope of my job.

Just my humble opinion. 


-Keith "I don't know why my toilet works, but I'm gonna flush it anyway"
Cronin


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

*** 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

TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com


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