How to debug a novel

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
—Brian Kernighan

Revising a novel and debugging a computer program may seem like very different activities, but they have one important thing in common: when something breaks, you usually don’t know the hell why. With a program, at least, it’s often clear when you have a problem. You’ve carefully written a bunch of code—or typed it in verbatim from a textbook—and checked it over for mistakes, but when you compile and run it, you end up with an error message, a bunch of garbage, or nothing at all. When a novel is failing, it isn’t always as obvious. You’ve invested months into telling a particular story, which you wouldn’t have done if you didn’t care about it, but when you take a few weeks off and go back to reread it, the result seems inert: the characters are flat, the events don’t pop the way they did in your imagination, and you find yourself getting bored by your own story before you’re halfway done. What’s required, in short, is debugging. And while coders have access to a range of useful debugging tools, if you’re writing fiction, you’ve got no choice but to do it the old-fashioned way.

The first step in traditional debugging is to carefully read over the code, preferably on paper. Sometimes you find that you’ve made a stupid syntactical mistake—there’s a missing semicolon or closing parenthesis that throws the entire program out of whack. The equivalent in fiction is bad grammar or sloppy sentence construction, which makes even the best stories die on the page. (Here the best guide, as usual, is Strunk and White, and it’s no accident that its example inspired Brian Kernighan and P.J. Plauger to write The Elements of Programming Style.) On a somewhat higher level, you can ask yourself whether the story follows the few objective rules of storytelling in which you have any confidence. These vary from one genre to another, as well as between authors, but most writers eventually figure out a set of their own. Does the protagonist have a logical objective from one moment to the next? Does each scene start as late and end as early as possible? Does every chapter open with a clear situation? These are the building blocks of narrative, and if they don’t work on the lowest level, the story is likely to fall apart on the highest.

Which brings us to the print statement. It’s a trick that most beginning programmers figure out on their own: if a program is breaking, it’s often because one or more variables aren’t receiving the values they should. Modern debuggers have tools for tracking down such problems, but the most basic solution is to insert print statements into the code to display the value of the suspect variables at each stage in the process. It’s a window into the program, allowing you to follow it step by step. And although there isn’t an exact equivalent in writing fiction—in which everything is right there on the page—it can often be useful to pause the story to ask yourself where exactly you stand. As a writer reading over your own work, you have full knowledge of where the story is going, and you know that a slow stretch in Chapter 5 is necessary to set up an exciting sequence in Chapter 6. But a reader doesn’t know this. As difficult as it might be, then, you need to ask yourself what a reader encountering the story for the first time will think of a scene on its own terms. And writing it out often helps. Like a print statement, it’s a snapshot of where the story is right now, which is all the reader—or computer—can be expected to care about.

The last technique worth mentioning is the wolf fence algorithm, as first described by Edward Gauss:

There’s one wolf in Alaska, how do you find it? First build a fence down the middle of the state, wait for the wolf to howl, determine which side of the fence it is on. Repeat process on that side only, until you get to the point where you can see the wolf.

In programming, this means subdividing the code until you find the section where the program is failing, then repeating the process until you’ve zeroed in on the problem. Most novelists tend to do this intuitively. When you’re reading over a novel, you start to think of it in large chunks: you know that the sequence from page 150 to 250 works fine, while the first forty pages are giving you trouble, even if you’re not sure how or where. Instead of trying to crack the novel as a whole, it makes sense to focus on the trouble spots, continuing to narrow the scope as you iteratively revise . After the first revision, you find that three out of the five chapters in question seem fine, even though the overall section is still giving you trouble, which implies that the problem is in one of the two chapters remaining. And you repeat as necessary, homing in on something as small as a misconceived page or paragraph, until you’ve found your wolf.