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??? From:Simon North <north -at- SYNOPSYS -dot- COM> Date:Tue, 8 Jun 1999 15:02:56 +0200
Tim Alton asked:
> Is there really any significant number of tech writers
> who, in addition to the skills required to succeed even
> as a very technically oriented writer, know how to write
> C++ code?
No. In fact, in my experience they are very hard to find. My
employer in Silicon Valley was recently looking for a tech writer to
document a C++, non-GUI tool and wasn't having much luck at all.
Having said that, it cannot do any harm to learn. Apart from the
usual 'hobby' languages (I started with assembler in 1971), I have
variously programmed in Fortran, C/PM, Pascal, Lisp, C, Ada,
Algol, Modula 2/3, Basic, Java, various scripting languages and, of
course, C++. I wouldn't dream of calling myself a programmer --
and heaven help me if I ever have to earn my living from writing
code -- but a familarity with the terminology and methodologies
have proven invaluable. Granted, no-one -- not even the
programmers themselves can work from the source code (yes, I
*have* written docs using only the assembler source code, it's
possible - it just takes months to puzzle things out), but the ability
to at least scan code to extract the basic principles can be a
useful skill. [It used to really annoy me ten years ago or so when I
had to compete for jobs with so-called software tech writers who
didn't know the difference between an interpreter and a compiler ...
but then many of the products I've documented have meant really
getting familiar with the code itself (optimising compilers,
programming libraries, real-time virtual machine enviroments). ]
Once you get into online help development, the boundaries begin to
shift (oh, those happy days of manually adding RTF codes to Word
documents) ... when I got into IETM development, I found that I
really had crossed the line; the document *is* the software.
Apart from that, in 15 years as a tech writer I have lost count of the
number of places where some kind of document processing was
part of the production process. For these tasks I found that being
able to write Perl scripts was invaluable (I'd picked up
NROFF/TROFF, sed, awk, bourne/C shell script along the way on
various contracts). With the advent of SGML, add Omnimark,
DSSSL and Python to that ... the boundary between tech writer
and programmer becomes a bit vague.
Being able to at least hack some code (I still call myself a 'hacker'
in the original sense of the word) has also allowed me to move a
little beyond my normal job boundaries. Writing books (chapters for
HTML4 Unleashed, Dynamic Web Publishing and, my latest
"Teach Yourself XML in 21 Days") on computing subjects would
have been impossible if I hadn't been able to put together the code I
So, the answer to your question is no, there aren't many. You don't
need to learn to program but it certainly cannot do any harm now
and I predict that in the future it will become increasingly more
difficult to avoid doing so.
Simon North Tech Writer
north -at- synopsys -dot- com Synopsys GmbH
"Presenting XML", "Dynamic Web Publishing Unleashed"
"HTML4 Unleashed, PRE" and "Teach Yourself XML in 21 Days"
so many idiots ... so few comets.