Process Imagineering, Part 2: Plans, Plumbing, and Porcelain

Okay. Great. So we hold status meetings for our writing stuff. Same as everyone else who works in an office. Gee, thanks Josh. Truly, this is revolutionary stuff.


We will certainly take the co-authoring world by storm.

My point in talking through our jam sessions (status meetings) was mostly to introduce the idea of continuously clearing snags for the other person. But there are other reasons. Chief among them: to plan work. That is, come up with the stuff you plan to work on. That way, when each of you go off and attend to your own devices, you’ll both have a clear idea of what you’re supposed to be working on.


We probably had, oh, I don’t know… a year? We started outlining mid-2012, but didn’t start principal writing until late 2013. I’ll say there was at least a year of jam sessions where all we talked about was the book’s thesis, the characters, elements of the worldbuilding, and what the hell we would call certain things. Again, if you’re a solo author, all of the decisions are up to you. If you are not, you have to be clear with your intent otherwise you end up going in the wrong direction, or worse, you end up duplicating some amount of work.

Some authors are what they call ‘pantsers’, by which they mean that they ‘fly by the seat of their pants’ when writing a book. I find this wholly alien and bizarre, but that’s just who I am. And while a perfectly reasonable way to crank out a book, it would be completely untenable when two authors are in the mix. If you have two pantsers, you will write two completely different books.

That should be the end goal of the repeated jam sessions: to ensure that you are not writing two different books.

Those first years of jam sessions were spent working our way through the following:

  1. Thesis. Establishing the core questions and concepts that the story should ask/convey. Sort of like a mission statement, but less lame. Find a thesis, or set of theses, that you both agree on, or else you will be writing different books. Do not proceed unless you have a set of theses you both agree on. You will revisit these repeatedly.
  2. Character. Establish the characters that will support your thesis. Get as detailed as you need so that both people feel comfortable writing in their voice. This might involve writing some prototypical scenes to see if a character trait works. Iterate until you have a cast of characters you both feel give you the tools you need. Do not proceed until you have those characters.
  3. Outline. Establish the story outline. Start broad, then get detailed. We had a numbered list of things that we wanted to happen in a book. Things that had to happen. We broke that list down by chapter, and had a list of things that would happen in each chapter. The outline forced us to choose when and where they happened. Both authors should know what each chapter should be about and what thematic and emotional tones should be present. Stuff can always change, but having an outline you can both look at and agree upon is very important. Do not proceed until you have a chapter outline.

There are lots of resources out there on how to approach thesis, character, or outline. And better than I can relate here. More what I am after is getting them down, and agreed upon, so there is no confusion about the core elements to your story.

Once you have both agreed, you’ll have to start in on planning the actual chapter contents (environments, dialog, scenes). It’s not enough to just agree on a thesis and go. You will have to collaborate on the chapter content as well. I found that the best way to convey planned/intended chapter content was to hash out either:

  1. Storyboard. Establish storyboards. It’s relatively easy to write an outline. It’s harder to actually block out locations, dialogue, character movement, and scene progression, keeping all of the variables in your head and making them logically consistent.

    Write out moment by moment storyboards as if you were going to film the thing. That way, both of you can have the same image in your head of what is supposed to happen.

    You can choose to storyboard first, or you can choose to write your dialog first.

  2. Dialog. For me (Josh), cranking out dialog is the best way to lock down what you want from a scene. I try to write dialog with the intent that if you took everything away (narrative, exposition, thought bubbles, etc.) that the dialog would tell the same story. It’s hard to write good dialog. But it’s easy to see bad dialog. Finding things for the characters to discuss, making their conversations believable, and their intentions relatable is core to making someone care about what you write. Everything else is window dressing.

There’s nothing that says you can’t storyboard and write dialog at the same time. The visual elements and character environments tend to inform the dialog, and the dialog informs how characters emote and interact with their environment. Forcing your dialog into a visual storyboard also helps so that you don’t just have talking heads reading their lines back and forth. Characters should never (read: rarely) just be talking.

So, at this point, you are probably regretting getting this far in reading this. I’m telling you what you already know. Like your disappointment in the first paragraph, my pushing of the food around on the writing process dinner plate hasn’t been all that informative. Why have an entire article about planning when you could easily summarize it as “Have a plan, and if not, make one?”

Well. For me, it’s the difference between plumbing and porcelain.


Please. Don’t go. Let me explain. I’ve got something for this.

Mike and I use a number of tools, but at the very core we use Git. Git is a piece of software that is a version control system (VCS). Its lot in life is to track a directory of files, keep past versions, and let us see differences between old and new.

This sounds pretty simple. But among the popular VCS products, Git is pretty complicated and obtuse. It is famous for having hundreds of obscure commands that, while very helpful and powerful in some situations, usually require some degree of Googling to find what you want. Eventually, you get used to the pain. Or you just write more software to make it easier.

There are so many commands that they divide them into two categories: plumbing commands, and porcelain commands. They use the different terms to describe the lower-level, background functions of Git (the plumbing) versus the more human-friendly, human-readable interfaces for Git (the porcelain). The programmers of Git, in their infinite wisdom and wry sense of humor, decided that the best analog for describing the difference between these types of functions was the concept of waterworks in your house. Because toilet humor.

The idea is this: you generally don’t deal with your plumbing every day (unless you need to make modifications or fix something). But you will definitely use your fixtures (your sink, your bath, your probably porcelain toilet) often.

Git plumbing functions are intended to have well-formed interfaces whose format will (hopefully) never change. Output is reported such that another computer program can interact with the interface and get what it needs with little fuss. This makes plumbing functions ideal for consumption by and interaction with other software, given that they are easy to program against and have some guarantee that the interface will not break in future versions.

Git porcelain functions have no such guarantee. Their interfaces are intended for consumption by humans. Fickle, capricious humans, that speak of love and beauty and want computers to know what they want without having to describe what they mean.

So. What does the concept of plumbing and porcelain have to do with planning and the writing process?

Well. The planning process is the plumbing. The writing is the porcelain.

Planning is making sure everything is mapped, and that the right pipes are going to the right places. Your theses need to be present in every chapter, and your characters and their scenes need to be able to convey them. You want a pipe and a drain in every room that needs water, the right valves, and both of you agreeing on where the sink is.

On the other hand, the writing is where all of those pipes meet fixtures, and ideas meet readers. Where your porcelain meets the… hands? Because they’re porcelain knobs… Nevermind. The writing-porcelain is sentence structure, the word choice, the meter, rhythm, and balance. It is the handle you twist to get the hot or cold you want. It is the interface that makes sure all of those things are put together such that a human will read it, understand it, and want to read more. And as you grow as writers, you will eventually say to yourself, “Man. I don’t know why we chose dark gray for the toilet. And why is the tank 6 feet off the ground?” The porcelain is relatively easy to change, and will probably be swapped more than the plumbing it connects to (provided you’ve got good plumbing).

The plumbing and the porcelain of your writing must inform the other. When it comes to good storytelling, neither should exist in a vacuum. But there is a pretty strict order of operations. Plumbing comes first. Because you should absolutely be done with the plumbing before you start putting in any toilets.

You might say, “You started in 2012, but you didn’t start writing until, like, late 2013? What gives? Just write. Figure it all out later.”

It’s because it doesn’t how matter how nice a toilet, nobody should sit on it unless it will flush.

Process Imagineering, Part 1: Holy Jam

When you tell people that you’re writing a book there are a handful of responses that usually come up.

First, and by far the most common, is the “Oh. Neat.” Their tone is somewhere between vague, non-commital interest, and the frantic Oh my God realization that they’ve opened themselves up a conversation they never wanted to have.

Second are the skeptics. “Oh. Really?” they ask. They are the ones that look at you like a stranger, wondering at what point they mistook you for a normal, well-adjusted person. Their eyes go blank for a moment as they trace their path to the present in an “it was there, right in front of me all along” montage. The flights of fancy. The introverted, narcissistic behaviors. All of the times Josh corrected you on pronunciation in front of everyone. Their eyes snap back, ready to head you off at the pass before you try to recruit them for beta reading.

Third are the curious. Those that have a bunch of questions. They might initially start as the first or second cases, but they find themselves resigned to their fate. They want the satisfaction of finishing a conversation, or the accomplishment of getting through one with me. They realize I just want to talk about the thing I am interested in for a few minutes. In this case, the best way out of the hole is to keep digging. Ask a question, nod understandingly, then walk away. Everyone gets what they want and nobody gets hurt.

How long have you been working on it? We’ve been working on it for four years. What’s it about? Scifi fantansy. How long is it? We wrote way too much. Wait. You said we. Who is we? Oh, me and my co-author.

This is where the decision tree for people starts to break down, the branches cracking off and the trunk listing badly. The world made sense in that Josh would be the weird, quirky author type. He does all that stuff with computers so that sort of makes sense that he’d be into all those orcs and elves and dwarves and shit.

But the equation changes when there are two people in the mix. There is only really one branch left on the decision tree, one question: How the hell does that work?

The insect machine thing deep within me starts spooling a lengthy, unsolicited lecture on the importance of tools, backups, traceability, and accountability. It never really lands, and I usually just sound crazier than when I started.

When I’ve heard Mike answer this question, he just answers, “Slowly. Very slowly.”

I should take notes. Those asking the question aren’t curious on what we use to do it. They are curious how, at a very basic level, do you sit down and both arrive at the same creative vision.

Well. Here it is. The one time I attempt to answer a question in a straightforward manner, and maybe even answer the question that was asked. This is your moment, Josh.

This post will start a series that will detail all the weird things we do, and hopefully answer the question of how this all works.

The Holy Jam

When an author sits down to hash out a chapter, crank out a scene, or wrench on some dialogue, there is some pretty crazy stuff going on. My background in computer science has no way to adequately quantify it. For someone to start with absolutely nothing and end up with a string of symbols that represent natural language that describes a story that other people would want to read is mystifying. It is one of the many things that we will struggle to mathematically or computationally model for a long, long time.

That said, the human brain does this kind of shit all day. We can contextually identify objects from a continuously moving field of vision. Or maintain locomotion using muscles that we had to learn how to use from scratch. All while processing billions of sensory inputs. And the most difficult part of it all is having ‘Fight Song’ stuck in your head one more fucking time.

So, the question is: what happens when you have two authors? We don’t have wiring for telepathy or mind-melds. Mike and I, though we share a lot of the same interests, are not exactly of the same mindset. We are, in fact, pretty different writers, both in method and style. So how do we come up with something we both agree on?

Well. You get together and jam. Jam session, that is. Like musicians do. Except a lot quieter. So far we haven’t been banished to a garage. Except for that one time we had to stain Mike’s doors.

A writer-ly ‘jam session’ probably isn’t the best name for it, but it’s the best fit we have. The purpose of a musician’s jam session is well understood. It is to rehearse. To practice. To figure out problems before they happen during a performance. Or just to get better at playing with people. Or just to drink and have fun.

The purpose of a writing jam session is a little muddier. The jam session isn’t a write-in. It isn’t a team writing exercise (also, those never work, regardless of whether you’re drinking). It isn’t where you sit and read each other’s work (unless there have been quick edits since you looked last). You should both be caught up, and either be in agreement with the other person’s work or have items you want to figure out.

The jam is to free each other from whatever is stopping you. It’s an… unjam session.

(I’ll just see myself out.)

Here is what one of our jam sessions look like:

  1. One of us sends out a jam subpoena. This is in text form, or just a straight up Google calendar invite. We try to use a pun in the name of the invite. Jamboree. Jambalaya. Log Jammin’. You get it.The time is always the same: 8pm, when Mike’s kids get to bed.
  2. One of us heads to the other’s house. We both bring a computer. We bring up the file called ‘NextJam’, and enter multi-editing mode so we can see each other’s edits. Both people can type, but you try to take turns so someone isn’t just typing the whole time while the other person yammers.
  3. You follow the items as dictated by the NextJam. The NextJam is the listing of the stuff you added to the NextJam since the last jam session. It starts with a section called ‘Discussion Items’, which is just a bunch of random shit that’s on your mind. New video games. Something you saw on reddit. Sometimes it is book related. Most times not. Allow yourself some time to have an adult conversation about adult things. Some people have been talking with four-year-olds all day and just need to interact with someone who isn’t hustling them for snacks.
  4. Once the discussion items are complete, you will completely ignore the items under ‘Bookkeeping’. These are things like the links to the last jam session, or reviewing the work list, or the TODO list, or the Document Status review list. Nobody has time for that. Skip past where Josh wants to talk about renaming the Empire. Skip past where Josh wants to talk about book titles. Scroll, scroll, scroll…
  5. Get down to what you really want to talk about. Book stuff. The things you’ve been working on. The pending questions. The things you wanted to run by the other person. The stuff that came up while you were working on things.Or, even better, try to remember why you put something on the list. That’s always fun. At the same time, try to remember all the things that came to mind while you were trying to fall asleep, or in the shower that morning.
  6. Talk for 2.5 hours. Write down any decisions you make, and any notes for future modifications. Save the file, giving it a timestamp. Keep the pending items in the NextJam for the next jam session. Go home.

Repeat the above steps until you have a novel. For Mike and I, we have held one hundred and eleven jam sessions according to our records. Possibly more impromptu or unrecorded ones that didn’t make it onto the system.

Some jams are more productive than others. Some get off on a topic that you didn’t even have on the list, but needed to hashed out anyways. Sometimes nothing gets hashed out, and you just sit and gossip for hours. But most times it can be effective in breaking you from your collective procrastination. Regardless of productivity, you should always walk away from a jam session with work to do. Don’t go home until you have work to do.

For instance: You aren’t sure about a character’s decision? Ask the other person. Not sure how to implement an aspect of world building? Ask the other person. Between the two of you there is most definitely an answer, a clever solution, or a way to cheat around it. Something that may be a showstopper for one person may be trivial for the other. One of you is super into maps? Great. Fix the cardinal directions I ham-handedly misplaced in my latest edits. I’d rather be inventing magical cryptosystems anyway.

The final, and maybe most important feature of a jam session is seeking the assurance that you are not crazy. As an author, your job is to make shit up and hope that it sounds like something somebody would want to read. Wherever this stuff comes from is usually a pretty crazy place. And unless you have unwavering confidence in your creative abilities, there will always be the doubt that whatever you came up with is silly and dumb. Or crazy. The jam session is there to run these things by your coauthor. To have a system of checks and balances. Having someone else there to drop a ‘Awww jeaaaah’ or a ‘Awww hell nah’ can get you past whatever snag you are on and solving the problem.

The jam session is pretty central and somewhat holy to our process. It’s something we started early, and while at the time we probably didn’t realize it, it would become pretty important.

So. Yes. The answer, part the first: we jam.

Minimizing Potential

When I make a purchase, it usually follows a period of long reflection on the object’s highest use. I do not like committing to something without understanding what it was designed to be used for, and then maximizing its potential. Some of my logic extends from a cost-benefit analysis so that I am getting the most for my dollar, the rest comes from the depression of seeing something languish in disuse. The stroller my wife and I bought some years ago has had countless miles put on the axles, despite our initially wrangling over the purchase price versus expected use. Often my motivation for maximizing potential comes after acquiring a product, as I am now committed to making the most of it. Seeing that stroller sit in our garage inspires me to get outside and take my children somewhere. I’ve pushed it over rough surface, walked on paved trails, run with it, and towed it on a bike, using it well within the designed parameters – not just as a luxury carriage. I’ve restrained myself in other avenues, calculating that I don’t need the bigger storage device on a phone, or that I wont be shooting short films when looking for a video camera. When I use a product or tool, I dedicate myself to its highest use.

However, there are exceptions to the rule.

Giterary is one. For Josh, I imagine he often see’s me as the crass, club-handed and hind-brained user. I barge in regretful and angry to have something new and foreign foisted upon me. I mash the keys and balefully wonder what the big problem with a Google doc was. “Why can’t I just copy paste out of an unaddressed email? Google autosaves on the reg, *Josh*, if that’s your real name.” My coauthor foresaw the plethora of deficiencies that would arise from collaborative writing, and sought to rectify them all in advance of our colossal undertaking. He surveyed what was available on the market and determined he could- nay, *should,* summon a work from the primordial ooze of bytes and bits. I nodded along when Josh introduced the concept of the tool, more concerned with getting words on digital paper than his ramblings about *redundancy* and *clarity* and other bullshittery. His constant nattering about *archiving* and *backups* was only cluttering my brain space. I just wanted to get to the story about airships and skywhales.

So Josh took me along by the hand, a disinterested and apathetic co-writer with the attention span rivaling my toddler. While he simultaneously worked on our story and the very palette with which we would chisel it upon, I would make scathingly naive critiques on the nascent UI. I bumblefucked my way through his elegant baby and Josh would solve my problems with nary a nod of objection or whisper of dissent. While I would scrawl my purple utterances in mislabeled documents, Josh was already thinking ahead on how Giterary would scale with our work, creating processes and tools to head off future problems of categorization, timelines and tables. While I would happily mash word after word in the same bloated document, Josh had coded organization and structure in which we could effortlessly create. He built things I didn’t use. Things I don’t use.

But the thing is, he fixes my bullshit. He cleans up my visceral grunting and rambling world building into coherent content. I revisit old wiki-esque entries on our invented calendar or nomenclature concepts and gleefully discover that I can sort an integrated table by different parameters. Did I enter the content properly? Did I ask for that organization? No, but by the All Father Josh thought of it (or was sick of my single carriage return lists) and made it happen.

With a keystroke I can find myself with the minimal input terminal I require. I can search for that mislinked document on concepts for the pilot’s oderic weapon. Most importantly, I can see every minute change to every document we made the mistake of creating. Josh and I are writing this thing together, and he left us a record of every gods damned punctuation change. With a click I can revert to content three years old (and Josh can sigh and redact my editing privileges). He created an amazing, helpful, powerful tool.

A tool I sadly do not appreciate for it’s highest use.

You signed up for many years of this, Josh.
Josh suffers well.

The Sharpest of Tools

I (Josh) follow /r/writing. It occasionally has content that I’m interested in, similar to /r/todayilearned or /r/trippinthroughtime. It’s something to let the other side of my brain breathe during my union-mandated 15 minute breaks. It also looks suspiciously like work. That it seems like work, or could be construed as work is important. “I work in IT. I will always need to keep up on my communication skills” is what I’ll say if anyone ever calls me out on it.

But really, I don’t have a door to my cubicle. My only, once, and future aspiration in my career is to have a door that I can shut. And maybe to be able to wear headphones again. Being able to see daylight during the day would be a distant third.

I am far from my hunter-gatherer roots.

Anyways. Despite a lot of repeated posts (“How do I get started?” or “How do I cure that pesky writer’s block?” or “Here are ten things writers should / should not do”), there is the occasional nugget. Someone talking earnestly about their project, or someone talking about their experience with publishing. Sometimes it’s fulfilling, hearing someone else struggling with the same things you do. Sometimes it’s horrifying, hearing that someone is getting taken by an agent or a publisher.

But other times, someone asks, “What software do you use for writing?”

And even though the answer is almost always the same, I will still descend into those depths. As a computer programmer, I am essentially a professional text wrangler. Yeah, there’s code and everything, but the way to that code is a series of keystrokes that put characters on a screen. The better, the faster, and more economical I can be in this, I can spend more brain-time on the problem I’m trying to solve.

Whether it is code that I am wrangling or natural language is sort of incidental.

In those /r/writing writing tool threads people usually bring up Scrivener. Weirdly, this seems to always coincide with a sale on Scrivener. Always with the Scrivener. I am sure it is great. I, personally, have never used it. This is because it doesn’t cut cans.

The can that needs cutting is that I am not just one author. I am one of two authors that have to collaborate, and do so over long periods of time, short distances, and the extreme variability of child-weather. Well, Mike’s children’s child-weather. My free time is a deep, lush forest. Mike’s free time is that lone tree on the mountaintop that you wonder how it got there.

Anyway. Our use case is a little unique. We have to track each other’s changes, notes, have discussions about further content, and generally do all the things Scrivener does without stomping on each other’s work or losing it. It’s a tricky thing. The kind of tricky thing that you need the right tool for.

This was my exact thought progression when we started Skysail. I did some research. I saw the /r/writing threads about writing software (“All hail Scrivener!”), and rather than taking the advice of Internet randos, I became curious what famous authors used. I did some looking and I found the following:

List of word processors used by famous authors:

Patrick Rothfuss: Microsoft Word '97
George R. R. Martin: Wordstar
Neil Gaiman: Fountain Pen / Final Draft
Steven King: Microsoft Word
John C. Dvorak: Wordstar

This from a file I have called WordProcessorsOfFamousAuthors. I never cited my sources, so I really can’t claim much in terms of how solid those are. But I’m pretty sure that I’ve seen repeated references to GRRM’s choice of tool in Wordstar, and I think Neil Gaiman’s method is documented as well.

What I was looking for here was the Photoshop, the Illustrator, the Premiere of novel-building software. Something that professionals use, can use, and if they aren’t using it, they are using something else very specific to their job. Unfortunately, I found the answers above. A couple of Microsoft Office junkies, and hold-outs from 1980’s. Nothing that I could pick up and say, “This will do all of the things.” And certainly nothing that would help Mike and I work on the thing in tandem.

Well. I should qualify. There are tools that help. Can help. Programmers have solved the “multiple authors, multiple files, high complexity, over time” problem for a while now. But they are not tools that you can sit someone in front of and say, ‘Write.’ No. They are tools that demand sacrifice. They are tools that only speak the language of pain.

Git is one such tool. I had just learned Git then. Git is an amazing piece of software. Git is software that helps you build software, tracking changes and history of a directory over time. That it was built to track code and not a book is, like I said, incidental. But it is pain wizard software. As a code monkey, my tolerance for this pain is rather high. I am a pain wizard, drinking the pain to fuel my strange powers. Yes, I can do these magicks. But do I wish all of this pain and suffering upon my friends and family? No. I can’t. I’m not that kind of a monster.

Surprise! I’m just a different kind of monster. A code monster. The kind of monster that says, “If something doesn’t do exactly what you want, it is your moral and biological imperative to create the thing that does exactly what you want.”

So, back in 2012, pretty much the day we started putting things together, I also started putting together Giterary.

Giterary is not amazing software. It is okay software. It’s a wiki that I built that tries to smooth over the knobs and angles of Git and make it a decent writing experience. In actuality, it’s a confusing, half-built mishmash of cobbled together editors and forgotten functionality. It’s weird, it’s over- engineered, but we call it home.

It lets Mike and I edit the book in pieces. It lets us check out the book to our computers, work on them during long flights or the dark, disconnected times. And it lets us quickly organize novel content and marginal content. But when it comes down to it, it’s just a wiki. A wiki that can make eBooks. And can do columnar editing. And searches with regular expressions! And manages your TODOs! Oh, you’ve left. Darn. Not another one.

Anyway. Now, as it was four years ago, I feel that online authoring is in its infancy. We’ve had things like Wikipedia (which is run on the Mediawiki platform) to demonstrate what can be done when you have multiple authors and editors and consumers. But we’re only just getting there. As I’ve learned with developing Giterary and other tools, online text editors are limited to the resource constraints of a web browser, which, while considerable these days, are still limited at scale. For instance, loading Skysail into Google docs will crash the browser every time.

Anyway. We’ll document our workflow at some point. But really, the purpose of this is just to give a sort of colophon for our novel. A “tools used” so that others in some future /r/writing thread can have another weird data point to ignore in lieu of Scrivener.

We both use Giterary, the wiki I wrote to help us collect, organize, and write the novel. I (Josh) use it, and if I’m on a computer with a decent terminal emulator, I’ll do a git pull and edit in Vim. Mike, if he‘s really desperate, will use Notepad++, but that’s only if his Internet dies at the coffee shop and he’s afraid that he’ll lose his draft (he won’t, unless it was that one time, and I’m still sorry).

As is the default format in Giterary, we both use Markdown, which is a really great, simple, way to generating HTML with minimal syntax and hardship. Giterary makes use of the CodeMirror editor, which provides syntax highlighting and a lot of other nice things. We edit in text, we read in HTML, and export to ePub format.

P.S. I don’t waste all that much time at work. I don’t smoke, I don’t whinge for hours on about politics, and I don’t do fantasy sports. Even if I was into two of the three, I think they would be money ahead.

It has been zero days

There is a running gag in the Youtube channel Game Grumps:

For those that don’t want to click, their episode begins with the following:

Arin: Bringin’ it back, ya’ll! [beat boxing over a play-through of Zelda: A Link to the Past]
Dan: It has been zero days since Arin beat-boxed.


I like this for a lot of reasons. First, it’s maybe my favorite way to call someone on their bullshit. Second, as a computer programmer, it speaks to my weird, mechanical mind that clicks and whirs beneath layers of social emulation engines.

Among the random shit I have coded I have made a number of “count-up” clocks. “Count-up” being the opposite of “countdown,” in that rather than counting down to something it will tick away the amount of time since an event.

I build these because, well, quite frankly, my perception of time is poor. Things that happened recently feel adrift and ephemeral. Things that happened a while ago really happened decades ago. Children born yesterday hit the double digits, or even worse: start high school. Back to the Future day (October 2015) came and went. My passport expires this year.

I build count-ups because they give you an objective sense of the passage of time. It helps so that the inevitable, “Can you believe it’s been this long since that?” conversation is not as crushing when it finally comes. Also, they help you to remember birthdays.

Anyways. At time of writing, it has been 981 days since last I blogged (July 2013). In my last post, I went on about good data practices, computer truth, file formats, and digital legacy. Nothing new, if you’ve been around me at a party when I’ve had a bit to drink. I ended with this:

It will not be boxes of photographs that our descendants (theoretical, or otherwise) will have to sort through after we’re gone. With any luck, it will be a hard drive, or flash media, or whatever holographic crystal storage medium supersedes them with a password sticky note hastily taped to its side. It won’t seem like much to them. Tiny files with old, old timestamps. Maybe there will be gaps, or just nothing before a certain date. Hopefully the contents will help them to realize it’s a hollow, horrible, dark feeling to be unable to account for lost time.

I am just a riot at parties.

At the time of that post, we (Mike and I) had already been working on the Skysail novel for a year (June 2012). We would meet in secret for our book jam sessions hiding our secret passion from friends and loved ones. We established our core theses (from which my last blog post was inspired), constructed outlines, built characters, and debated what we would eventually call ‘odeum’. Three months after my blog post we would begin principal writing on the narrative portions of the book (October 2013).

But even before that we were still working on Skysail. Even if we didn’t realize it. And by we, I really mean Mike. He had been a part of a writing community for the better part of a decade, writing with people he met on the hallowed gaming forums of yesteryear. There he found people with a shared love of fantasy, airships, and Final Fantasy fan fiction.

Unfortunately, by the time we started working on Skysail the community had been waning for years, with membership and updates slowing to a crawl with the onslaught of adult life. Each time their forum host would be bought out, or become less free, or unexpectedly disappear, old members and old content would be lost.

I (Josh) had stumbled across their community by accident (early 2011), finding a fascinating microcosm of creative fantasy. I read their backlog of posts, learning about the universe, the characters, and the authors who wrote them. I never understood the game that was being played but I did end up writing a short story based on a throw-away character being left behind at port after an airship was forced to make a hasty escape (October 2011).

That throw-away character’s name was Vasili Mikhailovich. He would eventually turn into our protagonist for Skysail.

So, in ye olde 2016, as we are nearing the completion of our first draft, it’s weird to go back and objectively account for time. I have records and tools that tell us exactly who did what and when. But when it comes down to it, it feels both like an eternity and yesterday. We’ve done a ton of work and yet it doesn’t seem like anything. We’ve been working on the story long enough that it feels like it has always been written. All that exists now is the unendurable weight of the work we have left to do.

Anyway. It has been zero days since Josh blogged.