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.
If you see my most recent post, you'll see that I absolutely do NOT
advocate ignorance.
You MUST understand what the product does. And, you MUST have the big
picture (as opposed to the tech writer who is content to put on his
blinders, document the 10 screens in the module HE's assigned, and have no
idea what the main product does). I think we're closer in our opinions
than you think - with the exception of our views on the importance of
knowing the UNDERLYING technology.
I think you need to understand the PRODUCT. If that's what you mean by
"understanding the technology" then you and I are in complete agreement.
But - I do NOT think I need to understand the programming. No, it can't
hurt to understand the programming, but I don't feel it's necessary. And
as I'm sure you've seen, a little knowledge can be a dangerous thing. If
I, with my surface knowledge of COBOL, C, C++, and VB, were to make a
suggestion to a programmer that he should do something in a different way,
I do NOT think my opinion would be well received. My experience with
developers is that they LIKE being the Wizard of Oz (pay no attention to
the man behind the curtain) and are NOT receptive to ideas that question
the programming decisions they've made. Yes, it DOES help you converse
intelligently with them, but deep down they're thinking "If he was a REAL
programmer, he wouldn't settle for writing mere MANUALS!" Incidentally, I
get along great with developers, so please don't think this is an
anti-developer rant.
And I'm not one of the Style Guide Sissies that Andrew so despises. But I
AM content to leave the programming to the programmers, and strive to
develop well-rounded knowledge of the product I'm documenting.
If it's a very technical product (such as some back-office software I've
worked with), then "learning the product" becomes a more technical task.
You DO need to understand (for example) how a user's input will touch the
database, what records will be created, and what modules are affected.
Absolutely.
I am not advocating the "I pressed this button and the screen turned
green, so in my documentation I wrote 'Press this button to make the
screen turn green.'" approach. I've seen tech writers do that, and I
don't respect it any more than I assume Andrew does.
What I DO advocate is growth.
I WAS a newbie; now I'm not. And a year from now, I hope to be even
better. But even as a newbie I really believe I created some useful and
accurate documentation.
I'm encouraging others to attempt the same. And then to get better at it.
After all (much like being a member of Menudo), nobody gets to be the "For
Dummies" poster child FOREVER!
-Keith "have you hugged a user today?" Cronin
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by an
anonymous satisfied subscriber since 1994.
---
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.
