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.
> --- Bruce Byfield <bbyfield -at- axionet -dot- com> wrote:
>
> > Another thing: technical writers who don't have some knowledge of
> > code - even a limited one - may be at the mercy of what developers
> > bother, choose, or remember to tell them. Not only is this
> > dependency another reason why developers may despise writers, but it
> > means that, in some cases, you can never know first hand whether you
> > are doing a good job or not. This dependency is frustrating and
> > inconvenient.
>
> YES! This is exactly what I meant when I said "anticipate issues."
>
> I cannot tell you how many times the engineers managed to "forget" to tell me
> something. However, because I understand how they built the product and what it
> does, when I see something new, I can anticipate their changes and as such
> confront them first. This DRAMATICALLY cuts down on the time it takes me to get
> information because I can ascertain a lot of it myself.
> Similar to what Bruce said, it also lets me get the jump on how users might
> object to such a change and discuss the issue with the engineers before it is
> cemented in their heads. A lot of the complains tech writers have about
> engineers ignoring their UI suggestions are because the tech writers don't
> anticipate the UI change until it is too late.
>
> Andrew Plato
Programing knowledge is not the only way to achieve this - with business knowledge
I know what the end user needs to do, and from writing for numerous applications in
multiple business areas I know how many different applications work.
I have even at times pointed out functionality to programmers that they were not
aware existed.
All this with no programming knowledge.
I'm not saying programming knowledge is not useful. It is one tool, one of many. A
good Technical Writer should have many such tools, and should use as many of them
as possible, or they run the risk of becoming too specialised themselves, and
unable to act as interpreter, or my preferred analogy, bridge, between
programmer/application and end user.
Ceri Williams
cwilliams -at- basis100 -dot- com
These are my personal views, not necessarily the views of my company
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 SOLUTIONS, Conferences and Seminars for Communicators
Publications Management Clinic, TECH*COMM 2001 Conference, and more http://www.SolutionsEvents.com or 800-448-4230
---
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.
