---
title: It works on my machine. Why?
teaser: A list of things to check when something works on your computer but not on
  someone else's.
tags: debugging
author: Matheus Richard
published_on: 2024-08-15
---

We've all been here. Something works just fine on your computer but not on
someone else's. The root problem might be tricky, so I listed possible things
you can investigate. Next time it happens, you have a list of things to check.

## You have a different environment

In my experience, this is the most common reason. You have something set up
differently in your environment (i.e., computer) that makes the code work.
Here's a list of things to check, in no particular order:

- **Different execution environment:** you're running the code in
  development/debug mode, while the other person is running in
  production/release mode.
- **Different env vars:** maybe you have a different value for an environment
  variable. Check if your project `.env` files and system environment variables
  match those of the other person.
- **Your database schema is different:** your database might have different
  columns, indexes, tables, or constraints. This could be because you ran a
  migration that the other person didn't.
- **You have different data:** your database doesn't have enough records to
  trigger a particular bug, or you have a record that the other person doesn't.
  Check if you both have run the same seed files.
- **You have different dependencies:** you have a missing (or extra) system
  dependency, like `libxml2`. (Insert meme about Docker and shipping your
  computer here.)
- **Different browsers:** it's no secret that browsers behave differently. Check
  if the issue is browser-specific. [Can I Use][] and [MDN Web Docs][] are super
  helpful for this.
- **Different email clients:** very similar to the previous point. Email clients
  are known for being hard to work with. [Can I Email][] is a friend for this
  scenario.
- **Background services not running:** maybe it's your database, maybe it's
  Redis, or perhaps a background job processor like Sidekiq. This is particularly
  common if you're running your server manually with `rails s` instead of
  `bin/dev`.
- **You have cached data:** indeed one of the hardest problems in computer
  science. You have cached data in your browser, project, or package manager.
  Reloading with <kbd>Ctrl</kbd>/<kbd>Cmd</kbd> + <kbd>Shift</kbd> + <kbd>R</kbd> or running something like `rails
  tmp:clear` might just do the trick.
- **You have different cookies:** you were working on a feature in a different
  branch that changed some cookies, and now something works differently for you.
  Try clearing your cookies.
- **Different security settings:** check if you have different security
  settings. That might be in your browser configuration or extensions (like
  uBlock Origin), or in your project (like Content Security Policy), or maybe
  the non-working machine is behind a firewall or VPN.
- **CORS:** it often happens that something works in development but not in
  production because of [CORS](https://jakearchibald.com/2021/cors/).
- **You have different Docker image versions:** even you, Docker! Yes, even with
  Docker things might behave differently. For one, Docker works differently
  depending on the OS you have. That aside, you might be using `:latest` for
  your image, but you ran that a while ago and then there are new versions
  available. So you can be running under a different environment than your
  colleague.
- **Different resources available:** the non-working machine is running other
  software that is using resources (ports, processes, files) in a way that makes
  them unavailable. Looking at you, AirPlay Receiver running on port 5000.
- **Different operating systems:** there's just too much to list here. Windows,
  MacOS, iOS, Android, all the Linux distributions... They're all awesome and
  terrible in their ways. Check if the software you want to run is compatible
  with the OS you have.
- **Different computer hardware:** again, there are countless possibilities
  here, but one that has become more common is the ARM vs Intel processors. Ever
  since Apple's M1 chips dropped, this has become a more common issue. Check if
  the software you want to run is compatible with the architecture you have.

## You have different code

If your environment isn't the issue, having different code might be. Things to
check:

- **You're on a different branch:** very common and easy to overlook. This is
  sort of a catch-all for many of the other points. Your branch might be ahead
  with a bug fix or behind before a bug was introduced. Make sure you're on the
  same branch.
- **You have a modified file that you forgot to commit:** maybe you were
  splitting work into multiple PRs and forgot to commit a change. This might
  cause tests to pass on your machine but fail on CI. Another possibility is
  that you have your changes hidden by [a global .gitignore] or you used
  something like `.git/info/exclude` or [`git update-index
  --assume-unchanged`][] (Oh My ZSH has a `ghide` alias for this) to hide your
  changes locally and forgot about it.
- **You've touched a dependencies code and forgot to revert it:** I often use
  `bundle open` to open a gem's code and debug it. If you forget to revert these
  changes, you might run into trouble. Fortunately, you can run [`bundle
  pristine`] to revert them all.
- **You have updated dependencies:** maybe you're running a newer version of
  some dependency that has fixed bugs (or introduced new ones). Perhaps you
  installed them with different package managers (yarn vs manually), or the
  lockfile isn't committed, so you are running different versions. Ensure that
  your versions match those of the other person to debug this.

## Other reasons

- **Different user permissions:** if you have an authentication system based on
  user roles (say, [Auth0]), you might have different permissions than the other
  person.
- **Different feature flags:** similar to the previous point, you might have
  different flags turned on, so you have access to a feature that the other
  person doesn't.
- **You're in a different physical location:** if you and your colleague don't
    live in the same _physical_ location (region/country/continent), you might
    run into issues with time zones and language settings, for example. I've had
    to have different setup instructions for a client project because I was in
    Brazil and they were in the US.
- **Things happen too fast/too slow for you to notice the error:** you have a
  fancy new chip or a very fast fiber internet connection. That might make the
  error happen so fast (like something blinking in the UI) that you don't even
  notice it. Who would've thought that having a faster computer could be a
  problem?

## No luck?

If you've checked all of these and still can't find the issue, give a shot at
the good old <q>turn it off and on again</q>. Sometimes, simply restarting your
computer can resolve the problem. Or if your issue is that you change code but
nothing happens, check out [_Rails: When Changing Code Doesn't Change Behavior_], where I describe possible reasons
for that.

[Can I Use]: https://caniuse.com/
[MDN Web Docs]: https://developer.mozilla.org/en-US/
[Can I Email]: https://www.caniemail.com/
[`bundle pristine`]: https://bundler.io/v1.15/man/bundle-pristine.1.html
[`git update-index --assume-unchanged`]: https://git-scm.com/docs/git-update-index#Documentation/git-update-index.txt---no-assume-unchanged
[a global .gitignore]: https://sebastiandedeyne.com/setting-up-a-global-gitignore-file/
[Auth0]: https://auth0.com/
[_Rails: When Changing Code Doesn't Change Behavior_]: https://thoughtbot.com/blog/rails-when-changing-code-doesnt-change-behavior