Thanks for the great response to my offer. I’m sending out copies today to all the bloggers who’ve requested, and I’ve got just a handful left. If you want to read the book and post something about it, let me know soon!
UPDATE: No books left, sorry.
Thanks for the great response to my offer. I’m sending out copies today to all the bloggers who’ve requested, and I’ve got just a handful left. If you want to read the book and post something about it, let me know soon!
UPDATE: No books left, sorry.
I planned to ask Keen when he’d become worth listening to. He argues that we should listen to experts, not to amateurs… but this is his first book. Did he become an expert in a single moment of enlightenment? Or when the check from the publisher cleared? If it wasn’t a quantum process, was there a moment as a very good amateur where he was suddently worth listening to? And if so, doesn’t that mean that there could be, theoretically, out there on the citizen-generated internet, someone else worth his time to listen to?
Rings a bell for me; way back when I was working as a theater and movie critic and trying to figure out what to do next with my life, I toyed with the idea of trying to write criticism about videogames and computer games. After producing one extended opus on the Mario oeuvre I realized I was already (in my early 30s) way too old for the work.
I confess I’m confused.
A good while back I read about the “page 69 test” — apparently descended to us from Marshall McLuhan. The idea is that you can open any book to page 69 and use that to determine whether you will like the book.
Well, OK. Page 69 of Dreaming in Code contains a description of Moore’s Law and concludes, “…there is no Moore’s Law for software. Chips may double in capacity every year or two; our brains don’t.” Whew. I think that’ll do the trick for at least some people.
Only next I read about a variation of this, called the “page 99 test,” and attributed to Ford Madox Ford: “0pen the book to page ninety-nine and read, and the quality of the whole will be revealed to you.” So, let’s see: on page 99 of my book you can read a story about how hard it is for developers to keep up with the tools available to them. In a visit to OSAF, a programmer named Anthony Baxter described his search for ways to speed up the processing of audio data in a Python application. Baxter was the release manager for the most recent version of Python, yet even he had forgotten that the programming language comes with a utility that exactly suited his needs. “The batteries were indeed included, as Python devotees liked to say. But with so many batteries, who could keep track of them all?”
OK. Fine. I’m willing to let my work be judged on this, too!
But now here comes the page 123 test! This one seems less about helping you decide whether to read a book and more about “bibliomancy,” or the art of making oracular use of arbitrarily selected passages of books. The page 123 test dictates that one “grab the nearest book, open to page 123, go down to the 5th sentence and type up the 3 following sentences.”
For Dreaming, this turns out to be a passage about the Chandler Project’s search for a development manager:
As the hunt dragged on, Lou Montulli and Aleks Totic suggested a name from their Netscape days. Michael Toy had been one of a band of employees at Silicon Graphics who left with its founder, Jim Clark, when Clark decided to start a new venture that would turn into Netscape. He had led the company’s programming team through several hyperspeed cycles of the browser wars in an era that redefined the norms for software development, establishing new benchmarks for fast releases of new versions.
I think I know what the multiplication of these memes is getting at. At this rate, authors are going to have to expect to be judged by every page they write. The nerve of that!
Books aren’t typically fractal — you can’t pull out lots of individual parts and allow each to stand for the whole. But each passage ought to count. In the end, every page and every sentence of a book ought to be able to present a good face for the larger entity it belongs to — like a diplomat abroad.
I wrote Dreaming in Code because I believed that, as Bjarne Stroustrup says, “our civilization is built on software.” I noticed that creating software remains stubbornly difficult in certain ways, and, despite its centrality to our civilization, our understanding of that difficulty remains deficient. But I also wanted to create a journalistic record of the day-to-day experience of the software developer at the start of the 21st century — to tell a story about the act of programming itself.
I’m grateful that a good number of the book’s readers who’ve posted their thoughts feel that I achieved that goal. Others don’t think I did, and some days I agree with the criticism. Writing about the act of programming itself is as difficult as writing about any act of writing: the subject is an essentially interior process between the mind and the page (or screen), and it’s highly resistant to illumination.
Consider the difference when the topic of an essay is a rough physical act — like, say, digging coal out of the ground. I read a lot of George Orwell early in my career but I’d forgotten this passage, which Brad DeLong hoisted into the light of blog last year:
Our civilization, pace Chesterton, is founded on coal, more completely than one realizes until one stops to think about it. The machines that keep us alive, and the machines that make machines, are all directly or indirectly dependent upon coal. In the metabolism of the Western world the coal-miner is second in importance only to the man who ploughs the soil. He is a sort of caryatid upon whose shoulders nearly everything that is not grimy is supported. For this reason the actual process by which coal is extracted is well worth watching, if you get the chance and are willing to take the trouble.
When you go down a coal-mine it is important to try and get to the coal face when the ‘fillers’ are at work. This is not easy, because when the mine is working visitors are a nuisance and are not encouraged, but if you go at any other time, it is possible to come away with a totally wrong impression. On a Sunday, for instance, a mine seems almost peaceful. The time to go there is when the machines are roaring and the air is black with coal dust, and when you can actually see what the miners have to do. At those times the place is like hell, or at any rate like my own mental picture of hell. Most of the things one imagines in hell are if there — heat, noise, confusion, darkness, foul air, and, above all, unbearably cramped space. Everything except the fire, for there is no fire down there except the feeble beams of Davy lamps and electric torches which scarcely penetrate the clouds of coal dust.
It should go without saying that a wide gulf separates the strenuous and perilous experience of the “grimy” miners that Orwell depicted and the abstract, cerebral work of programming. The parallels are less obvious — but they jump out at me, too.
Both activities are essential to industry and highly profitable to those at the top of the economic pyramid they support. Both require the exploitation of long hours put in by young workers. In each, the treasures society values are struggled for in dim places and retrieved into the daylight after obscure labors to which their beneficiaries are oblivious.
Writing about a software project couldn’t have been more physically different from descending into a mine. But there were times, during my three years of research, when I felt like I was in an underground labyrinth, hunting for nuggets of insight in the dark.
It was, in any case, striking to find the “Our civilization is founded on…” construction that kicks off Dreaming in Code in Orwell’s penetrating lead. I’ve been trying to trace the Chesterton passage Orwell refers to as his antecedent, but so far no luck. Anyone have a clue?
It’s been fantastic keeping track of the reviews and critiques of Dreaming in Code in the blogosphere for a whole year. I’ve diligently stored them by a Delicious tag, and fed them via that mechanism into a widget on the book Web site’s front page. Today there’s 275 URLs in that list.
To get the word out about the paperback release, I’ve gotten my publisher to donate some copies for me to hand out, here, free, to anyone with a blog who wants to read it. All I ask is that you post something about the book — positive, negative, indifferent, that’s up to you. Go ahead, tell me you think it sucks! Just write about why.
Yeah, one goal here is to promote the book. But I also wish to bow in the general blogospheric direction. I owe ye, bloggers, big time!
So: want a copy? Just drop me email at scottr /at/ this blog’s domain (or use the form, Luke). Send me your blog’s URL and your snailmail address so I can send you a book. I’ve got a bunch here. First come, first served, till they run out.
UPDATE: Sorry, the books are all gone…
This week, the paperback edition of Dreaming in Code arrives in stores. (And of course at Amazon, too.) The official publication date is Tuesday, Feb. 26 — tomorrow.
What’s the paperback like? It’s just like the hardcover — only the price is a bit lower, and there’s a new postscript bringing the Chandler story farther along. Pay a little less, get a little more. A deal, no?
In honor of this event, the next few days here are going to be a bit Dreaming in Code-focused.
Clive Thompson writes about how software can shape our creative work:
Our tools, of course, affect our literary output. And all this made me wonder how other writing tools affect what’s written. I use Movable Type to write my blog, and I’m constantly annoyed by how small the text-entry boxes are. Whenever I write an entry, the text quickly flows down several box-lengths, which can make it hard to keep track of my argument. The problem, of course, is that the tool was designed with the idea that people would be writing extremely short, pithy entries … whereas my entries tend to drag on and on and on. It reminds me of the writing on one of those old, proprietary-hardware word-processors from the 80s, which were outfitted with screens that only let you see seven lines at a time.
WordPress lets you set the posting box to any size you want. But for longer posts, I compose in a text editor. It’s just handier. I have no doubt, though, that browser-based editing will eventually evolve to the point where I don’t need to do that.
Thompson also references Virginia Heffernan’s recent Times piece on word processors, which recommends the Zen-like blank-screen approach of the Mac-based WriteRoom. (Of course, the dominant DOS-based word processor, WordPerfect, offered what was very close to a blank screen; in a pre-Windows world, you didn’t have a browser or e-mail always competing for screen real estate.)
For those of us who learned Basic on a Zenith Z19 and started word processing on a Kaypro (anyone?), the retro green-and-black now takes the breath away. It’s not just the vintage features available on WriteRoom, it’s also that the whole experience is a throwback to a time before user-friendly interfaces came to protect us from technology’s dark places. In those days, the mystery of the human mind and the mystery of computation seemed both to illuminate and to deepen each other.
All of which brings back involuntary, wincing memories of one of my earliest word-processing experiences, at the Boston Phoenix. In the early ’80s the Phoenix had some ancient minicomputer sitting in a back room, feeding the newsroom’s small and much-fought-over handful of dumb terminals. When I say dumb, I mean really dumb. In a limitation that is inconceivable today, these terminals had so little memory that they could only handle a few hundred words at a time. Most Phoenix reviews were way longer than that, yet many of us composed directly on this system (who could afford one’s own PC on what that alternative paper paid its writers?).
To compose a lengthy piece you had to write a chunk (a “buffer”), then save it — sending it on a leisurely journey back to main memory — to make room on the terminal for the next installment of your opus. Unfortunately, these terminals also had a habit of crashing. Too often you’d press that “send” key only to see the screen freeze, and you’d know then that you’d just lost all your work stretching back to the last time you’d saved your work. Only sometimes pressing “save” would itself trigger the dreaded freeze — a tragic Catch-22 indeed.
As a result — in a tableau that somehow seemed to epitomize all the pain of human composition in a technological age — you might occasionally spy some desperate writer hunched over notebook and pen in front of a frozen screen, painstakingly copying the slim remnant of his verbiage that was still visible, rescuing some fragment of inspiration before the inevitable reboot wiped the words clean.
I haven’t yet seen Michel Gondry’s Be Kind Rewind, but A.O. Scott’s New York Times review made me want to:
…It treats movies as found objects, as material to be messed around with, explored and reimagined. It connects the do-it-yourself aesthetic of YouTube and other digital diversions with the older, predigital impulse to put on a show in the backyard or play your favorite band’s hits with your buddies in the garage.
And the deep charm of Mr. Gondry’s film is that it allows the audience to experience it with the same kind of casual fondness. It is propelled by neither the psychology of its characters nor the machinery of its plot, but rather by a leisurely desire to pass the time, to see what happens next, to find out what would happen if you tried to re-enact “Ghostbusters” in your neighbor’s kitchen.
I would argue that “the do-it-yourself aesthetic of YouTube and other digital diversions” and the “older, predigital impulse to put on a show” are in fact one and the same. It is this motivation that drives a great deal of the creativity on today’s Web. What’s different today is that the “backyard” theater can pack in, potentially, millions. The garage is infinite.
David Edelstein didn’t like it quite as much, but he concludes:
…it radiates the kind of optimism you don’t see in films about how new media is turning us all into passive voyeurs in our own hermetically sealed bubbles. This bubble is warm and inclusive.
OOPSLA is the ACM conference that most broadly and widely addresses the sorts of questions I tried to explore in DREAMING IN CODE. I found the two events that I’ve attended, in 2004 and 2006, both highly rewarding. I couldn’t make the 2007 edition in Montreal, but I was delighted to find this page of podcast recordings of many of the conference’s highlights.
I’ve only had time to dip my toes in this stuff so far; there are talks by David Parnas, Fred Brooks, John McCarthy, Patti Maes, Guy Steele, Richard Gabriel, Gregor Kiczales and many others.
