In the late mid-90’s I was working at HotWired, an offshoot of Louis Rosetto’s WIRED magazine, itself an attempt (and a quite successful one) at documenting the “digital revolution” that was then just beginning to happen. After months of cajoling, I finally just told them to hire me, and they did. Although I had never properly learned to write code, I had taught myself enough to be able to throw some things together, and so began a span of months that I spent on a third floor in the still-nascent startup playground between South Park and the China Basin rail bridge, south of Market Street in San Francisco. In contrast to today’s lurching jam at the intersection of Third and Townsend, at that point there were empty lots in all directions where we could park freely and at will—and one small McDonalds franchise, which, if we had known better, we would have seen clearly as a harbinger what was coming our way.
Caught between a group of raver-cum-webmasters on my floor and an entirely separate clan of high-minded and much more communicative digerati upstairs, neither of which seemed like quite my crowd (a recurring theme), I mostly wrote a lot of perl, a simple, powerful programming language that powered much of the early web. The office setup that we all used there was emblematic of the early startup ethos: save some money, spend more: a desk made of an IKEA door slapped on top of two sawhorses, fronted with a brand-new Herman Miller Aeron chair. I was issued a compact IBM laptop—the worst possible machine you could imagine for writing code, its angled screen requiring a hunched-over posture matched by the cramped layout of the keyboard and the weak display. There in the dim light of what was optimistically called ”engineering“, I learned to use vi to add email addresses to our computer network, editing the aliases file directly. @wired.com was a quite the nifty handle in those days, and gifting a cleverly crafted email address to an attractive officemate was a form of casual flirtation perfectly suited to the time and place.
Early web sites were fragile things, especially when they involved a large quantity of data. This information was stored in a database, a combination of software and hardware designed for doing just that—storing data—and so you’d think, able to. The thing is, we were building web sites that created so much data so quickly that it was hard for the database to keep up. As the data poured in from all directions, the database would often get itself into a sort of gridlock. Given how the data was stored, broken down into many interconnected bits and pieces, to maintain its internal integrity the database would often have to limit itself to handling only one piece at a time, holding the huge incoming steam of other facts behind a “lock” while the software attempted to chisel just one bit onto the spinning platter of a hard drive. Issue being that if the bit being chewed on at the moment happened to be, let’s say, the billionth bit of information of a particular type (and it often was), then the file to which that bit had to be appended was very large, larger than the designers of the database had anticipated, and larger than the memory of the machine that served as its physical body. In trying to write just that one bit correctly, the database would try to first load up that huge file, holding everything else back in the meantime—and when it found itself unable to complete the loading, and therefore the writing, the entire system came to a halt in a jumbled, invisible heap of virtual locks and steams of bits strewn around the grid.
This happened quite often, and when it did, the web sites that we had built would stop working, since they all depended on real-time access to data. If the computer running the web site couldn’t get data to or from the database, well, no web site. And so it turned out that all of these beautiful and very well-considered showpieces of digital media, despite being so lovingly designed and curated by well-groomed and thoughtful adults were dependent on a very different type of person: the DBA. “Dee Bee A” stands for data base administrator, which stands for whoever is so entirely asocial as to have dedicated him or herself to the care and feeding of those agglomerations of spinning disks, blinking lights and obscure commands that stored the giga- (and soon, tera-, and peta-) bytes of information that we were collecting and creating.
Our DBA was a pale blob with rotting teeth and a totally understandable speed habit, which needless to say didn’t help with his anxious oversight of the highly complex system under his care. Both the system and its administrator were chronically on the verge of complete failure. When the database got itself into gridlock, the only thing to do was to shut everything down and try to reset the thing to a previous state from which it might be able to recover, or simply to delete a day-or-so’s worth of information. The constant breakdowns and this recurring, unresolvable dilemma made for a truly sorry mess at the desk across from mine: the sour smell of Stephen’s night sweat reaching across the aisle while he tried and tried to rebuild something meaningful from a loose pile of a trillion ones and zeroes. His work was not made any lighter by the knowledge, which we all shared, that none of the data that he was so desperately working to save meant a damn. For all the work that went into preserving all of that data, most of it would never be looked at again, and if not lost in the first place would soon be forgotten and eventually deleted with a few keystrokes, a future administrator erasing an infinity of miniature, meaningless histories in an instant.