Physics in Code #1: Schrödinger's Cat and "It Works on My Machine"

Karine Babajanyan — Thu, 12 Nov 2026 13:38:02 +0000

"But it works on my machine!"

Every developer has said this at least once. 😄 I think physics can explain it.

There is a phrase I really like, from my C++ lecturer at university:

Programming is the interpretation of our daily life in a programming language.

Our daily life follows the laws of physics. So physics and programming both describe the same real world, and we can compare them. This is the first post in a series. In each post, I take one idea from physics and connect it to one lesson from programming.

The physics: a cat in a box

In 1935, the physicist Erwin Schrödinger described a thought experiment. A cat is in a closed box with a mechanism that may kill it, or may not. Until someone opens the box, we can't know what happened. In a way, the cat is alive and dead at the same time.

Only when we look inside the box do we get one clear answer: alive or dead.

Fun fact: Schrödinger didn't really think cats work like this. He wanted to show how strange quantum ideas sound when we use them for everyday things. But in software, this strange situation is very real.

The programming: code in a box

You write a new feature. The tests pass on your laptop. You are sure it works.

Then the code goes to the server, to staging, or to a teammate's laptop, and it breaks.

Until code runs in its real environment, it is like the cat: working and broken at the same time. We only find out when we "open the box", when we run it in the place where it really lives.

Why does this happen? Because the result depends not only on the code, but also on the environment:

different OS, Node.js, or library versions
missing config or environment variables
different data, timezone, or language settings
network access and permissions that you don't have on your laptop

A simple example: a missing environment variable

The app reads the API address from a .env file:

function getUsersUrl() {
  return `${process.env.API_URL}/users`;       
}

The same code gives different results on two machines:

Machine	Result
My laptop (has `.env`)	`https://api.myshop.com/users` 🐱 alive
Server (no `.env`)	`undefined/users` 💀 dead

The server has no .env file, so API_URL is undefined. Nothing crashes. The app just calls the wrong address without any error, and we find out later, maybe from a user.

The fix: open the box early

First, check the variable. If it is missing, stop with a clear message:

function getUsersUrl() {
  if (!process.env.API_URL) {
    throw new Error("API_URL is not set. Add it to your .env file.");
  }
  return `${process.env.API_URL}/users`;
}

Now we see the problem on the server right away:

Error: API_URL is not set. Add it to your .env file.

The developer finds the "dead cat" on the first run, not the customer.

In a real project, it is even better to check all the variables once, when the app starts. Also, keep a .env.example file in the repository, so everyone knows which variables the app needs.

More ways to open the box early

Docker: dev and production use the same image, so the environment is the same.
Lock files: commit package-lock.json, so everyone installs the same library versions.
Check config at startup: stop early with a clear message, like in the example.
CI similar to production: run your tests in an environment that looks like the real one.
Real test data: test with real cases, not only the easy ones.

Sometimes the box is production itself. That's why good logs and monitoring are important. They let you look inside the box without breaking anything.

Try it yourself

The example code is on GitHub: physics-in-code (folder 01-schrodingers-cat).

Takeaway

"It works on my machine" is true. It just means you have opened only one box.

Make the environment a part of your code: know what your code needs, check it early, and stop with a clear message if something is missing.

Have you ever had a "Schrödinger bug", a bug that appeared only after you opened the box? Tell me in the comments.

Next in the series: Inertia and legacy code.

DEV Community: Karine Babajanyan