This essay feels like two essays combined: the first about the importance of erring on the side of caution, and the second about the importance of lore in tech. Attending an engineering school managed to instill in me the former; the latter feels more and more controversial.
I was getting into programming in 1999, when this essay was first being written. At the same time, I was getting into hacker culture. My worldview was impacted heavily by lore (as filtered through Eric S. Raymond, Steven Levy, Karen Jennings, and Steven Johnson — filters I later found were slightly yet systematically warping the specifics of some of these stories, but important figures nonetheless in that they wrote these stories in a form that a kid with a library card who knows no other programmers and has unreliable internet access can absorb), and at the time many of my sources emphasized the importance of lore. I stand by that importance — I agree that our mythology teaches important lessons, and I would go further, saying that (much like bibliomancy) good mythology continues to teach lessons that it was not constructed to teach, being general enough to act as a stand-in for wide swaths of truth, with meaning unfolding as one’s experience increases.
However, I get a lot of push-back when defending the importance of this lore, from people who see it primarily as elitist gatekeeping. I can understand this take, too: particularly as someone who, were it not for a series of happy accidents, would never have stumbled upon most of this lore.
On one level, the lore is functional. Referring to common lore is important as a communication tool. Even the gatekeeping element of lore has a function: lore teaches lessons (which unfold over time), and we would like to be surrounded by people who make good decisions, so previous familiarity with a piece of lore is a good proxy for having a nuanced understanding of some of the lessons that piece of lore teaches (although there are, as in all uses of shibboleth, false negatives: people who learned the same lessons through different means, who will be unreasonably excluded).
I see a lot of the bad ideas I see in Silicon Valley’s tech sector as related to unfamiliarity with pieces of lore that people who began learning to code a few years earlier almost inevitably would have absorbed. So, I feel like pretending lore is valueless is not just stupid but dangerous, too. It’s not merely in terms of cautionary tales, but in terms of stories that poetically illustrate the ramifications of particular design decisions (such as the apocryphal story of Marvin Minsky & the checkers-playing neural net, which at first blush looks like a blanket criticism of random wiring but can be taken as an illustration of the circumstances when avoiding programmer bias makes sense), or slang that makes particular elements of a technical mechanism viscerally clear (like the use of vomit metaphors for debug prints).
I suppose the difference is one of how learning the lore is framed. I always saw it as a joyful thing: sharing stories and jokes, and exploring history — something we do as part of our own self-development but also as bonding with friends. It’s easy to see it as a set of obscure tests intended to trip up outsiders, if you already feel like you don’t belong among programmers.
I’m not sure how to fix this. Popularizing the stories (the same way ESR did) helps, but there’s a tendency to eliminate important but unmarketable items (the same way that, in the realm of urban legends, the Vanishing Hitchhiker has had endless film and TV adaptations while the less-marketable spiders-in-the-beehive-hairdo myth from the same era and area has had nearly none). For instance, SV culture buys in 100% to the (mostly nonsense) hero-myth of garage entrepreneurs but appears to forget anti-authoritarian trickster myths like The Story of Mel.