We like to think of ourselves as people of logic. We work with machines that do exactly what they're told. We believe in evidence, reproducible steps and root causes.

And yet. Ask a room of developers to deploy at 4:55 on a Friday and watch the faces. Somewhere deep down, every one of us carries a small collection of rituals we can't fully defend but would never dare to skip.

Here are the ones I recognise, in myself and in every team I've worked with. The fun part is that almost all of them are secretly good engineering wearing a costume.

1. Never deploy on a Friday

The ritual: the deploy is ready on Friday afternoon. It waits until Monday, like a guest who arrived too early.

Why it secretly works: problems need people to notice and fix them, and on Friday evening those people are leaving. The real rule isn't about the day. It's "don't release when nobody will be watching for the next few hours." Teams with good monitoring, feature flags and one-click rollback can deploy on Friday without fear. Teams without them have invented a superstition to protect themselves, and honestly, fair enough.

2. Have you tried turning it off and on again?

The ritual: restart the server, the queue worker, the Docker container, the laptop, the router. Then, if needed, restart them in a different order.

Why it secretly works: a restart clears memory leaks, stale connections, stuck locks and cached state all at once. Annoyingly, it often works. The problem is that it also wipes the evidence. If a restart fixes it, ask why. Something was accumulating, and it will accumulate again.

3. If it works, don't touch it

The ritual: there's a file in the codebase that everyone walks around carefully, like a sleeping dog. Nobody remembers who wrote it. Everybody remembers what happened the last time someone "tidied" it.

Why it secretly works: code without tests is code whose behaviour nobody can prove. The fear is rational. The fix isn't courage, it's characterisation tests: pin down what the code does today, then change it with a safety net.

4. It's always DNS

The ritual: something on the network is broken. Before checking anything else, a senior developer sighs and says "it's DNS." It is, worryingly often, DNS.

Why it secretly works: DNS sits underneath almost everything, it's cached in several layers, and changes take time to spread. When a problem is weird and intermittent, a caching layer is a smart first suspect.

5. Do not say the Q word

The ritual: on call, nobody says "it's quiet today." Saying it out loud is how you summon the 3 a.m. alert. The same applies to "this should be a quick one."

Why it secretly works: it doesn't, obviously. But "this should be quick" is the most reliably wrong estimate in our industry, so treating it as a curse at least keeps us humble when planning.

6. Run the failing test again

The ritual: CI is red. You don't read the error. You press "re-run" and hold your breath. It goes green. You merge, quickly, before it changes its mind.

Why it secretly works: it doesn't work. It postpones. A test that passes on the second try is a flaky test, and it's usually flaky for a reason: time zones, test order, shared state, a race condition. Sometimes that race condition is in your real code, not the test.

7. The bug vanishes when someone watches

The ritual: you've been stuck for an hour. You call a colleague over, start explaining, and halfway through your own sentence you see the problem. They didn't say a word.

Why it secretly works: this one has a real name: rubber duck debugging. Explaining forces you to state your assumptions, and the wrong one stands out the moment you say it out loud. No colleague? A rubber duck, a notes file, or an AI chat works surprisingly well too.

8. The sacred comment

The ritual: a line in the code reads // DO NOT REMOVE. Breaks checkout. No explanation, no ticket, no name. Nobody removes it. Nobody ever will.

Why it secretly works: someone learned something painful and left a warning. They just forgot to leave the lesson. A good comment says why: what breaks, and under what condition.

9. Clear every cache in existence

The ritual: php artisan optimize:clear, composer dump-autoload, delete node_modules, hard refresh, clear the browser cache, and finally the incognito window, just to be sure.

Why it secretly works: stale caches really do cause "impossible" bugs. The better habit is knowing which cache holds what, so you clear the right one and learn something instead of carpet-bombing.

Friday deploys become boring when rollback is one click. "Don't touch it" becomes "go ahead" when there's a test suite. And "it's DNS" becomes a five-second check instead of a guess.

The rubber duck can stay, though. The rubber duck has earned its place.

Which developer superstition do you secretly follow, even though you know better?