There are just about as many approaches to writing as there are writers. Some technical writers start with an outline, some start with engineering specifications or market requirements. Unless it is a completely new product or process or whatever, most technical writers start with the existing (or similar) documentation. Some writers take a sort of 'stream of consciousness' approach. With all of these approaches, the author has at least a general thesis in mind: we know what we want to write about. I am particularly fond of this last approach for technical writing.
Starting writing is almost always difficult. Gene Fowler, a 1950's era screenwriter, is attributed as saying, "Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead." Overcoming the initial inertia of a "blank sheet of paper" can be almost overwhelming. As the director of a technical writing team, I was fond of telling my staff to "just write." Don't get caught up in style, or organization, or what you don't know. Just write what you do know. "Just writing" (with the appropriate end in mind, of course) allows for a focus on the text itself -- the rhetoric of the message. And as a great bonus, it leads to getting a lot of writing done. At the end of the day, the paper is not blank.
Knowing when something is "finished" has its own set of problems, There is always something else that can be written, or edited, or otherwise mucked around with. Using the parieto rule, 80% of the writing probably takes 20% of the time; the last 20% takes 80% of the time. Much of that is because we change and reorganize and edit and format and do a number of things at the end that don't have a lot to do with content. "Just writing" also helps prevent too much mucking. If you are focusing on the writing, you are not focusing on editing or formatting or rearranging. When you have nothing new to say, you stop -- and move on to the next topic to "just write" about that. It actually works.
At my company, we have been interviewing senior managers for the technical communication and training departments. A major topic of discusion is our corporate initiative to move to a structured authoring paradigm for creating "architected" knowledge bases using XML and DITA. XML is the extensible markup language. DITA is the Darwin information typing architecture. Both are technologies that facilitate creating documentation in a topic-based architecture, which makes it easier to reuse content. Because the new manager will manage in this new paradigm, it is important that we discuss it as part of the interview process. To date, each candidate who has already worked in a structured authoring environment stated that the technical communication team initially resisted it. From initial resistance, technical communicators either embraced it once implemented or left for environments more appropriate for their interests (often completely out of technical communication). I hear similar stories from my colleagues at other companies: initial resistance, then either a complete turnaround or total exodus.
Now the reason my little writing trick is of particular interest to me here is that it seems to be a good way to approach writing in the structured authoring paradigm. Research that I began for my master's thesis surfaced some initial data that supports this. However, my sample size was small and it was admittedly slanted toward adopters of structured authoring, so it really provides more of a possible direction for research rather than answers to the questions that I initially sought. One unanswered paradox continues to intrigues me: Why do some technical communicators seem to thrive writing in "topics," focusing almost exclusively on the text rather than format or style? And why do some thoroughly resist it? Before we had "word processors" and everything was typeset, technical writers had little to do with the way something would appear in a final document. The same is true when writing for publication even today; each publication has its own rules about style and format, which leads the author to emphasize the content without relying on format as a rhetorical vehicle for the message. So "just writing" is not specifically a question of the digital age, but it has come to the forefront as technical writing more and more becomes structured authoring.
Monday, June 16, 2008
Subscribe to:
Post Comments (Atom)
1 comment:
I like our advice to "just write," but I don't quite understand what you mean by writers writing "in topics." (Frankly, I think I'm pretty confused because I'm also taking Invention this semester, and we went back before Aristotle and have worked our way through several definitions of "topics.")
If your interest is in why some writers want to put the "meat" into the paper and ignore the "design" features that really help move ideas along (subheadings or graphics, for example), then I also agree--sounds interesting.
I've come to think of "design" as the whole package--but the "meat" and the "window dressing" (like subheadings/organization) that make the whole work rhetorically strong. But so far I'm not having a lot of success in getting my engineers past Sgt. Friday: "Just the facts, ma'am!"
Post a Comment