Being so steeped in software development, I tend to see a lot of things in terms of software processes. Sometimes the tools help, and often, they don’t.
When I got through with a version two of a chapter for the book, my editor returned it with the most brutal comments to date. The thing had notes all over it, and she gave me longer, more general notes on the backs of the sheets. She wanted a return to something similar to what the first chapter’s structure was like, and from there, many comments on the different sub-sections, and then almost infinite bugs on the smaller parts.
I’ve tried two ways to go through this so far. The first is the “build it from scratch” approach, where you tear up the old one and re-write. This is tough, if only because it requires you to do a lot of research again where you can’t re-build off your citation index or whatever. It’s time-intensive and wearying.
The next is the bug-fixing. Each comment’s a defect in the original, and for each comment, you make a single correction. Typo, possible new wording, suggestion that two paragraphs should be moved up ahead of something else? Do them all, one at a time, and then put a check mark by the comment. This works fine when you’re close to the finish, the structure, tone, and other high-level issues are resolved, and the adjustments are all minor, even if they’re numerous.
On a chapter like this, that’d be equally disastrous. Moving everything around without fixing the larger structural issues doesn’t help.
I’ve been on products like this. It sucks.
What I’ve ended up doing on chapters at this stage is refactor in place. I read all the comments and identify that the biggest points are. Structure was the big one. The revised structure for v2 had led to repetition of information, poor connections between subjects, and was responsible for many of the smaller issues as well.
So I fixed that: I built out a skeleton and then took all of the discrete pieces and slowly, in order, worked them in, writing new sections, deleting duplicate chunks as I found them, and as I built the structure and fleshed it out, flow came more easily, and I was able to adapt the things I’d already written to fit. At any point, though, my editor could have called and told me she needed a draft right away, and I’d have been able to turn over a chapter that was x% new, well-flowing writing and the remainder the old version 2, with no duplication between the two. It worked great.
When I was done, I had a dramatically improved chapter, but had only directly addressed the top-level complaint. So I went through and read the second-tier: move this paragraph here, this other paragraph here, and found that they’d all been resolved by the structure work. Then the sentence structure/corrections too — the rewrite had fixed easily two thirds of those. The only remaining work was the request for new stuff (new features!) like a better description of a particular incident, and so on.
Those I still have to do. But ten years ago, I couldn’t have managed it. Given a large number of comments on a short story (say, from a workshop), I would look through for some suggestions I thought would make it a little better and take those. If there were structural problems, or issues with characters, I’d either ignore them or if I agreed, use them as justification to tear the whole thing down and restart.
I used to beat myself up sometimes for not continuing to work as little as possible while continually honing my writing, but it’s been interesting to see that the different things I have done, from baseball writing to screenwriting to the being steeped in methodologies of quality software development, have each given me tools to easily solve problems that once blocked me entirely.
It makes me want to go write that novel again.
