Aside from blogging here, I’ve been trying to build my writing habit by working on a short story. I wrote some short stories while in college, and thoroughly enjoyed it.

My best friend, Collin, writes quite a bit. He credits me with initially inspiring him to write, but he has since far surpassed me in quantity of output, and, I would argue, quality. Although he doesn’t code, he said he imagined storytelling and programming to be similar disciplines, or for there at least to be an overlap in skills and practice.

I think his hunch is true.

A bit of advice sometimes given to writers is to stop writing in the middle of a scene, or a point of tension in the narrative. That way you have something to work with when you return to it.

I’m finding a similar practice has been helping me with programming lately. I’m currently working on a tool for importing legacy configurations into a new schema in a new system, and trying to use test-driven development while doing it. The whole export/import system is fairly involved, taking me more than a day to build, and starting the day with a new function or component to write without knowing exactly what you want it to do, let alone how, can be fairly daunting.

In the spirit of true TDD, I write a failing test that expects a certain output, and then code the feature until the test passes. But, instead of spending tomorrow morning determining the “shape” of data I want and writing a new test, I ended today by writing a failing test, giving me an explicit objective to complete in the morning. I’ll admit it felt uncomfortable leaving this undone, but having something clear to accomplish in front of my when I start my day tends to be very motivating, and provides fuel when moving on to each successive task.

Never underestimate the power of interdisciplinary insights.