If you google “story engineering” you’ll quickly see that I’m not the first person to think of writing a story as a kind of engineering. I imagine that this seems strange to people who think of engineering as being more about calculation than creativity.
Let me describe to you the three fundamental things that I got out of my first Computer Science class. I think you’ll see immediately how these translate to writing:
- Define the “big problem” you’re trying to solve.
- Decompose (break down) the big problem into smaller, more manageable problems. If necessary, decompose those problems, and so on until you’re left with nice little problems that you know how to solve.
- You will find things you don’t like about the way you broke the big problems into smaller problems, and you will find things you don’t like about the way you solved some the small problems. Revisit those things until you’re happy with them.
There. I just saved you a semester’s worth of tuition.
In all seriousness, these simple tools are incredibly useful. If you learn how to define your problems effectively and how to break them into smaller problems then you can accomplish almost anything. The third part – iterating – is mostly a matter of being open to new solutions and having the patience to spend the time to execute them.
In writing, the “big problem” is obviously your story idea. You may know a lot about it or you may only have a general concept. It doesn’t really matter. Just jot down notes about what you know, however much or little it is. If you don’t know much, then you’ll probably end up iterating more, but so what? You’re going to iterate some regardless. If nothing else, ask yourself this question: What would have to be true about this story when it’s done in order for me to be happy with it? Maybe it needs to capture a certain tone? Express a certain idea? Leave the reader feeling a certain way?
In writing, the story is decomposed (broken down) into scenes. So… take a look at your notes about what you want to accomplish in your story and start jotting down scenes that accomplish those things. You’ll probably find that most of the things you want to accomplish are too big for a single scene, so break them up and accomplish parts of them in different scenes. Conversely, you will find that a single scene can typically do double- or triple-duty (and be more interesting) by dealing with more than one of your smaller problems at the same time.
In writing, multiple iterations are multiple drafts — or at least multiple passes through the manuscript to deal with specific things.
Keep in mind that I titled this “basic principles of story engineering,” not “everything there is to know about story engineering.” At their core, though, this is how both writing and engineering work for me.
I took the picture above in the museum under the Gateway Arch in St. Louis. It seems like a great example of the relationship between engineering and art.