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.
Subject:Re: Programming vs. Technical Writing From:"Wright, Joe - FWP" <Joe -dot- Wright -at- FMR -dot- COM> Date:Thu, 13 Aug 1998 11:51:13 -0400
Lisa Meng wrote:
<snip>
The comments that J. Fraser made about programming attracted my
attention, because I've found the same thing to be true when I
program.
I've been writing a series of short, web-based courses on
JavaScript,
which means I've had to learn some programming. I've noticed
that the
SME, (a "real" programmer), can write a program to accomplish a
specific task in a few lines of code; when I write a program to
accomplish the same task, my code is always longer.
This makes me think that technical writing and programming
approach
information in entirely different ways. When I write, I tend to
present
information step by step; the last thing I want to do is to skip
a step and
lose my reader. When the programmer writes code, he seems to
look for
ways to skip steps, or integrate several steps into one. His
main concern
is making his code short. Has anyone else noticed the same
thing? - LM
</snip>
Actually I would disagree. I don't think the programmers position is to
'skip'
steps per se but instead not to include any unnecessary steps. Such is
the case in Tech Writing where the TW attempts to be as concise as
possible, leaving out all information that is not necessary to the
subject.
Also, generally code that is compact and hard to follow is
considered poor code. If code is not modular, easy to read and
understand, then it is difficult to maintain or improve.
In most object oriented design languages, I have seen similarities
between the technical writing process and the programming process.
Each requires a methodical, logical, and modular layout. For example,
good programming practice is generally to keep each function very
simple, so each function only performs one, maybe two tasks.
Likewise, most technical documentation practices aim towards a
modular design, where each paragraph of text pertains to one
idea.
Of course, there are huge differences between the two practices, but I
think the thought process and design approach for each process is
quite similar.
