Study Guide
The practical companion to How to Study · Course home
How to Study gives the method; this page shows how each piece of the course is meant to be used.
The anatomy of a unit
Every unit has the same shape — learn it once, use it 16 times:
| Piece | What it is | How to use it |
|---|---|---|
| Lesson 1 (session N.1) | the unit’s first reading | read + run + modify every example |
| Lesson 2 (session N.2) | the second reading | same; usually deepens Lesson 1 |
| Examples | small .cpp files, one concept each |
compile each one; break it on purpose |
| Exercises | 8–12 practice items | attempt all before checking any |
| Lab | realistic scenario + starter + solution | build first; diff with solution after |
| Debug It | a broken program hidden in the lab | find bugs before reading the fix list |
| Quiz | 10 questions | attempt all 10, then read the answer key |
| Debug activities | more broken programs with hint ladders | use hints one at a time |
| Challenges | ★/★★/★★★ open problems | optional, for stretch and joy |
| Revision sheet | 2-page summary + flashcards | last; feeds your personal deck |
Working with examples
- Type it — don’t paste. Typos are teachers.
- Run it — confirm it behaves as the lesson says.
- Modify it — change one thing; predict; run; check.
- Break it — remove a semicolon, misspell a name, and read the error. You are building an error vocabulary on purpose.
Keep each unit’s examples in cpp-course/unit-NN/ — by Week 16 that folder
is a personal reference book you wrote yourself.
Working with exercises
- Concept checks: answer in one written sentence; if you can’t, you’ve found your re-reading spot.
- Predict the output: write the prediction down. A prediction you can’t see can’t be wrong, and being wrong is the point.
- Short coding: the compiler is the first checker; the included answer is the second; “could I explain my version to a friend?” is the real one.
Working with labs
- Read the brief twice; write the steps as comments before any code.
- Build the smallest piece that compiles; grow it one step at a time.
- Compare outputs against the expected output in the brief.
- Debug It last — it’s the lab’s boss level.
- Score yourself with the lab rubric.
Working with quizzes
Attempt all 10 in one sitting (~15 minutes), then read every explanation in the answer key — including for the ones you got right. Explanations carry the extra 20% the lesson couldn’t fit.
Taking notes that help
- One bug diary line per bug: wrote → compiler said → fix was.
- One flashcard per glossary term you didn’t know; term on one side, plain-language definition + tiny code example on the other.
- A “surprises” list — anything the computer did that you didn’t expect. Surprises are the gaps; Unit 16’s practice final loves to revisit them.
Pacing & energy
- 60–90 focused minutes beats 4 fading ones; take a 5-minute break each hour.
- Hard day? Re-run an old example and modify it. Momentum matters more than coverage.
- Never study two units at once — the course’s sequencing is the whole design.
When you finish a unit
Tick it off in your progress checklist, write your quiz score in your progress file, and read the next unit’s first paragraph only — knowing what’s coming makes sleep consolidate tonight’s work (and it’s nice to end on curiosity).