Why “It Works on My Laptop” Is a Real Engineering Problem

“It works on my Laptop” is not a joke.

It is a symptom of poor engineering practices and costs time, money, and trust. Imagine this: it's 2.00 AM before a final group project submission. You have been coding on Windows, and your teammate is on a Mac. You merge the code, run the final build, and crash. A library is missing. A path is wrong. The stakes are high; grades are on the line, and you could lose a potential internship because the code did not run when it mattered most. On VIVA day, while the lecturer watches, you utter the most infamous phrase in software history:

“But it worked fine on my machine last night.”

Your grades take a hit, but more importantly, you lose credibility.

The situation students face

In university, we often see programming as a solitary act of writing in an editor. In a group, this leads to chaos. Everyone sets up their project differently. One student uses Python 3.8, another uses 3.11. One installs libraries globally, another uses a virtual environment. When things break, we treat it as a personal machine issue and blame “your laptop”, “your Windows installation”, or “your messy setup”.

Why this happens

To understand why this happens, you need to understand Environment Drift. Code does not exist in a vacuum. Software depends on the Runtime (Node.js or Python version), OS Level libraries (C compilers, image tools), and System Configurations (environment variables, file paths). When you send your code to a friend, you send the instructions but not the context needed to run them. If their “soil” (environment) is different from yours, the “plant” (code) will grow differently.

Key Takeaway: If software only works in one environment, it is unreliable.

The solution Pattern

To fix this, we need to change how we ship code. We stop sending just the source code and start including the environment as well. The solution is simple: package the application with the specific libraries, configurations, and runtime it needs so it behaves the same everywhere. You can do this through:

• Virtual Environments: Isolating language dependencies.

• CI Pipelines: Automating tests in a neutral environment.

• Containers: Packaging the entire OS context.

While tools like Docker are the industry standard, the concept matters first. If you are just starting out, begin with options like virtual environments or simple scripts. These let you isolate dependencies without the complexity of learning Docker right away. This gradual approach builds your foundation before moving to advanced tools.

Consistency must be engineered, not hoped for

The Role of Containers (A High-Level View)

This is where technologies like Docker come in. Think of a container as a standardized box. Inside, you put your code, your specific Python version, your exact library versions, and the parts of the Operating System your app needs. When you give that container to your teammate, they are not running your code on their OS. They are running the container. Because the container's interior matches yours, the ambiguity disappears. If it runs in the container on your laptop, it will run in theirs.

Student-Relevant Takeaways

You do not need to master Kubernetes overnight to stop the “works on my machine” cycle. Start here:

1. Stop sharing ZIP files. Use version control tools such as Git and GitHub. These platforms offer robust solutions for tracking changes, collaborating with teammates, and managing different versions of your project.

2. Stop “setup by memory.” If you have to type a command to make it work, write it down.

3. Document your environment: a requirements.txt or package.json is mandatory. To create a requirements.txt file in a Python project, run the commandpip freeze > requirements.txt in your terminal. This will take a snapshot of all the installed packages and their respective versions. For a package.json file in a Node.js project, you can initialize it by running `npm init` and then manage dependencies using commands like npm install <package-name>, which will automatically add them to the package.json.

4. Treat setup as part of the project. The code that installs your app is as necessary as the app itself.

What comes next?

“It works on my laptop” is not a failure of effort; it’s a failure of process. And this is the first student problem that the industry has already solved.

In the following article in the series, I’ll explain how dependency conflicts silently break up group projects and why this keeps happening in universities.