Discipline(s)

You may not know this about me, but I’m a programmer. It took him years, but one of my best friends from college finally convinced me to try my hand at it…well, a decade ago, now.

He found the right language for me (Python), and then my interest in tedious videogames sealed the deal. Most of the hours I’ve spent programming have gone toward automating or enhancing the games I was playing–whether I was writing a page-scraper to play a browser game for me or developing AddOns for World of Warcraft.

Anyway! The programming I’m doing now is focused much more on my writing and publishing. I’m helping maintain an e-book conversion and production tool, collecting and drawing some pretty cool sales reports with those same skills I used to hack old browser games, and even developing a couple commercial-level projects on the side for friends.

I set aside some time on Saturday to do just that. The project is…well, from the outside, it’s pretty boring. It’s a tool for easily, quickly, and accurately applying contextual labels to large batches of image files. But to me, it’s just a series of puzzles.

• My friend says he needs to be able to handle non-numeric page numbers. I growl at the absurdity of the request (“non-numeric numbers”? really?), then figure out how to make my program handle that.
• My friend says he needs to be able to make duplicates of all subsets containing more than 100 images. It’s a tedious process for him to count and copy and rename. It’s three lines of code for me.
• My friend says he needs to be able to Undo when he makes a mistake (and it would be nice to save old copies of his data file just in case something bad happens to the working copy)….

When he brought up that last one, I shrugged and nodded. “No problem. That’s a normal thing in programming. To keep from wasting storage space, instead of saving lots of old copies of the data, we’ll just save the original document plus a list of changes. That way you can calculate the ‘current’ version by adding all the changes to the original, and you can revert to older versions just leaving out some of the changes.”

That really is an utterly normal thing in programming. Happens all the time. It’s a smart way to do things. And, hey, any program you use regularly supports Undo and Redo, right? How hard could it be?

So Saturday afternoon, when Xander was taking a nap and Annabelle was reading in her room, I settled down with the laptop to add revision history to my program.

Turns out…it’s not easy. I couldn’t find a standard library (where someone else had already done the work for me). I couldn’t find good examples. I had all the starting points, but they didn’t give me quite the information I’d expected to get, and I spent hours trying to figure out how to turn what I did get into something useful.

I spent six hours on it. In retrospect, that’s probably a pretty respectable time, but going in, I really expected it to be a half-hour job. After all, thousands of people do this sort of thing every day. I’m not a professional programmer, but I know all the basics (and I’m pretty good at the things I do often). Something so standard should have just made sense to me. That’s what I expected, anyway.

Anyway! The cool news is that I did end up getting it to work (after giving up completely on two separate occasions). Not only that, but I built my solution into a standalone file, so now I can incorporate that into any other program I want. For me, at least, it will be a half-hour task to add revision history to future projects.

I’ve been thinking about that experience a lot this week, because it carries a strong parallel with another one from the same weekend. On Sunday morning, I started outlining a Sherlock Holmes-style short story for my Auric’s Valiants series. The character is one we’d wanted in that universe from the start and, again, I’d just taken it for granted that I could whip up a Sherlock Holmes-style short story.

I did make it easier for myself by getting the whole Sherlock Holmes series on audiobook. I’ve been working my way through the series for weeks now, and it’s really good stuff. I admire the way Doyle balances the distant, refined narration with the visceral, evocative premises.

The stories have strong, consistent structure to them. That helps a lot. There are some pretty reliable elements, like the size of the cast, the number (and order) of clues, the misdirections, and so on. I felt like I could pretty easily mimic that structure, substituting in my own characters and setting.

But when I started outlining a short story in my scribblebook, expecting it to take about a page, I quickly discovered that the inputs didn’t automatically lead to the output. In fact, it turns out most of what goes into a great Sherlock Holmes story has nothing to do with Sherlock Holmes (or Dr. Watson). It took me fifteen pages of scribbling and a lot more energetic thinking than I ever expected it would, just to come up with an effective plot for a Sherlock Holmes story.

And I haven’t even started on the style and tone–the actual storytelling. Luckily, that’s the part I know how to do. It’s just like my programming problem Saturday: A given writing project can be a huge challenge for me, even as a professional writer, just to get to the point where I can do my kind of writing within the project.

But once I’m there, I’m virtually done. It might have taken me six hours to figure out the outline, but I’ll only need half that much time at a keyboard to get the actual story written. And now that I’ve figured it out, I can reuse it in future projects.

That sort of thing is fascinating to me. I love seeing the parallels between my disciplines. Just one of the many things I love about my job.