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

http://lambda-the-ultimate.org/classic/message7628.html#7629

by byrneseyeview • 18 years ago

58 27 18 years ago

lambda-the-ultimate.org

bgutierrez• 18 years ago

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

ggruschow• 18 years ago

Me too. Like Andre: http://www.multicians.org/andre.html

npk• 18 years ago

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

tokipin2• 18 years ago

i actually write a lot of code on paper, when i'm figuring out how to do something algorithmy or otherwise tricky

albertcardona• 18 years ago

I use a prompt (usually python), which amounts to the same: scratch paper. The nice parts one can copy-paste and edit as needed.

Real scratch paper I use only for drawing angles and lines when dealing with geometry.

I recall Donald Knuth stating he programs by sitting next to a big trash bin and writing down all code in pieces of paper, most of which he discards.

greyman2• 18 years ago

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• 18 years ago

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

Small pieces, loosely joined, as they say.

klocksib• 18 years ago

You're HURD's biggest proponent, aren't you?

greyman2• 18 years ago

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

zandorg• 18 years ago

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.

byrneseyeview2• 18 years ago

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• 18 years ago

You must have never written any GUI code.

tokipin2• 18 years ago

i don't see the difference. there is input and output in writing a novel too if you want to trivialize it like that. and programs have multiple execution paths, both potential and actual, and can have successive versions as well (e.g. CorelDraw 10.) choices made at some point can affect decisions later on. and it's likely actual humans will use your program

aspirant• 18 years ago

Reading a book is a linear process. Writing may be anything but, especially with fiction.

I have never exactly 'made' a story. With me the process is much more like bird-watching than like either talking or building. I see pictures. Some of these pictures have a common flavor, almost a common smell, which groups them together. Keep quiet and watch and they will begin joining themselves up. If you were very lucky (I have never been as lucky as all that) a whole set might join themselves so consistently that there you had a complete story: without doing anything yourself. But more often (in my experience always) there are gaps. Then at last you have to do some deliberate inventing, have to contrive reasons why these characters should be in these various places doing these various things. I have no idea whether this is the usual way of writing stories, still less whether it is the best. It is the only one I know: images always come first. -CSL

akeefer• 18 years ago

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• 18 years ago

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.

nostrademons• 18 years ago

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.

trekker7• 18 years ago

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.

Tamerlin2• 18 years ago

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.

zasz• 18 years ago

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.

byrneseyeview2• 18 years ago

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?

dmv• 18 years ago

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• 18 years ago

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

omouse2• 18 years ago

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.

bkovitz• 18 years ago

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.

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

Related Stories