Project Roadmap
One Project, Many Milestones
The study log project is one application that grows over the whole course. You do not create a new project in each part. Instead, you keep extending the same project until it becomes the final version.
Each part adds one bounded capability, so the project grows without becoming too large to understand.
The course also uses small, focused examples in the regular chapters to study programming ideas directly. This page is only about the project side. Its purpose is to show how the study log grows across the course.
What the Study Log Is
The study log is a small application that records study sessions. The idea is straightforward: you log what you studied and for how long, and the program does increasingly useful things with that information as the course goes on.
In its first version, the program asks for one session, prints a personalized response, and exits. By the end of the course, it accepts many sessions across many runs, stores them in a file, summarizes them with pandas, and produces charts that answer real questions about your own study habits.
How the Project Grows
A short summary of the project at each part:
| Part | What the study log does |
|---|---|
| 1 | Asks the user one entry at a time and prints a personalized response. |
| 2 | Handles many entries in a single session and reacts to what the user enters. |
| 3 | Is reorganized into a small set of functions you can test, with input validation. |
| 4 | Saves entries to a file on your own computer so they survive between runs. |
| 5 | Computes summaries like totals, averages, and streaks. |
| 6 | Models entries as structured data and switches its storage to JSON. |
| 7 | Reproduces its summaries with pandas. |
| 8 | Produces a few charts answering different questions about your data. |
| 9 | Is reviewed end to end: what you would write differently now, and what to keep. |
The detailed instructions for each part live in that part’s project checkpoint chapter. This roadmap is only an overview.
You are not committing to filling every row of this table at the start. You are committing to the first row. The shape of the project is mapped out so you can see where it is going, but the only thing you need to build at any given moment is the next row.
Local Workflow from Part 4 Onward
For Parts 1 to 3, the project runs in the sandbox. There is no local workflow to worry about.
Starting in Part 4, a typical local development cycle looks like this:
- open a terminal in the project folder,
- run the project (for example,
python main.py), - make a change to a file,
- run again,
- and verify the effect, both in what the program prints and — when files become involved — in the contents of the data file.
You will get more comfortable with this rhythm as you go.
A Useful Habit Throughout the Project
At the start of each new part, ask:
- What already works?
- What is the one new capability for this part?
- How will I know that the capability works?
That small checkpoint makes the project much easier to manage over the whole course. It also helps separate the refactor of existing code from the addition of new behavior, which is a habit that becomes increasingly useful from Part 3 onward.