How software engineering made me a better story writer

I'm currently working on writing my first novella-length story. In doing so, I'm reading a lot about others' experiences writing and advice that helped them the most. I realized that a lot of the habits I've gained from my career in software engineering have been a huge help in the process of writing, and I'd like to share some of them in this little blog post.

Maintaining a design document

When starting a software project, you generally start with a design document that asks some of the following questions (and then some):

• What's the purpose of this project?
• What's not the purpose of this project?
• What steps do we need to take to achieve this purpose?
• What might get in the way of us accomplishing those steps?

Following that habit, before I even wrote a sentence in the doc for the story, I made a set of Notion docs to outline it. While it didn't follow the exact format of an engineering design doc, it did include:

• asking what the purpose of the story is (themes, philosophy, etc.)
• how we'll get there (a specific scene-by-scene outline, with each scene having a purpose)
• a list of characters with their traits and what they bring to the story
• a list of details to remember, like how scenes are set up, reminders to myself, and the general setting

Because of the groundwork I laid out, I'm able to write without really getting blocked. When in doubt, I go to the outline and work towards the next step of the story's purpose. Additionally, it's ensuring that through every step I'm writing purposefully and within the realm of what the project wants to do. This practice has made me so much more productive than when I would write stories without any side documentation.

All code is written with a purpose

This brings me to the second benefit: writing with a purpose. In code, every single line should do something important for your program. Similarly, in a story, every detail should have a reason for being there. A setting should be made up of details that build a scene; a scene should be set up to prop up some change; characters' interactions should be the cause of an effect and the effect of a cause. By being careful about this (and trying not to be too straightforward in my writing), I can stuff in a lot of metaphors and symbolism and keep the story progressing at an engaging pace.

Code should be easy to change

An important lesson that a lot of writers learn is that nothing has to be final. As long as you get something down on paper, you can always go back and change it. I struggled with this for a while, overthinking everything I wrote as if it would be in the final product. But when I started to think of it more as something I'm engineering, it became pretty easy. Since each part of the story has the purpose stated in the outline, big ideas are easy to switch out - they just have to work towards the same development. Those developments can also change, and by updating the design document it can stay consistent, and I know exactly where else I need to edit the story. Essentially, you can write your story modularly, especially in the rough draft, and smooth it out once you're happy with the general progression.

Conclusion

These are just a few ways I've been viewing story-writing as an engineering process. It's been incredibly helpful in keeping me productive and enjoying writing. As I continue writing the story (and hopefully finish it lol), I'll update this blog post with any other findings I discover.