05 — Teach to Learn¶

The Feynman Test applied to DSA: if you cannot explain an algorithm to a 15-year-old without notes, you have not understood it yet — you have memorized it. Memorization is not worthless, but it expires. Understanding compounds. The surest way to convert a memorized pattern into genuine understanding is to explain it to someone who doesn’t know it.

The output pipeline is not a supplement to learning. It is the final and most honest stage of learning. Understanding → implement → explain → publish → get feedback → deepen. You cannot skip from “implement” to “deepen” without the middle steps. The middle steps are where you discover what you actually don’t know.

The Feynman Test (DSA Version)¶

After solving any medium or hard problem, ask: can I explain this to a 15-year-old who knows basic math but no CS?

The test has three checkpoints:

Can you explain the problem in plain language without using jargon?
Can you explain why the naive approach fails (or is too slow)?
Can you explain why the optimal approach works — not what it does, but why it works — using an analogy, a diagram, or a step-by-step trace?

If you fail checkpoint 3, you do not yet understand the solution. You may have implemented it correctly. You do not understand it. Return to the problem until you can pass checkpoint 3.

The 5-Sentences Habit¶

After solving any medium or hard problem: before you close the tab, write 5 sentences explaining why the solution works. Not what it does. Why it works.

This takes 3–5 minutes. It is not optional.

Template:

Problem: [Name]
Date: ___

The key insight is: [what observation makes the efficient solution possible]
The naive approach fails because: [why brute force is insufficient]
The algorithm works because: [the invariant or mechanism that makes it correct]
The time complexity is O(___) because: [explicit reasoning, not just the answer]
A variation that would break this approach: [forces you to find the boundary conditions]

If you cannot complete sentence 3 without looking something up — you haven’t finished the problem yet.

The Rubber Duck Protocol¶

Before submitting any solution, explain it aloud to yourself as if you are teaching someone sitting across from you. Say:

“This works because… The key thing I’m tracking is… The reason I can discard [alternative approach] is… The time complexity is [X] because…”

If you stumble, stop. The stumble is information. Return to the part where you stumbled and derive it until you can say it cleanly.

This costs 2 minutes per submission. It prevents the Memorizer failure mode more effectively than any other single habit in this system.

Where to Publish¶

Output does not have to be public to be effective — private lab notebook entries count. But public output creates accountability, forces clarity, and occasionally returns feedback that corrects errors you didn’t know you had.

Platform	Format	Audience	Why It Works
Your lab notebook	Any	Private	No friction. Output still forces clarity. Start here.
GitHub	Code + README	Public	Canonical reference. Employers look here.
Codeforces Blog	Technical writeup	Competitive programmers	This community values depth and will call out errors. High-signal feedback.
Hashnode / Dev.to	Tutorial-style post	Beginners	Explaining to beginners forces you to state all assumptions.
r/learnprogramming	Question or solution	Mixed	Good for getting feedback on understanding, not just code.

Teaching Schedule¶

One blog post or writeup per phase across the 9 months. Six total. These do not have to be long — 400–800 words on one concept or problem you found genuinely interesting is sufficient.

Phase	Target Month	Suggested Topic
Phase 0	M1	“Why Big-O matters and how to derive it without memorizing formulas”
Phase 1	M2	“Two pointers: why it works and when it doesn’t”
Phase 2	M3	“Recursion: how I learned to stop guessing and read the call stack”
Phase 3	M4-M5	“A tree problem I got wrong and why”
Phase 4-5	M6	“My first DP problem that actually made sense”
Phase 6-7	M8-M9	“What competitive programming taught me about thinking under pressure”

These are suggestions. Write about what actually interested you in each phase. The audience for these posts is you in 12 months, reading back. Make them worth reading.

Why This Matters for This Learner Specifically¶

You have been in an environment where AI generates code and you evaluate it. The cognitive mode that environment trains is: receive output, assess output, accept or reject. That is a valuable skill. It is not the skill this plan is building.

This plan is building the ability to generate the output from first principles. Teaching forces this. Every time you sit down to explain an algorithm, you are practicing the generation mode, not the evaluation mode. Over nine months, the generation muscle becomes strong enough that the hard problems become tractable — not because you memorized more, but because you can construct the solution from the pattern up.

Navigation: ← Daily Practice | Failure Modes →