Tips for being a better development editor

I love lists. Lists of tips are awesome too. My twitter feed served up this tweet by the Society for Editors and Proofreaders (@TheSfEP):

I loved that this author thinks of editing as structural editing, or what I call substantive or development editing, and not copy editing or proofreading. She introduces her list of tips with this awesome quote about editing as magic, another love of mine:

For me, editing is where the magic happens. And editing has a lot in common with magic: it takes a lot of practice, and it works best when you see its effects, but not the details of how it was done.

Here are her 5 tips, with my thoughts or comments:

  1. Stay focused on the brief and the audience.

    I think I’d split this into two tips: Be brief and Stay focused on the audience. I think both have value for editors to remember.

  2. Remember: it’s a dialogue.

    Yes! It is not a dictatorship (even though we might want it to be sometimes), not a directive, but a dialogue.

  3. Look out for what the author doesn’t say.

    Editors must use all contexts, all information that is presented to them, and what is not written is very valuable information to consider.

  4. Timing is important.

    This one feels very specific to fiction writing, at least the way she presented it. In a technical communication world, timing of when you do your editing is important, so I’ll just adapt this tip for my context.

  5. Share the love.

    Editing is a very critical process, so it is important to comment on what you like or what is good about a piece of writing, so that you can keep the dialogue going between yourself and the writer.

This entry was posted in Substantive editing, Technical Editing. Bookmark the permalink.

3 Responses to Tips for being a better development editor

  1. Larry Kunz says:

    Those are good tips, Michelle. Thanks for passing them on.

    Timing matters in technical communication too. I still think of my lab partner in high-school chemistry, reading the instructions as I performed the experiment: “Place the magnesium strip into the flame.” Then, as my eyeballs were being seared by the flash of light: “Caution: do not look directly at the flame.”


    • Michelle Corbin says:

      You’re right, Larry! Even in my software documentation, there are issues of “timing” and needing to highlight prerequisite steps in procedures. I think the fiction writing focus of the article distracted me from seeing this connection immediately. Now, do I update my own blog post to address these user comments?


  2. Yup. I always enjoy reading what comes out of sfep. Wish we could get certification here in the U.S., but I’m fighting every impulse to go into a rant.

    What I really want to say is that the importance of no. 3 cannot be overemphasized.

    Especially for the technical communication world, it takes skill to identify information gaps, and our job as editors is to “see” these gaps when no one else does, not even the writer. Like professional indexers whose indexes include concepts that aren’t explicitly mentioned in the content, we provide our readers with context.

    Similar to indexing, developmental editing requires domain analysis: The context of the reference or the information must be examined for its relevance to the user. Both professionals must consider the perspective of the user.

    Perhaps I’m overreaching here, because we are talking about developmental editing, but I just couldn’t help but see the connection between indexer and developmental editor.


Comments are closed.