This is the fourteenth entry in the O’Reilly Radar series about how alpha geeks got into computers. This story is from Tim O’Reilly, one of the authors of Unix Power Tools.
Tim O’Reilly’s Story
I was 23, working on my second book, about science fiction writer
Frank Herbert, when a friend named Peter Brajer asked me to help him
rewrite his resume. He was a computer programmer who’d mainly worked
contract jobs, and his resume showed his longest stay at any company
being about six months. I thought that wouldn’t do, so I rewrote his
resume to emphasize his skills rather than the positions he’d held.
It worked, and he landed a contract job writing a manual for Digital
Equipment Corporation, a hardware and assembly language manual for a
product called the LPA-11K Laboratory Peripheral Accelerator. Since
he wasn’t that comfortable with writing words rather than code, Peter
asked me if I’d help him with the writing behind the scenes. So I
subcontracted with him to do some copyediting and rewriting of the
text. Of course, I didn’t know anything about the technology, but
words are words, and putting them in the right order means
understanding the structure of a document and good prosody more than
it necessarily means full understanding of the content. My background
in classics, parsing difficult texts, was good training for the job I
was facing.
We made a good team, so after the contract was up, Peter proposed that
we go into business together. We applied for the next job, a user
manual for the Digital WPS-11 Word Processor, with the seemingly
unlikely story that pairing a programmer and a writer together
produced better documentation. The day we applied for the job at
Digital’s Merrimack facility, Peter took me into the Maynard facility
on the way up, and showed me my first computer, so I’d at least have
that much under my belt.
Fortunately, the WPS-11 manual was easy. The next job was a FORTRAN
manual for the LPA-11K, and by now, I was feeling pretty comfortable,
and did a lot of the writing directly. There’s a dirty secret in
writing technical manuals, of course, at least in that era, and that’s
that most writing was really re-writing, as there were almost always
technical specs to start from, and the job was to turn them into
something more effective.
We next landed some work at Hewlett-Packard’s medical division, and it
was here that I really began to fall in love with computers. What put
me over the edge were the regular expressions in the text editor on
the HP-1000 computers. Wow! You could do so much with a simple
script.
And I did a lot of great work in this period when I was first coming
to grips with computers. Since I didn’t really understand a lot of
the underlying tech, I just read and re-read the specs till I could
see the structure and connections in them. I didn’t make any
assumptions. I just tried to put things in the right order, and tell
the story in a way that didn’t surprise the reader. And it worked. I
also realized just how important it was to talk to people who did
understand the technology, and capture their knowledge in the manual.
A lot of the O’Reilly approach to technical writing was born in this period.
In this period, I got pretty good with the RTE operating system and
editors, as well as getting a handle on assembler and FORTRAN, at the
level of writing simple example programs for manuals. Eventually, I
broke up the partnership with Peter, as I’d learned quite a bit about
computers but he’d never got as comfortable with the writing side of
the equation, which is what we were charging people for.
The first computer I owned was an Osborne 1. I fell in love with
dbase II, and wrote my first independent program in it, a small
accounting system that we used to run the business for its first
couple of years.
I fell into Unix at a company called Masscomp, where I wrote the first
ever Unix system administration manual (which eventually morphed into
Aeleen Frisch’s Essential System Administration), sold them on an idea
for a readers’ digest version of the Unix man pages that I called Unix
in a Nutshell (yes, that Unix in a Nutshell, which they funded but let
me keep the rights to). I also became something of a wiz with sed,
formed my attachment to vi rather than emacs, and started tinkering
with troff. Steve Talbott, a full time tech writer at Masscomp, was
maintaining a custom troff macro package based on one originally
written by Randal Schwartz (yes, that Randal Schwartz) whom Steve had
worked with at Tektronix.
I saw troff as a real competitive advantage for my consulting
business, since in that era of “Letter Quality Printers”, it would
allow us to produce typeset (well, laser-printed) manuals. So I took
over the macro package, which we used in our documentation business,
and eventually our publishing business for many years. You might not
think of troff as a programming language, but it’s actually pretty
full featured, albeit very specialized, and the macro package I wrote
for the formatting of the original Unix in a Nutshell is probably the
most complex (and obtuse) program I ever created. Debugging it kept
me up for many an all-nighter. And some of the killer shell and sed
scripts I wrote to automate editing and indexing were pretty powerful
— I once personally indexed a complete 5000 page documentation set in
a weekend. (And the index was pretty good.) I’d use sed to search
for terms, and insert the troff calls for index entries, then extract
those and look at the structure of the index, then write new scripts
to refine the inserted troff.
I dabbled in C, but mainly to port Unix programs like writer’s
workbench (for which I had gotten source code at Masscomp) to other
Unix boxes we owned. I also wrote a killer C manual for Lightspeed C,
one of the first visual development tools for programming. I did a
bit of C++, but mainly just at the example program level, for some of
the books we did on X.
I was never a real programmer, but I was the company sys admin, troff
hacker, and scripting wizard for its first five or six years, till we
got big enough to hire other people to do those things. I’ve always
considered myself at best a journeyman hacker. But all that work I
did with recognizing patterns in specs that I didn’t at first
understand, and later in writing complex regexes to identify
micro-patterns in text I wanted to change, turned out to be great
training for recognizing big patterns in technology adoption.