Most people forget almost everything they read within a few days—yet still feel like they “understand” it. You finish a chapter, close the book, and if a friend asked, “So explain it to me,” you’d stall out. This episode is about closing that gap between knowing and truly explaining.
In technology, this gap quietly kills progress. Developers “understand” a new framework after a 40‑minute tutorial, then freeze when asked to wire it into a real codebase. Data analysts “get” a new model from a 20‑page paper, yet can’t explain it clearly in a 5‑minute stand‑up. The problem isn’t intelligence or effort; it’s the way we study. We read, highlight, nod along—and never force our brain to do the harder work: reconstructing ideas from scratch. The Feynman Technique attacks this directly. It turns every article, lecture, and doc page into raw material for you to rewrite, compress, and teach back in your own words. Not “someday,” but immediately: after 10 minutes of learning, you start talking or writing as if you were mentoring a new hire who depends on your clarity to ship.
In tech, the cost of shallow understanding is measurable. A 30‑minute mis‑explained API can spawn 3–4 days of rework across a team. A data scientist who can’t clearly justify a model choice may see it blocked in a 15‑minute review, wasting weeks of experimentation. Meanwhile, study habits stay stuck at skimming docs and bookmarking blog posts. That’s where the Feynman approach becomes a tactical advantage. It doesn’t just help you “get it”—it turns each concept into something you can defend in design docs, code reviews, and stakeholder meetings, under time pressure and with real numbers on the line.
Step 1: Capture, don’t copy Start with a small, bounded chunk: maybe 3–5 pages of a systems paper, a 10‑minute segment of a Kubernetes tutorial, or a single RFC. Spend no more than 25 minutes per chunk. While you read, jot brief trigger phrases only: “leader election,” “health checks,” “backoff strategy.” No full sentences, no transcribing slides. Your goal is to load the ideas, not create pretty notes.
Step 2: Close the tab and teach from scratch Now remove all crutches. Close the docs, mute the video, flip the paper over. On a blank page or in a scratch file, write as if you’re explaining to a specific junior teammate: name them, give them a role and a current task. For instance: “Mina joined last week and needs to add a new endpoint.” In 10–15 minutes, lay out:
- What problem this tool/idea solves - How you’d explain it in 3–5 plain sentences - A concrete, numbers‑based example - e.g., “We reduced latency from 220 ms to 140 ms by adding X.”
If you stall for more than 20 seconds, put a star in the margin. That’s a failure point you’ll hunt down later.
Step 3: Hunt gaps with targeted review Only now reopen the source. Compare line by line. Anywhere your explanation was vague (“it handles stuff automatically”) or wrong, highlight in one color. Anywhere you omitted critical constraints (limits, trade‑offs, costs), highlight in another. Expect 5–10 such gaps per page when you start; that’s normal. For each, write a 1–2 sentence fix underneath, still in everyday language, plus one “when this would break” scenario.
Step 4: Compress and stress‑test Rewrite your explanation as if you only had 60 seconds in a stand‑up or design review. Force yourself to:
- Use one concrete number (throughput, error rate, dollar cost) - State one risk and one mitigation - Include how you’d verify it’s working (specific log, metric, or test)
Then stress‑test: say it out loud to an actual person, or record a 90‑second voice note and listen back. Do you ramble? Do you dodge specifics? Anywhere you feel friction, go one level deeper in the docs and repeat the loop on that subtopic.
A practical way to apply this is to tie it directly to work artifacts. Suppose you’re learning a new message queue for a backend service. After your first Feynman pass, open your actual repo and:
- Write a 6–8 line README section explaining why this queue is in the architecture, aimed at a future teammate joining in 3 months. - Add 3 comments in code where it’s initialized, consumed, and monitored, each in 1–2 plain sentences.
Next, test yourself under “pressure.” Book a 15‑minute slot with a colleague and say: “I’m going to explain how our queue works in under 2 minutes; stop me if anything is fuzzy or hand‑wavy.” Note where they interrupt you—those are real‑world stress points. Finally, try a second round 48 hours later without rereading: your ability to reconstruct the explanation cold is the metric. If key numbers, limits, or failure modes vanish, loop back and tighten that slice.
As tooling improves, you can wire this straight into daily work. Example: after a design review, paste your 90‑second explanation into a team wiki, then set a bot to ping you 3 days later to rewrite it from memory. Or pair with an AI coach: ask it to attack your reasoning, not your grammar. Over a quarter, 10–15 such cycles can turn scattered notes into a vetted “internal textbook” for your stack.
Use this method where it matters most: before shipping. For one upcoming decision—a database choice, retry policy, or model architecture—run a full Feynman pass, then attach your 120‑word explanation to the pull request. Your challenge this week: do that for 3 different PRs. In 90 days, you’ll have 30+ battle‑tested mini‑lessons written by you, for you.
