The Writer as Software Engineer

This post was originally published at talanhorne.com

Stories are software.

No, really.

A Synthesis

They say that for the man holding hammer, every problem looks like a nail. And that may be coloring my perspective here.

But as someone who is both a writer and a software engineer, I can help but notice a certain amount of similarities. The both require me to sit down in front of a computer, with a keyboard, for hours at a time, and type.

They also don't mind if I belch while I work.

But seriously, the similarities go deeper than that.

Mr. Devil's Advocate: "Seems like a tough sell. These are obviously two very different things. A completed book, after all, just sits there. It is an object to be observed. But a piece of software actually performs work."

Well, you're not wrong: a book does no work. By itself, it is just a long string of data.

But a piece of software is exactly the same: by itself it does nothing. It doesn't actually perform work, because it is also just a long piece of data.

Mr. DA: "That can't be right. The software obviously does something. This post itself is a great example: the people reading this right now are doing so only because software makes it happen."

Wrong: the people reading this post can only do so because computers make it happen. The machines themselves are the ones doing the actual work.

The software is just an algorithm. It's like a recipe found in a cookbook.

And in cooking the one who does the work is not the recipe, but the cook.

Once the computer has the instructions, as outlined in the software, it follows them to the letter until completion. During the time when the software is running, it can be said to have the computer's attention.

Now, a book is not run on a computer's CPU, but it does capture the attention of something more powerful---a human mind. During the time in which the book is read, it holds the readers attention. The reader, in turn, acts out the list of instructions found within the book, though not physically. Rather, the reader's mind constructs the setting, the plot, and the characters based on the substance of the story, creating a living play inside the brain of the reader.

Mr. DA: "But that has to be a problem for someone who writes both books and software. You're dealing with two different kinds of audiences who want different things. Just what kind of similarity could be found between the two products?"

Shared Principles

It's true that you can't interchange a story with a computer program. Such a trade would not please either audience.

However, it would be hasty to conclude that these two things don't work according to the same principles. Both are made better by good design, and it is these design aspects that become highly swappable between the two disciplines.

As an example, let us take a look at the foundational credo of all software programming: "Don't reinvent the wheel."

This warning steers away software developers from laboring to create solutions that already exist. It also wards them away from that perennial design error: code duplication.

Because why should you bother to type out a set of instructions more than once? In software, this is avoided by creating "subroutines", which are a way of combining many small instructions into a big one. For example, if you find that your software commonly uses the following functions many times in the same order:

1. Insert Food.
2. Chew Food.
3. Swallow Food.

You can write a new subroutine called "Eat" that contains all three steps. And from now on, you can just call "Eat", instead of having to state the three steps one by one.

Subroutines also exist when writing a narrative story, though here it manifests as characters, props, locations, and events.

Characters are the best example. When the reader first encounters a new character, this person is a completely blank slate. But each time that character is in a scene, new details about them can be added to the reader's knowledge. If in an early scene, we discover that the character is not trustworthy, then we do not need to be told, each time the character reappears, that they are so. We already know this about them. It is already an established part of their subroutine.

If this were not so, then every time a familiar character walked onto the stage, the narrative would have to reintroduce them and reiterate all of their traits. That would be exhausting to the reader.

Ideally, the characters, props, locations, and events should accrue traits and functions incrementally as the story progresses. This will cause the story to get easier to write in the later chapters. Once everyone is well established, you will be able to set the tone of each scene just by putting some predefined assets into it. You can have a character who makes the atmosphere sinister or dangerous just by him being in the scene. Or you can have a location where the reader knows to expect comic relief, because you've already established that it's a funny place. All the work of description and mood-setting has already been taken care of, and you can keep the story going without having to reinvent all these wheels.

And, as much in writing as in software, you want to pare down what is there, until only the essential remains. By treating your story elements as subroutines, you can keep from unnecessarily repeating yourself, and you can delegate the work of creating the atmosphere to these subroutines---these characters and other elements that store and transform story data for you.

Order of Events

One other important similarity between software programming and story writing is the way that the flow of events is managed. Software is all about making sure the right functions are called in the right order. That's the entire discipline in a nutshell.

And stories also rely on a strict ordering of events. That order is not always chronological, but it is (if done right) always presented in an order that expands the reader's understanding of the events. The reader begins with an uncomplicated nugget of the plot, which opens the way to bigger and more complicated nodes as the story expands.

When events are presented in an order that causes a malfunction, or is not reliable, both reader and computer can, in their confusion, take erroneous action. The machine may do something it wasn't supposed to do. And the reader may see something on the stage of their mind that isn't supposed to be there.

From this we can see that books and software have even more in common when things go wrong, because they often go wrong for the same reason between the two disciplines. Both are vulnerable to the following problems

1. Syntax Errors - The result of incorrect spelling or grammar. Usually causes the machine/reader being unable to parse the code/story.
2. Semantic Errors - The result of ambiguity. Causes the machine/reader getting the wrong idea of what is supposed to be happening, which then leads to misinterpretation and then incorrect behavior.
3. Algorithmic Errors - The result of bad ordering. Functions are called out of sequence, and the machine/reader executes each function correctly, but still gets a bad final product.

Being trained to hunt for these errors, as a software engineer, has led me to be more aware of them in my writing.

Conclusion

Mr. DA: "I admit that there appears to be some overlap between the two disciplines, but couldn't that be said about almost any profession? I hope you're not claiming some special dispensation that software engineering gives over writing fiction."

You're right. It would be a mistake to make such an assertion, seeing as how humans have been writing fiction long before there were any kind of computers.

Still, algorithms are similarly old, being traceable back to the Greek mathematician, Euclid, at the very latest. I haven't done the work myself, but it's possible that a study of the history of algorithmic mathematics and the history of fiction writing may have some interesting parallels.

But there are also parallels between writing and all kinds of other professions. It makes sense that you could compare it to, say, carpentry or marketing or alchemy or whatever else people do. I already compared it to entrepreneurship.

Mr. DA: "And, to be fair, you've also already compared books to software."

I know. And I reserve the right to make other comparisons in the future.

Until then, I feel that the points made in this post will be useful, and may even solve problems for perhaps a few writers trying to hone their craft.