The Multitasking Writer

I came across this article through Lifehacker. It’s another one of those get more sleep and more exercise type of things. You know, stuff that we all know we should do but never seem to find the time? While reading this article, do as I did and blank out the word “geek”. Replace it with writer or novelist, or whatever you call yourself. I used writer myself:

Debate: Health Problems Related to the GeekWriting Lifestyle

The typical geek trains their brain to be heavily focused while multitasking day after day. Is it surprising that this same brain does not do well when forced to isolate down to one task? Listening in a meeting is a very isolated, very passive event. Coding, developing, debugging — these are not passive at all. The geek brain is just not trained to sit quietly and listen.

Writing and coding are so similar in process and execution. Just take a look at the tag line for WordPress – “Code is Poetry.” Indeed it is.

Like a programmer, writers tend to keep a lot of pots on the stove. We have fifteen story ideas in the oven and a few defrosting in the sink. Of course, there’s also the grocery list of ingredients that always seems to get longer and longer. We tend to file that under the general heading of “Research” but really it’s probably better to call it “Books I am Pretending to Read Instead of Writing.”

The best programmers hate to work from a plan. They say they just know what needs doing and they do it. Of course, in practice, most of these programmers have a plan. They keep it in a hidden file that no one else can see. They tend it and work it over and over again, much as a novelist might an outline. Like the real outline for a novel, the plan is often narrative in shape as opposed to list-focused. The idea is to tell a story about the code being worked on instead of mindlessly iterating through points A and B.

Think I’m kidding? Check this out:

User Stories in Extreme Programming (XP)

One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest
difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.

As writers, we are faced with the same sort of multifaceted information stream that programmers deal with each and every day. Our stream may not come as fast, but it’s there in our subconscious. Though, I have to say, how awesome would it be to have your novel send you critical notices when your plot is going awry? “Where are the log files for the scene in Deborah’s kitchen?”

Rather than force yourself out of that stream, you should embrace it and learn to file the bits and pieces away. Learn how to pause while writing, just long enough to put a little note down. Fiction is an active sport, learn to play it with your whole mind.

Leave a Reply

Your email address will not be published. Required fields are marked *