05 — Teach To Learn¶

If you can’t explain it, you haven’t finished it. Every exit deliverable ships as a public artifact.

The rule¶

Each phase in this roadmap has an exit criterion. Each exit criterion becomes a public post. Not a private note. Not a Notion doc. Public. On the internet. With your name on it.

Why public: because writing for an audience forces a completeness you never reach when you’re writing for yourself. You’ll gloss over gaps in your own understanding all day long. You won’t gloss over them when strangers might comment.

Why exit criteria only: because you don’t need to blog every experiment. You need to publish the load-bearing ones. Roughly 8-12 public posts across 13 months. That’s the target.

The Feynman test (do this before you hit publish)¶

Before any post goes live, close the laptop and answer out loud:

“Can I explain this to a smart friend — who knows Python but not inference — in 5 minutes, without notes, without slides, without hand-waving?”

If yes → publish.

If no → back to the code. The gap in your explanation is the gap in your understanding, and it’s exactly the gap that will get exposed in an study loop at Fireworks or Baseten. Fix it now, for free, instead of fixing it there, for expensive.

Optional but powerful: actually find a smart friend. Explain it to them. Watch their face for the moment of confusion. That’s your target for revision.

Where to publish (matched to content)¶

r/LocalLLaMA¶

Best for: Benchmark posts, local-inference results, quantization comparisons, “I got X running on Y hardware” writeups. This is the community that respects reproducible numbers.

Format that works:

Title: specific number + hardware. “Llama-3-70B AWQ at 32 tok/s on 2x RTX 3090” beats “Some quant benchmarks.”
Body: hardware, model, quant, engine version, actual numbers table, script link.
End with: what surprised you, what you’d try next, invitation to comment.

Rules: No hype. No “insane speedup!!” No screenshots of terminals when a table would do. This community can smell marketing at 100 paces. Be the person who posts numbers, not the person who posts vibes.

Personal blog / Substack / static site¶

Best for: Long-form technical writeups. Kernel deep-dives. Phase exit deliverables. Anything > 2000 words.

Recommendation: static site (Astro, Hugo, Zola, or plain Markdown-in-a-Cloudflare-Page). Your own domain. Owned distribution, not platform risk. Don’t spend a sprint on the site — use a starter template, ship rough, iterate.

Structure that works for a technical deep-dive:

TL;DR (3 bullets, the number/finding/link)
Motivation (why anyone should care)
The setup (hardware, versions, workload)
The measurement (numbers, plots)
The explanation (arithmetic, why the number is what it is)
The follow-ups (what you’d do next)
Reproduction (link to the script, exact commit)

This is the same shape as your lab notebook entries. That’s not an accident. The lab notebook is the draft.

X / Twitter thread¶

Best for: TL;DR of a blog post. Announcement of a PR. A single graph with a punchy insight. Getting on the radar of engineers you want to work with.

Format:

Tweet 1: the single most surprising number + a chart
Tweets 2-6: the story (one point per tweet)
Tweet 7: link to the blog post for the full writeup
Tweet 8 (optional): who to follow up with, who to credit

Don’t overthink X. Ship the thread. If it flops, learn what didn’t land. Threading is a skill and you’ll get better by month 8.

GPU MODE Discord¶

Best for: Kernel work. Anything Triton or CUDA. This is where you get real technical feedback from people who actually write kernels.

How to post: short summary in the relevant channel + link to the writeup or PR. Ask for feedback specifically (“Am I bandwidth-bound or compute-bound here? Ncu report attached.”). Don’t ask “how do I learn CUDA” — that’s a search-engine question.

GitHub (as publishing)¶

Sometimes the best “post” is:

A PR (even a small one)
A well-written issue with a repro
A gist with a benchmark + a chart
A README on your project repo

Code + numbers speak louder than a blog post any day. Don’t neglect this axis.

The exit-deliverable → post mapping¶

Rough plan for the 13 months. Adjust to your actual phase structure.

Phase	Exit artifact	Publish target
1 Foundations	“Predicting decode tok/s for 6 models on my GPU”	Personal blog + r/LocalLLaMA
2 Transformers	“Llama-3-8B forward pass from scratch, correctness verified”	GitHub repo + blog
3 GPU Kernels	“Triton FlashAttention-2 within 2x of official on RTX 3090”	Blog + GPU MODE + X thread
4 Attention	“PagedAttention explained by re-implementing it in 300 lines”	Blog + r/LocalLLaMA
5 Engines	“A minimal continuous-batching engine in 800 lines”	GitHub + blog + X
6 Quantization	“AWQ vs GPTQ vs SmoothQuant: quality-latency curves on Llama-3-8B”	r/LocalLLaMA + blog
7 Distributed	“Tensor parallel 70B across 2x 3090s: what actually happens on the wire”	Blog + GPU MODE
8 Production	“Building an on-prem LLM serving stack: goodput, autoscaling, observability”	Blog + X
Bonus	“My first merged vLLM PR: what I broke, what I learned”	Blog + X + r/LocalLLaMA

Nine to twelve posts total. That’s your public portfolio. That’s the CV. See 12_portfolio/ for how these become study weapons.

The “ship rough” rule¶

Your drafts will be too polished. Everyone’s drafts are too polished. You will re-read paragraph 3 for the eighth time and it will still not be perfect.

Publish it anyway.

80% polished, out on Sunday >> 100% polished, still in drafts on Wednesday
Typos in a technical post are forgiven. Silence is not.
The comments and pushback are where the real learning happens. You can’t get comments on a draft.

My hard rule for you: from first draft to publish should be ≤ 5 days. If you’re on day 6 of “polishing”, ship what you have and write a follow-up if you must.

Cross-posting etiquette¶

Don’t be a jerk. Rules:

r/LocalLLaMA: cross-post at most 1x/month. Don’t drop-and-run — respond to comments for 48 hours.
X: post the thread when the blog post goes live, not before. Tag the tools/authors you used (@vllm_project, @tri_dao, etc.) only when actually relevant — spammy tagging burns you.
GPU MODE: don’t crosspost blog links into random channels. Post in #showcase or the relevant kernel channel.
Hacker News: don’t submit your own posts more than once in a blue moon; it usually flops from the author account. Let others submit if they want.

Engage in comments. For 48-72 hours after posting, treat the comment section as extension of the work. Someone points out a benchmark bug — fix it, update the post, credit them. That behavior is how you get respected in these communities.

The identity shift¶

Here’s what quietly happens over 13 months of teaching to learn:

Month 1: You write the first post. It’s awkward. You’re an intruder.
Month 3: You write the second. It’s less awkward. A few people comment.
Month 6: Someone links your post in a Discord. You’re a source.
Month 9: A vLLM contributor replies to your thread. You’re a peer.
Month 12: Someone new is reading your posts to learn what you learned last year. You’re a node.
Month 13: In an study, the study partner says “oh, you’re the person who wrote the AWQ post.” You’re known.

That trajectory is what public teaching buys you. It’s not vanity. It’s the mechanism by which “anonymous engineer in Tamil Nadu” becomes “the person who wrote the reproducible benchmark that everyone forwarded.” That reputation is the on-ramp to every job you actually want.

Ship the rough draft. It’s the whole point.