Programming as storytelling

When I create something using computer graphics programming, I often wander from one thing to another. First I will try a little of this, and then, depending on the outcome, I will try a little of that.

This process could be captured in a number of different ways. For example, I could keep a video running, showing the screen at all times.

Or I could capture the input somehow — perhaps the literal keystrokes that I type — so that the exact journey from start to finish can be recreated later.

I suspect though that the ideal would be something more literary. I should be able to annotate the process as I go, jotting notes down when needed between changes to say “here is my thinking as I go from here to there”.

That could be done in a video, but not very well. What I really want is a system that will let me go back later and edit those annotations. The end result should be a sort of interactively explorable documentary of the process of creation.

I don’t know of anything out there that does that well. Maybe I will just have to build it.

2 thoughts on “Programming as storytelling”

  1. While not a visual way to tell the story, a source control system can be a way of capturing the narrative of the development of a program. It takes a lot of discipline to make many small yet self-contained changes with meaningful check-in comments.

    I made a conscious effort to do this recently on a small library I wrote over the course of several weeks. Reading through the change log tells a (mostly) coherent story of those weeks, as I tried things, changed my mind, refactored, discovered and fixed design problems in the API, stole ideas from similar projects I stumbled upon partway through. A couple times, adding a small test opened my eyes to an entire portion of the problem domain I had completely missed.

    The log alone is enough to capture the story, but the actual changes that correspond to each step are there to drill down into if desired.

    I see the value of Knuth-style literate programming for explaining complex programs (e.g., the TeXbook or PBRT), but often I wonder not how a program works but how it evolved. Even when the source control log is available, it’s often not as coherent as one would like. Many programmers use source control more for “safety” than as an opportunity to document process. I think it can (and should) be used for both.

Leave a Reply

Your email address will not be published. Required fields are marked *