Changelog

Making art requires putting a part of yourself into the weird thing you make.

(Let’s assume we’re talking in the figurative sense. I’m not prepared for the ads that will follow and haunt me after I search for literal examples.)

As a programmer (and by definition egotistical and self-aggrandizing), of course I tend to see code as art. Or at least as a craft that can be pretty artful at times. Not, eh, high art, you know? But I’d say it’s still up there. Code can be beautiful and elegant in addition to efficient and hopefully working.

So, then, if we assume that code is art or art adjacent, we should expect to see people somehow represented in the code they write, either through their ideas, their opinions, their philosophies, or the way they think, as expressed through code and code design.

But we usually don’t see people or their art when using a program. Interacting with a program tends to be impersonal and artless, focusing instead on utility and reliability. I have worked with computers for many years, and I have yet to hear somebody say, “The validation logic behind these spreadsheet cells was artfully implemented! I feel spiritually enriched with how the artist alerts me to the wrong number of decimal places I have used!” I’m only one person, though. Lots of spreadsheet enthusiasts out there. Such a thing could very well have been said.

There are a lot of reasons we don’t see the art or the artists behind programs:

  • Larger, more popular projects tend to be the work of many individuals, and are designed and decided by committee (thereby masking or overwriting any particular individual’s input or vision).
  • Managers and executives in charge of development projects hire marketing and brand management people to make sure that programmers have as little to do with the marketing or the brand of the software as possible.
  • Most programs aren’t created with the intent of producing art. If you don’t intend to make art, it’s not super likely that you will accidentally create art.
  • Programs are expensive to write, and if artfulness would cost extra, it’s almost guaranteed to not be included with the end product.

That isn’t to say there isn’t art in coding. Far from it. There are a bunch of resources out there that discover and detail artful code. There’s the seminal tome The Art of Computer Programming which I have yet to read despite working with computers for 15+ years. There’s also a book called Beautiful Code that describes a wide array of interesting, clever, and artful things people do in their source. (I have only read a part of it). And for those that don’t care so much about code, but do care about what good programming looks like to the end user, you can check out the interesting, clever, artful things that people do over at Little Big Details.

Or, finally, if you couldn’t care less about art in code, and you’re already bored with this article, you can go play your favorite video games, which are some of the few programming projects that are created with the intent of making art. Games like Portal, Braid, or Stardew Valley show us where small teams, or even just individuals, spent years putting themselves into their art. Playing such games, which sit at the intersection of storytelling, digital art, music, and game design, is a conversation between the player and the people that spent years of their lives putting themselves into their art.

But the developers making the Portals, the Braids, the Valleys of Stardew, they are in the minority. My searches aren’t coming up with good data, but I’ll estimate there are 200,000 game developers in the U.S., compared to the 1.2 million total software developers in 2016. They’re still a significant chunk of the codemonkey cohort, but the games industry isn’t a kind place for game developers. Large corporations take every advantage of passionate artists, who being a relatively young engineering discipline and having a “professional” culture, have very little union representation. I like programming, but game development isn’t where I would want to be. People sometimes ask me, “Hey Josh. Do you ever think about making a game?” And rather than bringing up the 60 hour work weeks, or the burn-and-churn pace of game development projects, I just tell them that no, I’m not good enough at programming to work on games.

Instead, most programmers are working on smaller, and decidedly less artful things. They work on things like the aforementioned spreadsheet cell validation. Things that help people and businesses with problems they have. Problems like making sure you put in exactly as many decimal points as you intended. Making sure you don’t lose your work when the network connection goes bad. Making sure something happens when you click ‘save’. Spiritual enrichment usually isn’t among our deliverables, but there’s something to be said for making people’s lives a little better.

With countably few exceptions, even though programmers are responsible for every piece of software you interact with, you still rarely hear from them. That is unless you read the change logs. Depending on how interested you are, or how often you update the software on your devices, you may have read something like the following:

So yeah, maybe not the most exciting, artful declarations of the human experience. Change log messages tend to be terse, routine declarations, like “Bug fixes” or “Performance improvements.” This is partly because it’s assumed that the people reading the change logs aren’t interested in the particulars, or the people behind them, only whether their program would work better, or faster.

But then came along ubiquitous mobile devices. And with the mobile devices, came their app stores, which took it upon themselves to continually bother people about the pending updates to their apps. And some time later the app stores came with user ratings, which forced software teams to not only compete technologically, but also to compete for the engagement and loyalty of their userbase so that they got better ratings than their competitors.

And so, change logs are changing:

To distinguish themselves from their peers, change logs are becoming more interesting. Developers can put more detailed, thoughtful messages in their change logs. Granted, most folks just say, “Ok, yeah, do the update thing now please,” and continue on with their day. But there’s a chance that in scrolling past a dozen pending updates, you might read something that wasn’t the rote “Fixed errors” or “2019 Updates.” It could be from what sounded like a real person on the other end, not just some faceless corporation. You could maybe hear from the artist about their art. It could be that the software was no longer an immutable set of algorithms and protocols, but an organic, living, human creation that contains the artistic input of the people who make it.

So, we’re pretty far into the weeds, dear reader. I know, precious, shushushuh, I know. This isn’t where you wanted to be. I know you’ve only budgeted for just so many new ideas a day, and this wasn’t necessarily one you were hoping for. Your question, at this point, is a valid, and natural one:

Why are we here?

Well. It’s because we’re re-releasing The Apotheosis Break (Skysail Saga: Volume 1). And we want to show you its change log.

Change Log for Vol 1, version 2 (Released July 2019)

2019-06-30 Josh Rhoades and Mike Rutledge <skysailsaga@gmail.com>

  • General stats
    • 262 revisions since October 19th, 2016.

  • Revised for typos, word/phrase use, and overuse
    • BUG: Dozens of typos and misspellings made it through to the published text. FIXED.
    • BUG: Everything that was like a mouth was a “maw.” FIXED.
    • BUG: Characters do a disproportionate amount of fumbling, jostling, scurrying, and scampering. FIXED.
  • Revised for filtering language
    • BUG: Overuse of saw, noticed, heard, realized, etc. FIXED.
  • Character distinction
  • Revised for dialog attribution and distinction.
    • BUG: Too many dialog attributions that aren’t simply “X said.” (Self-Editing for Fiction Writers, pg. 95) FIXED.
    • FEATURE: Dialog clean-up to ensure clarity, tone, and speaker (in the absence of attributions).
  • Revised for scene blocking descriptions
    • BUG: Stop nodding. FIXED.
    • BUG: Stop turning. FIXED.
  • Revise for language consistency
    • BUG: Toward(s), backward(s), upward(s), downward(s), forward(s), etc. are inconsistent. FIXED.
    • BUG: Use of “damn it” and its variations are inconsistent (and not always character appropriate). FIXED.
  • Beta reader issues:
    • BUG: Overuse of direct address in dialog. FIXED.
    • BUG: Not apparent enough that airships are not spaceships. FIXED.
    • BUG: Address gender biases in character descriptions. ADDRESSED.
  • Revised for Mike-isms and Josh-isms
    • BUG: Every list of things is a “parade of [those things]”. FIXED.
    • BUG: If two emotions are felt, they are a “mixture of X and Y.” FIXED.
    • BUG: “could not help but” should not be before every impulsive action. FIXED.
    • BUG: Too many comparisons of people on the ground as seen from an airship to ants or insects. FIXED.
    • BUG: Limit the use of ‘festoon’ to once per novel. FIXED.
    • BUG: Too many “As… —ing” sentence constructs that describe two events poorly (see: Self-Editing for Fiction Writers, pg. 193). FIXED.
    • BUG: Too many adverbs (see: Self-Editing for Fiction Writers, pg. 94). FIXED.
    • BUG: Too many gerunds (-ings). FIXED.
    • BUG: Overuse of indefinite “she was X-ing” or “she had been X-ing” instead of a more precise preterit verb (“she X-ed”). FIXED.
  • Typography
    • BUG: Don’t use bolded text, too distracting. FIXED.
    • BUG: Use of italics, single quotes, and double quotes for dialog, narrative quotation, emphasis, and dialog, is inconsistent. FIXED.
    • BUG: Directed quotation glyphs (single or double quotes) are inconsistent. FIXED.
    • FEATURE: Mike has added bespoke “Skysail” glyphs for scene and chapter breaks, rather than using plain horizontal lines. NEW.

    • FEATURE: Mike has implemented a printed version of Volume 1 in InDesign, addressing issues with “widows and orphans” as necessary. NEW.
    • FEATURE: Mike has implemented new styles for chapter beginnings (quote blocks, dropcaps, etc.) NEW.

    • FEATURE: Mike has implemented new glossary, appendix, and dramatis personae stylings. NEW.
  • Cover Art
    • New Cover Art:

It’s almost been three years since we released Volume 1. We were very proud of it. We put ourselves into it. But in three years’ time, we’ve (attempted to) become better writers. We’ve read books. We’ve been to conferences and lectures. I even took notes sometimes. But our most effective education is easily the whole ‘nother volume (#2, The Gestalt Job) that we’ve been throwing ourselves into, and learning from our mistakes. And with that, we decided that Volume 1 needed a little freshening. Some sprucing up. A little bit of spring cleaning prior to the release of its successor. Because a lot of what makes good art isn’t a singular idea or an uncommon talent. I feel like a lot of it is doing a ton of tiny things that nobody notices. I feel like it’s a lot of tedious edits, grammar, style, and “rookie move” passes. It’s a lot of sanding and polishing. It’s hard work. It’s honest work.

So, yes. We’re releasing a new edition of Volume 1 soon. We’ll make sure you hear about it. And soon after will come the release of Volume 2. We’ll make sure you hear about that as well. Your weekly, low-key Skysail feed full of airship concept art and espresso-fueled writing “jokes” should be a little busier in the coming months. Stay tuned.

But while we’re getting our shit together, my hope is that this article answers the question: What has changed?

The answer is: Quite a bit.

And there is quite a bit more to come. Talk to you soon.