Technical Enough

Week 1 · The Map · by Shivali

Day 7 of 21

Environments + Week 1 self-test

Of all the sentences that have been said in every engineering team meeting since the year 2000, one shows up more than any other.

"It works on my machine."

It is said with a small shrug, sometimes annoyed, sometimes baffled, almost always defensively. What it means is I ran this code, on my laptop, and it did the thing it was supposed to do. The fact that it is not doing the thing on your laptop, or on the production server, is a problem, but it is not a problem I can see from here.

Image slot

Suggested meme: the classic 'It works on my machine' trophy or sticker image (a literal trophy with that engraving), or the variant where someone is awarded a 'Works on My Machine' certification. Save as public/lessons/day-07-meme.png and add src='/lessons/day-07-meme.png'.

Every team has shipped this with a smile at some point.

The reason this sentence exists at all is the topic of Day 7. It is the topic of Day 7 because once you understand why it is so common, almost every other "why does my software behave differently in different places" question becomes answerable.

Environments, defined plainly

An environment is the specific setup where a piece of code happens to be running.

That setup includes:

  • The operating system (macOS versus Windows versus Linux).
  • The version of every tool installed (Python 3.9 versus Python 3.12).
  • The values of various configuration knobs (which database to talk to, which API keys to use, whether to send real emails or just pretend to).
  • The amount of memory and CPU available.
  • The other software running at the same time.

Two computers can have very nearly the same code on them and behave wildly differently, because their environments differ in some detail that turns out to matter. That is what it works on my machine is pointing at.

Why teams have three or four environments at minimum

Developmentyour laptopStagingpreviewProductionreal usersdeploydeploy
Same code, different setup. That's why it works here and breaks there.

Most teams of any size have at least:

  • A development environment. This is the laptop of each engineer. It is a sandbox, things break here all the time, on purpose.
  • A staging or preview environment. A copy of production that nobody outside the team can see, where new features are tested under realistic-ish conditions before they ship.
  • A production environment. The real thing, the one your users see, the one where breakage costs money and reputation.

When AI tools ask you something like should I deploy this to staging or production?, they are pointing at this distinction. Day 12 (Hosting) and Day 14 (Monitoring) will both come back to it. For now, the only thing to know is that "deploy" means "take a copy of the code from one environment and run it in another," and the order is almost always dev to staging to production.

Why environments diverge

A few common reasons.

Different versions of the same tool. Your laptop has Python 3.12, the server has Python 3.9, and one of the features you used was added in 3.11. Boom: works locally, breaks remotely.

Missing configuration. Locally, your code talks to a test database with friendly data. In production, the database is real and full of edge cases the test database never had. Boom: works locally, breaks remotely.

Hidden dependencies. Your code uses a library, but on your laptop the library was already installed for some other project last year. The production server starts from scratch and does not have that library. Boom: works locally, breaks remotely.

Each of these is a specific case of environments differing in a detail that turned out to matter, and each of them has a specific tool that exists to fix it. You do not need to know the tools yet. You need to know the shape.

Week 1 self-test

Before you move to Week 2, take five minutes and try the following. None of these have one-word answers, all of them should be one or two sentences.

  1. Pick a piece of software, and describe its three parts (Day 2): the instructions, where it runs, the input and output.
  2. Pick a different piece of software, and decide whether it is mostly local, mostly remote, or some of both (Day 3).
  3. Pick one specific action you took today on any internet-connected app, and describe its journey (Day 4): client, request, server, response.
  4. An AI tool asks you what language to use for a new web app. What do you say (Day 5)?
  5. A teammate tells you they are going to "create a branch" before trying a new design. In plain English, what are they about to do (Day 6)?
  6. A teammate says "it works on my machine." In plain English, what is the most likely reason (today's lesson)?

If you can answer all six in one or two sentences each without looking back, you have Week 1. If you stumbled on one, go re-read the relevant lesson before starting Week 2.

What's next

Week 2 opens on Day 8 with the first of the seven layers, the frontend. From here on, every lesson is going to open with the exact question an AI tool will literally ask you about that layer, and end with your answer to it. The shift from "the map" to "the layers" is the moment this course turns from vocabulary into decisions.


Day 7 wrap

The thing you can now say plainly. An environment is the specific setup where code runs, and software behaves differently in different environments because details that did not matter on your laptop turn out to matter somewhere else.

The thing you can now do. When something works in one place and not another, suspect the environment first, not the code.

The guardrail to remember. Never trust a "tested" claim that does not say which environment it was tested in.

You finished Week 1. See you in the layers.