Mike Clark

From this interview of one of my favorite authors, Neal Stephenson:

TCS: I understand that you did all the writing on the Baroque Cycle books by hand, using a fountain pen. Did that make a difference?

NS: Absolutely. The key difference is that it's slower. It's like when you're writing, there's a kind of buffer in your head where the next sentence sits while you're outputting the last one. As long as it's still in your head, it's easy to manipulate that next sentence, or even to reject it. Once it's out, well. . .

[snip]

Quicksilver, the first volume (of three) of the "Baroque Cycle", is a mere 944 pages in length. Given Stephenson's history, we can expect nothing less from each of the upcoming books. What Stephenson reveals is almost unthinkable. I can imagine other authors might be secretly laughing at him for being so... baroque. I can also imagine how boring and physically demanding using a fountain pen must be after about the second paragraph. Sure, the typesetting and print format have a lot to do with the total number of pages, but any way you slice it that's still a very large body of ink. Slower than typing? Indeed, glacially slower.

But writing a book isn't typing any more than programming is typing, a notion credited to Martin Fowler. Writing a book, in my limited experience, is more about thinking and rethinking. Once I know what I want to convey to the reader, writing it down on any medium is easier. Programming is, in my slightly less limited experience, similar in at least one respect. Once I know what the program should do, and how I know when it does that thing, typing it in is easier. Granted, I need to type it in to get feedback that the idealized model in my head can be cast into the reality of working code. And I need an interface that allows me to shape (and reshape) code quickly for rapid feedback. But what I need first and foremost is a construct for thinking and rethinking.

(Faithful readers should pause here to pat themselves on the back for already knowing where I'm going with this woefully inadequate analogy. Green bars for all of you!)

I am certainly no Stephenson, but his response prompted me to think of how slowing down makes a difference for me. Stephenson uses a fountain pen to slow himself down; I use a test. That is, writing the test first has the same buffering effect for me that using a pen does for Stephenson. Forcing myself to slow down by first codifying the "what" question as a test allows the "how" answers to ferment in the mental buffer just a little while longer. While in the buffer, the answers are more fungible and subject to close scrutiny. Once the buffer is flushed out to code, the ideas seem to become more permanent. I'm less inclined to remove code once it's been typed in. Consequently, the accumulation of code leads me down a certain mental path. Sometimes that path is in fact a rat hole -- a series of distractions that corrupt the buffer. It often takes me a while to realize the buffer has been corrupted. We call the result "rework". It's usually more expensive than work.

So how does one slow down to speed up? The trick, for me, is to get into a rhythm of frequently filling and flushing a relatively small buffer. The act of writing a test first creates the logjam for the buffer to begin filling. Once the test passes, the logjam is released and the buffer is flushed. With no buffer, I tend to wander aimlessly. With an infinite buffer, I never take the critical first step into reality. Somewhere in between is my maximum effective throughput. And at the end of the day, I'm more interested in overall throughput of quality code than speed measured at any given point in time.