This week I’m reposting some favourite Inflatable Ink pieces from the last year or so. Here’s the last.
Oh yes, and Happy New Year! I hope you all achieve your writing goals!</p>
Oh yes, and Happy New Year! I hope you all achieve your writing goals!</p>
In another life, I’m a coder, and I write books about code.</div>
As I’ve become more serious about fiction in recent years, I’ve increasingly noticed parallels between the process of developing software and that of building a story. I’ve been meaning to write about this for a while, but the intersection of coders and fiction writers is probably quite small. So it looked like one of those nice little echoes you enjoy, but can’t quite find a use for.
Now I’m not so sure.
The core similarity lies in the fact that any story is a system, a machine you build and then set off in the imagination of others. As writers we create structures that we must keep in our heads, and yet also inhabit. We engage with our story as if we are consuming it for the first time from the outside. We also enjoy its hidden aesthetic, the neatness of our tricks. All those balances of theme and foreshadowing, tension and pay off have an elegance in their construction, as they have an affect in their consumption.
A software developer builds systems too, and inhabits them in a similar way. When I’m coding I often imagine my project in spacial terms, as if it were a palace of the mind. Just like a novel in development, it really only exists as words on a screen as I write. And yet each component I’ve created lives in balance with others. I create lines of communication between these components, modes of interaction. In my mind they have shape and they talk to one another.
When these components are activated, though, processed, they’ll actually come alive and the shapes I imagined will have real meaning. That meaning will be tested by users of the system (both real people and programs that pretend to be people).
Users will not see the complexity and elegance of the components that interact behind the system’s facade, but they will prove the coder’s imagination. What started as a fantasy of parts moving in co-operation will end in something that a user believes is real, inevitable even. The structures behind the scenes will have been transformed into flows of use, just as the structures that make up a story are transformed into a flow of narrative.
Users and readers are trained to accept convention without thought. So much so that the conventions disappear. The cues that signal a flashback, the hook at the end of a chapter, a faux defeat before a protagonist finally triumphs, these are all used by a reader to negotiate a story, and accepted without too much conscious thought. Such conventions only really become noticeable when they go wrong. The same is true of the menus, and recycle bins, the windows and pointers, the whole drag and drop world a software system’s user must negotiate. Most of the time it’s transparent. And yet, of course it’s a complex set of conventions that must be learned.
And why is this useful? Well maybe, if there are similarities here there may be tools, or strategies, modes of thought that could translate well from one field to another. In a future post, I will look at one technique that has hopped disciplines in the past, and may do so again.
