"It Works on My Machine": Meaning, Meme and How Teams Fix It

"It works on my machine" is what a developer says when code runs fine locally but breaks for someone else. The usual cause is a different environment: the OS, a runtime version, a missing dependency or a config file. It's also one of programming's best-loved jokes, because almost every developer has said it.

What "it works on my machine" means

On the surface, it's a status report. The code ran, the tests passed, the page loaded. On your laptop.

In practice it means something closer to "I can't reproduce your bug." The same codebase is behaving differently in two places, and nobody knows why yet. It's common enough to have its own acronym: WOMM.

It isn't always an excuse. Sometimes it's the most useful clue you have. If the code works locally and fails in CI or production, the bug probably lives in the gap between those two setups, not in the code itself.

Why it happens: five usual environment gaps

When code works locally but not elsewhere, it's almost always one of these environment discrepancies.

1. A different operating system. One developer is on a Mac, another on Windows, and the server runs Linux. File paths, line endings and case-sensitive file names all behave differently.
2. Different runtime or library versions. Your machine has one version of Node, Python or Java. The server has another. A small upgrade in a dependency can change behavior.
3. Missing environment variables. Your local .env file has the API keys and database URL. Nobody else has that file, because it isn't in version control.
4. Local changes nobody else has. A tool you installed months ago, a cached build, a branch you forgot to push. Your development setup has drifted from everyone else's.
5. Different data and services. You test against a small local database. Production has millions of rows, real users and a network in between.

One developer on r/software summed up the most common version in a single line: "He had a Mac, she had windows, cant make it any more obvious."

Where the "Works on My Machine" badge came from

Nobody can point to the first developer who said it. The phrase is older than any record we could verify, so we won't guess at a date.

The famous badge does have a clear source. On March 15, 2007, Jeff Atwood published "The 'Works on My Machine' Certification Program" on his blog, Coding Horror. He credited the idea to developer Joseph Cooney and the badge design to Jon Galloway.

The joke is a fake certification with four steps. Step one: compile your code, where "getting the latest version of any recent code changes from other developers is purely optional." The last step: check it into version control. Then, in Atwood's words, "Congratulations! You're fully certified."

The comments under that post read like the meme being born. One reader said their colleague was laminating the badge "to use as the award for developers who break the build." Others asked for stickers and T-shirts.

The meme: why developers keep sharing it

The meme works because it lands on both sides of the argument.

To testers and ops teams, it's the classic developer dodge. To developers, it's a cry for better bug reports. In a 2021 r/ProgrammerHumor thread with over 15,000 upvotes, one commenter put the developer's side plainly: "I don't say 'It works on my machine' when I'm claiming it's perfect. I'm saying if you hand the ticket back to me with little more feedback than 'it doesn't on mine', I'm going to proceed to throw random shit at the wall."

Another top reply in the same thread joked, "And that's how Docker was born." Which brings us to the fix.

How teams fix it

The goal is simple: make every machine look like the same machine. Here's how teams get there, from lightest to heaviest.

Pin your dependencies

Commit your lockfile (package-lock.json, poetry.lock, Gemfile.lock and so on). That way everyone installs the exact same versions, not "whatever was newest today." Pin your runtime version too, with a file like .nvmrc or .python-version.

Write the setup down, then script it

If getting the project running takes a page of tribal knowledge, that knowledge will drift. Put it in the README, then turn it into a single setup script. Keep a .env.example file in the repo so missing variables are obvious.

Use containers

Containers package the app together with what it needs to run. Docker's own docs describe a container as "self-contained," with "everything it needs to function with no reliance on any pre-installed dependencies on the host machine." If the app runs in the same container image on your laptop, in CI and in production, a whole class of "works locally" bugs goes away.

Use dev containers

A container for production doesn't help much if everyone still codes against their own local tools. That's what dev containers are for. The Development Container Specification is "an open specification for enriching containers with development specific content and settings." In plain terms, a devcontainer.json file in your repo describes the editor tools and settings, and the spec says the same setup can be used "as coding environments or for continuous integration and testing."

New team members open the repo and get the same development setup as everyone else on day one.

Let CI be the referee

Your laptop shouldn't be the source of truth. A clean CI build should be. If the tests pass in CI, it works. If they only pass on your machine, it doesn't yet.

Ship better bug reports

Half the WOMM arguments are really about missing information. Ask for steps to reproduce, the exact error, the full stack trace, and the OS and browser. As one r/ProgrammerHumor commenter put it: "What does it do instead of working?"

What developers say

We read through the top threads on Reddit. A few themes kept coming up.

• Containers help, but they aren't magic. "Docker works on my sysyem [sic], what do you mean it doesn't work on the clients system?" one reply joked.
• Bad bug reports cause as much pain as bad environments. In a 2024 r/ProgrammerHumor thread with over 10,000 upvotes, one developer walked through a long back-and-forth with a colleague. The full stack trace finally showed "unable to access s3 bucket: access denied." The fix was logging in from the terminal instead of the browser.
• Version mismatches are the classic cause. Another commenter described asking why someone didn't test "with the same java version, database version and connected applications as we specified." Then added: "I might be traumatized."

These are individual comments, not data. But they match the five gaps above almost exactly.

Works on my machine shirts, caps and gifts

If you've ever said it with a straight face, you might as well wear it.

• Works on My Machine Shirt: the "certified developer" classic.
• My Code Works On My Machine I Swear Shirt: for when you need everyone to know you mean it.
• Works on My Machine Pixel Cat Shirt: the same excuse, now with a cat.
• Works on My Machine Embroidered Cap: an embroidered take for standups.
• localhost vs production T-Shirt: the whole story in two words.
• Works on My Machine Custom Shirt: add your own name or team.

For more, browse our developer shirts. If you're shopping for someone else, our guide to gifts for programmers has more ideas. And if your fix for WOMM is to skip staging entirely, read I test in prod.

FAQ

What does "it works on my machine" mean?

It means code runs correctly on the developer's own computer but fails somewhere else, like a teammate's laptop, CI or production. The cause is usually a difference in environment, not in the code.

Where does "works on my machine" come from?

The phrase itself has no verified first use. The well-known badge comes from a March 15, 2007 Coding Horror post by Jeff Atwood, based on an idea by Joseph Cooney, with the badge designed by Jon Galloway.

Is "it works on my machine" an excuse or a real bug?

It can be either. Used to close a ticket, it's an excuse. Used as a clue, it tells you the bug is probably in the difference between two environments.

Does Docker solve "works on my machine"?

It solves a lot of it. Containers package the app with what it needs to run, so the same image behaves the same way across environments. It won't fix missing config, different data or a vague bug report.

How do I stop these problems on my team?

Pin dependency and runtime versions, script your setup, run the app in containers, use dev containers for development, and treat a clean CI build as the source of truth.