- Introduction -
In 1980, on the strength of a Bachelor's Degree in English and a couple years' experience teaching teenagers how to program their Radio Shack TRS-80, I got my first job as a technical writer, for the company that more-or-less invented Technical Writing as a career.
For the next 34-plus years, I have made my living as a writer, editor, or technical communicator. Sometimes my career has seemed as solid as rock; sometimes it has felt as risky as crossing the Ohio River by jumping from ice flow to ice flow. Though most of my experience has been in computer documentation, I have also been able to write about history and literature, and dozens of other topics.
Now that I'm within a few years of putting the day job out to pasture, I can't help thinking about all the great and goofy experience I've had over the years. If you're a career technical writer with a few miles behind you, you will be able to relate. If you're looking forward to a career in technical writing, you may find this informative. If you think that office shenanigans only happen on television sitcoms, you'll find it incredible. If you're a critic, you'll find it self-indulgent. But memoirs always are. What bothers me is when history books or technical manuals are self-indulgent.
But whoever you are, hopefully you'll find it entertaining.
The contents are more-or-less chronological, starting in May, 1980 and going up to present day, although not all periods are covered equally. Although the sections are divided largely by the state of technical writing during the events being described, they're really about what it was like to work in the industry at that time.
If you can relate to any of what I've written, e-mail me and let me know. If you have something to add, I plan on putting a reader response section on every page eventually.
In the meantime, enjoy!
The Birth of the Technical Writing Profession
Yes, people have written instructions for centuries. But technical writing as a profession didn't emerge until:
Those two trends emerged at a time and place where mechanical business machines reigned supreme and seem to have an infinite future - at a city with a long history of for such innovations as heavier-than-air flight, in a company whose hybrid tube-and-mechanical computers had recently helped the Allies win World War II by breaking the code of the infamous German Enigma machine. NCR, in Dayton, Ohio.
Surprised? So are most people who were born after, say 1955. By the time you had your first real job, mismanagement had nearly caused the collapse of that company, and, except for a few heroic attempts at a comeback, it has been shrinking ever since. But one trend the company pioneered during that transition continues until this day - technical writing as a profession.
The Rise of the MachinesNCR, which is currently a Georgia-based shadow of its former Dayton-based industry-leader self, started many innovations that other companies have since been credited with. For example, NCR invented the world's first solid-state business computer; then upper management decided it had no future and stopped funding it, leaving IBM to pick up the slack. So it's no surprise that the company that pretty much invented modern technical writing gets none of the credit for that innovation either.
For most of the twentieth century, NCR sold mechanical cash registers. To say they were complex would be an understatement. They were also designed to be adapted to the needs of foreign countries, including things like currencies with three decimal places and weird sales tax formulas. By the end of World War II, NCR had even figured out how to use hybrid mechanical and tube-based computers to do things like calculate rates of radioactive decay and break the code of the German's Enigma machines, so there seemed to be no limit to what their business machines could accomplish.
Of course machines that complex could misfire or break down in ways no one could possible have anticipated. So NCR's repair forces were constantly being brought to Dayton to be updated and retrained, first at a log-cabin-based "campground" in Oakwood, Ohio and later on at a college-style campus built on that site and at a dorm-equipped campus near Miamisburg, Ohio.
Field Engineers and Purple Wires
Repairmen were not only trained to fix broken machines; they were also taught to troubleshoot errors that no one had encountered before. A communications network - indeed, a subculture - emerged to communicate new solutions around the world. So it was no stretch when NCR started calling their cash register repairmen "field engineers."
As an example of the subculture, when a field engineer solved a problem by changing the wiring in a business machine, they used a purple wire, so any future worker would realize that the machine departed from the blueprints at that point. They would document the repair and send their documentation back to Dayton, where their supervisors would print up the documentation changes and send them out everywhere those machines were sold (as many as 88 different countries).
In the meantime, any new business machines of that model would include the modification, purple wire and all. That way, any field engineer who had to work on one before the new documentation came out would realize that the machine would not match his blueprints. Once the documentation was updated, the wire that had been purple was changed to conform to the standard wiring color code.
When a field engineer who showed particular aptitude for writing up "fixes" was burning out in the field, they would occasionally bring him in to the factory to assist in writing the user and repair manuals.
Field Engineers as Writers
As solid-state machines began taking over roles that "mechanicals" had "owned" before, the company realized that the need for distributing well-written updates to their field engineers would become more critical than ever. They formed a "Technical Writing" department and started calling their field-engineers-cum-writers "technical writers." At first, however, they saw no need to train these technologically savy folks to write coherently.
As an interesting footnote to this part of the history, for years after this transition, certain old-timers would refer to emergency updates to any kind of equipment as a "purple wire." This included things like software updates, in which no wire was involved at all. I only know this because several of these guys were nearing the end of their careers as I was beginning mine, and I heard plenty of "war stories," believe me.
Field Engineers as Managers of WritersFor years, the manager of all these new "technical writers" was a former field engineer himself. We'll call him "Norm." By the time I was hired (1980), "Norm" was nearing the end of his career, holding a sort of "emeritus" position that both rewarded his years of diligent company service and pretty much kept him out of trouble. So my exposure to him was mostly through "bulletins" he would publish whenever he deemed that some crisis related to technical communication deserved his attention.
Like Saint John, who always referred to himself in the third person, "Norm" had learned somewhere that it was bad form to use "I" in a written document. So he called himself "the writer." As in "It has come to the writer's attention that . . . ." That sentence is clichéd and wordy, but at least it's understandable.
Unfortunately "Norm" sent his bulletins to writers, and they often talked about writers. Worse yet, "Norm" didn't like using second person, either. So when he would say "the writer must do such and such" you just about had to draw a flowchart to figure out whether "Norm" was talking about himself, you, or some third party.
For many years after that, most of the folks who managed technical writers had started their career with a two year degree in electrical engineering (or less) and a screwdriver in their hands. Fortunately, most of them realized that the college-degreed folks they were hiring knew more about writing than they did, and gave them free rein over the organization and syntax of the documents they wrote.
Still, as late as 1984, I was working for a former field engineer who thought stuffy, convoluted writing sounded "more professional" than straightforward text, so bad writing was still being rewarded in some circles.
Needless to say, changing a person's title from "field engineer" to "technical writer" does not magically endow him or her with the requisite skills to do the new job effectively. Quite predictably, the first generation of FEs-turned-"writers," supervised by FEs-turned-"writing-managers," tended to turn out disorganized technobabble that only made sense to people who shared their vocabulary and experience. When the company started developing software to bundle with their new mainframe computers, the lack of training became even more obvious.
Finally, the company realized some retraining was necessary, and engaged a professionally-trained writer to train the rest of the technical writers and to write a "how to write" reference handbook. That was Charles "Ted" Busaw who was writing books like Practical Writing; Composition for the Business and Technical World as early as 1973. Ted also worked with writers Gerald J. Alred, and Walter E. Oliu on several series of technical writing manuals, many of which are still required reading in university courses on technical and business writing today.
Ted and his cowriters customized one of their projects into the NCR Handbook of Effective Writing to address common problems that Ted was encountering while working with the FEs-turned-writers. I enjoyed it largely because it was full of real-world examples Ted had culled from his experiences at NCR. For example, in the section on misplaced modifiers, Ted included the what-not-to-do example, "Rolling around in the bottom of the drawer, I found the missing ball bearings."
Ted also trained writers and writing managers through a series of in-house programs. By the time I hired on, Ted was less hands-on. I was eventually coached by a writer who had been coached by a writer who had been coached by Ted, and I learned more practical advice from her (third-hand from Ted) than I had learned in my entire college career. I did have the chance to sit through two of his seminars on managing documentation projects. I always appreciated his wisdom, his gentle humor, and especially his "war stories."
Eventually, our company's writing groups developed a culture of professional technical writing that was second-to-none. Then, in 1979, upper management decided to break up all the writing groups. Sadly, this had occurred by the time I was hired on, so I didn't get the benefit of Ted's hard work for the first couple years I was an employee.
Where I Come In
Enter me, in 1980, hired to work for Dale "Mick" Rittenhouse, a former field engineer who reported to another former field engineer. That manager reported to a former cash register sales manager who was managing software development projects because the cash registers had gone away and he had no qualifications to speak of, but he still had powerful golfing buddies.
Most of my coworkers had BAs, though not all in English. At the time, I had a BA in English, a writing-intensive degree, to be sure. But none of my university professors had ever helped me improve my writing since I had graduated from Miamisburg High School, where Mrs. Robinson had drilled principles into our heads that I had coasted on for the next four years.
Mick and Joe both realized I was a better writer than they were and left me to do my job as I saw fit. My immediate coworkers got the same treatment. Ironically, I realized later that they were allowing us all to write mediocre manuals in which each chapter sounded like it was written by a different person, because it was. There were few standards beyond template requirements and not using the term "execute" to describe starting a program. (NCR had customers all over the world, and translators almost always interpreted the word "execute" as "kill," the exact opposite of what the customer needed to do.")
Technical Writing in the Stone AgeBack in those days, our software's "user interface" was a screen of ascii text with blanks or boxes where the operator had to type information. There were literally thousands of screens, and no help systems. So our "user documents" defined each screen field by field by field by field. If the next screen used most of the same fields, they would be redefined on the next page of the document. On a big system, the "user manual" could easily be ten thousand pages long!
As if that wasn't cumbersome enough, many of our clients only had one "user terminal" per mainframe, so the people doing computer input didn't have the luxury of sitting at the screen working on one record at a time. For those clients, we had to create "worksheets" that the customer employees would use to collect the data that the operator would eventually put into the system.
Before 1983, we didn't have computers or terminals either, so everything we did was typed or handwritten, including the "tag names" of each paragraph type (H1, H2, BT, etc.). We then hand-carried the "hard copy" to a typesetting department in another building, a chapter at a time. After the typesetters had done their best, we'd review the galleys. Those always contained manifold mistakes, usually - but not always - caused either by our bad handwriting or by the person typing our copy into the typesetter. We usually had "one shot" to get all the corrections into the system before the "camera-ready" copy was produced. After all, our department was being charged per page by the typesetting department, and multiple turnarounds of big documents cost real money.
Getting Grounded in the Corporate Communications Culture
For most of the 1970s, NCR had had a huge pool of writers that the writing manager would assign to various software projects. A year or so before I was hired, the company had split the writing department into three departments according to the industry they were supporting.
Consequently, when I was hired into the Financial division, I went into a pool of writers with a single manager who would assign them to various Banking-related projects as needed. I started in Foreign Exchange/EFT (which is why I understood certain parts of the movie Jumping Jack Flash better than some of my contemporaries).
The Retail division had its own writing team, as did the group that handled manufacturing, healthcare, and several miscellaneous software products (I'll call them "Manufacturing" because I have forgotten their meaningless acronym).
Initially, all three writing groups were in the same building, so we got the chance to get to know each other, to consult on common problems, and to build on the "tribal knowledge" that had been established in the 1960s and early 1970s. We would discuss hot topics in technical writing, post funny writing mishaps on a bulletin board, and hang home-made posters in our offices like "Eschew Obsfucation" and "Lack of planning on your part does not necessarily constitute an emergency on my part."
A number of us belonged - off and on - to "STC," the Society for Technical Communication, and we would pass around the newsletters. At the time, the regional chapter was dominated by employees of a Cincinnati database company, so going to STC meetings was a lot like attending someone else's high school reunion. There was also a lot of emphasis on trying to get the membership to agree to professional standards. STC members also strove to get "Technical Communicator" recognized by nonwriters as a profession in its own right, and not just a necessary evil, as many companies saw us. (Sadly, STC is still pushing that rock up the hill. Because so many companies still perceive technical writing as a clerical function or worse, every time there's a recession, they lay off the technical writers, causing a glut in the market. And that results in highly qualified, previously well-paid professional writers fighting over jobs that pay half of what they were making before, once again lowering the bar for company expectations of what we were really "worth." In many parts of the country, even the salaries of COBOL programmers have kept up with inflation better than the salaries of qualified technical writers. And don't even mention "career paths.")
Breaking up is Hard to Do
Back to NCR in the early 1980s. About a year after I came onboard, the groups were physically split up so that Retail was in one building, Financial was in another and Manufacturing was in another. We still consulted across vocational lines occasionally, but the culture of world-class technical writing began to erode as the AVPs over the various divisions started setting priorities that had nothing to do with quality.
Then, between 1982 and 1983, our department (Financial) was reorganized so that each application development project had its own writer(s). The short-term "down-side" was that software development managers never consider documentation a priority, never consider writing ability as a useful job skill, and more often than not find ways to reassign the writers to tasks they consider worthwhile, like testing. So writers assigned directly to development managers wind up not being given time to do their "real job" and working at tasks that they find boring and frustrating.
The "long-term" downside was that, as more and more writers were assimilated into the individual development groups, departing old-timers were replaced by new hires who never had the benefit of Ted's training and who would do whatever their immediate manager wanted, regardless of corporate standards. In short, NCR lost its commitment to world-class documentation. Eventually most divisions of that company had lost even a basic understanding of what that was.
By then "Norm" had retired, and the fellow who had taken his place (I'll call him "Phil") discovered that he had gone from about sixty direct reports to six. "Phil" valiantly attempted to prove his group was still important by specifying software requirements and documentation standards that nobody used, and by funding internal "research" projects that never benefitted anyone who was actually writing for a living.
That said, one of the "breakouts" actually helped me - I found myself reporting to a coworker who had been trained to write when Ted's influence on the corporation was at its highest. (Today, we would say that she was "old school," even though she was not much older than I.)
Under her guidance, I learned to write the way I should have been writing all along, using the most precise, concise, straightforward sentences possible. Always. Passive voice - gone, except where it could not reasonably be avoided. All other inverted syntax - gone. Using more than one wording to describe identical tasks - gone. All those cutesy, self-indulgent tricks that some of my coworkers had actually admired - gone. After six months of her tutelage, my writing - all of my writing - had improved by leaps and bounds.
I've done all kinds of writing since, including academic, K-12 textbook, technical, journalism, and fiction. I've also been brutally overedited by supervisors and senior editors who insisted on imposing their indefensible personal quirks on my prose. But all real success I've had at ANY kind of prose writing, I credit largely to that six months of my life.
Technical Writing in the Bronze AgeSome time around 1983, our department was split up again and I became the uncompensated supervisor of six other writers, working for yet another field-engineer-turned-writing-manager whom I'll call "Frank." 8086-based IBM PCs running MS-DOS were beginning to trickle into the corporation, and WordStar had just emerged as a way for fast typists to input text at breakneck speed. We worked on typewriters for about a year beyond that.
Then "Frank" told us he was getting us computers. And he did, after a fashion. Our new NCR-branded "desktop computers" were single-piece units with two floppy disk slots next to a monochromatic scren. NCR had still not figured out how to get MS-DOS to work on their computers (in those days, every computer architecture required a unique implementation.) So the P-3 computers we got ran on P-system, an operating system that had been developed to support the Pascal programming language.
Since no word processing software had been developed for P-system, "Frank" told us to use the P-system text editor to input everything, including the tag names for each paragraph. Windows Notepad has more features.
At the time, I kept in touch with technical writers in other companies, and I saw the tools they were using on MS-DOS computers. A real word processor (like WordStar) would have saved us countless hours a week just on inputting the text, even if we still had to send it to the typesetters for the "fancy" copy. Before long Apples could do even fancier things with Adobe's Pagemaker software, and Ventura Publisher was on the verge of introducing the same capabilities to the PC world. When I told Frank what my friends were doing in other companies, he accused me of lying to him and refused to speak to me about it.
Not long after, our division got our first "laser printer," a text-only printer based on a Canon chassis. Again, I saw what folks in other companies were doing with HP printers that used exactly the same Canon chassis. I brought in samples of professional-looking pages - formatting, graphics, and all - to my manager. I explained how much money we'd save in typesetting alone if we just adopted the same tools all of our competitors were using. To his credit, he did contact "Phil," who was still trying to prove he deserved a manager's salary when he only had six direct reports.
By then, "Phil" had invested about $100,000 into a Motorola-based RISC minicomputer, expensive typesetting software, and a 600dpi laser printer that his "experts" were struggling to get to work together. Phil assured my manager that if we wanted professional results, we would have to wait until he got the bugs worked out of his system, then buy a similar setup ourselves. What about all those folks who were claiming to get professional results on microcomputers with off-the-shelf software? They were all liars, and the enemies of all that was good and true.
A few years later, I realized that in addition to "Phil's" self-serving bad advice, there was another reason why my manager was so reluctant to get us the tools we needed - the company accountants were more-or-less allergic to capital investments. You could spend a million dollars a year on typesetting charges, as long as you accumulated the charges a page at a time. But if you tried to buy a $500 laser printer or software package, the request had to go all the way to your division's vice president, who had no idea what your department did, much less why you thought you needed such superfluous toys.
The nominal capital investments I was requesting would have pushed our productivity "through the roof" by 80's standards. But developing a culture of rejection saved the accountants having to depreciate those investments over a five year period, so it "worked for them." Too bad that it cost the company tens of millions that I'm aware of on typesetting costs alone.
The transition between typesetting and desktop publishing was so full of ironies, it's hard to appreciate how strange those days were. In the early 1980s, NCR was paying an outside company to do our typesetting, and that company was using a paper-tape-based system developed in the 1960s. Soon after that, NCR found another "provider" who demanded the same cost per page (now $75), but had very fast turnaround. How could he be so fast? Because he wasn't using 1960s technology. Instead he had invested about three grand into an Apple, a copy of Adobe Pagemaker and a 600dpi laser, but he made certain to tell everybody he had a "typesetter," and nobody at NCR ever caught on. In the meantime, his one-man shop grossed about $500,000 a year for several years, due to NCR's diligent attempts to save money on "untested" technologies like desktop publishing software and hi-res laser printers.
The Field-Engineer-Turned-Writing-Managers' Last Gasp
One of the funniest things (in retrospect) that ever occurred to me in that department was the day the manager called me into a private meeting to complain about the way I was administrating the project. He had two documents in front of him - one I had written, and one that one of my "reports" had written. (I'll call him "Fred.")
My document described a ridiculously complicated process for installing our multi-million-dollar mainframe system, importing up to a million pre-existing user accounts, and testing the result before going live. It was well-organized, concise, straightforward, and written at an eighth grade level (never assume that computer engineers or service people read at a college level). On top of that, it had already been used successfully in two beta sites.
"Fred's" document described how to enter a customer name and address into the system. It was verbose, unnecessarily complicated, and - frankly - gave the impression that the system's most basic tasks required a "rocket scientist."
I had talked to "Fred" about his obtuse writing style, but he was retired from the military on a full pension, he didn't really didn't need the job, and he had run crying to my manager every time I tried to get him to write like a professional instead of a college sophomore trying to sound impressive.
So my first response to being called into a meeting was that the manager had finally noticed Fred's verbose abominations and was wondering why I hadn't busted the guy's chops by now.
To my surprise, the manager asked me why I was documenting all the "easy" tasks and making Fred document all the hard ones. I explained that, ordinarily most people would consider installing a multi-million-dollar computer system harder than entering customer information.
"That can't be," he said, "Look at all this." And he ran his finger down Fred's page, in awe of all the apparently complex content. It took several minutes for me to get him to admit that the installation document might have been harder to write and to get right, than the customer information screen page, which only required getting a printout of the screen and stating the obvious: "Enter the customer's last name in the 'Last Name' field."
My manager still wasn't satisfied, though - there was something about our conflicting writing styles that still bothered him. Finally he admitted that I "might" be right about taking the hard jobs myself and giving Fred the easy ones. "But," he added, "When I read Fred's stuff it just sounds more like technical writing!" Sadly, I knew just what he meant.
About the same time a new hire who dressed provocatively and was obviously gunning for my (uncompensated) supervisory position started spending a lot of time in closed-door meetings with "Frank." "Frank" eventually told me that he was impressed by her qualifications and was going to give her my job. To his credit, he actually helped me find a better position in another department. At the time, the whole project was on the verge of collapse, since "Frank" couldn't hold a candle to the ineptitude of his boss and his boss' boss. So "Frank" didn't have to tell me to move on twice.
Technical Writing in the Iron AgeBy the time I landed in another position, I was no longer reporting directly to a "writing manager;" rather I was reporting to the head of the entire software development project. The "up-side" to that was that he didn't second-guess me every time I tried to get my writing tools out of the 1950s, but the "down-side" was that, to him, software developers walked on water and documentation developers were glorified secretaries. At first I was grudgingly allowed to have a beat-up old eight-bit PC that one of the software engineers had "outgrown." Later on, when the engineers all got 32 bit machines, I was given a 16-bit machine that I could actually work on without having to wait several minutes for the screen to refresh every time I moved a paragraph. The irony was that the engineers were doing all their actually work on the mainframe, using their high-end PCs as terminal emulators (except when they played Flight Simulator on them after hours).
For the first several months on the project I was mostly planning our "family of documentation and training projects," since the project was new. But now that I was responsible for the "final output" of the documentation, I started looking seriously at desktop publishing as a way of avoiding countless hours of shuffling documents to the typesetter, reviewing gallies, etc., not to mention avoiding all of the typesetting charges.
Soon "Phil" (the writing department manager with almost nobody left to manage) learned that I was trying to talk my new manager into investing two grand into new 32-bit PCs and over-the counter software versus the system his people were still trying to get working right. By then they had brought the cost down to about $40,00 a workstation. But he was afraid that if he couldn't convince people like my boss to invest, it would become painfully obvious just how big a drain on corporate resources he was. So "Phil" proactively deluged all of the managers in the company with "white papers" explaining that "desktop publishing" was a fraud, that it never delivered on its promises, and that it wouldn't last.
About that time the company went from WordStar to WordPerfect, which was easier for clueless wonders, non-writers, and non-typists to use when writing business letters. Still, I could do most of what I needed to do many times faster in Wordstar, so I secretly continued to use that until I was forced to change.
My new department also had a Hewlett Packard LaserJet that had the graphic-processing software installed (some early version of PCL). So I occasionally experimented with trying to make WordStar (and, reluctantly WordPerfect) documents look like our typeset manuals. I could get close, but it was cumbersome.
About that time, "Phil" scheduled a meeting in which he brought all the NCR technical writers he could together to give us matching hats and to explain how valuable his organization was to the rest of us. Over lunch, I learned that another technical writer in the company was already using Ventura Publisher with a laser printer. (He was a one-man department, located in another town, so he was more insulated from "Phil's" interference.) Once their documents were printed on an offset press, they were nearly identical to the typeset equivalents. I realized, since I had more knowledge of typesetting principles, I could get them identical period.
After running all the figures, I explained to my manager that I could probably save him $200,000 or more a year if he would let me buy a faster computer, a desktop publishing system, and a faster laser printer. He, in turn, did the "responsible thing" and asked the manager of the "Information Products Division" what he thought about that approach. Of course "Phil" gave him an earful. The inhouse system wasn't ready yet, but it would be soon, and in the meantime, we were risking the good name of the corporation if we released documentation that didn't look like we had spent a fortune getting it typeset.
At the time I had one "report," and I could tell that the project was going to be huge. Adding typesetting iterations to the work ahead of us would be overwhelming. Finally, I "bit the bullet" and bought a copy of Ventura Publisher with my own money to try it out (several hundred dollars at the time, equivalent to over a thousand in today's dollars).
Over the next few weeks, I figured out how to make Ventura Publisher work exactly like the "Information Product Development" department's $40,000-a seat system, except that the latter was still full of bugs. Like today's HTML, all of the words were stored in a flat "text" file along with tag names like @H1=, @H2=, @BT=, and so on. All images were stored in separate image files and plugged into place as needed by the WYSWIG and printing features. To this day, I prefer this system to the "user-friendly" systems that make the graphic part of the file and require you to remove it and plug it back in whenever you need to make a minor update.
I also learned that "prepping" a file from a text editor, WordStar, or WordPerfect to go into Ventura Publisher was exactly the same as "prepping" the file to go itno the IPD's typesetting sytem, except that the tag names were formatted a little differently.
Since my early experience with desktop publishing was so encouraging, I contacted the IPD again. I suggested that they could keep the various writing groups from sending millions outside the corporation every year, simply by bringing Ventura Publisher "in house," and developing templates and procedures that we could use until the "real system" was working.
In response, I was told that the IPD would refuse to print or distribute anything I ever did on Ventura Publisher, because it would never be "the same" as "the real thing." For one thing, the IPD used Plantin and Gil Sans in all of their publications, and our laser printer couldn't print those fonts.
In those days, buying a new digital font was a real investment. But I spent real money to get Plantin and Gil Sans from the Monotype corporation.
Then I went to work in earnest, exactly replicating the "official" corporate templates for all kinds of publications. I showed my manager what I had accomplished, then put in a requisition for two 32-bit computers and for reimbursement for the software and fonts I had already bought. When my manager saw how much money I'd be saving him, he went along.
When the new computers arrived, I trained my single "report" on Ventura, and bypassed corporate distribution by having a local printer print and mail out the manuals, at another huge savings.
By the time we had done two releases of the software, my single "report" and I had produced just as much documentation as seven of us had produced in the same amount of time on the earlier project. And we did it for about 2% of the total cost (counting salaries). I was sure that the company would see the value of my contribution and reward me somehow.
The assistant vice president in charge of our division heard about our success and asked if I would box up my Ventura release disks and send them to him for him to "check out." I complied, hoping that this meant I was on his radar, or on his "good side" at least. What I didn't know at the time was that he was being forced to resign for alleged sexual harrasment, and my software was just one of countless "souvenirs" he planned to take with him when he left. Gotta love 'em!
Not that it mattered. A few months later, the mainframe that our software project ran on was discontinued, and I was looking for work again.
Technical Writing in the Dark AgesThe first place I interviewed was one of the few remaining technical writing departments in our company. They were still sending their typesetting out at an exorbitant cost, easily spending four times my salary every year. "Here's how I can pay for myself and then some," I said, and walked the hiring manager through my recent experiences. I had even "dummied up" a Ventura Publisher version of one of the hiring manager's own typeset documents.
He seemed to barely be paying attention. When I had done my "spiel," he explained that IPD had already "beat him over the head" about desktop publishing, that IPD's new system was going to be available any year now, and that, at any rate, anybody could easily see the quality difference between a document produced on a 600dpi typesetter and a document produced on a 600dpi laser printer. Actually, when he looked at my samples, he couldn't tell which was which, but he was sure there was a difference, because the IPD had told him there would be.
I didn't get that job. A year later, I heard that he had earned a substantial bonus by saving the company a quarter of a million dollars on typesetting costs. How did he do it, you ask? He came up with the brilliant, original idea of using Ventura Publisher and a 600dpi laser printer to bring his typesetting "in house." Ya gotta love 'em.
In the meantime, I landed in the marketing department of a division that sold PCs and UNIX computers to resellers. In that group, most of what we wrote was for internal distribution only, so there was only a simple template to use. Interestingly enough, we were required to use Ami Pro for our word processing, even though most of us had Microsoft Word on our computers - one of many self-defeating petty feuds with Microsoft I've witnessed in my career.
As a plus, one of the fellows in the department was responsible for testing each new PC to make certain it ran all of the standard applications. So I had a chance to get up to speed on the early-1990s versions of all the "high-end" graphics and desktop publishing applications.
My job, technically, wasn't writing as much as it was coming up with creative new ways to market our computers to wholesalers and other retailers. We were supposed to come up with all the ideas out of thin air. At the same time, I had inherited a file cabinet full of competitors' material we weren't supposed to have, and my manager used to suggest that I go through that to come up with "original ideas."
As a result of familiarizing myself with the competition, I realized that nearly every time one of my coworkers would announce a "new" marketing program, to the kudos of our manager and his director, I would recognize a point-for-point parallels with some competitor's program. In one case, the marketeer had gotten hold of a Word file describing the competitor's program, done a "search and replace" of the competitors' name with our company name, and presented it as his own work.
Frankly, the place was such a pressure-cooker, I can almost understand why some of those shenanigans occurred - there's nothing like a crisis-junkie manager forcing you to spend 60-80 hours a week at the office for no real reason but his own ego, to make any real creative juices you ever had dry up for good.
People often ask me why I don't find comedies about obnoxious bosses in the workplace funny. Now you know.
For my part, I did come up with a few original programs, one of which proved more useful in the "real world" than anything else I saw produced that year.
War story alert! After my albeit minor successes, I was ordered to come up with a complex program that other people had failed to accomplish. It would substantially help our resellers and give us an edge in the marketplace. But it would also require the "buy in" of several other departments that had no reason to give us what we needed. And that was where the marketeers before me had failed.
After months of negotiations with no leverage but my continued, good-natured "nudging" and a few minor "trade-offs" that I could influence, I finally got the buy-ins I needed, signatures and all. The program needed only the Assistant Vice President's signature to be implemented.
Before that could happen, a new director took over our division. "Eugene" (not his real name) liked my proposal. He liked it a lot. In fact he liked it enough to change the name on the front page from my name to his own, and to start promoting it as "his program." This wasn't the first or the last time this sort of thing has happened during my career. Conventional wisdom is to "close your eyes and think of Christmas," and to expect the idea-stealing supervisor to repay the favor at some time in the future. As hard as it may be to believe, in my experience, most of them do - the smart ones have figured out that it's a good idea to reward employees that make them look good. Sadly, though, "Eugene" appropriated my proposal without even bothering to read it all the way through.
"Eugene" scheduled a meeting with the AVP whose signature would be required, made up his own Powerpoint presentation to replace mine, and declined my offer to look over the materials he'd be presenting to be certain he hadn't missed anything (I said it nicer than that).
Finally the meeting day came, and the "Eugene" went through his presentation smoothly and convincingly. Then the AVP asked him a simple question and "Eugene" betrayed a humiliating ignorance of the most basic details of the program he had just promoted as "his own." He embarrassed not only himself but everyone in the room, although that didn't keep him from giving me a "dirty look" on the way out.
Afterword, my manager told me that I had "let Eugene down, big, time," and it might be a good idea for me to start circulating my resume. I didn't need to be told twice.
Gotta love 'em!
Technical Writing in the Industrial Revolution
Still in the same company, I landed in a customer support organization chartered with writing procedures for our systems analysts to use when putting together proposals or providing on-site services for customers. Most of my work there involved planning and installing voice and or computer networks, a relatively new field for me.
For example, we found a software program that would evaluate whether a client's networking infrastructure would survive Y2K, then charged a regional phone company to "vet" their entire infrastructure. An engineer did the technical research, I wrote up the procedure, and the company grossed about half a million dollars for a few weeks' work.
My "crowning achievement" a the time was a workbook and interview guide that even a relative "newbie" to the field could use to evaluate a customer's LAN and WAN requirements and propose an effective solution, usually using Cisco routers. I was proud that we had "rigor" to the process. After you'd worked through the workbook, you would have the "textbook solution," not only to the customer's perceived needs, but to the real needs you recognized as you were meeting with the customer and touring the site(s). If the customer still preferred another approach (say, Novell over MS or vice versa), we could deliver it, of course, but there was no way the customer could claim we had failed to do "due diligence."
The year our project came out, and the year after that, our company sold and installed over half of the Cisco routers installed outside of North America. I was not only starting to feel good about my work again, but I was most of the way to earning my Cisco certification.
Our manager was so pleased with our successes that he approved my request for tuition reimbursement to complete an MA. I took lots of graduate business courses (learning, among other things, why so many of our corporate accountants would rather waste millions they could expense than spend hundreds they would have to depreciate). I was also able to take enough English courses to complete an MA in Composition and Rhetoric.
Then the company split up into three separate companies, and our division was gutted. Eighty-five technical writers out of a hundred were thrown at once into a relatively small market. Judging by the writers they kept, the only way I could have saved my job would have been by getting pregnant right before the layoff notices came out.
To add insult to injury, IPD, with whom I'd been bumping heads off and on for ten years, talked the corporation into establishing policies that would make it impossible for any of us to be hired back as contractors unless we went through a certain agency. Which agency? The one that had just been started by the same manager who had decided which writers to lay off, and who had apparently worked out all of the details with IPD ahead of time. Gotta love 'em!
After fifteen years of service, and several projects that had either saved or made the company millions, I was "on the street." On the other hand, I had just completed a master's degree, and was one course away from Cisco certification, if I wanted to pursue that. So things didn't look as bad as they could have.
Technical Writing in the Information AgeThere's nothing like trying to get an interview for a job in a small market and learning that eighty of your former coworkers have been there ahead of you.
Add to that the fact that certain rules that apply to you don't seem to apply to anyone else. In spite of the new requirements that were supposed to keep our former supervisors from using us as consultants, one of the remaining managers seemed to have no trouble keeping several close friends busy.
In fact, one manager paid his laid-off-friends their "layoff bonus," then hired them back as consultants, and when things got better, hired them back as employees again, for more money than they had earned before. Gotta love 'em.
In the meantime, I did a little bit of consulting for a local company. Then one of my former coworkers contacted me and begged me to come work for him on contract. "Ron" (not his real name) had a project to finish and I was the only writer he knew who remotely understod the technologies involved.
Ron and I both spent hours on the phone with "gatekeepers" (Consultant Policy Administrators) trying to figure out how some managers' favorites could come back to work the next week, and I was not allowed back unless I jumped through extraordinary hoops.
One hurdle was that I couldn't come back as myself - I had to be represented by "a company." So I started a company - Breakthrough Communications(tm) - by filling out a DBA form with the state of Ohio and opening a business checking account in the company's name. (I also started the BTComm.com web page, using basic HTML skills I had picked up the last year on the job.)
Then the gatekeepers decided that my "sole proprietorship" wasn't enough. I had to work for a corporation. I asked the gatekeeper I had been "working with" if she knew the corporate structure of every janitorial, repair, and catering service they used. She admitted that she did not - apparently the new requirement only applied to former employees who were looking for work as technical writers. Finally, she admitted that the requirement was unenforceable.
But then she told me that I couldn't contract with the company unless I took out a million-dollar "malpractice" insurance policy protecting the corporation in case I wrote something with mistakes or plagiarism in it. That kind of insurance policy is insanely expensive for individuals. Our former manager's new and "approved" company could spend a thousand dollars a month and cover all of his writers. But for me to spend a thousand dollars a month on the off chance of getting steady work from the corporation would have been prohibitive. I found other local work for a few more weeks, while Ron kept pushing from his end.
Again after several phone calls from Ron and me, the gatekeeper had to admit that the new insurance requirement applied only to former employees who were also technical writers - it didn't even apply to contract trainers, programmers, or marketing writers, who were just as likely to produce mistakes or plagiarism as we were. Eventually, one of my former coworkers threatened to sue for unfair hiring practices, and that requirement vanished as well.
Sixteen years after the fact, all of these petty barriers to former employees delivering services that the company still needed seem unbelievable. But at the time, the twenty or so of my former colleagues with whom I stayed in touch were also being forced through exactly the same hoops. It was increasingly obvious that these barriers weren't there to protect the company - they were being erected by friends of our former manager to help him protect his monopoly. By now, I had no intention of working for the fellow if he'd asked me.
And sometimes there didn't seem any reason to - every barrier fell with a few weeks after its erection. But no matter what Ron and I did, or who we talked to, or how many hoops we jumped through, we still couldn't get final signoff from the gatekeeper for me to work on Ron's project - there was always one more hurdle that hadn't existed a week before.
Finally, frustrated beyond measure, Ron said, "Tell you what, you give me a couple days' work, and submit an invoice and I'll send it through and see what happens." The invoice was approved and paid with no resistance on the part of accounting, who - after all - didn't mind reporting expenses. And my consulting career actually started looking like a possibility.
As I read back over the last few paragraphs, I have to admit, that, all things considered, I got off "easy," compared to a number of my friends. As each barrier fell, I reported back to everyone on my "nice" list what I had discovered. A few folks felt informed and encouraged enough to jump through the same hoops I had, and eventually got into the system and started working again. But there were quite a few others who didn't have the emotional or financial resilience to keep "treading water" until things worked out.
Between the day I registered my DBA with the state of Ohio and the day I actually started working on contract, several people heard that I had "started a business" and asked me to represent them to the corporation the same way our former manager was representing those who had signed up with him. That could have been profitable for me, I suppose, but by then, I was hanging by a thread as well, and the only thing I could tell them was that I'd keep them informed of every step and in mind if I heard of anything at all.
By the time the "dust settled," some of them had got back "in" as consultants, some of them had found work elsewhere, a few had taken worse-paying jobs in other fields, and a few had just dropped "off the map." Back in 1995 there weren't as many ways to keep in touch as there are now, I'm afraid.
Later I learned, that one talented and focused writer in his early sixties had been planning to work a few more years, but finally gave up and started taking Social Security - that and drawing on his underfunded company pension were his only dependable sources of income. He and many others I can bring to mind were a true loss to the industry, and I regret that those of us who eventually "landed on their feet" couldn't have done more.
I do have to confess that my "nice" list got shorter as friends who asked for and received my help with one thing or another stopped taking my calls once they had landed somewhere. On the other hand, I can almost understand why some of that happened - I've been a "new hire" in situations where bringing in a distraught, but qualified friend would have made my new boss question his or her wisdom in hiring me - not unlike the would-be rescuer being drowned by a panicked person he was trying to save. And by the time any appreciable number of us started landing "on our feet," we were all pretty distraught, and, if nothing else, emotionally unpredictable.
At any rate, several of us did find our way back into the company as consultants. As contracts ran out and new contracts started, I made sure to look out for folks who had looked out for me. One interesting event occurred during that period. I was recruited to help "finish" a job that one of our former coworkers had been "working on" for eighteen months. The client figured it would be a two-man job, so I brought in a friend who was a great writer and had been helpful to me. The contract was to be for ten weeks at the most, since "Joe" (not his real name) had almost everything done and just needed our help getting it "out the door."
The project was to document a family of services that the company would sell to its customers - not unlike the work I'd done on LAN and WAN design. Although we were both charging what was then a standard fee for senior tech writing consultants, the client kept griping that we cost "so much." It turned out that he was comparing our fee to Joe's. Joe was charging a third of what we were! His low-balling had certainly kept him employed for the last eighteen months, so maybe that was all he needed.
The client was also nervous about bringing in people who would be working at home. He literally wanted us to call and tell him every time we went to the bathroom.
But the biggest surprise was when my friend and I finally got our hands on Joe's files. We learned that Joe had done nothing more than copy the file from another project, then changed the title page and headers on all the files four times, once for each service he was supposed to be documenting. What was he really doing all day long at the computer? We finally figured out that he was spending all of his time buying and selling things on an online auction site. That was how he could afford to "work" for a third of our salaries.
Knowing it is "bad form" for one consultant to point out the failings of another consultant, we nevertheless had to go back to the client and show him that, to finish the project we each had nine month's work to do - four months, if we could get Joe back on task. The client was unimpressed. "You agreed to get this done, so that's what you'll do."
My friend and I worked out an attack plan that involved only the most critical parts of the project, and with a lot of work and cooperation between the two of us, finished those parts of the project on time - with zero help from Joe. After it was all done, and we made sure that the client was satisfied with the outcome, I said, "Just out of curiosity, why do you keep Joe on, when he doesn't really do anything?"
The client answered, "He works so cheap, I can't afford not to."
Gotta love 'em!
Over the next two years, I was employed almost constantly by different groups in my old company. Then, as that started to thin out, I began finding contracts with other Fortune 500 companies. Ten week contracts came and went, then six-month contracts came and went, then year-long contracts came and went. At the time, I thought I was getting "real money" - I was certainly earning more money than I ever had in my life.
The last really good consulting job I had in that series of work was documenting a huge system built using an oversold so-called "fourth-generation" programming environment. A Fortune-500 consultant had sold my Fortune-100 client on the idea that the programming environment could understand common speech. You would write out your requirements in everyday English, input them into the system, and working code would come out the other end. If the code didn't work the way you wanted, you would tweak your requirements and try again.
This was called "self-documenting," because the requirements would be the documentation.
But, of course, the programmers who discovered that the code didn't come out the way they wanted, fixed the code, and the requirements never got changed. By the third week of development, there was no relationship between the "documentation" and what the program was actually doing. And no writer was brought in for another year!
Eighteen months and 200 hires after the project started, the consulting firm rotated out the guy whose resume they used to get the contract and brought in another guy whom they promised would "learn on the job." After what I would estimate to be a five-to-ten million dollar investment, only one person in the company even knew how the thing worked!
Fortunately for me, the fellow hired to support the thing once it got rolled out saw that as a problem. He brought me in, initially, to write a troubleshooting guide to address a particular problem that was recurring at our beta site in central Europe. "Fine, what causes the problem?" "Nobody knows." "How do you fix the problem?" "You call 'Singh'"(not his real name). "What does Singh do?" "He goes into the database and deletes records that have a null character in such and such a field." "Why does that work?" "Nobody knows." And so it went.
Singh's real problem was that our beta site was seven hours ahead, and the problem always occurred when they were closing down for the night - 6:30 P.M, their time, 1:20 A.M. our time. So, several nights a week he was being awakened by a phone call to come in and fix the problem aain. You can be sure that he was only too glad to tell me everything I needed to know.
I mention this because I had to learn how the system worked before I knew why it was breaking, let alone how to fix it.
As I learned, it was a complex state-based system using a constantly-churning library of Oracle stored procedures. What was "breaking it" was that one of the senior managers who thought he knew how it worked (the same one that had bought into the program in the first place) kept shutting down the stored procedures in a sequence that was guaranteed to leave transactions hanging, half-processed, in the system.
If this had been my first exposure to Oracle, I would have been in serious trouble figuring all this out. As it is, with Singh's help I got my head around it. And while I was learning how the system worked, I documented everything.
I constantly ran the drafts past everyone who would look at them. I was hoping they'd find any errors. But most of the reviewers, including a few senior programmers said things like "I didn't know it worked like that!"
By the time I had been there six months, I had not only written the "troubleshooting" guide; I had also written a technical manual and a pile of training material - since new people were still coming in. My training program was getting newbies up to speed weeks sooner than newbies usually did.
Here's one of those "special moments" that are funnier in retrospect than they were at the time. As I mentioned, the consulting firm that convinced my client/employer to buy into this so-called "fourth-generation" system likes to use one person's resume to get the job, then, after some period of time, use the same person's resume to get business elswhere, and rotate in someone who is only marginally qualified to continue what the other person started. About the time I had documented the system thoroughly and was sending the document around for one last pass before I made it available on the intranet (which I also created), a new guy came in. He used my document to get up to speed, which you would ordinarily consider a selling point. But after he got familiar with the system, he found one minor mistake on page 37. Instead of bringing it to my attention, he sent out an email to the entire division and the Vice President above that. The e-mail said only "Your document is WRONG! Please see me immediately!" When I went to see him and learned that the offending mistake was basically a typo, I told him, "You know, most people like getting on upper management's radar, just not this way."
Gotta love 'em!
Then the same manager who had bought the development system and been responsible for most of the failures decided that the project was taking too long and costing too much, and he shut it down, laying off or terminating the contracts of nearly 200 people.
At the time I had three weeks left on my contract extension. My manager told me to drop everything and find a job. So I searched for jobs all over the region. I also kept my eye out for jobs that would be good for my coworkers, most of whom were great people who deserved better treatment.
During that time, while the office was in an uproar, I met two young women who had seldom strayed from their office before. "What kind of jobs are you looking for?" "Oh, we're professional trainers, they answered me. "We write training materials and such." "Have you been writing materials for our programs?" "No, silly, there's no sense writing training materials until the beta site starts working properly and we have something worth training people on."
So for as long as I had worked there, documenting the system from the bottom up and creating a whole family of training materials, two young women responsible for training had been sitting in their office chatting, reading books, and surfing the web. And nobody in the whole organization noticed. How do you even DO that when there's work available?
But the crowning blow came when I found them jobs. Or thought I had - two technical training jobs that each paid $20,000 more a year than I was earning on contract. I wasn't interested since they were too far from my home, but they lived in the area, so it was worth passing on. I printed out the job descriptions and took them over. They both looked at the job descriptions and - believe it or not - smirked! "I couldn't live on that," one said. The other one said, "Yeah, talk about a step down!" So it turned out that the two young ladies whose jobs I'd been doing for most of the past year were bringing home substantially larger pay checks than I was!
Gotta love 'em!
By that time, the "internet bubble" had burst, so the economy was already on a downslide. Then 9-11happened and the country's depression, emotional and financial, only increased. The market for experienced technical writing consultants bottomed out all over the state, and I found myself piecing together 10-week contracts for half of what I'd been earning just a year or two earlier. And the contracts kept getting shorter and farther apart.
Eventually I took a full-time job for relatively poor pay editing K-12 textbooks. I learned a fantastic amount about writing and editing textbooks, and had some of the best "team" experiences of my working life - we really did work together instead of working at cross purposes as many "teams" have over the years.
The company always seemed on the brink of financial disaster, though. When the job market picked up, I started looking again.
Ironically, I found a job in a company that was a wholly-owned subsidiary of the company that laid me off in 1995. I found out after I started the new job that they were really going to be paying me $15 an hour less than they had promised. But the pay was still better than the old job, and the company seemed much more stable.
Several months later, the family-owned company tanked, so I probably made the right choice.
Technical Writing in the Cloud AgeIn the new company, I rewrote a 600-page help system and a related 600-page technical manual. I also started an intranet for storing all of the various sources of information that the other writers had produced.
During this time, the managers kept telling me that they were going to "fix" the discrepancy between what they had promised me and what I was being paid. But they also kept reorganizing, so I had a different manager every few months, and neither the second, third, or fourth manager was in the room when first manager made his promises.
Then the "wholly owned subsidiary" was assimilated, Borg-like into my former employer. As always, positions started being cut. I "hung in there" for another year or so. Then the employer decided to close our office, laying off about 1000 people at once, and transferring a couple houndred to another office. By then I had a pretty good sense of how the company was going to keep treating us, so I accepted the layoff rather than move several hundred miles just to get more of the same treatment.
I'll say this - the company made a point of subsidizing our Cobra payments for a year longer than they legally had to. In our case, that was about a thousand dollars a month, and it carried us until I found the next full-time job.
Here's an odd side-story. One reason that the company didn't think they needed to pay any "real" technical writers was that they were getting good results from several Filipino programmers. And after all, writing manuals is just like programming in English, isn't it?
The company couldn't see how documenting huge complex systems in English for demanding English-speaking customers would be any different. And, frankly, if you have to explain the problem with those assumptions to your new boss, you don't have a future with that organization anyway.
So while I was still an employee, they hired a young Filipino man I'll call Manuel. They allowed me to work from home a few days a week so I could keep a schedule that overlapped Manuel's. And I used the company conference line to train Manuel on the software, walk him through all of the web pages, help systems, and manuals we had done, and coach him on writing the most common kinds of documentation. If I'd had three years instead of four months, I might have made him into an actual technical writer. But in the meantime, I did everything I could to keep Manuel from hitting the wall hard as soon as I was out of the picture.
When I told one of my friends what I was doing, he said, "It would serve the company right if you would do a really bad job of training him, and then they'd be sorry."
I replied that it wasn't Manuel's fault. And bsides, if they couldn't tell the difference between my work after a thirty-year career and Manuel's best work, after several months of coaching, then I didn't want to work for them anyway.
In those days (the early years of Obama's administration), there were a few govenment programs to assist folks whose companies had sent their job overseas. Unlike 99% of the people in that situation, I actually knew exactly where my "job" had gone, right down to the name of my overseas replacement. But I didn't really need those programs as long as the company was extending my Cobra benefits, so I let it go.
Where to Now?By the time I was officially laid off, the country was in the darkest part of a recession caused by the implosion of toxic derivatives in hitherto unregulated financial markets. Jobs were thin. Professional jobs were very thin. To make it worse, middle- and lower- class Americans who'd been hurt by the financial crises that billionaire bankers had engineered were falling over each other in their rush to blame other middle- and lower-class Americans for their pain.
I went on unemployment for a few weeks - the first time in my life. I didn't tell my right-wing friends, because certain propaganda machines funded by anti-tax billionaires, were rising in influence, and my "friends" were spewing a huge amount of unfiltered, uninformed vacuous rhetoric about how people on welfare and unemployment are only interested in scamming the system.
To put it in perspective: At that time, if I wanted to keep healthcare insurance for my family without Cobra, it would have cost me $1500 a month. My unemployment was about $2000 a month. Do the math, and determine for yourself if long-working family folks like me are really choosing to go or stay on unemployment just to "scam the system."
Hopefully you can see why I appreciated my former employer extending our Cobra benefits (bringing the payment down to just over $500). I also hope you can understand why I stopped voting for a candidates that promise "family values," but whose voting records prove that their only real agenda is protecting the assets of the wealthiest families in the world. I guess they define "family values" differently than I do.
God blessed me with two great consulting jobs in 2010. For one of them, I taught ten people in Bangalore how to use Robohelp over the phone, and oversaw a successful 1000+ - page document conversion project. For another, I documented a web interface utility that the company liked so much, that they found another purpose for it and moved me onto another project.
In early 2011, I found a full-time technical writing job near my house - the first time since 1987 that I worked less than 32 miles from home. So things are actually looking up. A year from now, my last child will be out of college. Two years from now I'll be eligible to start taking Social Security if I want to, which gives me more freedom to choose what I want to be doing for the next several years of my life than I have ever had.
Of course, when you think that way, you're making assumptions. Several close friends have not been nearly as blessed as I've been so far. In fact one of my best writing friends from my first consulting phase died of cancer only a few years after we worked together. Another close friend of the family has just died of cancer as well. So if I don't get all the opportunities that I can't help "looking forward to," I really can't complain - I've already had more opportunities than most, and many more opportunities than some.
What about all of those "gotta love 'em" stories I told? Am I really upset about folks mis-judging me or taking unfair advantage or some such ten, twenty, or thirty years ago? No. I related those stories because I know a lot of other folks can relate. Hopefully, some of the accounts will be cathartic, some will raise a smile, and some will help prepare younger folks for when the same sort of thing happens to them.
In fact I'd be glad to see any of the folks in my stories again. Life has beat us all down over the years. Sadly a number of folks I've included in this memoir have suffered great hardship since our paths last crossed. You might say "So they got theirs." I'd say, "There but for the grace of God go I." And if my compassion for other people doesn't oughtweigh every grudge in my life, that's my fault, not their's.
Now it sounds like I'm writing about life, not technical writing. But when you've done something like this for thirty-two years, the lines get fuzzy.
Whether you're at the start of your career, in the middle, or at the end, I'll be glad to hear from you, especially if you have a "great moment in technical writing" - or several - to report.
Looking forward to your suggestions, additions, criticisms, and anything else you care to send me, I remain,
P.S. Enjoy your hobbies. And be sure to enjoy any time you have with your family in the coming weeks.
Note: Breakthrough Communications™, Family Garden Trains™, Garden Train Store™, Big Christmas Trains™, BIG Indoor Trains™, BIG Train Store™, and Trains-N-Towns™ are trademarks of Breakthrough Communications (www.btcomm.com). All information, data, text, and illustrations on this web site are Copyright (c) 1995, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 by Paul D. Race. Reuse or republication without prior written permission is specifically