Prose is Sort of Like Code


Prose is Sort of Like Code

I have recently found myself thinking how similar some of the approaches I use in writing prose are to techniques I use when writing code. Perhaps it’s common knowledge, or, maybe, I’m onto something here.

First, however, let me provide some back story.

Some Backstory

I started writing as a hobby when I was thirteen. I wrote short stories and some of them had some sort of a plot, others were meant to instil a certain feeling, yet others were semi-elaborate setups for a punch-line. My stories were bad for several reasons, let’s list them and try to put them into a software development perspective:

A lot of them were badly written - syntactically and semantically. I had experience in reading prose, but not writing it. I didn’t have a style either.

It’s fine, it’s a natural process. When you’re just starting - you don’t have the required experience, you maybe have something to say, but quite frequently it isn’t enough. Just like with code, the more you try - the more you get comfortable with the language at your disposal and get to know how you can make it work for you.

With programming - to get better at what you’re doing you read books on software architecture, code design patterns, clean code; you read other people’s code and note the really cool stuff, as well as awfully terrible stuff; you write programs, code up solutions - useful or completely ad hoc. And in programming you’re lucky enough to be able to easily tell if it fails, you can see metrics on code performance or test coverage. So it’s not that hard to determine whether your code is good or not.

In writing prose - you might read books on writing (although less frequently); you also read other people’s work; and you write your own stories and sometimes you don’t feel embarrassed when you re-read them fifteen years later. But there is no way I know of to tell that your story is good immediately after you’ve finished it, I guess you just have to trust your gut.

Most of them were written in an evening or in a weekend following an idea I had the day before.

I distinctly remember, when I was a placement student at IBM, my approach to fixing bugs or adding new functionality was simple: spend a few days struggling with the problem, make it work, as soon as it works - deliver it. Maybe my motivation for that was that I thought everyone expected the solution to be ready yesterday, maybe I just thought that a working solution and a good enough solution were equivalent. They are not. And, really, it should take as long as it takes to write a piece of code or text that is neatly written and does/says exactly what you want it to do/say. The amount of time it will take to get it to that point doesn’t matter, because - surprise! - you will get better and quicker at it with time, but only if you put enough effort now. Bad habits propagate too easily.

The majority of things I wrote were aimed at people I presented the stories to. I made assumptions about what they would like or dislike and wrote towards satisfying their imagined need.

Not a revelation, really, you write code to solve a problem. Writing it to satisfy every need (real or imaginary) of a client results in an explosion of irrelevant features and a monstrosity of a program. At the end of the day - the program needs to do that one thing that it’s supposed to do, and do it really well. Very much the same with text - it needs to tell the story you want to tell through a prism of your experience and empathy. Anything else would feel fake.

I have listened to reader feedback.

This step requires some confidence in your own experience and knowledge. Maybe a pinch of arrogance too, not too much though. If a client requests an Android app and then stands behind your back and tells you what methods to write, where to use conditionals, how your code can be improved - it’s insane and maybe they should’ve done it themselves. It’s also easy for the client to judge if the program does the right thing. Run it - does it produce an expected result? Awesome. With prose though, it’s not as straightforward, everyone can read and write text, but text is a means, not the goal. Here a whole combination of reader experiences, understanding of context, history, language - comes into play, some people are more qualified to judge the work in its completeness, others - less, but ultimately, I think, no one is ever able to look at a piece of writing and see it in exactly the same way as its author does. So, really, you know best what you want to say, with enough experience - you also know how you want to say it. Trying to cater to every single reader would be bonkers.

Later, in my late teens - early twenties I felt like I had to write a novel. Not because I had so much to say that it wouldn’t fit in my usual short story format - but because it felt like it was time for an upgrade. By the age of twenty four (2009) I wrote three novels, self-published one of them on blurb. Don’t ask. The reason they weren’t particularly good was something else entirely.

There was a distinct lack of a big enough idea or a well-defined structure.

The lack of a big enough idea for a book can essentially be compared to a solution not fitting the specifications. As for the lack of a well-defined structure - the only way I know of that helps create a solid, consistent narrative (either programmatic or prosaic) is establishing an architecture. Surely, knowing how something should be built beforehand - helps immensely with staying on track and not drifting off from the main idea.

At twenty five I moved to UK and stopped writing for my own reasons. Then two years back I thought that it would be rather nice to write one final book as a nod to a past hobby that used to be a big part of my life. But I wanted to write it on my own terms and using a smarter approach. I wanted to put so much effort into it that, regardless of whether I’d relate to it years from now, I’d still appreciate the work I put into it. That’s how Dream City became a project. Here’s what working on it was like.

Coding and Prose: Similarities

Prototyping and iterative design

I sat down and outlined some of the characters and the story. When I knew what direction the story was going - I created a simple book plan: how many parts the book will need to consist of thematically, what will be the message in each of those parts - are the messages distinct enough to justify splitting the book into three parts?

Once I had that - I split each part into chapters and wrote one or two sentences for each chapter, describing what needs to happen in it.

Having only a couple of sentences per each chapter means that you can easily change the direction of the plot, re-arrange chapters or scrap the initial assumptions and do something that’s way cooler. In fact, I did it several times.

Once I was happy with my chapter plan - I started writing bigger chunks of text. Mainly covering beginnings and endings of the three parts of the book. That gave me the ability to see whether there is enough meat in the story to fill the in-betweens. That approach helped me dump a few chapters that turned out to be fillers, irrelevant to the story or setting.

I have now finished my first draft and will be going through the whole thing a multitude of times to refine the text, make it cleaner, more readable.


As I wrote the chapters - I also wrote comments for myself next to chapters to remember to use a specific reference, to utilize a detail, to remind me that the bit I was looking at was dependent on a different chapter. Very much like with my code - once the job was done - the comments were removed, the text was good enough to explain itself.

Process Formalisation

When working on personal projects in the past - I frequently struggled with establishing a routine. It’s easy to work nine to five, five days a week - when you’re getting paid for it and need to show up at the office; it’s much harder when: a) no one is making you; b) there is no immediate gain from it.

Since I already used Agile for my hobby game project (to be addressed after I’m done with the book), I’ve decided to try some of the techniques with the book writing.

I established a schedule: I would write on Wednesday, Thursday and Friday evenings - after work, for at least an hour. I would frequently - once every three weeks - report my progress to a couple of friends. They didn’t exactly know that it was part of my writing process, but hey it worked. I found it to be a good motivator to continue working on the book consistently.

I would write out a plan for the next week or two on my glassboard, having it in front of me helped with motivation.

Another problem that I came across was that, once I started writing a chapter, I wanted it to come out perfect. And it took me a year to figure out that it was a problem. I would open the document, re-read what I have already written, feel like it could be improved and end up just modifying already existing stuff instead of attacking the unwritten. In the end I had to concede that what was already written was good enough for now. So from then on I only looked at the old text if I wanted to reference some of the details.

Like I said, a major clean-up will surely follow.


There are only three testing techniques for prose I know of and use.

  1. I re-read what I have written to get rid of typos, problems with grammar, too frequent word or idea repetitions.
  2. I read my prose to myself out-loud to test the flow of text - see if it’s smooth, understandable, if certain couplings of words don’t make me lose my rhythm or stumble. I do this frequently, at least a dozen times for each chapter.
  3. I either read bits and pieces of what I’ve written to one or two friends to see if my perception of the flow matches theirs, or ask them to give it a read - since anyone, especially the author, can easily become blind to their own misusages of words, grammatical errors or confusing formatting of the text. Note: friends need to understand that this testing isn’t about the story, it’s about the way it’s told.

Syntactic Analysis

Natural languages are much more complex than programming languages are, the day when someone comes up with a text editor that not only can track down grammatical errors, but also will tell you whether you should be using ‘complex’ or ‘complicated’ would be a wonderful day. In the meantime the best we can do is pay attention to the red squiggly lines.

Coding and Prose: Differences

It is tempting to avoid this section altogether, since a list of differences can get pretty long, but I felt there were a few worth mentioning.


‘You Aren’t Gonna Need It’ is a great principle in programming. It helps you avoid writing an explosion of methods for the sake of completeness or with an assumption that at some point in the distant future you might implement a new feature that will totally, absolutely, positively need these specific methods.

In my experience of writing (which you should take with a massive pinch of salt, me technically being an unpublished author and everything) - writing things that won’t end up in the final version of the manuscript is great. Write a whole chapter covering the background story of one of your characters, or write fifteen pages about the landscape that the character saw out of the window of a moving train. These are great, they’re studies of your imaginary worlds and people. You understand their motivations better, you get why they would stop in the middle of the field and gaze at the clouds when being late or something. And then, when you have sufficient understanding of drives and environments - you select all those chapters and delete them. But it’s not all for nothing, these things will find a way to express themselves in phrases, short descriptions, nouns and actions.

Fail Fast

Sometimes it’s extremely hard to tell whether your story is going in the right direction or not. Even with all the planning done and re-done and a UML diagram representation of your plot on the screen (note, I didn’t actually create a UML diagram for Dream City) - sometimes, ten chapters in, you realize that it just doesn’t work, so you throw it away and start over.

Bugs and Updates

Typos frequently get fixed in later editions of books, but rarely (if at all) would you find a different version of it - with some plot points changed, or new chapters added. Although you do get short stories that turn into full-blown books (for an example check out ‘Flowers for Algernon’ by Daniel Keyes), also revisions seem to work really well for technical writing.

Lack of an IWE

As in, Integrated Writing Environment (as opposed to an Integrated Development Environment). Like I said above, yeah - you can check for simple problems with grammar, but how cool would it be if you could select a character name, hit F3 and get to the point where they were first introduced to the reader. Or hit alt+shift+M and change the character’s name or gender everywhere in the book. Or run a semantic analysis on the work in progress, for the IWE to tell you that, yes, ‘for all intensive purposes’ is technically correct, but, no, that’s not right.

A kind of conclusion

In any case, I have just finished my first draft of Dream City and it’s not complete garbage. Maybe it will find its way to book-store shelves or maybe it will live the rest of its life in a locked drawer in my flat. Who knows. Regardless, I think the process of writing it has taught me things about my job role and, surprise-surprise, demonstrated the importance of discipline.

I don’t think numbers are a good representation of the quality of a book, but, to be consistent with one of my earlier posts, here are the deets:

  • I started ‘Dream City’ on the 17/02/2015
  • It consists of 3 finished parts of 3 planned
  • Or 57 chapters.
  • Or 180 A4 pages of text, font size 12.
  • Or 95,330 words.
  • Or 528,325 characters.