Defining technical editing

While presenting at the STC Technical Communication Summit on the levels and types of edits (I’ll write a post about that another time), I had a technical writer pose a question as a challenge to a statement I had made: “Why would technical writers ask to have their writing edited if their SMEs were reviewing their work?”. I attempted to explain the difference between technical editing and technical reviewing and ultimately technical writing.

The question reminded me of the first book that I read about technical editing, Judith Tarutz’s book from 1992, one that is still relevant and useful today. In her first chapter, she did a great job of differentiating the task of editing (which both writers and editors do) and the role of editor. My favorite quote is: “Think of the distinction between editing and being an editor as analogous to playing tennis and being a professional tennis player. The difference isn’t in the activity alone but in the skill of its execution. Other professionals may edit from time to time, but the editor is the skilled professional who does it all the time and so has a more trained eye.” (p. 5).

Tarutz’s definition of technical editing is also still my favorite: “Editing involves these activities: reading critically and objectively; reading from the audience’s point of view; questioning what you read and reacting to it; verifying, checking, and testing; evaluating usability; and judging the appropriateness for the intended use and audience.” (p. 4). Of course, we have to consult the premiere textbook for technical editing, by Carolyn Rude (and now also Angela Eaton), for it’s definition of technical editing: “Editing the text means making it complete, accurate, correct, comprehensible, usable, and appropriate for the readers…. The editor serves as the readers’ advocate.” (p. 12).

What is fundamental to these definitions, but which is often overlooked, is that technical editing is much more than editing the language alone. Technical editing cannot be automated or replaced by software (once again, an idea for another post). Almost 10 years ago, I had to justify the value of technical editing to my managers. These definitions were not enough, and so I researched what others had done, and ultimately came to my own definition: technical editing is a quality assurance activity. Because technical writing had been compared to programming, I compared technical editing to testing. It was a powerful argument to make: you don’t send your code out without it being tested, so you shouldn’t send your documentation out without it being edited.

My definition of technical editing really emphasized comprehensive editing in the context of quality assurance, including and thinking about these quality assurance activities: “ensuring technical accuracy; understanding and working toward the big picture; reducing the amount of information; re-using information; customizing information for different software solutions; and enabling continuous improvement.” (p. 290).

I think it is time for another look at technical editing, to try to discover how to define our field in the face of social media (like this blog, which I really should have someone edit before I post it), collaborative authoring on wikis, and other innovative ways of presenting technical information. Will writers seek out editors in these new environments to ensure the quality of their information? Can editors elbow their way into these new environments and differentiate the value that they can bring to producing high quality information? Or, will more writers become editors? Perhaps I’ll use this blog to explore this new definition and these questions.

References in this post:

Tarutz, J. (1992). Technical Editing: The Practical Guide for Editors and Writers. Reading, MA: Addison-Wesley Publishing Company:

Rude, C. D. (2006). Technical Editing (4th ed.). New York: Pearson Longman. (I am one edition behind what is now available on Amazon):

Corbin, M., Moell, P., & Boyd, M. (2002). “Technical Editing As Quality Assurance: Adding Value to Content.” Technical Communication, 49 (3): 286-300.

This entry was posted in Technical Editing. Bookmark the permalink.