Rob Heaton
Rob Heaton

Software Engineer
One track lover/Down a two-way lane

Writing stories is not like programming

06 May 2016

I’ve been writing some stories recently. It’s a lot of fun and I’m pleased with how many of them have turned out. However, I’ve found myself wanting to write stories in the same way that I program computers, and I don’t think that this works.

Writing the same way that I program doesn’t mean that I write short, reusable paragraphs or exclusively whilst extremely, extremely drunk. It means that I find myself building up a story layer by layer, one aspect at a time. In this methodology, first you lay down the plot, with the role of lead, love interest and sidekick all played by store mannequins and crash test dummies. Then you fill in that the lead crash test dummy plays jazz bass, is a Jehovah’s Witness, doesn’t care for cubism, is allergic to spandex. Then you do the same for the love interest. Then you describe where any of this plot actually took place. Finally you dust the whole piece with a sprinkling of poignancy dust, fix the most glaring typos, add a few warnings about the dangers of capitalism and inadequate fire safety and that’s a wrap.

Unfortunately, all of these different elements feed infinitely back into each other. The plot will affect the setting will affect the tone. Steve’s jazz bass impacts Alice’s depression, which impacts his faith, which impacts her search for meaning in her own life. I don’t think that these elements can be built on their own, isolated from each other. Powerful, immersive writing braids its themes and techniques together tightly, winding them in and out of each other until you can’t work out where plot ends and characters begin.

On the other hand, working on one aspect of one thing at one time is a huge part of writing good code. If you’re doing it right then you design everything in separate modular components that don’t depend on each other. You can and should leave huge gaping holes with a TODO saying that you’ll be back to fix things in a few hours with a trowel and some superglue. You can design what data a function or entire system will receive, what data it will give back, and then forget about implementing it until the time is right. Sure your code isn’t fast/readable/flexible yet, but you can worry about that later.

I can’t imagine that Ian McEwan’s first drafts are covered with “TODO: decide whether this world actually has magic or not” or lists of remaining traits to apply to his characters. Of course not everything that goes into a first draft is going to be good or even coherent. Characters, locations and imagery are added and changed throughout the editing process. But I suspect that a first draft has to start with at least some attempt to cover all of the different pieces that make up a good story.

I’m sure that temporarily forgetting about characters in order to focus on plot is not the end of the world, and perhaps this is simply what the planning process is for. But no matter how detailed a plan one has, the practice of converting plan to prose is a huge, safety-net-less leap that never has to be made when programming. It seems inconceivable that it could ever be a mechanical matter of slotting together different fragments that were prepared in relative isolation. You always have to simultaneously weave together hundreds of different strands, hoping that they are strong enough to keep you floating and that you don’t accidentally leave your main character’s secret addiction to modeling glue trailing behind.

I’d love to be wrong, but I don’t think that writers can start with something quite as simple and iterate to quite the same extent as programmers.

“The short man stole a ring and took it to Mordor.”
“The short man and his fat friend stole a ring and took it to Mordor.”
“The short man and his fat friend, neither of whom would stop singing oh my God Jesus Christ, stole a ring and took it to Mordor.”
“The short man…”

Get more posts like this: