Technical writing was not a job I set out to do. It was a 17-mile drive into the rural countryside from my house in town to PSL, the lab where I had worked as a programmer. Being in the country had its advantages. Often finding myself with little or nothing to do, I would go for long drives at lunchtime -- often a two-hour excursion -- and survey the rolling hills and valleys all over southern Dane County. Gasoline was only 20 cents a gallon in those years, so the cost of these drives was far less than it would be today.
Going somewhere was at least doing something -- I've always been very activity-oriented -- and I didn't feel nearly so guilty doing that as I did sitting in my office and reading yet another document that didn't really relate to anything useful. Most computer-related documents were very badly written. I would soon get my chance to do something about that, at least locally.
A budget crunch at PSL led to my being able to transfer to the campus academic computing center (MACC) in late 1969. From then until 1989, I had a succession of jobs that were all essentially writing tasks requiring a highly technical background. (Somehow I hadn't quite realized until now that 20 years of my life went away while I did that!)
When I started at MACC, the immediate assignment was to write a reference manual for the Sperry-Univac Fortran compiler then in use, and the bosses decided it might be a good idea to have it done by someone who had a sizable experience programming in Fortran, which I certainly did.
Subsequent reorganizations within MACC landed me in the Systems group, where I wrote handbooks and user manuals of all descriptions. A still later shuffle created a Publications group, consisting of one writer (later two) and one graphic artist. We had plenty to do, for in those days vendor documentation was notoriously bad.
The apparently difficult task with writing for a technically naive readership is to resolve complex material into an easily understood form that is relatively free of jargon. It turned out I had a talent for that.
I also liked document design work, mostly because it had tangible results. I didn't really want the task of producing our monthly newsletter, which was partly technical and partly promotional, but when I was offered the chance to rebuild it and do all the design work myself (we had lost the services of a professional designer through further cutbacks), I gave it my best shot. The next year it attracted some acclaim by winning several national prizes.
In time, as usually happens, the work became completely routine. The management, lacking the requisite technical and aesthetic prespectives, took little real interest in it, so it began to pall badly. There being few challenges remaining in the job, I too lost interest, which squelched any remaining incentive to be creative in the work. The final 3-4 years in that position were very difficult for me.
Release finally came in the form of an opening in the Network Engineering group, so at last I could go back to my technical roots and be a proper computer nerd. Thank goodness! Some of the skills I had picked up as our publications maven were quite usable in the new position. This proved to have both an upside and a downside.