Guest Post: The Software Engineer’s Guide To Writing

Writing a first draft is, for me, panicked, frenzied, and riddled with wrong turns. The first few steps are clear, and from there I’m running in a black room and my only light comes from a pair of shoes that blink when I step. At some point I run smack into a wall with “You’re Done” painted on it, and then I start the process of turning my winding path into a straight line.

Designing software to a nebulous set of requirements feels just like this.

I am both a writer and a professional engineer. Sometimes people are surprised, that I could manage being an engineer-type yet still pull off being a creative-type. This is strange. Sometimes people say it makes sense, pairing a very left-brained activity with a very right-brained activity. This is less-strange, but still strange. These responses tend to come from people sitting on one side of the divide, who have maybe glanced over the fence, but aren’t too sure about the other side, with their strange cocktails and funny hats. Being a card-carrying member of both camps, I am comfortable saying: Folks, we have a fair bit in common.

For me, there is a highly creative component to designing and implementing software, and there is a highly technical component to writing and editing a novel. Outside of the basics of simply getting your grammar done right, moving through a novel and getting something cohesive at the other end requires a blend of creativity and methodicalness very similar to designing software. I should know. I do both.

First comes the original creative push. What if this guy dedicated his whole life to chasing a big whale? What if I made my college directory into a website where you could openly call people your friends and send them messages? At this stage it’s ephemeral, just a dream waiting to be made real.

Then you start in on some of the details. Wondering what shape your story will take. How your software will look in the end. For writers, this is the outline or first-draft stage. For engineers, is the design and proof-of-concept stage. (While you certainly can code by the seat of your pants — similar to writing without an outline — it isn’t always advisable, unless you do so love rewriting your codebase.)

Then you sit back and examine what you’ve done. And you realize, crap, I wrote this realtime application in Java, and I should have done it in C. You realize, damn, I just wrote a 88,937-word novel in past-tense when it would be so much better in present tense (this is totally not from personal experience, nope). There is no hard-and-fast rule for what tense to select for a story or what perspective to write from, just as there are no hard-and-fast rules in software development for what language to select or what algorithms to use.

Though there should be a hard-and-fast rule against Java in realtime applications. Sayin’.

You examine the flow of information. Are the critical details in the correct order? Will the person seeing this struggle to sort out what’s going on? Will they be immediately pulled in and find themselves effortlessly moving through what you’ve created? In both writing and software, there is the human element. You do not publish your work for no one to read it. You don’t release software for no one to use it. As such, both have to be created with user/reader expectations in mind. And while to an extent these are known metrics, with tried-and-true methods to achieving your goals (Checkhov’s gun, binding +S to “Save”), there’s a point at which you don’t have a model for what you’re doing and you simply have to know, from a deep and intuitive place, that what you are doing is right.

So you revise. You refine. You rub your work with a soft cloth until the stone begins to shine. A well-placed data structure, an elegantly constructed flow of data, these are like a lovely turn of phrase or the unfolding of details on the page. It requires a skilled craftsman to come to the correct solution in either discipline.

And, just like writing, software is never completed. It is only abandoned.

Morgan Dempsey is a writer, professional engineer, and part-time masters student living in Silicon Valley. If you enjoyed this post, you may find more at

6 comments on “Guest Post: The Software Engineer’s Guide To Writing

  1. Ace says:

    I like the “seat-of-pants-code-writing” analogy. The Pantsers may protest.

    Nicely done, dempsey. I raise many beers and much applause in your direction.

  2. Not bad.

    He said, having written about 50 hardware & software manuals, and three novels.

    (It’s true; my novels tend to be about hardware and software and engineering, and also incidentally about people, so perhaps the disjunction is even less in evidence in my case. . .)

  3. Nicely said. I’m also a full-time software engineer who writes in his free time. I’ve always found the dichotomy works well. I’ve found others balance their technical side with, say, music. Lately, I’ve been integrating engineering concepts into my fantasy fiction. Sort of steampunk, but more a sort of pseudo-science.

  4. Nicely said my friend. Keep it ip

Comments are closed.