Teach Me

# Stage 5: PREPARE — Craft Teaching Materials

You have the map and the plan. Now build the actual materials:
analogies, examples, mistake demonstrations, and challenges.

## Analogy Construction

Analogies are the most powerful teaching tool. Every concept needs one.

### The Good Analogy Framework

```
A good analogy:
✅ Maps the STRUCTURE, not just the surface
✅ Uses something the learner already experiences
✅ Has clear boundaries (you know where it breaks down)
✅ Illuminates the key insight, not just the appearance

A bad analogy:
❌ Only matches superficially
❌ Uses something equally unfamiliar
❌ Breaks down immediately when examined
❌ Obscures the key insight
```

### How to Build an Analogy

```
Step 1: Identify the KEY MECHANISM of the concept
  Quantum superposition → "state is undefined until measured"

Step 2: Find a familiar system with the SAME mechanism
  A spinning coin → outcome is undefined until it lands

Step 3: Map the elements:
  quantum state    →  spinning coin
  measurement      →  catching/stopping the coin
  collapse         →  it becomes heads or tails
  probability      →  the coin is "more likely" heads if biased

Step 4: Identify where the analogy BREAKS DOWN:
  "Unlike a coin, a quantum particle isn't secretly heads or tails
   while spinning. The state genuinely doesn't exist until measured.
   The coin analogy helps with the 'undefined until observed' part,
   but the coin always HAS a definite state — the particle doesn't."

Step 5: State the boundary explicitly when teaching:
  "This analogy works for understanding measurement, but I should
   warn you — it breaks down when we get to entanglement."
```

### Analogy Library by Domain

```
COMPUTER SCIENCE:
├── Middleware → airport security checkpoint
├── Recursion → Russian nesting dolls / inception
├── Hash table → library card catalog with shelf numbers
├── Cache → keeping a cookbook open to the recipe you're using
├── API → restaurant menu (you order, kitchen handles it)
├── Dependency injection → hiring a contractor (you provide tools)
├── Git branches → parallel timelines in a movie
└── Async/await → ordering coffee and sitting down while they make it

PHYSICS:
├── Superposition → spinning coin (undefined until stopped)
├── Wave-particle duality → actor playing two roles
├── Uncertainty principle → photographing a fast car (sharp=still, motion=blur)
├── Entanglement → pair of magic dice (always sum to 7, no communication)
├── Tunneling → ball rolling partway up a hill but appearing on the other side
├── Energy quantization → stairs vs ramp (can only stand on steps)
├── Wavefunction → cloud of probability (denser = more likely to find particle)
└── Measurement → opening a box with a firefly (you see it somewhere specific)

MATHEMATICS:
├── Vectors → GPS coordinates (direction + magnitude)
├── Matrices → spreadsheet transformations
├── Eigenvalues → the axis a spinning top wobbles around
├── Derivatives → speedometer (rate of change at this instant)
├── Integrals → odometer (total distance accumulated)
├── Limits → zooming in on a curve until it looks straight
├── Proofs → building a bridge one plank at a time (each step holds weight)
└── Complex numbers → compass needle (magnitude + direction)
```

## Example Design

### The Example Progression

Every concept needs THREE examples, increasing in complexity:

```
EXAMPLE 1: MINIMAL — The simplest possible demonstration
  Purpose: "See? It works. Nothing scary."
  Strip away ALL unnecessary details.
  One concept, one file, one function, one equation.

EXAMPLE 2: REALISTIC — A real-world usage
  Purpose: "This is what it looks like in practice."
  Add context, error handling, edge cases.
  Show the concept doing useful work.

EXAMPLE 3: CHALLENGING — An edge case or advanced use
  Purpose: "Now you REALLY understand it."
  Show where it breaks, where it surprises, where it shines.
  This becomes the basis for the challenge exercise.
```

### Example Quality Checklist

```
Every example must:
□ Be RUNNABLE (learner can copy-paste and verify)
□ Be SELF-CONTAINED (no hidden dependencies)
□ Have a FILE PATH label (where would this code live?)
□ Be shown BEFORE explanation (never describe unseen code)
□ Demonstrate ONE primary concept (not three things at once)
□ Use realistic names (not foo/bar/baz)
□ Include comments only where the code is genuinely unclear
```

## Common Mistake Cards

For each concept, prepare at least one mistake demonstration:

```
MISTAKE CARD TEMPLATE:

Concept: [name]

THE MISTAKE:
  What they do: [wrong code / wrong reasoning]
  Why they do it: [the thinking that leads here]
  
THE FIX:
  Correct version: [right code / right reasoning]
  Key insight: [why the fix works]

THE CONNECTION:
  "This mistake comes from [previous mental model]. In [this context],
   the rule changes because [reason]."
```

### Mistake Sources

Where to find real mistakes:
```
- Stack Overflow: sort by votes, look at the QUESTION (not answer)
- GitHub Issues: common bug reports reveal common misunderstandings
- "Common mistakes [topic]" search results
- MIT OCW problem set solutions: see where students lose points
- Your own Stage 2 misconception inventory
```

## Challenge Design

### The Challenge Spectrum

```
RECALL CHALLENGE: "What will this output?"
  Tests: Can they predict behavior from understanding?
  Difficulty: ★☆☆☆☆

APPLY CHALLENGE: "Modify this example to do X instead"
  Tests: Can they adapt what they learned to a new situation?
  Difficulty: ★★☆☆☆

EXTEND CHALLENGE: "Add feature Y to what we built"
  Tests: Can they build on the concept independently?
  Difficulty: ★★★☆☆

COMBINE CHALLENGE: "Use concepts A and B together to solve Z"
  Tests: Can they synthesize multiple concepts?
  Difficulty: ★★★★☆

CREATE CHALLENGE: "Design a solution to this new problem"
  Tests: Can they transfer knowledge to an unfamiliar domain?
  Difficulty: ★★★★★
```

### Challenge Requirements

```
Every challenge must:
□ Be specific (not "try experimenting with X")
□ Be achievable with what's been taught (no hidden prerequisites)
□ EXTEND the tutorial content (not repeat it)
□ Have a verifiable outcome (they can check if they got it right)
□ Include a hint (collapsible) for if they're stuck
□ Optionally include a solution (collapsible)

HINT LEVELS:
  Hint 1: Direction — "Think about what [concept] does when..."
  Hint 2: Approach — "The key is to use [specific technique]..."
  Hint 3: Scaffolding — "Start with this: [first line]. Now..."
```

## Visual Preparation

### When Visuals Help

```
ALWAYS use visuals for:
├── Processes with steps (flowcharts, sequence diagrams)
├── Spatial relationships (architecture, layouts)
├── Data transformations (before/after)
├── Mathematical functions (plots, graphs)
├── Physical phenomena (wavefunctions, fields, motion)
└── Comparisons (side-by-side)

SKIP visuals for:
├── Simple definitions
├── Short code snippets
├── Sequential instructions
└── Concepts best explained by analogy alone
```

### Visual Types by Topic

```
SOFTWARE:   architecture diagrams, data flow, state machines
PHYSICS:    wavefunctions, energy levels, field lines, simulations
MATH:       function plots, geometric constructions, graphs
ALGORITHMS: step-by-step execution traces, tree visualizations
DATABASES:  schema diagrams, query execution plans
NETWORKS:   topology diagrams, packet flow
```

## Preparation Completion Checklist

```
Before you start teaching, verify you have:

□ ANALOGY for every concept (with stated boundary)
□ THREE EXAMPLES per concept (minimal → realistic → challenging)
□ MISTAKE CARD for every concept (at least one)
□ CHECKPOINT QUESTION for every concept
□ CHALLENGE for every session (with hints)
□ HOOK for the opening
□ BRIDGES between all adjacent concepts
□ BOTH TRACKS ready (conceptual + mathematical) if topic needs it
□ VISUAL planned for concepts that need spatial understanding
□ FURTHER RESOURCES ready for Phase 4 Solidify
```