One thing that was very important to me when I first started writing (or to be more specific, when I got serious about it) was process.
I’m a software developer by trade, and process is extremely important. Each software development team from company to company will vary widely in its implementation of process. Whatever works best for each team (and each developer on it) is a factor that plays an important role in both the success as well as the experience of each developer. While it’s true that a developer may not have the ability to try to change the process for the team, just because it doesn’t seem a good fit for them, developers CAN do that if they are working alone.
As a writer who wanted the best chance for success, I needed a process that worked best for me. I looked up interviews with writers, at times asking them personally, to find out about their writing processes. For me, the biggest hang-up was whether to outline or not. As a software developer, there’s a great amount of design that goes into software development before we write any code.
So, it would be my practice to do the same thing with writing. There are a lot of varied opinions on this amongst all writers. Some say that you should not do much outlining and just take off writing (Stephen King). Some say that you should outline everything before you go off without knowing where you’re going (J.K. Rowling). My favorite is Laurell K. Hamilton, who said to outline what’s ahead, and be prepared to change it because your story will change as you write it.
I understand now, more than I did at the beginning, that the more experience you get as a writer, the less you may need to do prep-wise. Perhaps, in one way, your outline may become natural to you and you may have to do it less.
Either way, I found peace with this topic when I ended up emulating a variant of a software development methodology that I’ve worked with. It’s called a scrum, and it’s basically a brief status meeting with developers and testers that takes place every morning. Going around the room, each person gets a turn to answer (briefly) the following questions:
1. What did you do yesterday?
2. What do you plan to do today?
3. Any roadblocks?
The rule is that you can’t talk in tech form, but only from the user’s perspective. Feelings aren’t allowed, and you can’t ask questions. There is one person (a manager) that runs the scrum, and they can ask questions, and generally collects information in such a way to direct if necessary.
I found it very easy to have one scrum a week, by myself but writing long-hand in a writing journal.
1. What did I do this week, writing-wise?
2. What do I plan to do next?
3. Any roadblocks?
The rule is that I have to talk (writing long-hand, as I’m answering these questions to myself) from the reader or the character’s point of view. Afterwards, the experience usually gives me a good perspective to modify an informal outline of my story. By informal, I mean that it’s more of an extended synopsis, that grows with the novel.
Doing this has helped me stay focused on the task at hand and gives me a good idea of progress. It also lets me know of any problems I’m likely to run into later because I caught them now. I once realized that I had forty-five thousand words written but wasn’t even a quarter of the way through my synopsis, which told me early on that my book was too big, and I needed to take another look at my outline.
This was one way of letting the software developer in me help out the writer in me. If only I could just as successfully get the software developer in me OUT of the way when the writer in me is trying to not revise as I write. 😉