Neal Stephenson: Programmer as a writer. Do it right the first time

Stephenson's idea--generate high-quality stuff on the first run by cultivating your subconscious to spew only high-quality stuff--reminds me of performing improv. An improv scene is anything from a skit to an entire musical, performed without a script or planning. The players get on stage and just do it, by saying, acting out, and/or singing the first thing that comes to mind, one line at a time.

There is plenty of bad improv: amateurish stuff, "gaggy" stuff (consciously aiming for cheap laughs), etc. But I've also seen amazing improv: entire plays and musicals, sometimes with serious themes, of such coherence and high quality that it doesn't seem possible that they could have been improvised. I once saw an entire Alfred Hitchcock "movie" improvised on stage, that somehow achieved Hitchcock's signature combination of eerieness and worldly elegance.

I've spent about three years training in improv, and it's actually a lot like Stephenson's tale of needing to keep the typewriter ribbon moving. Training in improv is mostly learning ways to tune into what is happening in a scene, let that trigger your spontaneous imagination, and trust that without judging it. There are some very specific techniques, like "very early in the scene, establish where you are," but mostly it's developing that skill of stoking your spontaneous imagination and taking what it gives you. You know after a while when you're tuned in and when you're not. A non-obvious but important element is to go s-l-o-w (like Stephenson with the fountain pen). That enables you to tune in.

If you don't have your imagination ready to go that way, cultivated by life experience and learning as well as by a feeling for how to tune into a scene, the good stuff just ain't going to happen.

My own experience with writing code is something like improv. Sometimes it sucks, and sometimes it's wonderful. There's no way the good stuff could ever have come about by continuous distillation and debugging. It had to flow. I debug very little. If code is buggy, I just throw it away and start completely from scratch. When the code is flowing, nearly all of the "thinking" is subconscious. I'm just tuning in, as if someone else is writing the code. When it's going super-well, it feels like I'm taking dictation. Just like in an improv scene, I'm writing the current line because I'm curious to know what happens next.

Interesting - I would've drawn a different conclusion than Stephenson from the same data. Instead of "Do it right the first time," I would've said "Revising means rewriting. Don't try to salvage crap."

I never get it right the first time. I also never succeed in turning that ugly first draft into pretty code. Instead, revising for me means taking a look at what I was trying to achieve with that ugly first draft, throwing it away, and doing it right the second time. All this done iteratively, so I'm never throwing out a complete body of work, only the latest bits on top.

In my programming experience working in large projects (100+ developers), it's virtually impossible to Do it right the first time - I mean the overall project. We always have had to iterate towards the solution...but for smaller stuff it could work.

I've had the same experience when writing, whereby my bad stuff was intertwined with my good stuff to the point where merely editing it was not worthwhile, and found that I need (at least) one draft to organize my thoughts before writing a final draft from scratch that generally needs very little editing. The conclusion I came to was that I just need to always write that second draft, rather than Stephenson's conclusion that he just needs to write the better draft the first time. To each his own, I guess . . .

But comparing writing a novel to programming a complex system seems pretty naive, to say the least. The first obvious difference is that a novel (generally) comes out of one person's head, but most larger projects end up far too large for any one person to truly keep it all in their head and understand all the interactions. That immediately makes it pretty much impossible to just do things right the first time; there are always things you don't understand or forget about when working on a larger project. There's also the fact that vagueness is tolerated and often desired in a novel, whereas it's not an option when programming; that just means there are more details to "get right", more decisions to make, and more interactions to worry about. In addition, a program generally has a definite purpose, and you can't re-define your goal as easily based on what it actually does (though sometimes you can; when writing, you often have an idea of where you're going or what effect you want, but if you end up with something different it might still be fine. There are a ton of other differences as well, of course; those are just the ones that first come to mind.

Orson Scott Card used to advocate, at least at a talk I was at a decade ago, write it-throw it away-write it again. Something like "if you wrote it once, you can write it again shorter and better". I've found that to be an important programming insight. Too often, I find myself stepping off the rapid interation path. Inevitably, it is much faster and much more productive to write it the awful and obvious way, prove that with some relaxed constraints the approach can work, and then rewrite it.

Frankly, I've loved Stephenson's works but they have gotten progressively looser. I've attributed this to his success relaxing his editors; this is much like a Senior Software Architect not being held to the same design and code review standards. The result is still impressive and functional, but may not be minimal.

PG, agree/disagree? i ask because this is an interesting contrast to what you've said about writing a crappy v1.0, then iterating on and improving it. but the two concepts aren't mutually exclusive, because maybe "crappy v1.0" can simply mean a well-engineered subset of your eventual goal.

From now on, I'm writing all my code on a legal pad first.

I can't imagine this process working for a book where there's a lot of intertwining between the later and earlier parts of the book. You just don't know what's going to happen until you write it with Stephenson's method. Compare _Snow Crash_ to any complicated story requiring internal consistency, like a Sherlock Holmes story.

Writing a book is a linear process. You have a start and an end.

But a Lisp program (for instance) has multiple paths to its goal, so it makes more sense using non-linear tools when writing Lisp software.