
Neal Stephenson: Programmer as a writer. Do it right the first time - byrneseyeview
http://lambda-the-ultimate.org/classic/message7628.html#7629
======
bkovitz
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.

------
nostrademons
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.

------
greyman
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.

~~~
jamesbritt
Doesn't that suggest that large projects should be a collection of interacting
small projects?

Small pieces, loosely joined, as they say.

~~~
greyman
Yes, but it is much more than that. You need an overall concept and strategy.

~~~
Tamerlin
The scope of the project doesn't change the need for concept and strategy.

------
akeefer
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.

~~~
jordyhoyt
I agree. Along with what you said in your first paragraph, I've found that the
times that I've completely lost all my work on a project and had to rewrite it
from scratch, the second "draft" was far superior and easier to write than the
first; mostly because I had already weeded out all of the bad assumptions.
However, I doubt this is feasible for anything larger than a fairly simple
one-man weekend project; for exactly the reasons you mention.

------
dmv
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.

~~~
haasted
Fred Brooks actually made a similar point in "The mythical man-month". "Plan
to throw one away", ie. build it, throw it away, and rebuild with the
knowledge gained from building it the first time.

Update: [http://en.wikipedia.org/wiki/Mythical_man-
month#The_Pilot_Sy...](http://en.wikipedia.org/wiki/Mythical_man-
month#The_Pilot_System)

~~~
omouse
But Brooks changed his mind about it because it was assumed that the project
would use the flawed waterfall process. So if you're using the right process,
you can iterate and move back and forth between different stages (i.e.
testing, specification design) easily, thus eliminating the need for re-
writing from scratch.

------
trekker7
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.

~~~
Tamerlin
I guess that depends on how you define "crappy". If by "crappy" you mean
"spartan" then sure. If by "crappy" you mean the code is bad, then you're only
racking up technical debt, not making progress. ALWAYS start with the simplest
solution that does the job.

Yet most people start with the most complex solution they can come up with,
even though they don't know what they're solving yet.

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

~~~
ggruschow
Me too. Like Andre: <http://www.multicians.org/andre.html>

~~~
npk
[I'm sorry for decreasing the signal-to-noise ratio.] Andre is the man.

------
zasz
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.

~~~
byrneseyeview
_Compare _Snow Crash_ to any complicated story requiring internal consistency,
like a Sherlock Holmes story._

A complicated story like _The Baroque Cycle_ , 3000 pages, multiple main
characters, taking place over about fifty years?

------
zandorg
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.

~~~
byrneseyeview
Writing a program is a linear process. You have an input and an output.

But a novel (for instance) has multiple paths and plotlines, towards an
indefinite goal, with the possibility of sequels, prequels, side-plots, and
other ancillary matters, all of which can contradict one another in
unpredictable ways -- and your debugger is an obsessed adolescent fan emailing
you at 3 AM or asking about that musical mixup in 2F09.

~~~
william42
You must have never written any GUI code.

~~~
omouse
That has inputs and outputs as well, though there is an input-waiting process
(which doesn't matter when you're modeling/designing the GUI).

