Informal Career History
(or how I became a technical writer)Caution: This section may be terminally boring unless you like big iron and dinosaurs.
All through high school, I seriously considered becoming a professor of Anatomy and Physiology. My love of science, chemistry, and biology—as well as the deep enjoyment I experienced helping and tutoring - teaching - my peers in those subjects—served to deepen the goal.
I entered college immediately after high school to achieve this; I wanted to teach, and enjoyed teaching. Unfortunately (or maybe fortunately?) I also had to work to support myself while attending college.
I started as an entry-level computer operator, running an IBM 360/30. The rest, as is said, was history.
It was absolutely fascinating to me; not only did I learn to operate the IBM 360/30, but I also learned the IBM 8080 and other wireboard-controlled machines. Within a few weeks, I was also a part-time computer operator for the Xerox Sigma 6 as well (think paper tape, teletype terminals, and punch cards). I quickly learned Basic, Fortran, and assembly language on both machines, and was intrigued by the machine-dependent differences.
The 360 was later replaced with an IBM 370/158; and I learned MVS JES2/JES3, VM/CMS, and JCL along with COBOL (shhh!), new versions of Fortran, Basic, and assembler. By this time I had been promoted to Computer Operator, and was operating both computers full time.
In the meantime, I had earned my AA degree in biochemistry. I was seriously considering switching my major and minor; unfortunately, computer science courses were not available. There was no such thing as a "computer sciences degree" in 1971. The closest matches were in electrical engineering, and the majority of the prerequisite courses had nothing to do with computers and computing theories at all. I audited all of the courses; but realized quickly that I was learning far more about computers, computer theories, and computer science on the job.
It was a very difficult choice. I was married, and had a three-month old son. I talked it over with my wife, and with other members of our families. The decision was effectively made for me when I and my wife were laid off along with 20% of the work force. So, I dropped out of college (with 17 credits left to go to get my teaching credentials) and concentrated on learning everything I could about computers on the job.
My next job was with a Department of Defense contractor, where I was a computer operator for an IBM 370/158 running MVS JES3. At first I worked the graveyard shift, while the FBI and the DoD did the background checks needed to grant security clearances. In the meantime, I was teaching the other computer operators MVS as well as JCL and MVS utilites. This, combined with the top secret and above clearances, resulted in my being moved to day shift to run the secure IBM 3031.
One day, I needed to swap out a disk pack on the mainframe. I knew it could be done while it was running, but was uncertain of the procedure. I looked in the Operations binder (a 3-ring binder containing notes and procedures written by operations staff) and found the procedure: Hand-written on standard binder paper.
I looked at the computer, looked at the printers—and went to my manager and asked her for permission to computerize the operations procedures.
She granted permission, and over the next few weeks, I entered, edited, and organized the contents of the new document as text files (using Conversational Remote Job Entry—CRJE, a single-line editor—fun!); printed them out, and then learned about the types of EBCDIC printer control characters and inserted page breaks where needed. Once I was satisfied with the organization, I manually created the table of contents and index.
When I completed the task, I took the manual to my manager, and as she and I reviewed it, one of the programmers stopped by. He asked to see the manual, complimented me on its thoroughness and layout, and then asked "What did you use? Waterloo Script?"
My manager and I looked at him and asked "What's that?"
He showed us, and I was off and running; learning Waterloo as well as IBM Script GML.
Within a year I was promoted to senior computer operator. By that time, I was also writing operations and data center analysis and support programs using COBOL (hey! quiet!) and 370 Assembler, and documenting them using Waterloo Script and IBM Script GML, which lead to my promotion to Operations Analyst. In this position, I was responsible for scheduling and maintaining all production, including system backups and disaster recovery processes; all of which I thoroughly documented.
Six months later, I was contacted by another company. A former coworker and friend had changed jobs and informed his management in his new company of my abilities, and that company contacted me. I was curious, replied, went to the interviews, and was subsequently made a substantial offer to join the company as a senior operations analyst; which, with a family to support and my wife no longer working, I could not refuse.
Once again I found myself in an environment where there was a marked lack of data center procedural documentation—backup schedules were posted on a chalk board, for example; and the only documentation available was that provided by the equipment manufacturers (aka OEMs) for the IBM MVS and VM/CMS systems. In addition, quite a few support tasks were done manually; for example, machine availability reports were calculated manually and then painstakingly entered in a text file using TSO/ISPF.
Within a few months, I had written a program automating the system availability reporting as well as other formerly manual support processes, and had thoroughly researched, compiled, and documented all corporate data center procedures using Waterloo Script. In the meantime, I was also teaching the computer operations and data center support staff MVS JES2, VM/CMS, and MVS JCL and Utilities, simply because they wanted to learn, and I enjoyed helping them learn. To facilitate this, I wrote several reference and tutorial manuals for the staff, including examples of how to run various utilities using JCL, and including exercises for the reader to reinforce what they had learned.
This came to the attention of the training department, and they asked me to work after hours twice a week—at contractual rates—as a formal instructor of OS JCL and Utilities as well as MVS and VM/CMS Concepts and Facilities, using the course material I had developed and written. I gladly accepted.
During this time, I moved into systems programming and data center management—said jobs accompanied by an electronic leash (aka pager)—and was responsible for the upkeep of an IBM 370/158, an IBM 3031, three Ahmdahl V7s, and a massive horde of 3350 disk drives. I again researched the existing procedures and documentation, reorganized it, and wrote new material and procedures detailing the tasks and principles involved in maintaining the data centers and procedures for disaster recovery.
Between systems analysis, data center management, and serving as a formal instructor, I was spending between 60-70 hours a week at work on average.
About a year later, there was a system-wide failure that had me at work for nearly three weeks solid; I literally lived at work for those three weeks, and only got glimpses of my family. At the end of the three weeks—and after I slept nearly 48 hours—I was stunned at how much my son (5 years old at the time) had grown during those weeks, and knew that something had to change. Management was unwilling to reduce my work load or allow me to transfer into systems programming full time; so after talking it over with my wife, I started looking for a new job.
Within a week, I found and accepted a job as a contract data center manager for a new data center for a shipping company. The contracting firm had set up the shipping company's new west coast data center and staffed it, and was responsible for operating the data center. Naturally, considering that this was a new data center, operations procedures, methods, and schedules were non-existent, and I once again found myself diving into writing support programs and documenting operations processes, system maintenance procedures, disaster recovery procedures, and more, as well as managing the data center staff.
The contract with client provided four options at the end of the first year. The client could:
buy out the entire data center, staff and all
buy out the data center and operations staff, and bring in their own management
buy out only the data center, and bring in their own staff
renew the contract for another year
At the end of the first year, the client took option 2, and I found myself hunting for a job once again.
Because I deeply enjoyed being a data center shift supervisor, and had documented data center maintenance, I figured my documentation would validate my ability to be a data center manager.
One of the head-hunters with whom I dealt read my documentation samples, and asked if I had ever considered being a full-time technical writer: She said that my documentation was the best she had ever seen when it came to running a data center. I had never previously considered being a technical writer, because for me, that was simply part of the responsibility of managing a data center; and she warned me that becoming a technical writer would mean a severe cut in pay - yet conversely, it would also mean a huge drop in the number of hours I'd work per week. I talked it over with my wife; and my wife agreed that the cut in pay would mean that we (me, wife, son) would have a life.
I told the head hunter that I was open to becoming a technical writer. One week later, I interviewed at a medium-sized California bank, and was hired during the interview - and thus started my career as a technical writer.
The work was fascinating; my first task (and a very challenging yet enjoyable one) was to create customized Waterloo Script GML macro libraries to produce documentation conforming to the requirements of the bank and the FDIC.
Another of my tasks was to customize the vendor-supplied Broadview Savings System software documentation to meet the needs of the bank, as well creating training manuals and tutorials based on the modifications of the Broadview System made by the programmers at the bank. Broadview later reviewed the documentation that I produced (part of the contractual agreement), and much to my pleasure, purchased my documentation from the bank (including source and support code) for their own use.
I deeply enjoyed learning and documenting the banking procedures, and wrote several manuals: teller, administration, loan servicing, loan processing, production control, adhoc reporting, personnel, and inventory system guides for NOMAD2 based software. Life was good.
Three and a half years later, the bank was federalized—an AVP made loans he should not have made—and all of us in the data center were given six months to find new jobs.
As luck would have it, staff from a defense contractor in New Jersey were seeking someone with strong data center management skills and active DoD clearances for a six-month contract. The job involved reorganizing a DoD data center that had gone from a single PDP-11 to several VAX clusters inside of a month, training the operations staff, and writing all of the operations manuals. Because of my background and, because my security clearances were still active, I landed the job.
The company moved me and my family to New Jersey, and I got a major introduction to what it was like to run and maintain a unionized DoD operations center. Thanks, but no thanks!
More than once, I went toe-to-toe with the shop steward simply because I was cross-training the console operater, tape-drive operator, and printer operator (yes, it was featherbedded that heavily!) to do each other's tasks; to me, it was logical that since each operator had identical clearances, it would make sense to cross-train them so that if one (or more) were on vacation or called in sick, the others could fill in. Prior to my taking the management role, if the console operator called in sick, all production stopped: Simply because no one else was trained to operate the console on the computers. The same occured if the printer operator or the tape drive operator called in sick or went on vacation: The other operators were, per union contract, not allowed to operate the other components. You wonder why NASA and other government agencies pay so much for a hammer? That's why. It didn't make sense to me at all, and I took steps to resolve it the best I could - and made myself miserable beating my head against the steel wall of union and government red tape.
At the end of the six months, the company offered me a permanent job as data center manager. I declined; not only because of the conflicts with the union, but also because the amount of time I was spending on the job was eating heavily into my personal and family life. I started hunting for a job as a technical writer.
One week later, I was offered an off-site contracting job as a technical writer at a major telecommunications company, and I accepted. The job required that I use a PC (provided by the company); and I was nervous, since I had never used one before. I stayed up late that first night, learning how to run and use the IBM PC (yes, the two-floppy-drive version, no hard drive), and quickly realized that it was a very simple system compared to the computers I had previously run and maintained.
The company provided an editor I had never seen before called "vi" on a floppy disk, and it took me about half a day to get used to the basic commands. The documentation was done using nroff and troff, which was similar enough to Waterloo and IBM GML Script that I immediately felt comfortable.
However, the operating system I had to upload and generate the documents on at the telecommunications company was something I had never encountered before: UNIX.
For the first few months, I could not help but think "Finally, something that makes IBM look user friendly!" It did not take long, though, as I learned more and more about UNIX (the original AT&T version) to falll in love with it. Pipes, scripts, redirects; strange-sounding utilities, programs and daemons with the unlikely names of "sed", "awk", "perl", "emacs", "shell", "grep", "uucp", "ftp", "smpdx", "tcp/ip" - and many more.
I was in seventh heaven.
About six months later, my manager asked me if I would like to install a hard drive on the PC. I accepted, and he handed me a PC expansion chasis, a 10-megabyte external hard drive, the installation disks and the documentation. I was scared stiff at first, convinced I would break the machine because I had never before installed and configured hardware of any kind; but, I forged ahead, read the documentation, and realized that not only was it was a very straight-forward process. but (for me) an enjoyable process as well-and a technogeek was born.
Early on, while working at the telecommunications company, I learned about newsgroups, and subscribed to several special interest computer-oriented groups. One result is that I learned about a third-party product that enabled the imbedding of PostScript graphics in nroff and troff documents, as well as learning about several different graphics programs that would generated encapsulated postcript files (anyone remember GEM?). I downloaded, installed, and experimented with the programs, and thus bypassed the (costly!) process of the time of copying and pasting professional artwork into a document and then photocopying (also costly!) the document for distribution. My coworkers and management were subsequently surprised and pleased that diagrams could be included in nroff and troff documents without resorting to the expensive processes of that era.
Shortly after that, I learned about the AT&T "BLIT" terminals; which used an early GUI interface to create diagrams and save them in encapsulated Poscript Format. I examined the output, and searched the newsgroups for information about the BLIT language and PostScript, and soon learned how to create illustrations using native BLIT commands.
At the same time, I noticed that the company discarded what they considered obsolete PC components: motherboards, video and memory cards, and more. I received permission to salvage the discarded PC hardware, and by 1987, had built my own PC AT from the various discarded components; and returned the original PC, hardware and software to the company.
During this time, my contract kept getting renewed; perhaps because of the quality of my work, but I seriously think it was also because I shared what I learned with my peers, both contractors and employees: Not only would I teach them about nroff and troff, but also about UNIX, PCs, and any new hardware and software technology that I had learned.
This is something I deeply enjoy doing; exploring new technology (hardware, software, whatever), learning it well, and sharing it not only with coworkers, but also with customers and anyone else who needs help and wants to learn. I've served (delightedly and unofficially!) as the local [ UNIX | Solaris | Windows 95/98/NT/2000/XP | Mac OS 7.x through X | FrameMaker | Adobe Illustrator | Adobe Photoshopo | PaintShop Pro | DreamWeaver | HTML ] - you get the idea!) guru, and have often documented that expertise for coworkers and clients. I love to share what I learn; must be the teacher in me - what can I say? After all, isn't technical writing a form of teaching?
During this time, I documented many different telecommunications products, ranging from telephony equipment, communications protocols, and route analysis software, to application development software and object-oriented applications; all while learning and applying a wide variety of UNIX, PC, and Macintosh-based tools.
Six years later, one of the employees with whom I worked and whose PC-AT I had fixed (simple fix: the CMOS battery had died) - approached me, and asked me if I would be willing to start a small computer VAR/Reseller company on the side with him. He knew nothing about building and maintaining computers, and wanted to learn; his offer was that he would provide the capital, and I would provide the technical expertise and teach him how to build, maintain, and repair computers. I agreed, and a single week later, we had an order for 10 machines.
We specialized in building Intel-based computers, and our largest order was for 18 computers installed as a LAN using Novell; and, later, a smaller order for 12 computers, networked together using Lantastic. Unfortunately, my partner and I would have had to sell 12 computers per day to make a living at it; we sold maybe 30 computers per month, enough though, to build ourselves our own machines (at the end, 486 DX-2/66s) and have a lot of fun.
In 1995, I decided to move back to California when my contract expired. I signed over the sideline PC business to my partner; having the computer was enough payment for me—and yes, my partner was very skilled in building and maintaining machines by then.
I quickly found a new contract with a major computer company, writing installation, administration, and user guides for an object-oriented and CORBA-complaint application development tool. Two months later, the company made me an offer to become an employee, and I accepted.
Since then, I've documented telecommunications hardware and software, computer operating systems, system and database administration applications, business-to-business server and web-based applications, manufacturing and warehousing applications, developer and end-user software, and system management and provisioning software on a very wide variety of systems ranging from high-end servers and workstations to desktop machines. I enjoy researching not only the various products, but also researching, learning, and applying tools that enable me to produce better documentation: Over the years, I've become skilled with a wide variety of software, and have used a very wide variety of graphics software to create the diagrams included in my documentation.
The advent of the web lead me to learn and use HTML; at first, coding using vi (no, not emacs, sorry) to create online help; as well as evaluating the various early HTML editors (Hotdog, Hot Metal, etc.); then going on to learn and use Robohelp, HotDog Pro, Webworks Publisher, Frontpage, DreamWeaver, and HomeSite.
Moving back to California did not slow me down regarding building computers from scratch and upgrading them; I have upgraded my wife's original Mac IICi, then later her G3; and have built and upgraded machines (Intel, Mac, and SPARC) for several friends, including installing and configuring the appropriate operating systems (DOS 1 through 6.2.2, Windows 1 through Windows 98, every version of NT, Windows 2000 professional and XP (all versions), OS/2 (yes, even that!); System 7.1 through X on the Macs; and Solaris 2.4 through Solaris 10 on SPARC and Intel machines - plus installing modems, scanners, network cards and software, USB devices, and a myriad of applications appropriate to each.
I also have a TRS-80 Model 3, a Compaq desktop 286, and a true-blue IBM PC XT; all working. I'm beginning to experiment with 3D modeling and animation software, and would love to have a fully-loaded Sun Microsystems Sun Fire V890 to do the work on—one can dream, right?
Remember earlier, when I said a techogeek was born?
A few years ago, I realized that being a technogeek has enabled me to not only effectively learn and document a very wide range of hardware, software, applications, and tools; but also to enjoy learning about the various technologies and to share that knowledge with my coworkers.
My love of technology and computers has literally enabled me to fulfill my original goal: being an effective teacher.
After all, isn't that the purpose of documentation? To teach and empower the reader to effectively use what they read and learn?
Wolf Davidson
Last updated: Sunday, 25-May-2008 00:00:59 PDT