How to Study This Course
Read this once before Unit 01 · Course home · Syllabus
This course is built for self-study: every unit gives you the material, the practice, and the answer keys you need to verify your own progress. This page explains the method that makes it work. (For the underlying learning skills — reading code, predicting, debugging, when to peek at hints, the notebook and portfolio — see the companion guide, How to Learn Programming.)
The method, in one line
Read → Run → Modify → Solve → Debug → Revise
| Step | What you do | Why |
|---|---|---|
| 1 · Read | Study the lesson slowly. Don’t skim. | Programming is precise; every word usually carries meaning. |
| 2 · Run | Compile and run every example as you meet it. | Reading code you haven’t run is reading a rumour. |
| 3 · Modify | Change something in each example, predict the new output, then check. | Prediction is where real understanding forms. |
| 4 · Solve | Do the unit’s exercises — attempt everything before checking any answer. | Struggle first; the answer then sticks. |
| 5 · Debug | Fix the unit’s Debug It programs before reading their fixes. | Finding bugs is the core professional skill. |
| 6 · Revise | Finish with the unit’s revision sheet and flashcards. | Two pages now save hours before the next unit and the final. |
The golden rule: never move on while something still feels like magic. If a line of code surprises you, run it, change it, run it again.
The weekly rhythm (16-week plan)
Each unit = one week, two sessions. Sessions are ≈ 90–120 minutes each; the whole week is ≈ 5–7 hours.
The session-by-session version of this rhythm — with prerequisites, objectives, reading, exercises, labs, challenges, and completion checklists for all 32 sessions — is the 16-Week Roadmap.
| Day | Task | Time |
|---|---|---|
| Day 1 | Session N.1: read, run, modify every example | 90–120 min |
| Day 2 | Session N.1 exercises (attempt, then check) | 45–60 min |
| Day 3 | Session N.2: read, run, modify every example | 90–120 min |
| Day 4 | Session N.2 exercises + unit Debug It activities | 45–60 min |
| Day 5 | Lab: brief → starter → build → compare with solution → self-score | 45–90 min |
| Day 6 | Quiz (all 10 questions), read answer key, score yourself | 30–45 min |
| Day 7 | Revision sheet + flashcards; preview next unit’s first page | 20–30 min |
Self-paced plan? Keep the order, drop the calendar. A “week” may take two days or three weeks of evenings — the sequence is what matters.
Study planner (copy into your own notes)
Week __ Unit __ ──────────────────────────────── dates: __ to __
[ ] Session 1 read + all examples run ( )
[ ] Session 1 exercises done ( )
[ ] Session 2 read + all examples run ( )
[ ] Session 2 exercises + Debug It done ( )
[ ] Lab built + checked against solution ( )
[ ] Quiz attempted, scored ____ /10 ( )
[ ] Revision sheet + flashcards done ( )
Notes / things that surprised me:
____________________________________________________________
Self-scoring: when is a unit “done”?
| Quiz score | Meaning | Action |
|---|---|---|
| 9–10 / 10 | Ready | Move to the next unit. |
| 7–8 / 10 | Almost | Re-read the sections the wrong answers point to; retake the quiz tomorrow. |
| ≤ 6 / 10 | Not yet | Redo the exercises and the revision sheet, re-run the examples you modified, then retake the quiz. |
The same idea applies to labs: complete it, compare with the published solution, and score yourself with the lab rubric. A lab is “done” when your version satisfies every rubric line — not when it merely runs.
Rules of thumb that separate learners who finish from learners who stall
- Type every example by hand. Muscle memory is real; the typos you make and fix are the lesson.
- Never copy-paste code you are learning. Copy-paste after you understand — for your own projects, not for practice.
- Predict before you run. Say the expected output out loud, then check. Being wrong is the useful part.
- Fix bugs in this order: read the error message → check the line and the lines just before it → simplify → explain the code aloud → search the error catalogue → ask.
- Stuck > 30 minutes? Move to the hint. Stuck > 1 hour? Read the solution, close it, rebuild from memory. That’s not cheating; it’s a technique.
- A unit is done when the lab works and the quiz is ≥ 90% — not when the pages have been read.
- Keep a bug diary. One line per bug: what you wrote, what the compiler said, what the fix was. By Unit 16 you’ll be your own best teacher.
- Practice in bursts, not marathons. 60–90 focused minutes beats 4 fading hours.
What to do when something breaks
- Read the error message fully — the first error is usually the real one; later errors are often echoes.
- Check the line number, then the few lines before it (many errors are reported after their cause).
- Reduce the program: comment out half; does the error move?
- Consult the compiler error catalogue and the FAQ.
- Still stuck? Reproduce the error in a fresh 5-line program and search that — or ask in the repository’s issue tracker.
Before you start
- Getting Started — compiler installed and
sanity-check.cppruns. - A code editor configured — VS Code tips.
- A folder for your work, e.g.
cpp-course/unit-01/,cpp-course/unit-02/… - The study method above, printed or bookmarked.
Then begin: Lesson 1 — What is a program? 🚀