But It Works on My Machine🤔

There is a sentence almost every developer eventually says:

“But it works on my machine.”

You run your application. Everything looks fine. The buttons work, the server starts, the database connects, and you are feeling pretty confident.

Then someone else runs the exact same project.

It breaks.

Suddenly, you are staring at the same code wondering how two computers managed to disagree.

The funny part is that the code might actually be the same.

So what changed?

The code is not the whole environment

When we think about running a program, it is easy to imagine something simple:

Code → Run → Application

In reality, there is a lot happening underneath.

Your application is running inside an environment. That environment includes the operating system, programming language version, installed dependencies, environment variables, file structure, permissions, databases, ports, and other configuration.

So two people can have the same repository but still have different environments.

For example, maybe I am running Go 1.26 while someone else has an older version.

The code hasn't changed.

The environment has.

And sometimes, that's enough to cause a problem.

“But it works here” might mean “my computer has something yours doesn't”

Imagine cloning a project and running it for the first time.

You type:

go run .

It works perfectly.

Your friend does the same thing and gets an error.

One possibility is dependencies.

Your machine may already have certain tools, packages, or configuration available. Their machine might not.

This is one reason projects usually have ways of declaring their dependencies and required versions. The goal is to make the environment less of a mystery.

But dependencies aren't the only problem.

Then there are environment variables

This one can be especially sneaky.

Your application might need something like:

DATABASE_URL
SECRET_KEY
API_KEY

Those values may exist on your machine but not in the repository.

So when you run the application, everything works.

Someone else clones the repository and gets:

“Why can't the application connect to the database?”

Because your computer knows something theirs doesn't.

This is also why configuration and secrets are normally kept separate from the actual source code.

The application isn't necessarily broken.

It just doesn't have the information it expects.

Your database isn't necessarily their database

Here's another classic.

You have been developing locally for weeks.

Your database contains users, groups, test accounts, transactions, and whatever else you've created while testing.

Then someone else runs the project.

Their database is empty.

The application technically works.

It just doesn't behave the same way.

This is an important distinction:

Running the same code does not mean running against the same data.

That can make debugging surprisingly confusing.

“Localhost” is not the same everywhere

There are also smaller differences that can cause surprisingly large problems.

Your application might be running on:

localhost:8080

But what if another application is already using port 8080 on someone else's machine?

The code is fine.

The port is the problem.

File paths can cause similar issues.

A path that works perfectly on Linux may not behave the same way on Windows because operating systems handle paths differently.

Even permissions can get involved.

Your machine might allow an application to read or write a particular file while another machine refuses.

Suddenly:

“But it works on my machine.”

isn't a joke anymore.

It is a clue.

So how do developers make environments more predictable?

The goal isn't to make every computer identical.

That would be difficult.

Instead, developers try to make the important parts of the environment explicit and reproducible.

That can mean documenting the required language version, declaring dependencies, providing configuration examples, using consistent database setup instructions, or using tools such as containers.

This is one reason Docker is so popular.

Instead of telling everyone:

“Install this, then this, then configure that, and hopefully it works…”

you can package much of the application's environment into a container.

It doesn't magically solve every problem, but it reduces the number of differences you have to worry about.

The bigger lesson

One thing I'm learning as I spend more time building software is that writing code is only part of making software work.

The environment around that code matters too.

When something works on one machine but fails on another, the first instinct might be to stare at the code and look for a bug.

Sometimes that's exactly what you should do.

But sometimes the better question is:

“What is different between these two environments?”

Different versions?

Different dependencies?

Different configuration?

Different data?

Different permissions?

Different operating systems?

Once you start asking those questions, the mysterious error becomes a little less mysterious.

So the next time a project refuses to cooperate on another computer, don't immediately blame the code.

Maybe it really isn't the code.

Maybe...

it just works on your machine.