The Hand That Wields the Red Pen
— Kumar Dhanagopal
This article is a tribute to that vital, yet often misunderstood, profession of editing. Through this article, I hope to achieve the following goals:
- Promote awareness about editing and its role in technical communication.
- Explain why it is so hard to assign a value to the function of editing.
What is editing?
In a rather simplistic sense, “editing is to writing what testing is to coding”. Style police, grammar nit-pickers, language maniacs … – these are some of the descriptions we often hear being ascribed to editors. It does not take a whole lot of digging to figure out that there’s more to editing than finding ‘bugs’ in a document.
A standard definition of editing is hard to come by. Practicing editors balk at providing any single catch-all definition. Instead, they painstakingly point out that there are several types of editing – substantive editing, production editing, developmental editing, language editing, copy editing, technical editing, and so on.
Role of editing in the technical communication process
Each type of editing plays a distinct role in improving the quality of documentation, and is performed at different phases in the technical communication process (see graph).
This graph shows the relative prominence1 of each type of editing during various stages in the documentation process.
- The blue area represents language editing — the most visible aspect of a typical editor's work. In the early days of a project, there's obviously very little 'language' to edit. In most projects, content development picks up serious steam as the final deadline looms. So toward the end of the project, the editor is literally scrambling to catch up with a constant inflow of raw content – as indicated by the blooming blue funnel in the graph.
- The grey areas (literally so!) are the lesser-known aspects of an editor's work.
- The light grey area represents developmental editing. In an ideal world, editors are heavily involved in this type of editing up-front in the documentation process. Here's where the foundation is laid for the overall structure of the documentation set. As the content takes shape, fewer and fewer structural changes would be required (and feasible); consequently, the role of this type of editing tapers off as the project progresses.
- The dark grey area in the graph represents substantive editing. After the first draft is in place (based on the structure that the developmental editor helps create), the editor looks for opportunities to improve the quality of content: completeness, relevance, and consistency. As the project nears completion, opportunities for improving content significantly dwindle, and so does the role of this type of editing.
The definition and prominence of each type of editing might vary across organizations, but editing is recognized as a specialized area within technical communication. Though not all organizations employ full-time editors, most large teams have a distinct editing function, often performed by senior writers wearing the editing hat.
So why is editing so important? To understand the reasons, let us consider how the absence of editing would affect quality of documentation.
Language editing
Sometimes (though not correctly) language editing is also called copy editing. Definitions vary. Let’s not even go there. Assume for a moment that this type of editing involves verifying whether writing adheres to the guidelines in that infamous, seldom-appreciated tome: the house style guide. What would happen if this type of editing didn’t exist? In such a world, every writer would need to produce content that (a) is grammatically perfect and (b) complies with every guideline and rule in the house style guide. Good writing is a rare commodity. As far as adherence to the style guide is concerned, the less said the better. Even writers for whom the style guide is bed-time reading material don’t necessarily apply all the style guidelines faithfully to every piece of writing they produce. That’s where the language editor steps in.
Then why is it so difficult for us to recognize the value of this type of editing? Let’s admit it: It requires lots of guts to receive a page full of annotations in red ink and not feel bad about it. It brings back unpleasant memories of red ink on our school answer-scripts. We all like to believe that we write well and don’t need a second set of eyes. Those of us who’ve never had the good fortune of having our work edited would rather not find out whether we can stomach the experience.
Another issue: Even in the most well planned of projects, this type of editing ends up getting squeezed between a rigid release date and an ever-slipping content-freeze milestone. The extent to which editorial feedback is eventually addressed in the documentation is anybody’s guess.
Developmental editing
Among other things, this type of editing ensures that content is structured logically and facilitates easy maintenance. It requires deep understanding of the target audience. Information architects often (sometimes mostly) perform developmental editing. Ideally, this type of editing occurs very early in the documentation process. Imagine a scenario where this type of editing doesn’t exist at all – not that hard to imagine, right? In such a scenario, especially in a large writing team, chances are that the final documentation set will turn out to be incoherent, poorly organized, and needlessly voluminous.
Still, very few organizations have a formal developmental editing function. In the few that do, this type of editing is performed for only ‘exceptionally complex’ projects. Why?
For the answer, we needn’t look far: Cost. In a typical product development project, how much effort is budgeted for product architecture (equivalent to developmental editing) as opposed to the effort toward product development, QA, and the other downstream activities? Not a whole lot, unfortunately! Product architecture is an expensive affair. So is developmental editing. Some organizations try to overcome this problem by ‘investing’ in a one-time effort of developing a one-size-fits-all information ‘model’ that they hope can then be ‘implemented’ by any writer for any project. No information model, however carefully designed, can compensate for project-specific developmental editing.
Substantive editing
In this type of editing, the editor looks beyond language and structure. The focus of this type of editing is on enriching content: making sure that it is useful and relevant. This necessarily means that the editor is familiar with (if not an expert in) the domain, the technology, and the product. The editor identifies issues such as inconsistent information across sections of the document, information that is obviously missing, ambiguous content, and, sometimes, even technical errors.
Barring a few exceptions, the documentation process in almost every organization involves some kind of ‘technical’ review by experts: typically, from development, quality, and product management. In most technical reviews, however, the experts go through the motions of reviewing the document without consciously focusing on the content. They are either too busy, too distracted with ‘more important’ product issues, or simply don’t know what to do with ‘that 300-page manual’ that lands one fine day in their inbox. Result: Large holes in the content.
To some extent at least, substantive editing can fill these gaping content holes. The problem is that, even in organizations that do have full-time editing functions, substantive editing is seldom explicitly spelt out in the editors’ job description. To complicate matters further, editors rarely get time to ramp-up on domain, technology, and product knowledge. Edit requests queue up so unpredictably that editors simply do not have the luxury of brushing up on the subject matter before plunging in with the red pencil.
Great! So what?
We have examined various editing types and understood why recognizing the value of editing is a challenge. The next time you see your frazzled editor in the hallway, remember this article and, if possible, spare a smile. Don’t cringe at those squiggly red marks all over your carefully crafted epic. Behind the hand wielding that dreaded red pen, there’s a friend trying to make sure that your document looks good when it goes out the door.
______________________
1 The graph does not indicate the relative value that each form of editing brings to documentation. That’s a matter for further analysis and, surely, some debate. For all we know, the dark-grey area (substantive editing), though small in terms of budgeted effort, might provide maximum return on time spent.
Remember that in the real world, the ramp-down/up of each editing type is never as clear-cut as the graph indicates. The ramp lines are likely to be very jagged, and, at times, may even change direction abruptly. The numbers too would vary widely across organizations. Nevertheless, the overall pattern would be similar to that indicated by this graph.
About the Author
Kumar Dhanagopal works as a Principal Technical Writer at BEA Systems India (now an Oracle company). His knowledge about editing comes from interaction with editors, peer editing assignments, and an online course from UCLA in technical editing – not necessarily in that order.
Acknowledgement: Thanks to Gururaj B S for his guidance in making this article possible.
STC India | Home | Contact Us