How You Will Learn¶
This page explains how the course is built and how to work through it without a teacher standing beside you. It is worth ten minutes before Module 1, and worth re-reading whenever you suspect you are reading rather than learning.
Because that is the central risk of self-study. Reading a page of correct C++ produces a feeling of understanding, and that feeling is not evidence of anything. The course is designed around the opposite: you predict, you run, you explain — and then you know whether you actually understood, while there is still time to fix it.
Two things are fixed for all sixteen modules: the sections, and the order of the sections. A student who is lost navigates by that order.
On this page: The eight levels · The loop · The seven steps · What a module contains · Where each level is asked of you · Checking yourself · When you are stuck
The eight levels¶
Not every task asks the same thing of you. Copying an example and designing a system are both "learning C++", and they are not remotely the same skill. So every objective, exercise, lab and challenge in this course is tagged with the level of thinking it demands, from 1 to 8.
| Level | Name | What you do | What counts as evidence | What does not count |
|---|---|---|---|---|
| 1 | Understand | Explain the idea in your own words; predict what given code will do | A prediction that is right, with a reason that is right | Reciting a definition |
| 2 | Apply | Use the idea correctly in a small program you wrote from a blank file | It compiles, behaves as specified, no warnings | Code that works by accident because you copied a pattern |
| 3 | Modify | Change existing code and predict the effect; repair code that is broken | A correct prediction of a change, and a correct repair | Editing at random until it builds |
| 4 | Analyze | Explain why a program behaves as it does; find the cause of a bug; compare two implementations | A correct causal explanation, and a cause you located | Describing symptoms instead of causes |
| 5 | Design | Choose between alternatives and justify the choice; plan before coding | A decision with a stated trade-off | Choosing by preference and calling it design |
| 6 | Build | Assemble a multi-part program that meets stated requirements, including failure cases | A working program whose parts you can each explain | A program that works that you cannot explain |
| 7 | Refactor | Improve a working program's structure without changing what it does | Before/after code with unchanged behaviour | Rewriting from scratch and calling it refactoring |
| 8 | Evaluate | Judge a design against criteria; say what you would reverse, and why | A written judgement that names a real cost and a real alternative | Listing buzzwords |
You will meet these tags everywhere: on objectives, exercises, challenge problems and lab checklists. They are there so that you always know what kind of effort a task is asking for. Level 2 is not harder than level 4; it is a different job.
Level 8 comes last on purpose. In most study frameworks, evaluate comes before create. Here, building comes first, then refactoring, then judging. The reason is practical: you cannot judge a design before you have built one. Costs are invisible until the code exists, and a judgement made without costs is just an opinion. So you build, you improve what you built, and then you say what is wrong with it — which is exactly the order working programmers operate in.
The loop at the centre of the course¶
Every program in this course — every example, every lab, every debugging walkthrough — is meant to be met in the same five moves:
- Predict. Before you run anything, write down what you think it will do. One line is enough.
- Run. Compile and run it, with the course's own command.
- Compare. Your prediction against the real output.
- Explain. If they differ, say why. If they agree, say why they agree. The reasoning is the learning; agreement by itself is a coincidence.
- Modify. Change one thing, predict again, run again.
This is the cheapest way to test your own mental model when nobody is available to test it for you, and it is why no example in this course shows its output before asking you to predict it. When you see a prediction prompt, stop and write something. A wrong prediction is not a failure; it is the entire mechanism. It tells you which idea needs another look, and it does so immediately, instead of in an exam three months from now.
Write the prediction down
In your head you will unconsciously adjust the prediction after seeing the output, and learn nothing. On paper — or in a file — the gap is visible, and the gap is the lesson.
The seven steps of practice¶
Learning a concept and being able to use it are different things, and the distance between them is covered by doing progressively more independent work. Each step adds one specific difficulty:
① Learn the concept → ② Study the example → ③ Modify the example
↓
⑦ Build the project ← ⑥ Attempt the challenge ← ⑤ Complete the lab ← ④ Solve the exercise
| Step | What you do | The difficulty it adds | Where it lives |
|---|---|---|---|
| ① Learn the concept | Read the explanation sequence and run its code | Nothing yet — you are being shown | Module concepts page |
| ② Study the example | Predict, run, then read why it behaves that way | Comparing your model with reality | Worked examples |
| ③ Modify the example | Change one thing and predict the effect | You must have a model, not a memory | End of each worked example |
| ④ Solve the exercise | Write a program from a blank file | No scaffolding at all; the blank page is the hard part | Exercises |
| ⑤ Complete the lab | Make the idea work inside the running system | Your idea must survive decisions you made weeks ago | Labs |
| ⑥ Attempt the challenge | An open problem with more than one defensible answer | You must choose and justify | Module challenge problems |
| ⑦ Build the project | Design and build something from a problem statement | Everything at once, including deciding what to build | Projects |
Steps ③ and ⑥ are the two students skip, and they are the two that produce the most learning. Step ③ is where a remembered example becomes a working model. Step ⑥ is where you find out that "it works" and "it is well designed" are different claims.
What every module contains¶
All sixteen modules have the same fifteen parts, in the same order. Once you have worked through one module you will never have to hunt for anything again.
| Part | What it is for |
|---|---|
| Why this module matters | The problem, felt first — so the concept arrives as an answer |
| Prerequisites | What you need, with a one-minute way to check each item |
| Learning objectives | What you will be able to do, each tagged with its level |
| Concepts and explanations | The sequence, each step opening with the question it answers |
| Worked examples | Code with the reasoning shown, and a prediction prompt before every output |
| Misconceptions and mistakes | The wrong mental models at this stage, and the errors everyone makes |
| Debugging | The technique this module adds, and a real diagnosis worked through |
| Exercises | Three tiers — warm-up, core, challenge — each stating what success looks like |
| Lab | One increment of the running system, with a self-assessment checklist |
| Challenge problems | Open problems at levels 5–8, judged on your reasoning |
| Self-assessment | Questions with explained answers, and what a full-credit answer needs |
| Summary | The module compressed to what you must retain |
| Skills checklist | "I can…" items, each naming the evidence that proves it |
| Suggested next step | What comes next, and what it will assume you can do |
| Further reading | Real books and official documentation, if you want more depth |
A module is complete when its skills checklist can be ticked with evidence. Every item names an artefact — a program that runs, a prediction that was right, a bug you found and explained. Nothing on those checklists can be ticked by reading, which is the point.
Where each level is asked of you¶
The course works across a range of levels in each module, and the range rises as you go. Early modules are about understanding, modifying and analysing. The later ones ask you to build, refactor and judge.
| Module | Levels worked | You are finished when you can… |
|---|---|---|
| 1. C++ and the OOP Mindset | L1 → L4 | modify a program and predict the effect (L3) |
| 2. Classes and Objects | L1 → L4 | modify a type and its use, predicting each change (L3) |
| 3. Constructors and Destructors | L1 → L5 | explain why objects are constructed and destroyed in that order (L4) |
| 4. Encapsulation | L2 → L5 | design the interface of a class and justify every public member (L5) |
| 5. Operators and Static Members | L2 → L5 | explain why a misbehaving comparison breaks a sort (L4) |
| 6. Inheritance | L3 → L5 | design a hierarchy, and justify what is not inherited (L5) |
| 7. Polymorphism | L3 → L6 | design a polymorphic interface that cannot be sliced (L5) |
| 8. Abstract Classes | L4 → L6 | design a contract the compiler enforces (L5) |
| 9. Composition and Association | L4 → L6 | draw and justify the ownership of every object (L5) |
| 10. Copying and Resource Management | L4 → L7 | refactor an owning type to the Rule of Zero, safely (L7) |
| 11. RAII and Smart Pointers | L4 → L7 | refactor hand-written cleanup into automatic cleanup (L7) |
| 12. Templates | L4 → L6 | build one generic component that serves several types (L6) |
| 13. Exception Handling | L4 → L7 | build a system whose failure paths are as considered as its success path (L6) |
| 14. The STL with OOP | L3 → L7 | refactor hand-written loops into standard algorithms, with a complexity argument (L7) |
| 15. SOLID and Design Patterns | L5 → L8 | evaluate a design against principles and name its real costs (L8) |
| 16. Advanced OOP Capstone | L5 → L8 | evaluate your own finished system, including what you would reverse (L8) |
The full descriptions are on All Modules. If a module's range feels ambitious, note that the range is what the module works across, not what you must master on the first pass — the exit level is the one that matters before you move on.
How to check yourself¶
There is no marker in self-study, so the course gives you the two tests a teacher would apply, and both work at any level.
The explanation test. Explain the code out loud, to an imaginary classmate who knows less than you do. When you reach a point where you say "…and then it just works", you have found the gap. Go back to that line. This is the closest available substitute for a teacher asking "and why?" — which is the single most useful thing a teacher does.
The prediction test. Change one thing and write down what will happen before running it. A correct prediction is evidence of understanding; an incorrect one is a lesson. Either way the session produced something, which matters when nobody is checking whether you showed up.
Then use the checklists. Every module ends with a skills checklist, and every lab has a self-assessment checklist. They are deliberately strict, and they ask for evidence rather than confidence. Ticking an item you cannot demonstrate is the one way to fail this course while appearing to pass it.
| Score on a module quiz | What it means |
|---|---|
| 80% or more, every miss explained | Move on to the next module |
| 60–79% | Re-read the sections behind the misses, retake in a week |
| Below 60% | Redo the worked examples and the lab before going further |
A quiz is a diagnostic, not a grade. Its useful output is the list of ideas that need another look — see Quizzes.
When you are stuck¶
Being stuck is normal, and it has a shape. Match what you are feeling to the row:
| What is happening | What to do |
|---|---|
| The code will not compile | Reading Compiler Errors — fix the first error only, then rebuild |
| It compiles, but the output is wrong | Read the Common mistakes table for the current module, then predict the output line by line |
| It compiles and then crashes | Something is undefined behaviour. Note it, and continue — the module that explains it is coming, usually 4, 10 or 11 |
| I understand the explanation but cannot write the code | You are at level 1 and trying to do level 2. Type the worked example from a blank file, then do exercise W1 |
| I can write the code but cannot explain it | Use the explanation test out loud. The line where you falter is the concept to revisit |
| I have forgotten earlier syntax | Cheat Sheets — using them is not cheating |
| A term is not clear | Glossary |
| I cannot tell whether my solution is good | Compare with the reference solution after attempting it, and explain every difference — including the places where yours is better |
The escalation ladder, worth following in order when a program fails:
- Read the first error properly, including any
note:line under it. - Look one line above the reported line. That is usually where the mistake is.
- Reduce the problem — comment things out until it builds, then restore them one at a time.
- Check the module's common-mistakes table, then the glossary.
- Ask the machine: add print statements, add a counter, use a sanitizer.
- Say the problem out loud in words, without code. More bugs are found here than anywhere else.
- Only then look at a solution — and afterwards, write your own version from scratch.
What this asks of you¶
Self-study is not a shortcut. It is the same material with the teacher's questions built in, and the honest version of the arrangement looks like this:
- Type the code. Do not copy and paste. Typing is where you meet the
const, thestd::and the missing semicolon, and those are the lessons. - Do the labs in order. They are cumulative, and they are the difference between recognising C++ and being able to use it.
- Attempt before you look. Reading a solution produces recognition, and recognition is not understanding.
- Keep a mistakes file. One line per bug you fix. It becomes revision material no textbook can provide.
- Be wrong on purpose. Every module contains something you are meant to break, so that the error stops being frightening and starts being information.
- Say when you do not get it. If a page here does not explain something, that is a defect in the page, and reporting it genuinely improves the course for the next student.
Related: Prerequisites · Study Plan · All Modules · Labs · Exercises · Course Home