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.
RE: Damnit Jim, I'm a technical writer, not a writer!
Subject:RE: Damnit Jim, I'm a technical writer, not a writer! From:david -dot- locke -at- amd -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 10 Jul 2001 13:01:18 -0500
Glenn said:
> IME, engineers know their corner of the code, but not the system. For
> that matter, any application that is NOT directly related to computer
> science may already be outside of their field of expertise. (A drafting
> package, an accounting package, an electrical engineering package, a
> documentation package, etc. are outside the scope of what you learn
> getting a C.S. degree.)
Programming is the act of encoding a discipline into software. The
programmer must know both the software domain used to encode the discipline,
and the discipline being encoded.
You see this in interfaces. A dialog will have the dialog controls and it
will have the controls related to the discipline specific work being done
with the dialog. There are tool tasks that the application forces a user to
do, and there are the user tasks that do what the user intended to do.
Saving a file is an example of a tool task. Software forces us to create a
file. The Go pen computing system didn't have files. All file related tasks
except search were sublimated or allocated to the system. The user of a Go
pen computer looked up addresses, wrote down addresses, and dialed phone
calls. Those where user tasks. The tool tasks come from the implementation
domain. User tasks come from the automated domain.
User tasks come from the requirements. Tool tasks come from the design
processes and implementation technologies. Technology choices carry tool
tasks into an application. Unfortunately requirements are not written to
emphasize this, nor do APIs reveal what tool tasks are carried into the
application that uses them.
*** 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.
