There's a wall that nobody warns you about.

You finish a Python basics course. You understand variables, loops, functions, maybe classes. You open a blank file, ready to build something real.

And nothing happens.

Not because you're bad at this. Because the jump from "I understand the concepts" to "I can build something" is itself a skill — and it's one that almost no tutorial teaches.

Tutorials teach decomposition: here is a loop, here is a function, here is a class. The implicit promise is that once you've collected enough topics, you'll be able to assemble them into something real. But assembly is a skill. And the only way to learn it is to build something that grows over a long arc, accumulates history, and fights back.

The question is: what do you build?

Not a todo list. Not a temperature converter. Something with stakes. Something where the decision you make in week two still matters in week six.

My answer: a simulation.

What Makes a Simulation Different

Most beginner projects have a simple shape: input goes in, output comes out, the program stops. A simulation has a completely different shape: it has state that persists, rules that transform that state over time, and events that keep it from being predictable.

Those three ingredients turn out to be exactly what you need to learn the things tutorials can't teach.

State is the set of values that describe your system at a given moment. A treasury balance. The condition of each building. The morale of each citizen. The day counter. Everything the simulation needs to know to continue from where it is.

Rules are the logic that transforms state over time. Each day, building condition decreases slightly. Each season, happiness shifts. Each tick, wages are paid before taxes are collected. Rules are deterministic — given the same state, they produce the same result. But they're also composable: the interaction between three simple rules can produce behaviour that wasn't written anywhere explicitly.

Events are the stochastic element that makes every run different. A fire breaks out. An investor arrives. A citizen gets promoted unexpectedly. Events prevent the simulation from settling into a predictable cycle.

Here's what that looks like in the simplest possible Python:

# State
city = {
    "treasury": 50000,
    "building_condition": 100,
    "day": 0
}

# Rules
def tick_day(city):
    city["day"] += 1
    # decay rate accelerates as condition falls — a neglected building deteriorates faster
    decay = 0.5 + (100 - city["building_condition"]) * 0.05
    city["building_condition"] -= decay
    if city["building_condition"] < 0:
        city["building_condition"] = 0
    # maintenance cost also rises as condition falls
    maintenance = (100 - city["building_condition"]) * 10
    city["treasury"] -= maintenance
    return city, maintenance, decay

# Run it — print every 5 days
print(f"{'Day':>4} | {'Condition':>9} | {'Decay':>6} | {'Daily Cost':>10} | {'Treasury':>12}")
print("-" * 58)
for i in range(60):
    city, cost, decay = tick_day(city)
    if (i + 1) % 5 == 0:
        print(f"{city['day']:>4} | {city['building_condition']:>9.1f} | {decay:>6.2f} | ${cost:>9.0f} | ${city['treasury']:>11,.0f}")

Run that and watch what happens across 60 days. On day 5 the daily maintenance cost is $28. By day 30 it's $332. By day 50 the building hits zero condition and the city is losing $1,000 every single day — bleeding $5,000 from the treasury every five days with no end in sight.

You wrote two rules. Decay accelerates as condition falls. Cost rises as condition falls. Each rule makes the other worse. That compounding interaction — not written anywhere explicitly — is the feedback loop. The treasury isn't just draining. It's accelerating toward collapse. And the city hasn't even had a bad event yet.

That emergence is the point.

The Bugs Are Different

Here's what nobody tells you about simulation bugs: they don't crash.

A bug in a normal script announces itself. The program stops, Python prints a traceback, you fix it. A simulation bug produces the wrong numbers quietly. The city runs fine. Citizens appear to be doing things. But morale is trending wrong, or the treasury is draining faster than it should, or events aren't firing at the right frequency.

To find those bugs you can't just read a traceback. You have to reason about state. What values did this function receive? What should it have returned? What rule is interacting with what other rule to produce this drift?

That reasoning — sitting with a running system and building a mental map of its behaviour — is exactly the skill that professional debugging requires. Real codebases don't crash cleanly either. They produce wrong outputs, subtle regressions, behaviour that only appears under specific conditions. The muscle you build debugging a simulation is directly transferable.

Why a City Specifically

The inspiration for the book I eventually wrote was Championship Manager — a 1990s football management simulation. You don't play a character directly. You sit one level above the action, make decisions, and watch a simulation engine translate those decisions into results over time.

Those games weren't famous for their graphics. They were famous for making you care.

You approved a new residential block in year two because the treasury looked healthy. By year four the roads serving it are at 30% condition, commute times have doubled, and three citizens are considering leaving. You don't blame bad luck. You trace the decision back.

A city has everything a good teaching simulation needs:

• Real state: population, infrastructure condition, economic health, political mood
• Real rules: maintenance costs, population growth patterns, economic feedback loops
• Real events: disasters, windfalls, elections, crises Nothing is metaphorical. It's a simplified model of actual dynamics. And every concept you encounter — object-oriented design, data structures, algorithms, testing — has an obvious real-world analogy in the city.

When you discover that a building is not just a name but a collection of named facts — condition, age, type, maintenance cost — dictionaries become natural, not abstract. When you need to track a citizen across many days, classes stop being a syntax exercise and become the obvious tool.

What Accumulation Teaches

The deepest thing a long-arc project teaches is something you can't get from isolated exercises: how systems age.

Code you write in chapter 4 is still running in chapter 14. Decisions you made early create constraints later. A function that seemed fine when it did one thing starts to resist change when you need it to do three things. You feel why small, focused functions matter — not because someone told you, but because yours got unwieldy and you had to fix it under pressure.

Consider this: in the book I wrote, there's a citizen named Tom. He's 63 when you first create him in chapter 4. By chapter 10 he retires. By chapter 12 his retirement is recorded in the City Chronicle — an append-only log of significant events. By chapter 14 a sparkline shows his morale trend across the years he worked.

Tom is not a real person. He's a named variable with richer state than most named variables. But when the simulation surfaces that another citizen, Elena, couldn't cover her rent last Tuesday, you notice in a way you wouldn't if it said "Citizen 4: rent shortfall." Names create the minimum viable fiction required for a simulation to generate the feeling of consequence.

And consequence is what makes the learning stick.

The Terminal as Canvas

One deliberate choice in the book: everything runs in the terminal. No web framework, no GUI library, no browser. Just Python and a terminal.

The terminal is universal — it runs identically on macOS, Linux, and Windows without installation beyond Python itself. But with the Rich library, it becomes genuinely expressive: colour, tables, panels, progress bars, live-updating layouts.

By chapter 8 of the book, the simulation runs inside a five-region live dashboard that updates in real time:

┌─────────────────────────────────────────────────────────────┐
│  NEW PYTHONVILLE   Day 847  |  Spring  Year 3               │
├──────────────┬──────────────┬──────────────┬────────────────┤
│  TREASURY    │  CITIZENS    │  BUILDINGS   │  EVENTS        │
│  $47,230     │  6 residents │  8 buildings │  Quiet day     │
│  ▼ trending  │  morale: 72  │  avg: 84%    │                │
├──────────────┴──────────────┴──────────────┴────────────────┤
│  CHRONICLE                                                   │
│  > Tom Wick retired after 847 days of service               │
│  > Elena Kosta promoted to Senior Engineer                  │
└─────────────────────────────────────────────────────────────┘

The terminal is also honest. There's nowhere to hide. If your dashboard renders wrong, you see it immediately. That short feedback loop between code and result is one of the most valuable things a learning environment can have.

How to Start Your Own

You don't need the book to start a simulation project. You need three things:

1. Pick a system you actually find interesting.
Cities work well. So do football leagues, ecosystems, stock markets, hospital wards, ant colonies. The subject doesn't matter. What matters is that it has things that change over time and decisions that have consequences.

2. Start with the absolute minimum viable state.
Don't design the whole thing upfront. Start with one entity, one rule, one event. Get it running. Then add one more thing. Let the architecture emerge from what the simulation needs rather than what you planned.

3. Name things.
Not entity_1 and entity_2. Names. The minimum viable fiction that makes you care about what happens. You'll debug harder, think more carefully, and learn more from a system whose inhabitants feel real.

The rest — data structures, algorithms, testing, optimisation — will arrive naturally when the simulation demands them. That's the whole point.

The Book

I spent two months building the structured version of this idea: Masters of the Metropolis, a simulation-first introduction to Python across 18 chapters. You build a city simulator from scratch — one layer at a time — until you have a live terminal dashboard, a seasonal economy, citizens with life arcs, save and load, elections, testing infrastructure, and a City Chronicle that makes every run unique.

If you've finished a Python basics course and don't know what to build next, this is that next step.

leanpub.com/metropolis — free sample available, no account needed.

What would you build a simulation of? Drop it in the comments — I'm genuinely curious what systems people find interesting.