Picture is unrelated

Well, I’m just going to come out and say it. I’m having trouble finishing my second novel. It’s been months since I worked it for any decent length of time and now I’m almost afraid of touching it and messing up what’s already written. Plus, each time I sit down to work on it I have to reread 65k words to get caught up with what’s going on, as well as to get into the character voice again. By the time I’ve read all that I’m out of energy to start writing. So I’ve hit a bit of a wall.

Now, the way I like to solve problems is with creative solutions that set up self-perpetuating systems, rather than solutions that rely on constant vigilance and unbounded effort. That is to say: I don’t like forcing a stuck door every time I want to open it. I’d rather take some time to study why the door is sticking and learn how to re-hang or trim the door so it opens smoothly thereafter.

Right now, for me, sitting down to work on my novel is forcing a stuck door. It takes too much effort and is a task that can only be performed via sheer willpower, which isn’t an easy thing, nor do I feel results in good writing. So I need a brainhack. I need to figure out what’s causing my stuck door and figure out how to rehang it to get back on track. I have a method that I plan to try. I don’t know if it’ll work yet, but it’s worth a shot and anything should be more effective than continually trying to force a stuck door. This post is a description of that method. It’ll take a bit to lay it all out, but once it’s done I’d like your input. If you’ve tried anything like this I’d like to know how it worked for you.

So, I’m a tech writer at my day job. This means that I regularly dip my fingers in lots of pies: graphic design, marketing, writing, training, web development, business development, and even a little light coding on occasion. I used to use a programming idea when I was teaching in grad school to teach students a problem solving method. The writing method in this post, what I like to call “Iterative Novel Development,” is also the result of adapting a programming technique to another field, in this case: writing novels.

Sometimes, when developing programs, there is a clear roadmap from the beginning. This is ideal. But sometimes when developing a program there is only a general idea of what needs to be accomplished and it’s up to the programmer to take that idea and translate it into exact instructions for the computer to execute.

In the latter case it’s sometimes necessary to sit down and plan all the features from the beginning. However, on other occasions it’s best to take the boiled down, core functionality of the program and develop that first, get it running and working, and then add more features on top. This method can cause some messy hacks if the initial code isn’t well written to begin with, or if too many “out of scope” features are crammed in later. But in general, developing something and making sure it works at each step is a better idea than trying to write a bunch of interdependent code to support all the features from the get go and then finding out it doesn’t work when it’s all linked together.

This is the idea: the idea of developing a program, getting the core working, and then adding more features. This is a method I’d like to try to develop a novel. I think it’ll be a successful brainhack to finishing the novel. Here’s my reasoning:

I’ve spent some time examining my stuck door on this one. First, I needed to answer why I don’t sit down to work on the novel like I sit down to work on other projects. That one is pretty easy to answer: I’m no longer excited about it. The magic is gone. There’s no joie de vivre. It’s old hat. I’ve solved all the problems in the story in my head and so all I have left to do is write it down and that’s the boring part. That’s an issue.

Now, before you protest (and I can already hear, even over the internet, the vacuuming breath intake that comes right before a lecture), I know that a good part of writing is ass-in-seat, pound it out, get it down, look up after the dust settles. There’s no other way to write a book than to sit down and type and type and type. I know that. That’s not a problem for me. I regularly write 10k+ words a week of documentation at work. (Hell, look how long this post is already and barely anything has been said.) Sitting down and pounding it out isn’t an issue for me.

I also hate hate hate the idea that an “artist” is this sensitive thing that only creates art when the mood takes him and the weather is right and he’s not hungry or thirsty or in a fragile emotional state and the Cubs are winning and it’s the 17^th Friday of the year and all the other bullcrap things that need to be on that list to get the project done. Besides, writers aren’t “artists.” Writers tell stories and solve problems. That’s not a sensitive emotional thing, even if the story is about a sensitive emotional thing. Writing is about calculating the best way to manipulate the reader into the desired emotional response. That’s science type shit, cloaked in the guise of art.

So believe me when I say that my stuck door here isn’t that I’m a sensitive artist who needs the stars to align to finish a project. However, I do need to be interested in it (or be getting paid). I need to have problems to solve and goals that are possible to complete quickly. I’m a gamer, too. Maybe games ruined me for this. Or maybe I like games because games operate in the way I need to work. I suppose it can be both. Can’t it be both?

So now I’m left with this: my stuck door is due to a lack of interest in the project. My only real motivation here is “finish the work” which is enough motivation for ass-in-seat of about 800 words every two months. That’s not a good timeline to finish the work in the next decade, let alone in the next year. Not to mention that the writing suffers because those 800 words aren’t in the correct voice, since it’s hard to pick up the correct voice for the character after a two month break.

So I know my stuck door is a lack of interest in the project for its own sake. I need to figure out a way to inspire interest in the project so I can get ass-in-seat and pound it out the remaining 30k words to finish the story and what I intend to be a 95k word book. That’s the problem I need to solve.

I’ve decided to test if a technique adapted from programming is the best way to renew interest in the project. I don’t know that it will work, but it’s worth a try to get this thing in the shipping bin.

Sometimes, when developing a program, first I’ll develop the minimum functionality and get it working. At that point, the project is complete. I experience the rush of finishing the project because I’ve created a working program. I like to use a Swiss Army knife as a metaphor for this. I have a Swiss Army knife with only a blade, but it’s useable as a tool. I’d done my job and I get the rush of completion after a minimum time investment. The other advantage, since the core didn’t take tons of time to develop, is that it’s easy to see if the program sucks. If I’d waited until I spent all the time adding all the features and fringe-scoped features that crept in before I actually got the program to work, and the program sucked, I’d have wasted tons more time. So I develop each section at a time, get it working, experience the rush, and then move on to the next feature.

This is a good method because my Swiss Army knife is useable from very early on in the process. It always has a blade. Later I can add a bottle opener, a file, a saw, scissors, and all the other features I want to add. Each feature is a new project that doesn’t take much time to develop. Each time a feature is added the program is complete and I experience the rush.

Of course, there can be issues that I have to be aware of as I develop. One: even though the project is complete after every feature, I have to be mindful as I develop that later I will probably want to add more features. This means writing code that is as general and expandable as possible as I go, otherwise I will run into issues as I continue to add features. Two: there is a max limit to how much a program can be expanded from a core, before the core must be scrapped and rewritten from scratch. This is okay with a small program, but can break the project if the scope grows too large.

Still, these issues can be mostly overcome with thoughtful programming and a firm stance against too much or the wrong kind of feature creep.

So I’d like to adapt this iterative programming method to writing a novel. Obviously this method isn’t needed for short stories or other projects that can be finished using the brute force (start to finish) method in one or two sittings. But for novels that require months of continued and renewable interest, this could be a good method to ensure that the zeal is refreshed on a regular basis by completing waypoints.

I imagine it would work something like this: write a first draft of the novel that is split into several chunks, whether it is chapters or sections or whathaveyou. Make each chunk one to two sentences long and tell the whole story of the book. My current novel is planned to be about 30 chapters and I’m sitting with a blinking cursor at chapter 22. Rather than trying to brute force chapter 22, I should write one sentence for chapter 22 and then move on to chapter 23. I’ll write one sentence for 23 and then move on to 24, etc.

Rather than think about this as an outline, which is what it seems to be at first glance, it seems better to think of each of these one sentence chapters as completed chapters, or at the very least, containers for chapters. Once they are done I’ve finished my book and experienced the rush of completion. Now it’s time to move on to iteration numbero dos.

In the second iteration I’ll take each of my one sentence chapters and make them into several paragraphs that expand what happens in those one-sentence events. I plan to think about this like I’m zooming into Google Earth. I start with a chapter that is the whole planet. On the second iteration my goal isn’t to now be able to read the writing on the newspaper held by the guy on 5^th Avenue in NYC. My intention is to zoom into a country, maybe. I’m not even ready for cities yet on this iteration.

Keep in mind that this is writing that is telling the story, not providing a framework to use to build the story, like an outline would be. I want to make sure that when I’ve finished iteration two that the story is again complete. I’ve added a bunch of features, but I haven’t broken the story or left parts where the story cannot be understood or suffers. This is very important. The story must be a usable Swiss Army knife at the end of each iteration.

Once iteration two is complete, I’ll move on to three, and four, and as many iterations as it takes to build in all the features I want. I suspect that each iteration will be easier than trying to develop the story from beginning to end via brute force. It’s much, much, much easier to flesh out a scene to get it to do exactly what I want it to do if I have a clear objective in mind before I finish the scene. It’s just like writing a function in a program. I know want a function that does a specific task. That’s the hard part. Now all I have to do is break that task down into specific steps for the computer to execute. It’s just logic and science, baby.

It can be the same with a scene. If my first iteration leaves me with a chapter 22 that says: “While looking for a job, Simon finds a local newspaper with an announcement that Lucian is coming to town for a book signing. Simon decides to visit Lucian at the book signing.” This works as a chapter because it tells the action, following from the previous chapter and leading into the action of the next chapter. In iteration two I can zoom in on the individual elements a little. Depending on if visiting Lucian at the book signing is in chapter 22 or in 23, I can start writing paragraphs to flesh out my scenes. I’ll have a paragraph wherein Simon is looking for a job through various methods and finds the ad about Lucian’s book signing. I’ll have a paragraph about Simon traveling to the book signing and thinking about Lucian. Finally, I’ll have a paragraph describing the book signing. Chapter 22, which was two sentences, is now three paragraphs and is feature complete. I’ll move on to Chapter 23, then 24, and on until the end.

Once I have all the chapters complete in iteration two I’ve finished the novel again. In a newly started novel (mine isn’t, but assume it is for this napkin math example), I’ve now taken my novel from 600 words (30 chapters at twenty words per chapter) to 9000 words (30 chapters at 300 words per chapter). Again, my novel is complete and I experience the rush of completion. I have a short story if I want to stop here. But I don’t. I want a novel with all the trimmings.

So on to iteration three, where I’ll break down each scene into sub scenes. I can break down the paragraph that broadly described the book signing into the needed elements: a paragraph explaining something weird Simon was thinking about in the parking lot, the people Simon noticed while standing in line during the signing, the brief conversation Lucian and Simon had during the signing where they made plans for later, the activities Simon did while waiting for Lucian to finish, the longer conversation Simon and Lucian had after the signing, and what Simon did once he came home from the book signing.

Since each expansion has a clear objective, these are much easier to writing than writing a scene with no clear objective. I know the entrance conditions of the scene (the state of the characters, the state of the plot, the state of the relationships, etc.) and I know the exit conditions (what changed in the scene, and how it changed). Now the only problems I have to solve are small, simple steps describing the exact method of what changed and how, or description problems (what are some thoughts Simon might have about standing in line? How would he express them?). This is much easier and allows me to control the pacing of the scene very precisely.  Since each node can be zoomed into (but not every node is necessary for zooming), more detail can be added with each iteration, until all the needed detail is in the story.

For the record I’ll restate that I haven’t used this method to write a novel, only brainstormed about how the method might work. But already I’m aware that I must be mindful of a few things as I write using this technique. One: each iteration will take more time than the last. The first few will be quick and easy. The later iterations will take longer. But, since the story is complete at every step, I think the excitement of adding more features will prevail over the additional time each iteration takes. This is something I plan to dispassionately observe when using this method, so I can see how it functions in practice.

Issue two: the first iteration will be dreadfully important, since it will be very difficult to change the story once the first few iterations are complete. Changing the story in the middle will require scrapping large blocks of content that’s already written. This needs to be avoided. It’s something I’m very frightened about. In general I’m not the type of writer who changes things midstream – I usually have the broad strokes mapped out in my head before I begin, but it does happen. For a writer who writes to “figure out the story” as she goes, rather than “tell a story” that’s in her head, this method would not work because of this immutability.

However, I feel like this issue can be minimized by writing a quality first iteration. Once the first iteration is done, the story can be examined for suck. If it sucks, I plan to change the first iteration before moving on, or scrap the whole thing. In a way, the first iteration is the story prototype. I stand by the notion that it’s impossible to determine if an unfinished story sucks, so a complete draft, even at 600 words, is needed. This is the first iteration.

Issue three: finally, it’s also necessary to be aware that if you are the type of writer who starts a story without knowing the ending, a writer who is writing the story to tell yourself the story as you write, this method seems very dangerous to the completion prospects. I’ve found that writers who write that way have a hard time finishing a story once they know the ending, unless they are within shooting distance of the ending and can brute force the writing of it. If this type of writer sorts out too much too soon, there is a weird thing that happens in the brain, this idea that the story has already been told somehow, and interest is lost in the story. I’ve seen this happen with people who talk about their novel too much, too. They tell the story while explaining the novel to people, and then have less interest in writing it down. This iterative method could be disastrous for that type of writer, since the complete story is told in the first iteration, the mystery is solved, and there is less reason to expand and add more features to the story.

So that’s the idea and I’m going to give it a shot to finish my second novel. Since I already have 65K words brute forced up to this point, I’m only going to try iterative novel development on the remainder of the story, rather than the whole thing.

I am aware that it may be easier to iterate the remainder of the story, since I already have a firm grasp on the characters and plot, than it would be begin iteration from the beginning. This may mean that when starting a third novel I should brute force the first 20k words while the excitement alone is enough to carry me, so I can get a firm grasp on the characters and plot, and then iterate from there. It’s something to be tested in the future.

Gosh. That took awhile to write. It probably took awhile to read, too. Now that it’s all out: has anyone used a method like this to write a long form work? How did it go? If you haven’t used it, what problems or advantages do you see with this method? Do you use something similar to this? Or do you use something else? If this isn’t your writing process, what is your writing process?

Please let me know in the comments below.

Thanks for reading.