Geek Mythology: The Religious, and Spiritual Folklore surrounding Programming

The word of the day is religionization. According to the Merriam-Webster dictionary it means…

to make religious : imbue with religious principles : bring into conformity with religious standards : interpret or understand (a thing) from a religious framework

When I first started learning how to program I was surprised at how much religious, spiritual, and folklore surrounded it. I mean this is computers! Shouldn’t it all just be rational and logical? Turns out this isn’t the case, and some people have taken this concept to the extreme building entire Operating Systems based on their faith. Let’s look at some notable examples.

The Usenet Holy Wars ⚔️

Conceived in 1978 Usenet was the precursor to the internet. It allowed people to communicate over a distributed network of computers. Users could read and post messages on Newsgroups for a wide variety of topics. When it was first created it was only used by graduate students and academics. But as it grew in popularity more and more people used it to discuss things outside of academia, including favorite T.V shows, movies, games, and software tools. This would ultimately lead to the Usenet Holy Wars as they are now known. Emacs vs Vi/Vim, BSD vs Linux, Tabs vs Spaces, the list goes on and on. Programmers have had their preferences since the age of computing. But beyond simple preferences, there are those who elevate their personal choices to moral imperatives. When this happens, emotions run high, rationality gets left at the door, and ad hominem attacks become the norm. One of the most famous examples comes from our Favorite Finnish Flamer Linus Torvalds himself over Linux vs Minix

The connection is obvious here. Humans have been fighting over belief for as long as there have been two competing religions within close proximity of each other. It’s only natural that with wide variety of software and tools that programmers would become just as passionate. My only hope is that unlike the crusades, no blood has ever been shed over someones personal choices in software.

Mysticism 🔮

A Koan is a Zen Buddhist story, question, or dialogue that is told to provoke a deeper understanding of a subject. Many programmers count themselves as Zen Buddhists. Whether due to the stress of Silicon Valley, or the insanity that comes from trying to speak to something as unfeeling or unforgiving as a computer, that drives them to Buddhism, I’m not sure. My first experience with Koans was with Emacs Koans very early on in my programming career. My favorite one is this…

In vain does the chicken cross the road; Emacs is on both sides. – Ludovic Brenta.

Programming parlance has adopted this terminology and it goes one of two ways. Like an ancient proverb as in the above example, or as a set of small problems that allow deeper understanding of a specific programming concept. This is how the ruby koans website works, with thirty different ruby problems designed to help you practice the test driven development methodology.

Sticking with Eastern philosophy we have websites like The Tao Of Programming. With tongue and cheek snippets spread out over 9 “books” it gives insights into the act of programming. My favorite of which is…

The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.

This mystification of the way we interact with computers reminds me of the religious naturalism that is seen in the way many people react to the natural world. But the similarities don’t stop there. We have “Bibles” which are books that are considered authoritative on their subject. Many times they aren’t even referred to by their actual names but by their covers or who wrote them, as if the names themselves are sacred. Examples like “The Red Book” for the The OpenGL Programming Guide, “K&R” for The C Programming Language, “The Wizard book”, or “SCIP” for Structure and Interpretation of Computer Programs, and “The Dragon book” for Compilers: Principles, Techniques, and Tools. These books have had deep cultural impacts on the programmers that grew up reading them, and they are treated appropriately.

And it is not just books. The Lisp programming language has also taken on a mystical quality. Something not seen in other programming languages developed in that era. A famous XKCD comic describes the feeling.

Faith 🙏

Hardware and Software are complex, and whether you call the trust you put into compilers, and computers that run your code faith or something, else it’s hard to deny that at times they can appear magical. There was a time where computers were simple enough that one person could know the whole thing inside and out. That they could solder every component themselves and truly build everything from scratch. If you are Ben Eater you still can. Even though computers are complex I don't think that's an excuse not to learn more about them. I attempted this on a small scale with the Raspberry PI 4, challenging myself to understand how the hardware works on it. But even the best of us's knowledge breaks down somewhere in the computer -> hardware pipeline, and we just have to take things on faith. God knows how many millions of lines of code have to be executed from the time I press a key on my keyboard, to the time the next character appears in this web browser. It's amazing that it works at all, and I'm grateful I don't need to understand all of it for it to keep working. Sometimes when I'm coding I like to think about all the things I put my faith into.

1. That the compiler will compile my code properly
2. That the Operating System will interact with my program the way I want it to
3. That the machine code will excite the necessary transistors to do the work in the processor I need it to do
4. That turning my computer on and off just fixes things sometimes
5. That the libraries I’m using don’t have back doors that will steal all my data
6. and on and on and on

I know it’s not magic, but it certainly feels like it. And there are still things like soft errors, and a whole list of hardware errata that seeks to thwart your understanding. This is on top of our varying ability to keep large chunks of programs in our head while reading code. Sometimes the code is doing something particular complex or obtuse, and even when it's actually written by a fellow human being, it’s not always clear what exactly is going on. My favorite quote about this is…
317: /*
318: * If the new process paused because it was
319: * swapped out, set the stack level to the last call
320: * to savu(u_ssav). This means that the return
321: * which is executed immediately after the call to aretu
322: * actually returns from the last routine which did
323: * the savu.
324: *
325: * You are not expected to understand this.
326: */

Line 325 is so famous, there is an entire book whose title is this quote. Thankfully more often than not we don't need to know everything when programming. We can usually take a programming lesson from Alan Knight's quote about Object Oriented programming when working in foreign code bases.

Try not to care.
One of the great leaps in OO is to be able to answer
the question "How does this work?" with "I don’t care".

With it becoming more common for AI to write code, I fear a reality where the majority of code that is written is not by humans, and not understandable by humans. Kind of like languages that transpile to C instead of machine code first. The feeling is captured in this meme…

Folklore🪕

Finally there is a lot of folklore surrounding programming. There is literally a website called folklore which documents the stories of the development of the original Macintosh, and spins yarns of programming aptitude I will never reach. My favorite probably being the -2000 Lines Of Code
story. If you are blessed enough to be immortalized in one those stories you become one of the gods in the programming pantheon. Eric Raymond describes a few in his Why Python? blog post.

Larry Wall, its creator, is rightly considered one of the most important leaders in the Open Source community, and often ranks third behind Linus Torvalds and Richard Stallman in the current pantheon of hacker demigods.

Not everyone agrees to who belongs in the pantheon, but for them there are fictional hackers, like Mel “The Realest Programmer of them All”. Mel the programmer who chose not to have faith in compilers, and hand optimized all of his own code. Mel whose mastery of bit fiddling allowed him to achieve performance not though possible on any hardware he touched. Even today's elite programmers would bow at the feet of Mel's accomplishments. Go read the story it's definitely worth it.

Wrapping it all up 🎁

Programming is suffused with religious mysticism. Like the West African griots, we tell the stories of our history through metaphor, parables, and folklore. We ask our machine learning models questions like they are the Oracle of Delphi. We take our actual faith and ask What would Jesus do? if he were programming. We borrow terms like Daemon, we have Chief “Evangelists” who spread the good word about our programming languages and software.

One thing is clear to me, there is a lot more humanity in the field of programming than people like to let on. Our Geek Mythology is still being written, and it inspires us, makes us laugh, and motivates us to achieve greater heights in the field. As I wrap up this article I’d like to leave you with one more quote. It’s from Proverbs 16:3…

"Commit to the Lord GitHub whatever you do, and your plans will succeed."

Call To Action 📣

If you made it this far thanks for reading! If you are new welcome! I like to talk about technology, niche programming languages, AI, and low-level coding. If this interests you there's more where that came from on my Substack. I’ve recently started a Twitter and would love for you to check it out. I also have a Mastodon if that is more your jam. If you liked the article, consider liking and subscribing. And if you haven’t why not check out another article of mine! Thank you for your valuable time.