5 ms·
Neal Stephenson: Programmer as a writer. Do it right the first time
- bgutierrez 18y agoFrom now on, I'm writing all my code on a legal pad first.
- ggruschow 18y agoMe too. Like Andre: http://www.multicians.org/andre.html http://www.multicians.org/andre.html
- npk 18y ago[I'm sorry for decreasing the signal-to-noise ratio.] Andre is the man.
- tokipin 18y agoi actually write a lot of code on paper, when i'm figuring out how to do something algorithmy or otherwise tricky
- albertcardona 18y agoI 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.
- greyman 18y agoIn 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 18y agoDoesn't that suggest that large projects should be a collection of interacting small projects? Small pieces, loosely joined, as they say.
- zandorg 18y agoWriting 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 18y agoWriting 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 18y agoYou must have never written any GUI code.
- omouse 18y agoThat has inputs and outputs as well, though there is an input-waiting process (which doesn't matter when you're modeling/designing the GUI).
- tokipin 18y agoi 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 18y agoReading 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 18y agoI'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 18y agoI 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 18y agoInteresting - 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 18y agoPG, 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 18y agoI 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 18y agoI 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 18y agoCompare _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 18y agoOrson 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 18y agoFred 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_System http://en.wikipedia.org/wiki/Mythical_man-month#The_Pilot_Sy...
- omouse 18y agoBut 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 18y agoStephenson'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.