On Editing And The Creative Process

Image credit: Dawn Turner via 101 Reasons To Stop Writing

Editing one's own work is something that nearly every writer has to do. That's especially true for bloggers, because on any personal blog there is usually only one potential editor. Nicole Palmby, AKA "NP", has written a couple of articles describing the process of editing one's own work. Together, they describe the process of self-editing. She recommends that the first step should be:

A good way to start editing is to read your story all the way through without making any changes. Try to read it as though it was written by someone else. By reading through the story, you can get a much better feel for the flow of the story, and you'll be better able to notice any inconsistencies that may appear. You may want to keep a notebook or piece of paper handy to make notes as you're reading, but try to concentrate just on the reading.

Editing Tips, Part One

I usually end up correcting minor mistakes the first time I read through an article, but I really wish I didn't. Whether you do will probably depend on how much you grit your teeth and growl when you encounter spelling and simple grammar mistakes. The only errors I think you probably should correct are the sort of subtle ones you might miss later, like using "to" where you should have used "too", that sort of thing.

NP's advice boils down to doing three passes through your work, with the first being the one where you try to just read it to understand how it flows. Then, start reading through again, this time making major changes. "Major changes" means adding, removing, or moving particular thoughts to make the progression of the story more logical or easier to follow. Then, on the third pass fix the minor stuff.

This process is similar to the one I used back when I was writing software. There's a certain logic to it - you don't want to be obsessing about what to name a counter or how to indent when you're not sure how the loop is going to work. What's more, with time, the little things will be things you will learn to do automatically. A writer's spelling will improve, and a programmer will learn how to name variables and format text so it's easier to parse.

The second part of NP's advice has to do with having someone else read and comment on your story. For a blog, this probably isn't practical, but for any story where you're not too sure how someone else will interpret it, this might be a good idea:

This method of editing can be particularly helpful when you feel like you're at a dead end with a story. It could simply be that you're too close to the story to see what needs tweaking. A fresh pair of eyes may be all you need to break through the dead end and finish writing and editing a great story.

When you get feedback from a reader, be sure you understand it. If something doesn't make sense to you, ask for clarification. When your reader makes a suggestion for something to be changed or added or deleted, make sure you understand why the person is making that suggestion. Once you understand their feedback, you can jump back into self-editing.

Editing Tips, Part Two

In programming, of course, there are counterparts to this. Structured walkthroughs and source code audits are two methods software engineers use to eliminate errors from programs by having other programmers review and discuss a program.

An independent reviewer might ask why I would bother to mention software engineering in an article about copy editing. The reason I did is that what NP has outlined is a process that works in many fields, especially when the end product of that process is something that other people will make use of. Not getting lost in the nitty-gritty details before you've figured out the basic design is a good habit in just about any line of art or engineering.

Eventually, there will come a time when the product you're working on is good enough. Writers would probably say "Art is never finished, only abandoned". Engineering managers would say "There's a time in every project when you have to shoot the engineers and get on with production". Learning when what you've done is good enough may be the hardest lesson of all.

Nicole's articles are well worth a read if you're a writer who is learning the craft. Even if you're not a writer, they ought to inspire you to think about the process you use in your own line of work.

Now, I think it's time to abandon this project and get on with production.

Afterword: For those interested Jody Paul has written a good reference on structured walkthroughs, describing both the motivations and a workable methodology. As an unreconstructed open source guy it pains me to say this, but the old Microsoft series on software engineering provides some great ideas on this subject. Unfortunately, finding a link to that series has been difficult. Anyone who is really interested and can't find it, please leave a comment.

My first encounter with the idea of code audits was in the OpenBSD project. All the core source code in this operating system is subjected to a rigorous review by other programmers in the group. The OpenBSD team have been responsible for a gradual improvement in the quality and security of POSIX (online specification) software over the years.