Myths and realities of contract technical writing

摘要

These ideas may provide one of the more meaningful sessions that you attend because we are going to be dealing with that thing of IDENTITY. The identity of the independent technical writer. Some of you will want to nod off and then there will be some who will be jumping off your seats. You may react, "No, it's not like that," or query "I've really got to know how your experience compares when it comes to …" (whatever) and out comes a Niagara of questions: your experience, your thoughts, maybe even your outrage.

Let me talk about some of the myths in contract writing and let me describe some realities as I've experienced them. Later we'll discuss their ramifications.

To give you the context for these experiences, let me give the statistics that arise when I tally the projects listed on my resume. Starting in the late '60s, I did programming (three positions), followed by a marketing position where I sold time on an international time-sharing system. Then I made a shift into technical writing. For eight years, I labored as an employee, doing technical writing in a wide range of computer environments.

For the last five years, I've been a freelance writer doing computer documentation in the computer industry in the San Francisco Bay Area. Here is a sample of the types of tasks I've been put to. I've written: manuals to support a product, in house technical notes where one programmer keeps another informed of progress, publicity pieces for trade magazines, a report from corporate management to their backers portraying the concepts and facilities of a proposed product, and several tutorials and quick reference cards.

Not including the range of hardware and software involved, the statistics on these contract jobs may give you a sense of the variety of modes in this work. I've participated in 30 writing/editing jobs of which two were co-authoring, four were editing commercial books and one was a technical review of a commercial book. Of these 30 tasks, 10 were performed at the client's place of business and 20 at my Albany office. Incidentally, there were approximately five failures: false starts where the "client" wanted only an estimate or the company rebudgeted for various reasons. In these five years, I wrote 1054 pages of original material and revised 922 pages. In terms of size, 30% of my tasks were for big companies (more than a hundred warm bodies onsite); 50% of my tasks were for medium sized companies (10 to 100 people); and 20% of my tasks were for small operations (1 to 10 wizards). I began by touting myself as a "documentation consultant;" I settled later simply for "technical writer."

That's a quick "statistical" look at my experience. But what is its soul? Sometimes contract technical writing is viewed as a top-notch rescue operation. What amount of that is myth and what amount is reality? Let's limit our grantedly breezy discussion to some myths clouding these few issues:

the experience you must bring to each task,

the imagethat you project and that the client buys,

the services that you really provide,

the standing you have within the company, and

what attitudes you need for survival and for obtaining nurturance from this line of work.

When we're done, I hope we'll be better able to engender productive attitudes. Those of you who hire independent contractors will be better able to describe your needs and understand the fears and insecurities of the freelancer. Those of you who are freelancers will see the broader picture of where you fit and understand better how to serve.