Working at a large corporation, in an information development department, on a suite of software products, I typically edit user interfaces, embedded assistance, contextual help, tutorials, and topics within an information center. That’s my main diet of what I edit day to day, week to week.
Every now and again, I will edit white papers or technical support documents that were written by developers. It is always a different experience (and process) to edit for developers instead of for trained technical communicators. I try to get a sense of the personality and working style of the developer before I begin my editing, so that I don’t walk into a lion’s den or open up pandora’s box, and end up doing more harm to the information and to the relationships that are so often a key to our success as technical communicators.
Recently, I was asked to edit a 125 slide presentation, which will be used as education. It was created by a developer, and will be updated and maintained by said developer. The request for editing came from my information architect, and really seemed like a simple request. I needed to apply our corporate template, clean up the formatting, and then clean up the terminology and check for egregious (my new favorite word of 2012) grammar errors.
I had started out doing all 3 tasks (template, formatting, and copy editing) at once, but quickly had to shift gears into making multiple passes. I was able to do the template and formatting editing in two days. I will finish the copy editing in a separate day, I am sure.
I realized several things by completing this edit:
- I really do prefer substantive editing (development editing, content editing, call it what you will) to copy editing. Ever since my first job as a development editor, I knew this was my preference, but this particular edit reaffirmed this feeling big time.
- I find template and format editing quite mind numbing. Perhaps having to do it across 125 slides compounded the issue, but I think I lost my patience and focus on this repetitive, detail-oriented work. This made me want to have been asked up front to provide the template and provide some advice on how to include both bullets and blocks of programming code on a slide, such that formatting it all would have been simpler and easier.
- Format editing is very distracting. It pops you out of the context, the language, and turns you into that hobgoblin. Inconsistent formatting is distracting to the language, and so you fall into fixing it, which then pulls you out of the language, and it is a constant fencing battle between the two types of editing.
- Before agreeing to help out with this edit, I should have asked more about the work. I might have delegated it to a co-op/intern on our team. As a senior technical editor, my time might have been better spent looking at other things. I need to be better about accepting work and delegating work to others. Or, perhaps this is one of those assignments that I have to just “suck it up” and get it done.
Well, time to get back to the copy editing pass of this presentation. Hope you enjoyed these musings of what’s coming across my desk this week. Happy editing!