Quote of the Day

I’ll use dirty tricks [in coding] for two reasons. One is if it’s really going to give me a performance improvement and my application is one that the performance improvement is going to be appreciated. Or sometimes I’ll say, “This is tricky; I couldn’t resist being tricky today because it’s so cute.” So just for pure pleasure. In any case, I document it; I don’t just put it in there.

—Donald Knuth, to Peter Seibel in Coders at Work

Coding by divine inspiration

When you have to fix a bug in a program you never, ever fix the bug in the place where you find it. My rule is, “If you knew then what you know now about the fact that this piece of code is broken, how would you have organized this piece of the routine?” What were you thinking about wrong before? Fix the code so that can’t happen. When you finish with a routine I want every routine you work on to look as if it was just written. I do not want to see any evidence of afterthoughts or things gone wrong followed by something to correct the error or a mysterious piece of code saying, “This routine returns the wrong value every now and then so I’ve got to fix it.” I don’t want to see any of that. I want to see code that looks like through some divine inspiration you got it exactly right the first time.

—Bernie Cosell, to Peter Seibel in Coders at Work

The Valley of Lost Things

Patti Smith once lost her favorite coat. As the singer-songwriter relates in her memoir M Train, it was an old black coat that had been given to her by a friend, off his own back, as a present on her fifty-seventh birthday. It was worn and riddled with holes, but whenever she put it on, she felt like herself. Then she began wearing another coat during a particularly cold winter, and the other one went missing forever:

I called out but heard nothing; crisscrossing wavelengths obscured any hope of feeling out its whereabouts. That’s the way it is sometimes with the hearing and the calling. Abraham heard the demanding call of the Lord. Jane Eyre heard the beseeching cries of Mr. Rochester. But I was deaf to my coat. Most likely it had been carelessly flung on a mound with wheels rolling far away toward the Valley of the Lost.

The Valley of the Lost, as Smith explains, is the “half-dimensional place where things just disappear,” where she imagines her coat “on a random mound being picked over by desperate urchins.” Smith concludes: “The valley is softer, more silent than purgatory, a kind of benevolent holding center.” It’s an image that first appears in Dot and Tot of Merryland by L. Frank Baum, who describes the Valley of Lost Things as “covered with thousands and thousands of pins…A great pyramid of thimbles, of all sizes and made of many different materials. Further on were piles of buttons, of all shapes and colors imaginable, and there were also vast collections of hairpins, rings, and many sorts of jewelry…A mammoth heap of lead pencils, some short and stubby and worn, and others long and almost new.”

I encountered the story of the black coat in the recent wonderful essay “When Things Go Missing” by Kathryn Schulz in The New Yorker, in which she, like Smith, uses the disappearance of physical objects as an entry point for exploring other kinds of loss. After a very funny opening in which she discusses a short period in which she lost her car keys, her wallet, and her friend’s pickup truck, she provides a roundup of the extant advice on finding lost items, including the “suspect” rule that states that most objects are less than two feet from where you think you left them. As it happens, I’m familiar with that rule, which appears in How to Find Lost Objects by Professor Solomon, which I’ve quoted here before. Personally, I like his idea of the Eureka Zone, the eighteen-inch radius that he recommends we measure with a ruler and then explore meticulously. It’s a codification of the practical insight that our mistakes rarely travel far from their point of origin. Joe Armstrong, the creator of the programming language Erlang, makes a similar point in the book Coders at Work:

Then there’s—I don’t know if I read it somewhere or if I invented it myself—Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place where you last changed the program…It’s the same everywhere. You fix your car and it goes wrong—it’s the last thing you did. You changed something—you just have to remember what it was. It’s true with everything.

By this logic, the Valley of Lost Things is all around us, and we’re wandering through it with various degrees of incomprehension. As Daniel Boone is supposed to have said: “I have never been lost, but I will admit to being confused for several weeks.”

I’ve been thinking of the loss and retrieval of objects a lot recently, in my unexpected role as biographer and amateur archivist. When I began my research for Astounding, I had to start by recovering countless scraps of information that must once have seemed obvious. Even something as basic as the number and names of John W. Campbell’s children turned out to be hard to verify, and there are equally immense facts, like how he met his first wife, that seem to have vanished into the Valley of Lost Things forever. (Not even his own daughter knows the answer to that last one.) I also have thousands of seemingly minor details that I hope to assemble into some kind of portrait, and they’re vulnerable to loss as well. I’ve spoken before about the challenge of keeping my notes straight, and how I’ve basically resorted to throwing everything into four huge text files and trusting in its searchability. Mostly, it works, but sometimes it doesn’t. During the editing process for my Longreads article on L. Ron Hubbard, a very diligent fact checker sent me questions about more than fifty individual statements, for which I had to dig up citations or revise the language for accuracy. I was able to find just about everything he mentioned, but one detail—about Hubbard’s hair, of all things—was frustratingly elusive, and it had to come out. Similarly, as I work on the book, I’ll occasionally come across a statement in my notes that I can’t find in my sources, and I have no idea where it came from. This has only happened once or twice, but whenever it does, it feels as if I’ve carelessly let something slip back into the Valley of the Lost, and I’ve let my subject down.

But as Proust knew, it’s in the search for lost things, however trivial, that we also find deeper meaning. As a biographer, I’m haunted by Borges’s devastating putdown: “One life of Poe consists of seven hundred octavo pages; the author, fascinated by changes of residence, barely manages one parenthesis for the Maelstrom or the cosmogony of ‘Eureka.’” I’ve often found myself obsessed by exactly those “changes of residence,” but it’s only in the accumulation of such material that the big picture starts to emerge, and the search often means more than the goal. If there’s one thing I’ve learned along the way, it’s that a dead end almost always turns into a doorway. Whenever I’ve had to deal with a frustrating absence of of information, it invariably becomes a blessing, because it forces me to talk to real people and leave my comfort zone to find what I need, which never would have happened if it had been there for the taking. The most beautiful description I’ve found of the Valley of Lost Objects is in The Book of the Damned by Charles Fort, who calls it the Super-Sargasso Sea:

Derelicts, rubbish, old cargoes from interplanetary wrecks; things cast out into what is called space by convulsions of other planets, things from the times of the Alexanders, Caesars and Napoleons of Mars and Jupiter and Neptune; things raised by this earth’s cyclones: horses and barns and elephants and flies and dodoes, moas, and pterodactyls; leaves from modern trees and leaves of the Carboniferous era—all, however, tending to disintegrate into homogeneous-looking muds or dusts, red or black or yellow—treasure-troves for the paleontologists and for the archaeologists—accumulations of centuries—cyclones of Egypt, Greece, and Assyria—fishes dried and hard, there a short time: others there long enough to putrefy.

As Baum notes, however, it’s mostly pins. The paleontologists, archeologists, and biographers comb through it, like “desperate urchins,” and pins are usually all we find. But occasionally there’s a jewel. Or even a beloved coat.

Quote of the Day

I think one of the most important things, for me anyway, when building something from the ground up…is, as quickly as possible, getting the program to a state that you, the programmer, can use it. Even a little bit. Because that tells you where to go next in a really visceral way.

—Jamie Zawinski, to Peter Seibel in Coders at Work

Joe Armstrong’s Law of Debugging

Then there’s—I don’t know if I read it somewhere or if I invented it myself—Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place where you last changed the program. When I worked at the Swedish Space Corporation my boss was a hardware guy. We were up at Esrange, the rocket-launching site and satellite-tracking station in the north. And one time he was banging his head, debugging some bug in the hardware, plugging in oscilloscopes, and changing things. And I said, “Oh, can I help?” And he said, “No Joe, you can’t help here—this is hardware.” And I said, “Yeah, but it must be like software—the bug will be pretty near the last change you made to the hardware.” And he went, “I changed a capacitor. You’re a genius!” He’d replaced one capacitor with a bigger capacitor and he unsoldered it and put the original one back and it worked. It’s the same everywhere. You fix your car and it goes wrong—it’s the last thing you did. You changed something—you just have to remember what it was. It’s true with everything.

—Joe Armstrong, developer of Erlang, in Coders at Work by Peter Seibel