How This Course Works
One lending shelf, built piece by piece
You do not study eleven separate subjects. You build one thing, the records program for Booknook, the lending shelf in a made-up café called Kettle and Page, and every module adds a part to it. The same 24 books, 6 members and 40 loans run through the whole course, so you never spend time learning a new example: all your attention goes on the Python. By the end you have one small repository you can show someone and explain line by line.
The shelf, its people, its rules and its dates are described in 03-the-booknook-project.md. It is fictional; the real cases that open each lesson are not.
You can start from nothing
You do not need to have written any code before. You need to be able to use a web browser, type, and copy and paste. Every new word is explained the first time it appears, and every symbol in the code (a bracket, a colon, an equals sign) is explained the first time it is used. If you already know some Python, each module's README says what it expects you to know, so you can skip what you have.
Pictures first
Every lesson is a walk through one example, one picture at a time. A figure shows an idea; a short paragraph says what the figure shows in plain words; a short block of code proves it; a walkthrough explains every line of that code. Then the next figure. A lesson has fifteen to thirty figures and takes thirty to forty-five minutes to read properly, longer if you try every block, which you should.
The same colours mean the same things in every figure:
| Colour | Means |
|---|---|
| Blue | Your code, the normal path, a block of indented code |
| Amber | Anything uncertain: messy input, a value that might be wrong, something to watch |
| Green | Correct, safe, passed |
| Red | An error, a bug, a failure |
| Grey | Optional, background, ignored |
The shape of every lesson
| Part | What happens | Why it is there |
|---|---|---|
| The situation | Something Amira needs from the shelf, with named people | You learn the idea because you need it |
| A real case, first | Something that really happened, or a page of Python's own documentation, from a published source, cited | So you know the idea matters outside a course |
| The idea | Figures and short paragraphs, one running example throughout | The picture comes before the vocabulary |
| Run it | A short piece of code, pasted into Colab, with a code walkthrough | You see it work, and you understand every line |
| Break it | You make it fail on purpose and read the error | Errors are normal; meeting them here first makes them less frightening later |
| In production | How working programmers use the idea | The part most beginner courses leave out |
| Check yourself | Three to five questions, answers hidden until you click | You find out whether it stuck |
| Exercise | One task with a way to check it | You do it, not just read it |
| Key terms and sources | A short glossary and the sources the lesson used | So you can go further |
In Modules 1 to 5 an exercise is checked by comparing what your code prints with the expected output given in the lesson. From Module 6 every exercise comes with a check cell of assert lines that stays silent when your answer is right and stops with an error when it is not.
Three depths of topic
Not every topic deserves the same attention. Each one is marked in its heading:
| Mark | Meaning | What you get |
|---|---|---|
| (Essential) | You need it to write Python at all | Figures, code and a "break it" step |
| (Recommended) | Skip it only if you have a reason | A figure and a short section, often with code |
| (Optional) | Knowing it exists is enough | A short card: what it is, when you would need it |
If you are short of time, do the Essential sections of every module first and come back for the rest. Most of the Recommended and Optional topics are in Modules 9 and 10.
What every module contains
| File | What it is |
|---|---|
README.md | What the module is for, what you need to know first, the lesson list |
| Numbered lessons | One file per group of topics |
...-module-lab.md | A guided build that adds this module's piece to the shelf |
...-incident-file.md | A real, published failure caused by the kind of mistake the module teaches you to avoid, then the same mistake made at Booknook and fixed |
Module 11 is the capstone: one lab that turns everything into a command-line tool, and its incident file.
How to run the code
All code runs in Google Colab, a free website that runs Python in your browser. Open a new notebook, paste each code block into a cell in order, and run it. Nothing needs installing. The course never calls a language model or any paid service, so there are no keys and no costs. How to open Colab, run a cell, and what the few notebook commands do: 02-setup-colab.md.
The code uses only Python itself and the standard library, the modules that come with every Python. The one exception is pytest, the testing tool in Module 10, which you install with one line.
Modules 1 to 6 are self-contained: every lesson writes the data it needs in its own cells. From Module 7, lessons build on files written earlier, so each one starts with a short catch-up cell that writes those files again. If Colab has reset, or you jump in at Module 9, the catch-up cell puts you where the lesson expects you to be.
Some things in the course happen outside a notebook: the Python prompt in a terminal, activating a virtual environment, running a script from the command line. Those are on one page, 07-run-locally.md, which shows how to install Python 3.12 and a code editor on your own computer. Lessons that point to it say plainly which steps were not run in Colab.
Every output is real
Every output printed in a lesson came from running that lesson's code, on Python 3.12, the version Colab uses. There are no hand-written "example outputs". Your output should match exactly, character for character. If it does not, something is different, and finding out what is exactly the skill the course teaches: read the last line of the error first, then compare your code with the lesson's one line at a time.
The one place your output may differ is anything that depends on the computer's clock or on chance. The course avoids both: "today" is always passed in as Wednesday 14 October 2026, and random numbers in Module 7 use a fixed seed, so the same "random" numbers come out every time.
Two habits from the first lesson
- Errors are normal. Professional programmers see error messages all day. An error is Python telling you, quite precisely, what it could not do. Read the last line first.
- Small steps. Run your code after every few lines, not after fifty. When something breaks, you then know it was in the last few lines you wrote.