Re: Knowing prog. lang. +s to a TW's $? (long)

Subject: Re: Knowing prog. lang. +s to a TW's $? (long)
From: Rebecca Phillips <Rebecca -at- QRONUS -dot- CO -dot- IL>
Date: Sun, 12 Jan 1997 11:07:13 +0200

The Tech Writer Asked:
>> Does knowing a programming language add to a technical writer's value?

And one respondent said
>> In my 30-some years of tech writing, I have usually not found that
>> knowing a specific programming language actually helps you do a better
>> job of researching and writing. <snip> I know about a dozen programming
>>languages, and > have rarely had to use any of them,

If you know a dozen programming languages, you don't know what it's like
not to know any. In one job I held, I had to let a technical writer go
because she didn't know the first thing about programming. (I hadn't
done the hiring.) The product was made up primarily of a scripting
language based on C, and it proved too great a task to integrate someone
who didn't know what a "variable" or "conditional loop" was. I felt
terrible about it, because the person was a competent writer, but it
would have been at least half a year of training to bring her up to par,
and my manager wouldn't approve the budget to send her to a programming

Other than specific applications, though, I think knowing programming is
invaluable in helping you keep on top of the informal flow of
information in your company. I took a couple of programming courses in
college, and I would argue that they were the most valuable courses for
technical writing, even though I have never written a program since.
Knowing programming is useful because:

1. There is nothing like writing a program to make you understand
logical mathematical and hierarchical flow. This improves your abilities
to organize material logically. That is doubly true for technical

2. Knowing a bit about programming helps you know what effort is
involved in creating and debugging features. My programming background
saved me a lot of work because I could predict more accurately than
salespeople which features were not going to be debugged in time to make
the next release. I could predict the documentation-vs.-programming time
line. Sometimes a "little feature" for programmers is a big feature for
us, and a feature that doesn't do anything visible to the user takes
forever to program.

3. If you can talk the talk, the programmers like you better. Some
people can pick up the talk without ever having written a line of code,
but it's a lot harder. Again, this doesn't help you directly with
writing the document, but it does let you in on information which might
not drift your way otherwise, like what bugs are really troublesome, and
what features are affecting other features.


Rebecca M. Phillips
Documentation Manager
Qronus Interactive Ltd.
Automated System Testing
rebecca -at- qronus -dot- co -dot- il

TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
Search the archives at or search and
browse the archives at

Previous by Author: Re: Checking the checkers through inaccurate information
Next by Author: Re: Web link testing tools
Previous by Thread: Re: PageMaker printing problems
Next by Thread: Re: Knowing prog. lang. +s to a TW's $? (long)

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads