Craft Singles

It’s been more than a year since we published The Apotheosis Break (published October 2016).

We’re sorry? We guess? We get asked a lot: When is the second volume coming out? That’s probably not uncommon of people who publish something with ‘Book 1’ or ‘Volume 1’ or ‘Saga’ in the title. We have hoisted our every petard.

Our coy, infuriating answer for 2017 was, “Coming in 2017!” People laughed, and nodded like they got a satisfactory answer, and went about their business.

Now it is 2018. Now we say, “Coming in 2018!” They laugh less. They do not nod. They insist, “Yeah, but when?” The eyes in the room turn toward us. We shrug. They go about their business, but glance back occasionally. Their disappointment is apparent.

We have been working. We have been working a lot. But that is mostly irrelevant to someone who has just finished the first book and wants more. They wonder if we’re ever going to answer the questions they have. They wonder if all the time they invested into the first book was worth it. They are asking if they should put that mental real estate back into the market where it could be put to better use: those continuing education credits, that dissertation, that critical thesis, that new season of Black Mirror.

We have done a lot of work. I mean, a lot. Giterary records the number of seconds that you spend inputting keystrokes. For Volume 2 alone, we are at 196 keystroke-hours. Based on Mike and I’s folk heuristics about how this translates into clock-hours, we estimate at least ten clock-hours for every keystroke-hour. So, we are estimating almost 2,000 hours between us for writing and editing. For perspective, the American 40-hour full-time work week, after 52 weeks in a year, weighs in at 2,080 hours. So that’s like working a full time job that we jigsawed into dwindling free nights, busy weekends, and ever-shortening holidays.

To clarify, that’s around 2,000 hours since February 2014 (when we started outlining and writing on Volume 2 in earnest). There are 1,440 commits (discrete changes to a chapter) between February 2014 and October 2016 when we published Volume 1 (and started editing on Volume 2). Since then, we have another 1,459 commits. That means, in theory, we’ve put as much work in our first draft as we have in editing it since then.

The editing, however, is without the gleeful exuberance of pure creation. And with it comes the continual reminder of your fallibilities as a writer, as a human being, and as a thinking machine. We might have around the same number of commits, but editing feels like it takes ten times as long.

Surely, we are doing it wrong, and surely there are resources out there. Say you go looking. You’ll find that there is a wealth of information for people wanting to start out with the writing their novels. Their mantra is Just write!, shouted with upraised fist. The purpose of the mantra is to get people to start, to worry less about the task ahead, and worry more about getting something down. The hope is to build up enough momentum that once you need to edit, the sheer inexcusably large mass of your manuscript has enough inertia to carry you through.

If you again go looking, there is comparatively little is out there for the end game. Lots of questions come up: “I’ve got my manuscript. Now what?” But there isn’t a mantra for editing. There is only work, and pain, and then one day you wake up and you hit ‘Publish’ on your book and you don’t know how you got there. All you know is that the last page of Volume 1 reads, “The story continues in Volume 2.” And the work you have signed yourself up for is immense.

With every new edit, we see Volume 2 getting closer to being publishable, and hopefully farther away from succumbing to sophomore slump.

Closer, but maybe not close. If Volume 2 were a video game, we wouldn’t be fighting the final boss, but we would certainly be in the final world. We could see the final castle on the map, flitting from place to place. We know there are some seriously bullshit water and moving screen levels in between us and victory, but it’s nothing we haven’t seen before.

As such, I’d like to use this blog post to document some of the stuff we do as part of our (hopefully final) editing passes. The following are some specific things we do to get from draft to draft. May they be a light for you in dark places. Especially those ghost levels where you can only see a little bit around you and you keep having to guess which door is the right one.

Thing 1: Say it in a stupid voice

I really love Star Trek. It’s silly at times. It’s bad at times. But I think for the moments when it’s good, really good, make up for everything else.

But it is truly difficult to get through some of Star Trek. And usually, the only thing that gets you through is the acting. Patrick Stewart saved innumerable bad lines by being able to out-act poor scripts. And while that can’t save you from an episode where your characters awkwardly battle on an alien jungle gym with a weird boxing glove with nails sticking out of it, it goes a long way.

Mike and I, however, will not have the incomparable Sir Patrick Stewart to read our book. In all likelihood, we probably won’t ever have someone read our stuff out loud other than ourselves, much less a professional actor. But that’s not of concern at the moment. That’s a problem for a future Josh and Mike.

I (Josh) keep Star Trek in mind when reading through. I say to myself, “What if it’s not Patrick Stewart reading the line? What if it’s someone else that is less bound by the conformity of perfection?”

The test is this: if I have a line that I am fond of, I put it through the “silly voice test.” This is where I read it in a silly accent, aloud, for the world to hear.

If the line stands up, and still feels like how it should feel when spoken like a Swedish Chef, then it’s a good line. If you have to imagine it being read by a knighted Shakespearean actor for it to be good, then it still needs work.

Thing 1 Summary: Read your important, power lines in a silly voice.

Thing 2: Every Change Can Be A Breaking Change

This is more of a practice than an editing pass, but it’s critical to editing nonetheless. Hear me out.

Our Giterary tool has a feature to be able to show the word-by-word differences between each update. The chapter text is displayed, but with removed words being marked in red, and added words being marked in blue.

This ‘diff’ display has two uses.

First, it lets us communicate our changes to the other, displaying quickly and succinctly show what was changed. This saves an incredible amount of time, making it so we don’t have to read the whole chapter over again and try to figure out the changes by ourselves.

The second use is a little more subtle, but equally important: We review the diffs as soon as we make the changes.

Why? That seems redundant, right?

A little, yes. But it’s important to review for a few reasons.

Consider that you’re making a pass for passive langauge. You find a few egregious examples. You change the wording. But as you’re typing, you reuse a portion of the sentence, because who needs to do all that typing.

Perhaps you made the conversion perfectly. Perhaps that sentence you reused rather than retyped was a perfect match. But maybe not. Maybe your tenses don’t match anymore, or you’ve got a plural mismatch. Your spellchecker might catch it. But it shouldn’t be something you inherently trust.

The thing to keep in mind is that just because you’re editing doesn’t mean that you aren’t still making mistakes. If you review your own diffs, and do so as you make them, you are likelier to catch a problem that you introduced.

This sounds tedious, I’m sure. But consider what the problem looks like at scale. We are looking at around 160,000 words for Volume 2. It already takes us a few weeks for each editing pass we do. We have to find ways to both reduce the number of problems in the book, but also not re-introduce problems with the fixes. We find that the best time to catch follow-on errors is right after they are made, while the part of the text is still fresh in your mind.

It takes work. But it’s less than leaving everything until the next pass, where you’ll just glide on past that part because you know you “already fixed it.”

Thing 2 Summary: Review your changes when you are making edits to make sure you aren’t making the problem worse.

Thing 3: Accidentally hit ‘R’

Mike is currently addicted to a game called PUBG. Before that, it was TagPro. Maybe he still plays TagPro, I’m not sure. All I know is that I haven’t heard shit about TagPro for a while. I don’t play the PUBG. I don’t really understand everything that is going on. But it seems important somehow. He has sent me links to a lot of gameplay videos.

Why I bring this up is because TagPro had a fun customization that some users would implement. It was called ‘honking’. Being a simple browser game, the game’s internals were exposed to tinkering. And some people would overwrite the keyboard handling routine to do something special when a player pressed both the up and down keys at the same time. That ‘something special’ was play a sound file of a honking car.

For it to work, both players would need the ‘honk’ customization to be applied to their web browser. The player customizations would listen for other players to indicate that they were pressing up and down at the same time, and honk. So, if many people had the customization, you would hear people honking themselves, with a response of other people honking.

It was silly and fun. I liked that idea a lot. So I did what I tend to do to all users of software I write: I torture them.

I customized Mike’s editor in Giterary to ‘honk’ whenever he accidentally hit the up and down keys at the same time. Well. Step back a bit. I actually customized it so that it would honk every time he hit the space bar. But then he asked to have it removed, so I reduced it to only honk when you pressed up and down at the same time.

From then on, whenever we were jamming, and he would navigate around our shared text editor, accidentally hit the right buttons, and I would hear a little car horn emanate from his computer. I would snigger a little bit. And then we would carry on.

Listen, honestly? All that above: I just like that story. I could do all sorts of backflips to try and relate it to our editing tool here, but at the end of the day, I think it’s funny.

We have a feature in Giterary called ‘random paragraph’. It… does what it says on the tin. If you hit ‘R’, it brings up a random paragraph from what you are reading. The paragraph is highlighted, and put into a separate modal window. The rest of the screen is faded, and all that remains is this randomly chosen paragraph. It is truly an oversight that I do not have Giterary also emit a small honk sound. I’ll get on that. See? I did bring it back.

Anyway. What pops up in the randomizer tends to be surprising.

This sounds odd, but consider this as another problem of words at scale. At some point, you will have written more than you can remember. And at some point during your editing passes, it all just starts to flow together. You know the parts that you like. You know the parts that you’re only so-so on. And you, being a fallible human, are inconsistent with the amount of attention you give to every paragraph.

The random paragraph feature removes the human element. It shows you a paragraph outside of its place, not preceding or following anything. And with your focus just on that paragraph, you can ask the question: “Does this stand on its own?”

It might. It might not. But we find that looking at a piece of writing apart from everything else tends to show things that were hidden before.

Thing 3 Summary: Take a random snippet of your writing. See if you like it. If not, mark it for fixing. If so, find another random snippet to fix.

Thing 4: Search and Destroy

We have a relatively new feature, called ‘searchgrid’. It’s something that the folks down at R&D cooked up.

I was noticing that Mike was doing “search passes.” Essentially, he would pick problem words or phrases that tend to indicate weak langauge or bad style. For instance, finding all of the times a character says, “The point is…” and replacing it with something better. Or finding all the instances of “suppose”, and just not using them.

Both Mike and I have our crutch words. We both have favorite words. They each have their time and their place, but it is not ‘all times’ and ‘all places’.

At some point during our editing passes, you will start finding these repetitions. Keep them in a list. Don’t forget them. Because as much as we like to think that we’ve become better writers over the years, we still have bad habits.

If I (Josh) am writing, and if something needs to be slowly diminished, I will have it erode. And if Mike wants many things attached to one thing, you may rest assured that is going to be festooned.

We acknowledge this. Mike is allowed one (1) festooned per novel. Whenever you see it, just know how much went into it surviving until the final draft.

Our current trouble words / phrases are as follows:

  • suppose
  • noticed
  • saw
  • heard
  • festoon
  • myriad
  • facade
  • could not help
  • the point is
  • the point being
  • turned
  • parade of
  • littered
  • realized
  • wonder
  • the boy
  • scurried

Thing 4 Summary: Learn your go-to words. Find them. And destroy them.

Thing 5: The Things You Can’t Just Search For

One of Mike and I’s favorite fantasy series is the Kingkiller Chronicles by Patrick Rothfuss. We’re not really shy about it. A lot of our inspiration comes from it. It’s part of the Triangle of Things That Bore Skysail:

  1. Name of the Wind
  2. Firefly
  3. Final Fantasy 6

Aside from the great storytelling, worldbuilding, and magic system, I (Josh) like KKC for how it expertly pulls off a complex framing narrative. For example, at any point, there are one of two stories being told: the protagonist Kvothe in a tavern telling his autobiography to the Chronicler, and the transcription of Kvothe’s autobiography telling of Kvothe’s storied past.

That makes it sort of an epistolary novel, and sort of not. It switches between the autobiography and the meta-story frequently, and sometimes one part of the story informs the other (meta-story characters occasionally pull us out of the autobiography to ask questions, clarify plot points, or just to switch things up a bit).

But what’s great about KKC is that you are never confused about who is talking. You are either: outside of the autobiography, in and around the tavern, or you are inside the story, spoken from the mouth of Kvothe. The novels are polished such that there is nothing but clarity when it comes to the speaker.

Writing for Skysail, I realize now that the kind of clarified narrative framing that is effortless and seamless in KKC is hard as shit.

Skysail’s narrative voice is somewhere between third person subjective and third person objective. The voice of the narrator is impassive and neutral, except where informed by the protagonist’s thoughts and insights. We hear and see other characters and their actions, but Vasili is the only person who we get to know what he’s thinking (styled by italics to differentiate it from the rest of the text).

We do this for a bunch of stylistic and plot reasons that probably warrant a blog entry themselves. But even without having a story within a story like KKC, this, too, is hard as shit.

Why? Let me show you. Take the following original snippet:

When he blinked awake in darkness, brief disorientation was followed by frustration. He had gone to bed with having eaten pickles for dinner and nothing more. Now, his lips had cracked and fissured in his sleep, while his head throbbed.

We changed it to the following:

When he blinked awake in darkness, brief disorientation was followed by frustration. He had gone to bed with having eaten pickles for dinner and nothing more. His lips had cracked and fissured in his sleep, while his head throbbed.

Not a big difference, right? I mean, the ‘now’ signifies a time progression between the previous sentence in the next while at the same time bridging the two sentences together. It anchors the reader a little, giving them a little less mental overhead on how to treat the time progression.

It sounds pretty reasonable. It might even sound better. But we removed the ‘now’. Why?

It comes down to who is saying ‘now’. The word ‘now’ implies an external reference point, an external perspective for which the ‘now’ can be evaluated. The ‘now’ belongs to somebody. It’s the ‘now’ for whoever is talking.

Which causes you to ask, “If someone just said ‘now’, then who exactly is talking?”

The easy answer is: ‘The authors. The authors are talking. Duh. Why is this section going on forever? See, this is the reason why blogs have died. If I had known the estimated read time for this thing, I would never have started. Fuck it. I’m going to scroll to the next bold heading.’

The hard answer is, well, a little bit harder.

For Skysail, our story is about the adventures of Vasili Mikhailovich. From the outside, it has the veneer of a plucky adventure with airships and cats and feeling the wind on your face. But upon further inspection it’s about disappointment, and how it feels growing up in an indifferent universe.

As with everything in writing, we can’t just outright say that. As much as we’d like to, it’d be pretty lazy. The real magic trick is to make you feel it without saying it. And there’s where our narrative voice comes in.

We arrived at third person subjective/objective because it is, by default, indifferent. The narrative voice is neutral, and does not weigh in on events unless a character does so. There is no authorial commentary from Mike or I, or from a disembodied voice. There is no speaker outside the characters who are speaking. There is just the story. The Telling.

Which is why we can’t use ‘now’ in our narrative voice. Or ‘this’. Or ‘that’. Or ‘this’. Because each implies that there is someone speaking that has a ‘now’ or a ‘then’, or has a ‘this’ or ‘that’. And if someone is asking who that someone is, then Mike and I aren’t doing a job of making you feel.

Back to my problem of words at scale. Imagine that you have to tell a story. And you have all of the dialog in your story, spoken between your characters. Now imagine the rest of it. Of that, you have to ask, “Who is talking?”

For Skysail, that answer always has to be, “Nobody.” And if it is, “Somebody,” even just a little bit, you have to find some way to rewrite it.

That’s a hell of an editing pass. And something you can’t solve using a search grid.

Thing 5 Summary: To unlock New Game+, try to write without using the words ‘now’, ‘then’, ‘this’, or ‘that’ in your narrative.

Sidenote: Mike recently told me that he is trying to get his wife to play Final Fantasy 6. While I’m interested in seeing what she thinks, I am fearful that the result will be that she will discover, as I have discovered, that 90% of everything Mike has ever said or done is inspired in some way by that game. The other 10% is Final Fantasy 9.

Thing 6: Call Me Writerly One More Time

You may be familiar with Godwin’s Law.

Basically, it says that the longer an argument goes on, the more likely it is that someone will bring up Hitler. Whether it’s Twitter threads, email chains, or familial Facebook comments, as time progresses, the probability increases that someone will bring up a comparison to Adolf Hitler, the Nazis, or the Holocaust.

Unless you are historians arguing over the sociopolitics of fascism in Europe during the 1940’s, the point at which Hitler is brought up is usually the point where the argument is over. Everyone can go home. Nobody won, and no further argument can be had.

In our arguments over Skysail, neither Mike or I have called each other Hitler, or compared our writing or editing methods to Nazism. Yet. I mean, yes, there has been some strong language with regards to our worldbuilding, and the use of the word ‘scurried’, but nobody has fallen victim Godwin’s Law.

But at risk of violating the law, I won’t say that being called ‘writerly’ is as bad as being called Hitler. But it sure is unpleasant.

What does ‘writerly’ mean? Between Mike and I, it could mean a few things:

  1. You’ve used words that are either over the top, too ornate, too flowery for the situation.
  2. Or, writing whose style calls attention to itself more than what it is styling.
  3. Or, you’ve used words that writers tend to use.

We’re well familiar with #1 and #2. That trying-too-hard, purple language is as punishing to the reader as it is to the writer. We know it to be the mark of early writers. Because we have looked back into our own __Notes.txt documents from yesteryear, and we have seen what it means to be early writers.

The use in #3, though, has been new experience. Used in the feedback from one of our beta readers, we learned that there are certain words, certain turns of phrase that are ‘known’ to be used by writers. Good writers, bad writers, it doesn’t matter. It’s the kind of writing that says, “Look here. I am indeed a writer.” And it’s the kind of writing that other writers can spot from a mile away, even when it’s good, and especially when it’s bad.

As someone who writes, I like to think I put a lot of work into my writing. I like to think everything I write is to the best of my ability. And I have a pretty good idea when my writing is not up to my standards. I delight in finding a word, a phrase, a sentence, a paragraph that is exactly what it needs to be.

But now something can be writerly. Now (goddamnit), we are no longer considering whether our writing is just something we would want to read, but whether something is too ornate, too stylistic, to the point that anything that is the least bit stylized feels like someone is pressing their lips together, giving a disapproving “Mm mm mm.” And now everything is in question.

Between Mike and I, writerly is our implementation of Godwin’s law. We’ve both used it when justifying edits or critiques. A “further erode” is replaced because it “feels writerly.” Questions about using the noun or adjective form of ‘myriad’ end with “[It’s] Writerly either way. :stuck_out_tongue_winking_eye:

We try to find a good balance. We feel that writing should be consumable, and as simple as it needs to be. We want to make art, but not to be too ‘art-y’. Neither of us considers our work to be literary fiction. But we do like to use good words sometimes. Useful words. Exact words. Precise words.

In addition to working on Volume 2, we are planning on issuing a new edition of Volume 1. It is mostly to fix typos that we’ve come across since publishing, but also to clean up things that we know were artifacts of our younger writing selves. And boy are those some hard edits, knowing that all of those writerly things have been out in the world for over a year.

Thing 6 Summary: Have someone point out to you where you’ve got some writerly bits in your manuscript. It doesn’t matter where. Then create a fearless moral inventory of your shortcomings, and start again at the beginning.

Thing 7: Don’t Edit As You Read

Our last thing, and I should get back to editing.

Your draft will not be perfect. It will probably have things that you aren’t 100% happy with. Things that you got to say what you want, and what the story needs, but you still feel like there may have been a better way. For our work, our sincere hope is that either a) people don’t notice the things we’re unhappy with, or b) people don’t care about them.

The trick is knowing when to stop. Because there is a point where you will need to stop. To move on. To get things out the door. Because, in the same way that you will always be introducing mistakes whether you are writing a first draft or editing a second draft, you may not be able to produce the perfect solution to every problem, and your next solution might just make it worse.

So, how do you know when to stop?

For me (Josh), it is where you can read through a chapter and not have to stop and fix something immediately. That is: I put Giterary into ‘Readable’ mode (where the editor and navigation options are disabled), and I just read. Print out your chapter if you have to. Go sit in a place that doesn’t have Internet. And just read.

If you can get through the chapter without getting up, saying, “This just won’t do,” then you’ve reached a good stopping point.

I think Microsoft Word and others have ‘reader’ modes, too. But I don’t often hear of people using them during the editing process. I see the application open to the editing screen, and fingers poised over home rows, ready to make the next change. And if you are short on time, sure. The Just write! mantra has the pal Just Edit!, and Just Read! sounds like a waste of time. Why not just make the fixes right there?

But for some edits, or the avoidance of an edit, you need to keep reading. To know why something was left there. To know why it was important to use that word first and the other word second. To see how pacing remained consistent between paragraphs, or dialogue was reordered to explain or to give some psychic distance.

It may take forever. But your work is more than the sum of its parts. And it’s important to consume it as such. Because otherwise you won’t see the same things that your readers see.

Thing 7 Summary: Don’t forget that your readers will just be reading. Be sure to read your work in the same way that they will be reading it (not in front of an editor).

Sometimes I feel bad when I do these craft articles. The time I spend writing these is the time I could be spending doing the craft.

But some days you don’t feel particularly inspired. And for all the effort you can put into something, you don’t feel like your heart is into it. It’s the middle of February in Alaska. It’s getting a little bit lighter, but it’s still very cold. And all that I want to do is eat and play Human Resource Machine.

So, if this happens to you, feel comfortable enough to switch gears, even if just for a few thousand words. When you come back, you will have learned something, and be able to see your problem anew.

Vol 2 Cover Art

It’s been a while! While we have been working deep in the word mines, Mike commissioned our Volume 2 cover art:

I (Josh) think it looks great. We have Gustaf Ekelund to thank for bringing to life one of our scenes from Skysail, Volume 2: The Gestalt Job.

As of this writing, Volume 2 is weighing in at roughly twice the length of Vol. 2. This means: twice as much to read through, twice as much to edit, and exponentially more times that Mike has requested that I split a chapter into two.

It feels like we’re close. Much like we said in 2017, we hope to deliver you Volume 2 in 2018. Or, you know… *soon*.

Until then… we’ll get back to those mines.


Writing Somebody Else’s Play

Earlier this summer I went to the Last Frontier Theater Conference in Valdez, Alaska.

It was pretty alright. And by pretty alright, I mean that it was probably nothing short of stunning for anyone new to the state. As an Alaskan kid, I’m sort of spoiled. I’m used to quaint towns nestled beneath breathtaking mountain vistas. I was born and raised under the towering majesty of nature in all directions. I sort of don’t see it anymore. Sort of like how you can’t smell your own deodorant after you’ve been wearing it for a while.

The conference has been going on in Alaska for decades. I was vaguely aware of it through some of my friends who do theater, but otherwise I had never been. This year, however, my girlfriend’s play was accepted to the conference to have a reading. She asked if I would be her armcandy while she attended. Being that I enjoy theater, and more generally, getting out and doing stuff in Alaska during the summer, I graciously accepted.

We had planned out how to get to Valdez (a short, 6+ hour drive). We had (mostly) planned on where we would stay (the conference-goers could take advantage of the vacant campus housing for dirt-cheap, dorm-style accomodations). But otherwise, I didn’t do any research on the nature of the conference before arriving.

I don’t know what I assumed would be going on. I’ve been to the Penny Arcade Expo, which is so massive and has so many things going on that there’s simply no way to see it all (or really even see a portion of what you really want). I’ve also been to work conferences where they are highly regimented and scheduled down to the nearest 15 minutes, and your itinerary is submitted and approved six months in advance.

I didn’t expect it would be a writer’s conference. I mean, had I bothered to read anything on their website I might have been a little more enlightened. They proudly list out all of the famous playwrights that have attended in past years. On top of that, their schedule had a number of writing-related workshops (in addition to those for acting, directing, and a new word I learned: ‘dramaturgy’). But maybe the most damning is that my girlfriend is a writer, and they asked her to the conference for a thing she wrote.

I guess I just assumed it would be all actors, doing, you know… ‘acting stuff’. Talking loud, emoting, and memorizing lines, like they do. And there was plenty of that. But as far as being a conference geared toward writers, I must have been too busy pretending to ignore our bold Alaskan splendor to pick up on the obvious hints.

(Aside: Go sometime, if you can. It’s stupid cheap, as far as conferences go. Like, I’m not even kidding. We spent half of the time making the joke that the conference had to be a drug front. You get a free bag, free coffee, free food… Oh, and each evening there was a featured artist / performance, which anybody could attend for free. Anybody. Even people who weren’t conference-goers. Drug front, I say.)

To be clear, I’m not writing this just to brag about living in the last frontier (well, the frontier you reach just before space). Or that I got to spend a week eating near-free lunches and drinking near-free coffee and carrying around my actually-free tote bag while correctly pronouncing the word ‘dramaturg’ so they would not suspect I was not one of them. Instead, I’m writing about something interesting that I observed among the writers at the conference.

The conference hosted play readings, which they called ‘Play Lab.’ For these readings, they would have a handful of professional actors from the Alaskan acting community and abroad read through the scripts. Actors would stand at podiums and ‘act’ through the scripts in front of them. While not a full production of the play (minimal costumes, no sets), it was a great way to preview a script, as well as give an opportunity for the actors to add their own art to the roles they were assigned to read.

The plays would be read. The audience would applaud. The actors would quietly close their scripts and find seats in the audience. But nobody would leave, like you would expect after seeing a play.

Instead, three professional playwrights, elected by the conference management, would stand up. They would make their way to the front and take a seat on the edge of the stage. They would introduce themselves, then turn to a lone individual in the crowd, and reveal that person to be the playwright.

I found this to be bizarre the first time I saw it. I mean, again, I should have known that this was how things would happen. After hearing 90 minutes of somebody’s hard-fought work it felt weird to have this person suddenly outed in front of a crowd. Like the triumvirate of judges was saying, “Look! This is them! This is the person you should hold responsible!”

But instead, people just clapped. And then the three playwrights would start to give insightful critiques. Then they would solicit feedback from the audience. It turns out that, to nobody’s surprise but my own, that a lot of thoughtful comments and suggestions would come from an audience full of people who are also playwrights.

I observed a few rules for these feedback sessions:

  • Playwrights would quietly take notes on the feedback they were getting. Notes would be recorded with a thankful nod, but the playwrights would be reminded that they were under no obligation to respond to the feedback.
  • Most feedback given to the playwrights was positive. When it was not positive, it was not given in an accusatory or punishing way (“That did not resonate with me as much as I wanted” or “I felt like I needed more” or “We want to hear more about this” or “Expand on that”).
  • Members of the audience were encouraged to give impressions and reactions, but to never provide suggestions on how to fix something. Or, more specifically, they were repeatedly told “not to write the other person’s play.”

When I first sat through one of these feedback sessions, it felt strange. Partly, because of the immediate responses that the authors were getting from their work. Partly, because the person was in the same room as those giving the feedback. And the rest was because, according to their rules, Mike and I’s own feedback process would be anaethema to them.

  • When we get together to jam, usually there is an issue or two that we need to hash out that can’t / shouldn’t be done over text or instant message.

    The usual way that we work through something is to read through the section in question, sometimes aloud, then see about explaining and defending it. Often, the problem shakes out in the reading itself (“Oh, wow, yeah, that doesn’t sound like what I wanted” or “I meant it like this, but I see where you would read it like that”).

    But it’s never the case that one of us just sits idly by, taking notes. I mean, sure, we take notes, but at the very least, we are expected to respond. We are each the other’s most immediate and critical combination of beta reader and editor. One of us can’t just say, “Oh. I’m sorry you feel that way, but that was just an artistic choice.” With equal responsibility with the project, we are beholden to the other’s criticism.

  • Mike and I’s feedback to each other isn’t all positive. I’m not even sure it’s anywhere near a 50-50 split. A good example is our commit comments (the notes that Giterary requires us to enter each time we make a change to a file).

    For instance, I had touched up a section, changing a reference to an overheard shouted insult. I thought that the reference to the insult should be, I don’t know, indirect, as I wasn’t sure that the main character would know that something was an insult if the main character didn’t speak the language being shouted.

    The next day, Mike reverted the change, responding in the commit comments with If you've ever walked into a South Texas junior high, you'll know which Spanish words are the insults.

    In response, I went back and corrected a new typo that appeared as a result of Mike’s reversion. My commit comment just said: o_0 (my usual emoticon to represent incredulity).

    Mike responded with a :|.

  • We always give each other suggestions on how to fix things. Always, always, always. From the way we conduct our discussions (“I imagined it was instead like this…” or “Would it be better if were like this?”), to the way we simply correct each other’s work as we see the changes happen, we have no hesitation in presenting or even implementing a solution along with the problem that we are pointing out.

    Part of the reason for this is the nature of our project. Being co-authors, and equally responsible for our combined output, both of us are writing, and both of our names are on the cover. It’s on both of us to make something, so it would be unfair for one person to just bring up the problems and the other person to solve them.

    Another reason is efficiency. Our process is already molasses-slow. With two authors, we have twice as many bottle-necks, twice as many periods of writer’s block, and twice as many life events to get in the way of writing. Add to that our added need to communicate and collaborate on almost every aspect of the story, and we’re 50cc karts running in the 150cc Grand Prix. If we only presented problems, and we said, “Oh, I have some ideas, but because this is your part, I’ll just let you figure it out on your own,” we would never finish anything. Mike and I make it a point to always offer solutions to the problems, even if they aren’t very good ones, because often even the bad suggestions can inspire good solutions.

So, given Mike and I’s methods of collaboration, seeing playwrights go through their feedback process was pretty weird.

I will acknowledge that this was a public forum for feedback, and not collaboration. The other playwrights weren’t there to collaborate on the plays that were being read, only to react to them. Which is an important distinction. The playwright community seems to be very particular about intellectual property rights. Based on what I understood from my (very) brief look into the playwrighting industry, individual and complete ownership over rights to a work is the best assurance that you will be paid for your work, and more importantly, be able to live off of your work.

I can certainly see why the Last Frontier Theater Conference had their rules in place. I can see why they don’t encourage playwrights to immediately respond to feedback, for the same reason you don’t feed the trolls on the Internet. Plus, thoughtfully nodding along makes you at least look like a professional, even if you want to scream at the person. I can also see why they try to cultivate a positive atmosphere with the feedback, giving largely positive criticism, or if not, at least pointing to where something was off.

I’m a little torn on the “don’t write the other person’s play” portion.

Sure, I probably wouldn’t take kindly to some rando who shows up and starts giving me suggestions on how we should write our novel. It hasn’t happened often, but when it has, it’s been a sort of awkward endeavor. The conversation usually starts with, “Have you thought about X?” And I respond with, “Yes, we’ve got X. Lots of X. In fact, we have an entire chapter dedicated to X. Actually, funny story, we had to rewrite a huge part of Volume Y just because we wanted to have more of X…” By that time, the person has reconsidered, and has moved on to ask, “Then have you considered Z?”

Honestly, I’m just happy that they’re interested. I mean… Their questions tend to imply that they didn’t read the book. But I’ll take what I can get.

Where it gets less fun and more biting is if the other person is an author (or a playright) as well. Given that new context, where you’re both writers, and both creative, both imaginative, and, in theory, both professionals, the question could take on a new tone. If another author suggests that something be done with your novel, your play, or really anything you do, it could imply that they think that you haven’t already thought about it first. That you must have overlooked something. Or that your idea is less great, and theirs is… well, worth it enough to make mention, otherwise you might never come up with it on your own, you poor thing. (In emoji: o_0)

Then again, that person might just be sharing in their experience at hearing your idea. “When you said this, it made me think of this!” or “Oh, this reminds me so much of that! I love that!” As an author, I spend a signficant amount of time when I’m writing trying to put my head into somebody else’s, and try to read like I’m in somebody else’s head. I have to imagine other authors spend just as much time in somebody else’s head. If I can provide a shortcut, or just a little bit of insight into what went on in my head when I read something, I’d rather the author know about it. Best case: it was the intended effect, and shouldn’t be touched at all. Worst case: it wasn’t the intended effect, and maybe could be touched up a bit. (Translation: :|)

I think what I’m trying to draw arrows to are the differences between critique and collaboration. Or more specifically, collaborative critique (getting feedback from an audience after a show), and critical collaboration (working with a co-author to figure out what is wrong with a scene).

In both, an artist solicits feedback from an audience. In both, artists ask an audience to experience their art, and to walk around for a while in their universe of novel construction. And in both, the audience agrees to walk around in a weird world for a while, and report back on the findings of their expedition.

But the critiques I saw after at the readings at the conference had an attitude I didn’t like. The attitude that said, or at least implied, that “I might know a way to fix this. But I’m not going to tell you.” The same infuriating attitude your teachers had when they made you show your work on a test.

It wasn’t that those giving the feedback were being disrespectful. In fact, they were withholding their ideas out of respect for the author. And if they did not, the up-front triumvirate would remind those in the audience to be respectful in this way, and to kindly avoid writing the person’s play for them. Everyone seemed to respect the process and the author’s ability to address the issues. Moreover, the author was discouraged from responding, so as to not make them feel like they had to immediately defend their artistic choices.

But there is still something being withheld. A room full of writers and creative people can’t help but see or hear a story be told and wonder at its construction. There isn’t a book I read, or a show or movie I watch where I’m not curious as to why something was written that way, or if I could write it better. Again, I have to imagine it the same for other writers.

What I think bothers me about this method is withholding the opportunity to learn from how another person does their craft. To learn how they think, or how they approach a problem.

In computer programming, we get to (have to) do this all the time when we read other people’s code. We learn how it ticks, and by proxy, we learn how the other person thinks. Sometimes, yes, it’s a dark path descending into the mines of madness. But other times, you get to learn something new. Something interesting. Something that you may never have uncovered by yourself.

(Note: there is an entire philosophy within the software industry based on the idea that software should be free, and open, and developed collaboratively. It’s called ‘open source’ software. I am a huge proponent, and am probably heavily biased towards this type of collaboration :))

I should probably qualify: not all ideas are winners. Point of fact: very, very few of my own ideas are winners. But a room full of professional writers? I don’t know. I have to imagine that it doesn’t hurt your chances. And, too, sometimes even hearing an obviously bad idea from another person is better than having to convince yourself that your own idea is bad. It helps with the self-esteem, anyway.

I don’t know how unique of a working relationship Mike and I have. But seeing how playwrights do it made me glad that we’ve arrived at this strange equilibrium. Otherwise, we would just be critiquing each other’s work without taking ownership in helping the other get better at writing. Which is a pretty lonely, ineffective arrangement.

My problem comes, now, in dealing with writers other than Mike. He and I can riff on something, brainstorm an idea, and put together a scene like improvisers might do on stage (albeit much, much more slowly). The idea of who came up with what is secondary to what we arrive at in the end. But that does not appear to be everyone’s mindset. Not everyone is a collaborator. Some people write alone, and all they want from your feedback is to know if something worked, or not.

I can see how just offering my honest critique is valuable, and sometimes preferable. I don’t always like it when people try to suggest something or write something into Skysail (unasked). It really is awkward to field the “Your story should have a Z, why doesn’t it have a Z?” conversations, particularly when they come from people who should know better. And when I provide feedback, I really try not to be that guy (unless asked).

But given that constant running thread in the back of my mind, thinking about things, through things, and coming up with new things, I can’t help but feel like I’m withholding something if I don’t share. I’m much, much less concerned with who owns the idea, and more interested in seeing cool stuff get made.

I want the person I’m giving feedback to know that I visited their world. That I walked around for a while, and saw the cool stuff they had put there. I want to tell them how it made me feel, and if I liked the things that I saw. If it was a good world to visit, I want them to know that. If it was a great world, I want them to know that I would return. That I would want to see more, and even make my own part of their world.

Anyway. Visit Valdez, everybody.

Tooting the Horn of Another

So it turns out that Mike (when not encumbered by the overbearing, obnoxious, and often unfounded criticism that comes with being a co-author with Josh) can crank out some decent words.

Taking a part in the /r/fantasywriters monthly writing competition back in June, he took home “the gold” after submitting a story about Archamae de’Cailleach, the pilot character we introduce in Volume 2. He, of course, failed to disclose that he won until weeks later. That, or Josh just ignored the announcement, playing a longer game than anyone realized.

Anyway. We’ve got Mike’s story here. You should, you know, go check it out. See for yourself.


All software must fail. All machines must fail. All people must fail. Eventually.

What a hook, right? Wowza. Anyway. This one sort of goes on. Josh goes nuts and gibbers on about software engineering principles for a time. He, uh… sort of ties it all together? Maybe relates it to novelwriting? Hopefully? If you’re short on time, or doubtful, scroll through until you see Hans Landa again.



The trick of engineering machines (software or hardware), is to accept a rate of failure and accommodate. Then you have to answer important questions: How often can a thing fail? What are the consequences of failure? What is the cost of a failure? Then you have to look at your given resources and decide how best to accommodate failure.

If failure is acceptably rare (say, one time in a million iterations), then it is acceptable failure

If the consequences of failure are minimal (can you just turn it off and on again?), then it is acceptable failure.

If the cost of failure is minimal (a D-Flange failed, but luckily, new ones cost $1.85), then it is acceptable failure.

Longevity, reliability, and safety are just ways to relatively measure the failure rate of a device. How many recoverable errors before your computer’s storage can’t recover those bits? How many cold starts can your car battery take before it gives up the ghost? How many times in a thousand doses does the radiation therapy machine kill its cancer patients?

All machines must fail. But certain failures are unacceptable. Loss of life, or personal harm, cannot be accepted. But if the function of a machine is inherently dangerous (say, providing radiation therapy to cancer patients), the possibility of harm must be addressed, and its chances must be reduced to as close to zero as possible.

Software is no different. A machine’s programming is just as an important part of a machine as its mechanical pieces. If software fails, the machine fails. The makers of the device have to accommodate, and address any inherent dangers.

Designing software for failure is tricky, though. Software is intricate, and requires the correct functioning of thousands upon millions of moving pieces in order to perform basic functions. Given an ever-changing ecosystem of moving parts and an environment completely outside of any control, even the simplest application is at risk for failure. And because programs can be run so often, and so quickly, probability starts to do weird things. The chances of one failure in a million become a certainty when executing a million times in a row. Failure becomes unacceptable when it is a certainty.

That said, wrenching on code with the knowledge of certain failure makes one paranoid. And defensive. And leaves one with a combined sense of dread and wonder at how anything works at all. But you learn to accommodate. You learn what pieces are most likely to fail. You test and validate your inputs. You close your file handles as soon as you’re done with them. You flush your buffers even though you don’t need to. You write your code to fail first, and fail fast, and to die in a spectacular, dramatic fashion so that somebody notices. You expect your code to die. You make an art out of dying. Ideally, your code should be better at failing than it is at succeeding.


But nobody is putting money into software that just fails. Software, like any machine, has to perform a required function. Whether it’s booting up your computer, or simulating the metro system in Cairo, or beaming X-rays through a tumor, it has to do something. It has to perform, eventually. You can put a lot of effort and resources into making a program die well. But those resources are in competition for what was originally intended for the program to do. Restrict those resources and some degree of compromise must occur. Higher failure rates have to be accepted. How well software is constructed depends on how well its problem is understood, and how the risk of failure was addressed, and mitigated, given finite and often limited resources.

Software engineers have known this for some time. Making good software is hard, and even more difficult in dangerous situations, but it has to be done. We were building software for space flight back in the 1960’s, the risks for failure being the death of astronauts and the failure of the space program. Young computer programmers learn about failure quickly, with their first fumbling attempts fraught with error codes and stack traces. They learn that the world is an evil, uncaring place, full of malicious, devious input values. And they learn that even the most well-meaning user, trained in every aspect of the software, will eventually do something dumb and destructive. They learn about Margaret Hamilton’s work on Apollo 11 on the same day they learn about the infamous Therac-25.

[record scratch, freeze frame, Baba O’Riley starts playing] Hi. You might be wondering how you got here. Don’t worry. I, too, thought that this was a blog about writing, not some regurgitated Wikipedia article about software engineering. Fret not, my friend. It’ll all make sense soon.

Let’s say, somehow, you’ve magically, no, miraculously put together software that performs well, and fails in a sane, organized fashion. It does what it’s supposed to, and when the unforeseeable occurs, it plays out a classic death scene both appropriate to the character and in direct service to the plot.

Let’s say it’s the program that controls the LEDs for a new brand of bicycle lights for Bespoke Bicycles (intended to be a fake company, sorry if this is a real one). That’s right: a program controls your bike lights now. And your program does what it needs to: turn on, wait one second, turn off, wait one second, then repeat. Cheap and easy, everyone loves it. The only way that the software can fail is if the batteries run out. If that’s the case, then they just put in new batteries.

Then the customers say, “It needs a toggle button.”

You ask, “Why?”

They say, “It’s because we don’t want to have to take out the batteries every time we get off the bike.”

You say to yourself, “Okay, that makes sense. I just thought that the light needed to blink. I wasn’t thinking from that perspective.”

The hardware guys design a button. You don’t have to make any changes to your software as the toggle just cuts the power. On, off. Easy. Your blinking software is perfect.

Then the customers say, “We want different kinds of blinking.”

Confused, you ask, “Different kinds?”

“Yeah. Not just on or off. Like… different.”

“But… a light can only be on or off. That is the nature of light. And… electricity— Do you mean you want it to be dimmable?”

“No, like… on— off— quick flash— slow flash— another quick flash then a slow flash—” They go on, detailing in a strangely rhythmic fashion the nature of the light switching. “I mean… Almost like it’s random. But not.”

“But… why? That would be annoying as hell, wouldn’t it?”

“That’s the point. It’s a bike light. It’s so other people can see you. And being annoying is the same thing as being seen. Bicycle rights.”

“Oh. That makes some sense. I mean— We’ll have to add in… Then we’ll have to.. Hmm. I’ll get back to you.”

You go back to your software. The facility for waiting in between blinks lets you wait for a variable amount of time. But based on the new requirements, the timing mechanism doesn’t let you wait for less than a second. You need sub-second timing. Plus, your beautiful blinking loop now has to be dirtied with a bunch of random timings. But that’s okay. The hardware guys give you a sub-second timer, and tell you how to use it, and now you’ve got a really annoying bike light.

“Oh, no… sorry,” the customers say. “We wanted the normal blinking, too.”

“But it’s… It’s not nearly as annoying. I made the new one considerably more annoying.”

“But that’s just for… Well… Sometimes we want to be annoying. Other times… we just want normal blinks. Can’t we have both?”

Goddamnit. You go back to the drawing board. The hardware guys laugh at you. Then tell you that it’ll be too costly to redesign the bike light chassis for an extra button. You’ll have to make do with just one button.

“How the hell will I do that without some sort of switch? Do you expect them to yell voice commands at the light?”

They humorlessly tell you that it’ll be too costly to redesign the bike light to include a microphone.

“What, then?”

They inform you that the power button can serve a dual purpose. If they do some clever wiring, and put power control in the hands of the software, then you can just click the button for a short period of time to toggle between blink modes, and hold the button for a long time to cycle the power.

You sigh. You know they’re right. But your software is getting more complicated. You have a timer at your disposal but now you have to use it to check for both button presses, the length of the button presses, and to do the different styles of blinking. But you’re the pain wizard, and a damned good one. You figure it out. Under budget and on time.

Time passes. The customer requests three more blinking modes to suit whatever mood. They request a charge indicator light, activated only when you tap ‘Shave and a Haircut’ on the button. Blue for charged, red for needing a charge. Then they want rechargeable batteries. Charging over USB cables. Different color lights depending on rider profile. GPS to detect when you’re riding in a federally-mandated low annoyance level bike light zone. Twitter and Facebook integration. Everything but the kitchen sink. Your code is a bit of a mess, but the customers are happy.

Their last request throws you. “We want it to be waterproof.”

It makes a lot of sense. The light probably does strange things if water gets inside, if it works at all.

You talk to the hardware guys. “So, just some rubber gaskets and we’re good, right?”

They shake their heads solemnly. They say it will require a new chassis. And if they’re going for a new chassis, they might as well switch to the new industry-standard BikeLightWare platform rather than keep with the expensive proprietary design you’ve had so far.

“Oh. That’s fine. Will BikeLightWare run my blinker software?”

Oh, how they laugh and laugh.

The new platform is entirely foreign. You sift through the manual. You can’t even see where they’ve got a sub-second timer. Or a timer at all. The hardware guys refuse to add one, saying that they only support what comes out of the box from BikeLightWare.

Ok. Fine. “I’ll make my own,” you say. But even you hear how uncertain your voice sounds. Everything you had, every intricate piece stacked atop the next, now has to be rebuilt. Do you know all the pieces? Do you even know how many pieces there are? How will you know things work the same? You sigh. You’re looking at months, maybe years of thankless work just to get things back to ‘on and then off again’-style blinking. You curse yourself and those damned hardware guys for not thinking about waterproofing. Of course it rains when you’re biking! Of course there are puddles! How could we have been so short-sighted? And how in hell did BikeLightWare become the industry standard? They don’t even have a sub-second timer! And even if you get all of this working, you can’t just hand all of this over to the paying customer and expect them to tolerate anything less than what they’ve had before. They don’t understand the change. They just wanted the dumb light to be waterproof.

In this harrowing example, everything would have been different if our hero had done things a little differently.

Start off with a waterproof bike light chassis? Sure. But maybe one didn’t exist when Bespoke Bicycles was in its infancy. Or it was too expensive. Or maybe they were just making bike lights for people living in the desert.

What about writing software against standardized bike light hardware to begin with? Same answer: maybe one didn’t exist. But more likely, the standards were designed by committee, and just suck.

The simplest solution would be to say ‘no’ to waterproofing. You can always say ‘no’. Besides. Customers don’t know what they really want. Customers are the worst. You got into the bike light business for the art. Make something for yourself, not for your customers. Yeah, but… Successful software needs users. Customers are users. And customers need to be happy, otherwise they stop being users.


No. The one thing that our bike light codemonkey hero didn’t do is test. Granted, he made sure it worked before pushing it out the door. And he fixed whatever issue the customers presented. But he did not test, in terms of software engineering.

Software testing is as much a part of software engineering as the actual writing of code, despite the fact that it is often neglected. Software testing is the process of formally defining the specific behavior of your software, and validating that behavior for function, quality, and the absence of unintended consequences. Software testing validates not only how software performs, but also how it is intended to fail.

For instance: your Bespoke Bicycles brand bike lights need to change color if you hit the button three times in one second. To test this, you will need to ensure that the bike lights change color when you successfully depress and release the button three times in less than 1000 milliseconds. If you press it one or two times, it ignores the input. If you press it more times, it ignores the additional button presses, but still changes the color of the lights.

A bike light, as simple as we can imagine it, can be complicated. And if something changes, or if features are added, the likelihood of failure increases. If an underlying component changes (say, the timer, or a migration to the shitty BikeLightWare platform), then someone, or something, needs to validate our color changing rules. If any of those behaviors are violated, then the product won’t be able to change colors, and is considered defective (a failure). Defects cost money. User dissatisfaction costs money. Bad reputation costs money. Failure costs money. As stated earlier, risk of failure needs to be addressed and mitigated by the software engineers, or they aren’t doing their job.

Formally describing the behavior of your software isn’t hard. Well, it is. But it’s no harder than anything else you, as the lone programmer at Bespoke Bicycles, has to put up with. It’s as difficult as being able to put down a list of instructions in how to test a feature. Or, to put it another way: it’s as easy as telling a story. For each behavior, you should be able to tell a story about how a user interacts, and what the intended result is. If you can’t, then you have to wonder how you’re supposed to write code for the behavior in the first place.

Programmers figured out that testing is invaluable to their development process. Having a battery of tests fully documenting existing behaviors means that, at any time, all behaviors can be validated. It would be tedious, but someone could sit down with the bike light testing steps and validate every single feature. Or, you can do as the rest of programmers do: automate, and have the computer do the testing for you.

Huge amounts of study in software engineering focuses on automated software testing. So much so that entire development strategies are based around it. Some methods even say that you shouldn’t write any code before there is a test written for that behavior. But in my experience, practicality and deadlines will always dictate how much and how often something is tested. It’s fantastic to be able to tell someone that, “Oh, yes, I rewrote the entire stack for the BikeLightWare platform. And all of the tests are passing. Thundercats are go.” It doesn’t always happen.

But remember, friends: all machines fail eventually. If you test your software, all that means is that your software will fail less in the ways that you tested for.

For instance, let’s get back to that three-click color change. Most customers wouldn’t have a problem clicking a button three times in one second. But some small percentage of your customers have written you strongly worded (if ungrammatical) letters saying that their bike lights won’t change color. You get a hold of one of these ‘defective’ devices. You try out the three-click change. It works just fine. What the hell?

You investigate. You ask around. Eventually, someone at the office asks if they can try it. They do it, but they do something… different. They fidget with it a little. Or they don’t depress the button right away. Or, as you figure out, they press the button three times, but then they hold the last. Who does that? That’s not in the instructions. That’s just… that’s weird, right?

You find the place in your code. You figure out that the BikeLightWare platform differentiates between “button down” and “button up” triggers. If someone keeps holding, and your software hasn’t counted three “button up” triggers, the color change doesn’t occur.

You’ve identified an uncommon but entirely possible series of inputs. It causes user frustration, and costs money as they send it back in the mail as defective. Learning from your past mistakes, you wrote a whole bunch of tests upon migrating to your BikeLightWare platform, but with everything else you were focused on, you didn’t think to test a long third button press. You told your boss that all tests were passing. Thundercats were go. But now no longer.

Unfortunately, software testing is not silver bullet for eliminating software defects. Repeat it with me: all machines must fail. But automated testing is a great tool for developing better software. For each new defect, you can write a new test. For each new fix, you can verify that the test fails at first, and then succeeds after the fix. You can make sweeping, destructive changes, and observe what succeeds and what fails. You can do this continually, automating your tests to be run every time you hit the ‘save’ button on your code. You can demonstrate to bosses that everything you knew that could break was working the last time you checked.

[record scratch, freeze frame] Wouldn’t that be fucking great if it were the same for writing a book?


As I’ve boldly claimed before, each word of a novel is part of a machine with a few hundred thousand moving parts. A novel is basically software for feelings, right? And as software, and more generally, a machine, a novel must fail. And its authors must mitigate that risk. So, shouldn’t you be able to apply tests to a novel in the same way you can apply tests to software? Shouldn’t these tests make for a better novel?

A novel is a machine. But it isn’t a machine in the same way that a program or a power drill would be. It’s a subjective machine. A non-deterministic machine. For the input of each given reader, a different output is more or less guaranteed. How are you supposed to write testing rules for that? If the machine is inherently non-deterministic, how can you be expected to validate outputs?

It’s difficult, but it’s not impossible. When setting out to write, you set down your core theses, right? Good. These are your first tests. “Does your novel support your theses?” would be a great test. Unlike a scientific paper that is valuable whether the hypothesis is proven or disproven, a novel really should support your thesis. For example, what if your thesis was: “Expectations are never the reality.” But everything in your novel happens more or less as expected… FAIL. But if your theses are well supported, and aren’t just shoehorned in at the end with a final monologue from a secondary character that didn’t have anything to do with the story? SUCCESS.

Okay then. Characters? Does your book have characters? SUCCESS. Does your book have characters that are People of Color that respectfully represent their ethnic and cultural background without being insulting or culturally appropriative? OH GOSH.

Let’s stick to what we can test. Story, right? Does your book have a story? SUCCESS. Does your book have a story that is personally meaningful, universally relatable, relevant to the cultural zeitgeist, but is not derivative of other works or victim to formulaic plot and genre tropes? OH DEAR.

Mixed test results so far. Dialog. There we go. Good dialog can float everything else, right? Does your book have dialog that is not just talking heads, or people talking past each other, or have characters explaining information that other characters already know? HOPEFULLY. Do all of your characters have dialog that is strong enough to withstand a really, really bad audiobook recording, where the voice actor reads everything in an accent reminiscent of a bad Swedish soap opera? OH NO.

You scour the Top 10 Writing Tips. You Youtube the Top 10 Rookie Writing mistakes. You descend the depths of TVTropes. You gather your tests. The things that you must do. The things that you must absolutely not do. You keep them posted next to your bathroom mirror. You recite them before you go to bed.

You work your way down the list as you make your edits. Fixing some things break others. You fan your draft out to beta readers. They find a bunch of things wrong that never occurred to you until they brought it up. Their opinions on blinking lights differs from yours considerably. A ton of new items make it to the list. But after time and toil, finally, you’re down to your last checkbox. The last test says: “Did you write the novel you want to read?” You wrote this a long time ago. It should really say: “Have you worked on this for so long that you now hate this strange thing you have created?”


And so you publish. Thundercats are go.

And then you are told that your book is not waterproof. It should have been waterproof from the beginning. Why wasn’t that on your list?

Readers that paid money inform you that you failed more tests. That your novel has plot holes, and leaks, and seams. That characters are made less interesting for the choices you made for them. That the story is hard to follow. That the dialog is discomforting. That you failed the Bechdel test. You don’t feature enough women, or people of color.

You pull your list of literary tests out of the trash can. You look them over again. You had hundreds of tests. A battery of tests. And you passed all of them.

But you knew about the other tests. Or you knew they must be out there. And if you didn’t, some were common sense if you put your mind to it. But you didn’t. You put your mind to everything else. You put your mind to the discrete, finite list you had said would formally describe the behavior of your novel. And if all of your tests passed, then you would have a better novel.

But all machines must fail. You, as the designer of that machine, have to manage a set of limited resources in order to address and mitigate the risk of failure. You can reduce risk by testing and eliminating failures. But something will always come up.

Here is where you may start reading if you elected to read the abridged version of this godforsaken tome.


Mike and I published our first eBook back in October and the paperback in November. So far, we have had pretty good responses. We had plenty of beta readers, plenty of editing. But there are still there are problems. Problems that, unlike with software, we can’t go back and fix. Software is mutable, and ever changing. Software can fail, and look great doing it. Books… less so. Books are abundant, and low in value. An imperfect book can be dropped and replaced with a new and better one near instantly.

We recognize the problems. For most, we even know how we created them. A lot of our issues stem from our first big problem when we arrived at our first draft and began querying publishers: Is the book too long? FAIL. Weighing in at 300k words, nobody would have accepted something of that size from first-time authors. It was too big, and too costly to edit and polish. High risk of failure, with unacceptable consequences. So we made a hard choice. We decided to serialize. To split up our work into shorter, well-polished volumes. We decided later that we would go the self-publishing route, which confirmed our decision to split/serialize, as otherwise volumes 1 through 3 would have been too big to finish by the end of the year.

But large, sweeping changes cause problems. Like waterproofing our fictional bike light, our chassis got swapped out, and Volume 1 become its own unique machine, with its own unique problems. We had pushed out content to beta readers, but only ever included all three volumes. After the split, we never had fresh eyes on Volume 1 and other than our editor. And that is what we published. Which is like waterproofing your bike light, but then only testing it out with people who live in a desert.

Later, we were politely informed that we did not pass the Bechdel test. We were asked, “Do you know what the Bechdel test is?” We said yes. We knew about it. Did we pass the Bechdel test when the book included Volumes 1, 2, and 3? SURE. Did we pass the Bechdel test after the split? NOPE. In software testing, this is called a ‘regression’, where changes to parts of the software cause other parts to fail. Fitting, then, that a regression defect causes our first novel to be socially regressive. Shwoops.


Okay. But that’s a problem of sample size, isn’t it? Mike and I can’t beat ourselves up over that. In the effort to make a more focused, polished product, we had to make some choices. It wasn’t a conscious choice to not have two women talk to each other about something other than a man. It wasn’t a conscious choice to not have two women talking to each other at all. But we did consciously decide on some issues. And those issues got addresses. Besides, pick a small enough part of a whole, and it’ll fail whatever test you want. Call it ‘testing gerrymandering’, if you like.

The further you walk down the list of failures, the less defensible things get. There are bigger criticisms you can’t discard or excuse because of sampling size. It’s a valid criticism that there aren’t enough women on board our fantasy airship. It’s a valid criticism that there aren’t explicitly stated people of color. And it doesn’t matter that we know about it, and thought about it, and cared about our choices. It doesn’t matter that there might be reasons in the story for it. Those reasons aren’t in the book. They aren’t in the appendix. So we failed the test. But I suppose no novel can be perfect. All machines must fail. And we keep building them anyway.

Writing software with the knowledge of certain fallibility makes one paranoid, defensive, and a little fatalistic. Writing fiction fills me with the same feeling. Every word you write might be spelled wrong, or be unintentionally alliterative, or even worse: rhyme. Every sentence you write has a good chance of missing a word, or repeating one. Every line of dialogue might be read strangely, or seem inconsistent with a character. Every paragraph may be logically inconsistent and in conflict with the other.

We have processes in place that look like testing. We have lists of feedback from readers, with TODOs next to them as placeholders, reminders for us to fix them. We have a file called TheJerkList, which is a place where we can be honest (and jerks) to each other about our writing. We do read-throughs and multiple passes, each focusing on story, pacing, story, tone. Each pass involves reading the book, end to end. Our test validations are not automated. But the tests are documented somewhere. It’s just the error-prone humans that can’t be relied upon to evaluate the tests properly. I’m thankful I have Mike to read my edits day to day. We catch each other’s bullshit all the time. We have to. Otherwise, who knows what kind of stuff I would have missed.


A few weeks ago, I was at some friends’ house, getting ready to play board games. A couple was there who I had met before, but hadn’t seen in some time. They were trying to set up a game of Dominion. I was trying to discreetly give one of my friends a physical copy of the Volume 1, of which she had been one of our earliest beta readers. She happily accepted the book, and showed it off to everyone.

“Did you guys know that Josh wrote a book?” she said, indiscreetly.

“Oh, cool!” the acquaintences said.

“Co-authored, but yes,” I qualified. I am not a creature that belongs in the spotlight.

“That’s awesome. How long did it take you?” they asked.

“Oh, four or so years. Most authors can crank out a book a year, but I guess we’re slow.”

“That’s fine. Wow. And how long did it take to get published?”

“Oh, well, we self-published.”

“So, on Amazon or something?”

“Right. It’s not that big of a deal. I mean, the self-publishing industry is sort of the Wild West right now. Pretty much anybody can crank out a novel these days.”

“Well,” the acquaintence said. “You shouldn’t do that.”

“What?” I asked.

“Don’t diminish your accomplishment like that. You’re selling yourself short. Don’t do that. You should be proud. Most people never write anything.”

I was sort of taken aback. Partly because I’d only met this person twice. Second because I didn’t realize what I was doing. I don’t take compliments well. I thanked them. I continued shuffling Dominion cards.

If our books ever see much success, I’m sure we’ll find more things wrong with our books. We’ll keep writing. Jeez, we sort of have to, now. But the upshot is that we’ll become better writers. And while we can’t test our books in the same beautiful, automated way that software is tested, we can take the same SUCCESS / FAIL list from the first volume and apply it to the next. And hopefully we’ll improve our ratios.