There is a sentence in the developer world that sounds innocent but has probably caused more chaos than actual bugs.
“It works on my machine.”
Every developer has either said this sentence or heard it from someone else. Usually it happens like this: A feature is built, the developer runs it locally, everything works perfectly, and the code is pushed to the repository. Then someone else pulls the code, runs the project, and suddenly the entire system explodes.
The conversation that follows is almost always the same.
- “Hey, the app is crashing.”
- “That’s strange. It works on my machine.”
The Investigation
Now begins the investigation. Sometimes the issue is an environment mismatch. Maybe the developer who wrote the code has Node v20 installed, but the rest of the team is running Node v18. Suddenly a dependency behaves differently.
Sometimes it is something even more ridiculous. A developer might accidentally rely on a local file path that exists only on their computer. For example, imagine this code:
const config = require("/Users/xyz/Desktop/config.json");
On XYZ’s laptop, this works perfectly. On literally every other computer on Earth, this code is useless.
The Environment Variable Trap
Another classic situation involves environment variables. The code expects an API key like this:
const apiKey = process.env.API_KEY;
On the developer’s system, the environment variable is already set. On everyone else's machine, the variable is missing and the application crashes instantly.
Missing Dependencies and Secret Rituals
Then there are dependency issues. One developer installs a package but forgets to update package.json or requirements.txt. The code runs locally because the package already exists on their machine, but nobody else has it installed.
The worst cases happen when the system depends on hidden setup steps that only exist in the developer’s head.
- “Did you run the migration?”
- “What migration?”
- “Oh… right.”
This is why modern development relies heavily on tools like Docker, environment files (.env), package managers, and automated setup scripts. The goal is simple: make sure the application behaves the same everywhere.
The Gold Standard
A good project should allow someone to clone the repository and start the app with minimal steps. For example:
git clone project-repo
npm install
npm run dev
If the setup process instead looks like a secret ritual involving five manual steps, three environment tweaks, and a mysterious configuration file hidden somewhere in the system, then the project is already in trouble.
Conclusion
The sentence “It works on my machine” is dangerous because it hides the real problem. Software is not built for one computer. It must run on many different environments: teammates’ laptops, staging servers, production machines, and sometimes millions of user devices.
If the code only works in one specific setup, then the system is fragile. In reality, the correct developer mindset should be the opposite. When something works locally, the next question should be: will it work everywhere else?
The best developers are not the ones whose code runs on their own computer. They are the ones whose code runs reliably on any machine that pulls the project.
Because in the real world of software, your laptop is not the final boss. Production is.