Our website uses cookies to enhance your browsing experience.
Bugs, bugs, bugs... There's so much in that word, and there are just so many of them. It's merely enough to freak anyone out or develop a phobia. And no wonder; you never know when a regular error in code will play out. In fact, the fear of the unknown and the desire to control everything are natural companions of superstitious thinking. But seriously, magic and superstitions in the 21st century? We're kidding, right? And what do these irrational beliefs have to do with programmers?
Throughout the ages, people have been turning to omens and rituals to explain the inexplicable and to find solace in the illusion of controlling an uncontrollable reality. The rise of superstitious beliefs is a side effect of our observation and ability to establish cause-and-effect relationships. It may have once been crucial for our survival as a species. However, even in the 21st century, many people still cope with their fears in ways that are not entirely rational. Once confirmed, a belief can evolve into an entrenched practice, even a ritual, no matter how far-fetched it seems at first glance.
Many of us are afraid of making mistakes, especially given the potential consequences they may entail. Paying heed to omens and superstitions may give us a sense of control over the situation. That's where many unusual beliefs and rituals originate, with some even becoming professional practices.
Indeed, there are plenty of occupation-related beliefs. Superstitions are commonly embraced in high-stakes professions. You've probably heard a lot about medical superstitions—they're widely recognized well beyond hospitals. Pilots, who also face high-risk situations, have their own superstitions, like avoiding taking pictures before flying.
However, it's not only about risky occupations. You might have also come across theatrical superstitions: some actors believe that leaving a single light burning onstage overnight—known as a ghost light—allows ghosts to perform onstage (which supposedly appeases them and prevents them from cursing the theatre). HR superstitions can involve beliefs about hiring; for example, some consider a candidate's resume with coffee stains or cookie crumbs on it a "good sign".
Although, it begs the question: do programmers have their own superstitions like others do? Well, there are definitely some key differences. Firstly, coding isn't such a risky endeavor. Then, devs don't usually lean towards magical thinking since their work requires a rational approach: testing hypotheses and solving problems using proven methods. Irrational beliefs and hoaxes don't really match the essence of their work.
It would seem that seeking real programming superstitions is an idea that fails from the start. But some developers do share their coding superstitions and rituals (though mostly in jest). Maybe it's worth taking a different perspective and looking at programming folklore as a whole? This sparked the idea of conducting a kind of "folklore fieldwork" within the development teams of the PVS-Studio office, much like folklorists explore ancient villages, gathering folk tales from their residents.
The archmage architect of the PVS-Studio C++ static analyzer helped me a lot with gathering programming sayings and folk wisdom:
The last saying gently encouraged me to continue my folklore research somewhere else...
Such proverbs are undoubtedly part of folklore, yet they do not harbor superstition, which usually aims to influence reality, either to bring about events or prevent them. Superstitions often arise from genuine fears among people, making them particularly common in various high-risk occupations. Moreover, a natural fear of the unknown is the main source of many superstitions.
Some familiar yet still mysterious aspects of programming are cloaked in eerie tales. Undefined behavior (or UB) is such a thing. While there are no creepypastas about UB like there are about sinister bugs in games, the causes and circumstances of its occurrence can sometimes seem so obscure as to border on irrational. Imagine this: a programmer meticulously adheres to all the rules of a programming language when writing a program (thus defining its behavior). Then, unexpectedly, the program produces a completely different result. Why? Who knows... The very concept of such undefined behavior can make you wonder if the machine has a mind of its own. Or maybe it's those mischievous "nasal demons" :) So, what can developers do? Cross their fingers, light a candle, and pray for the program to work as intended. Not all of the listed for sure. They can try to "define" the behavior of the program, or at least the reasons why UB occurs. To ensure you're not tackling this monster alone, you may read these articles about undefined behavior:
Another phenomenon that suggests the machine behaves as if it has its own free will is often referred to as "ghosts in the machine". This originally philosophical concept has acquired its modern meaning with the development of computers and artificial intelligence. The term is used metaphorically in the context of technology to describe unexplained failures, malfunctions, or anomalies in a system. These malfunctions seem devoid of rational explanation, as if there is some mischievous spirit at play within the technology that leads to such unexpected behavior. Who ya gonna call? Ghostbusters!
My folklore officefieldwork continued in the server room. The spirituality of this place is subtle yet tangible across all levels of existence: the air feels different, the air conditioning is running full blast, and the flickering of diodes resembles will-o'-the-wisps. A magical tambourine hanging on the wall is an essential artifact that maintains balance in this temple of technology.
An unremarkable gray box lurks in the corner of the room. I have been told it's a "sh*tcode box," much like Pandora's box, and strictly forbidden to open, especially during the pre-release week.
Good-luck charms are another recognizable element of many superstitions. The history of charms traces back through the centuries, when belief in the magical properties of objects was a fundamental aspect of everyday life. Charms embody ancient symbols that modern people still use to attract good luck and prosperity.
In our office, the concept of a lucky charm or mascot seems to have been embraced quite personally—almost everyone has one in some form or another. Moreover, charms have evolved into stuff like toys and rubber ducks.
Rubber ducks are especially common, they're brought from programming conferences.
All these little yellow ducklings in various shapes and forms are a nod to a well-known problem-solving method. The Rubber duck debugging was first mentioned in the book "The Pragmatic Programmer," written by Andrew Hunt and David Thomas. The method suggests solving a problem by first explaining it step-by-step to a rubber duck (or any other toy). The process of explaining often leads to finding the solution, as articulating your thoughts out loud helps you understand the issue better and identify errors. Although rubber ducks are best known among programmers for code debugging, this method is versatile and can help you solve many other tasks.
At first glance, the idea of talking to an inanimate object might seem absurd and even ritualistic, reminiscent of practices in ancient cultures. However, the rubber duck method is a recognized psychological problem-solving technique that effectively leverages human cognitive abilities.
Perhaps the thing is that programmers rely on practical and rational methods rather than resorting to magical rituals, isn't it? No, that's not quite right either.
A programmer from the C# analyzer development team shared a ritual handed down through generations, from team leads to developers. The murky origins of this practice and the first individuals involved remain unknown. One thing is clear: every C# developer in the company follows this custom these days. Pressing Ctrl, they steadfastly press 'C' exactly three times.
The mystery of why exactly three times and why it specifically impacts the C# team remains unsolved. Perhaps the developers prefer to keep this ritual a secret from outsiders so as not to awaken some ancient powers. The programmer who shared this ritual with me cautiously admitted that initially he noticed this habit only in his team lead, but soon began to observe it among his teammates as well. It may have spread through a joint code review. And now, as if compelled by an unseen force, his own hand stretches to press 'C' at least twice... To copy everything for sure...
A shred of common sense. The web development team revealed their inviolable rule: never deploy to production on Fridays, the 13th. Another superstition? Not that simple.
If issues come up on Friday, there'll be less time to fix them because employees leave for the weekend. The team may not be fully staffed, making it harder to address bugs promptly and increasing the risk of downtime until Monday. After all, let's not discount other human factors, such as decreased focus at the end of the week.
In internet discussions, some radical voices also advise against refactoring on Fridays, releasing fixes, and, if possible, working altogether.
The sysadmins certainly agree with it:
Read-only Fridays are not superstition, they are a Religious Observance.
"17 On the 5th day, The Great Administrator monitored all the changes They had made and knew that they were good. 18 They looked down upon them and documented all Their blessed works, and each was given over to Automation as they had need. 19 The songs of blessed scripting and tasks-schedulers rang from the firmaments, and all was as it should be. 20 For upon that 5th day, no Changes did They make."
-from The Book of Automations, Chapter 1, verses 17-20
There was also an opinion that with CI/CD pipelines, testing processes, and bug trackers in place, there's nothing wrong with deploying on Fridays, as all bugs will be caught before going into production. To play it safe with a Friday deployment, you can catch some errors with the help of static code analyzers :)
Surprisingly enough, even developers believe in superstitions related to unlucky numbers. On dev.to, a user shared their fear of the 13th line of code.
Put a line break or a comment at the 13th line of the code
It's funny how unlucky numbers do exist in code. And no, it's not 13.
Speaking of lucky charms. They may well become valuable archaeological finds or ritual artifacts for future generations.
I have a collection of weird things I find in the office, random desk toys, swag from vendors and other companies. I call it the gremlin shrine. You can appease the gremlins with offerings to the gremlin shrine.
Some superstitions concern compilers. Devs see their work as a whimsically unpredictable (and somewhat delicate) alchemical process, turning 'base' source code into 'golden' machine code.
Compile project, then compile again just to be sure.
Don't turn away from a compile:
If you walk away from a compile, it will break.
The longer the compile, the higher the probability.
Note: Browsing reddit doesn't count. :)
I knew a programmer who, if compilation error happened, immediately reran compilation to make sure this is not some random error in compiler. Only after this he looked for reasons in his code.
This one is true for many of us in one way or another. Especially as kids, when we eagerly anticipated finishing the installation of games so we could start playing as soon as possible.
Place your mouse cursor at the edge of a progress bar, just so it knows you're watching it, making sure it doesn't go backwards.
Some say just the opposite:
A watched process always fails. Just... look away.
Many share medical superstitions regarding the "Q word":
The Q word
About 2 weeks into my first ever IT job (also my current job but a level higher now) we were sitting in the office with an empty queue and silent phones. Being the naieve technician's assistant that I was, I said "huh, sure is quiet today"
What followed later that evening was a full scale POS outage for our restaurants on the busiest night of the week.
Learned my lesson there, that's for sure
In general, it's best to watch what you say:
NEVER trust someone who is confident in their fix
The more confident someone in what they fixed worked, the more likely it is to blow up in their face
Has roots in the not speaking in certainties (i.e. "This will fix the issue" vs. "This should fix it")
And don't say it will be a quick fix because that will be the ticket that will haunt you way past SLA
Here's another fairly common "ritual":
Click "Apply" before "OK." :P
A few superstitions concern certain office meals. It turns out that ordering pizza at random is not a good idea:
My company's network services people will outright revolt if pizza from a certain pizza place is brought in for a lunch meeting, because ordering from that pizza place WILL cause a massive network outage.
That goes for bagels as well.
We are not allowed bagels in our office. Every time people bring in bagels, the network goes down. Apparently our equipment is bagelphobia
Some say that coding is more productive at night than during the day. Maybe it's because bugs are asleep at night...
I don't know why, but programming at night is better than all day!
And here's a little more sysadmin wisdom for you:
When you approach a desktop to fix it as an IT person, you have to let the machine know you're not there to hurt it by gently stroking the side of the monitor to comfort it. It's suprisingly effective at fixing problems.
The results of this tiny mock research didn't surprise me. It seems developers aren't particularly keen on magic and don't engage in secret rituals for code compilation. But rituals appear to have a different, more practical sense in their world.
Professional superstitions are meant to help people cope with uncertainty and maintain control over work situations. However, nowadays, there are much more reliable ways to protect yourself, at least from errors in code. Application of code testing tools is a great way to boost your code's reliability.
Have you come across any funny superstitions or odd rituals at your workplace? What if some of them proved useful and became a practice? Share your thoughts in the comments! :)
0
0
0
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
35
0
0