When Worlds Collide: How Writing Fiction Intersects with Writing Code

I’ve recently become a big fan of author Trevor Schmidt’s science fiction novels. They’re pacing is perfect and the characters are wonderfully engaging. Despite his latest book being set in a truly alien environment, his writing is so immersive that you don’t even notice it. Trevor recently posted a guide to world-building for authors. As I read through his recommendations, I found a lot of his suggestions also apply to programming.

1. Fysiks (Not just for Newton)

Trevor’s first suggestion is establish a baseline for physics in a fictional world.  The same is very applicable to programming, as well. When you’re writing an API, a library, or a user-facing app, you want to have established a set of rules that defines how your app/library/code behaves. Let’s start with an analogy:

Jumping on the Earth

Let’s say you’re feeling pretty happy and want to express it by jumping up and down. On Earth, the basic rules of physics say: What goes up must come down. If I jump, I expect to land.

What happens if you travel to a new planet (or create a new system of physics for a fictional world)? You change the rules.

When you change that basic rule, you introduce uncertainty. Imagine a planet that had physics just like Earth, but 10% of the time, jumping up would cause you to travel at constant velocity into outer space. What would be the reaction of everyday people? Everyone living on that world would be terrified to ever jump.

Jumping in Code

From a programmer’s perspective, uncertainty is pure evil. Much like readers of a novel, you want to set a baseline of expectations for what the code will provide. For example, if you write a weather app, you need to ensure that that app is able to report the weather. If you’re unable to meet that baseline of expectations, you can expect users to flee in droves.

2. Back Story

Good fiction is often based upon a good back story. It’s difficult for readers to engage when there’s no history to drive a fictional world forward. Tolkein’s uber-famous Lord of the Rings trilogy was, quite literally, a footnote in the history of his greater saga of Middle-Earth.

Writing code is no different. From a high level, you already see this back story defined by the language you’re using:

  • In the world of Java and C#, the object is king. Everything is a class or derived from a class. The usage of objects is typically driven by the fact that they are most commonly named as nouns. They are typically things to be acted upon.
  • Way across the spectrum, you have languages like ML and Haskell. These are functional languages, whose raison d’etre is use functions as verbs, where the action being performed is king and the object/noun is the thing simply being pushed along as temporary data.
  • You’ll also find languages like Javascript who (for better or for worse) place little bounds upon how you use the language. In some ways, this makes prototyping new functionality a breeze, but there’s also little to stop you from shooting yourself in the foot.

3. Rule Systems

In writing, rule systems are often where the political or individual character nuances enter the fold. Given a world defined by scientific laws, these are the rules of behavior that govern an individual system of interactions.

In code, it is no different. Just as Darth Vader sets the tone for who truly rules the Imperial council, the expectations of a system of code will drive the user’s experience.

As an example, I wrote an API for my job that very strictly defined a set of behaviors. If anything in the code violated that behavior, it should be treated as a bug. Likewise, any new feature that was added would have to adhere by the spirit of the behavior, lest the new functionality would obscure the capabilities of the broader API. Human beings are very good at recognizing patterns. The idea behind the API was that you’d set a pattern of behavior before the user (and end-user programmer) that was so clear, there would be no confusion as to how to leverage it to drive domain-specific needs.

If an API can’t provide that level of assurance, no one will use it. In the end, the technical design detailing the spirit of that API’s behavior was so well defined, it was used almost verbatim as documentation sent to customers.

4. You’ve got me, what now?

This is where our story diverges. In entertainment (writing, movies, etc.), it’s often the unexpected that serves as the perfect hook to engage your audience.

Code is not like this. Remember, computers are machines and humans don’t want to have to think about what a computer is doing for them. Having a well-defined flow of behavior, with little or no deviation, is what drives usage. When you start throwing unexpected twists in the expectations, you’ll drive users away.

If Nothing Else: Explore

In the end, there is much a programmer can take away from learning expertise in other areas. It always benefits you to broaden your horizons, to challenge your brain to think in ways different than what you’re used to – whether that be learning a new language, contributing to a open-source library, or learning some suggestions for a completely foreign field, like fiction. That’s how your mental muscles grow and how you become a better programmer.