05 — Teach to Learn¶

The fastest way to find the gaps in your understanding is to try to explain the thing to someone else. The second-fastest way is to try to explain it to yourself as if you were someone else. C is a language that punishes vague understanding — you cannot handwave your way through restrict, or through why strict aliasing matters, or through what a segfault actually is at the OS level. Teaching forces you to close the vagueness.

The Feynman test¶

At the end of any session where you learned a new concept, do this: take out your phone, open the voice memo app, and try to explain the concept in 90 seconds.

Rules:

No looking anything up. No notes. Just talk.
Pretend the listener is a smart friend who codes in Python but has never written C.
Time it. 90 seconds hard limit.
Listen back to the recording. Where did you handwave? Where did you say “basically” or “kind of”? Where did you use a word without defining it?

The places you handwaved are the places you don’t actually understand yet. Go read those specifically. This is the tightest learning-loop this document contains.

You do not have to publish the voice memos. Delete them if you want. The value is in the recording, not the artifact.

The blog-post-per-month cadence¶

Once a month, minimum, you publish a technical writeup. Not “post my repo README on Twitter.” A real writeup, ~800–2000 words, with code samples, with at least one honest “I got this wrong initially, here’s what I learned” moment.

Why monthly, not weekly: because the goal is to tie the writeup to the portfolio rung you finished that month (see 12_portfolio/). Rung 1 ships → post about Rung 1. This yokes teaching to shipping and keeps both honest.

Why not quarterly: because if you do it quarterly, you will do it never. The one-per-month cadence is short enough that you cannot procrastinate for long.

Where to publish¶

Ranked by leverage-to-effort ratio for your specific position (India-based ML engineer transitioning to C):

Venue	Effort	Payoff	Notes
Personal blog (a simple static site, hosted anywhere)	Low ongoing	Compounds over years	Own the URL. Cross-post from here to everything else. This is the anchor.
dev.to	Very low	Modest, discoverable	Cross-post from personal blog. Tag `#c` and `#systems`. Gets some drive-by readers.
LinkedIn technical post	Low	High for career signaling in India	This is where hiring managers and Zoho leadership will actually see you. Do NOT skip.
r/C_Programming	Low	High for FEEDBACK, not audience	Post asking for code review; you will get real critique from real C people. Bring skin.
HasGeek / Bangalore ChennaiJS / BangaloreDevs meetups	High (talk prep)	Very high for network + credibility	From M9 onwards. One 20-min talk at a HasGeek Rootconf or similar is worth 6 blog posts for job leads.
Hacker News (Show HN)	Low to post, high to survive	Bimodal — either ignored or brutal	Only post projects, never explainers. Only when the project is genuinely done.
YouTube / short-form video	Very high	Very low for your goals	Do not bother unless you enjoy it as a hobby. Text scales better for engineer audiences.

The order of operations: personal blog → cross-post to dev.to and LinkedIn → post the most polished ones to r/C_Programming for review → talk at a Bangalore meetup starting M9.

Output-as-learning¶

Here is the mindset shift that separates people who compound from people who plateau: the artifact IS the learning. You do not learn a topic and then write about it. You write about it, and in the act of writing, you learn it.

What this means in practice:

Never say “I’ll write this up when I understand it better.” Write it up now, badly, and let the writing show you what you don’t understand.
Never say “I need to build the thing first, then blog about it.” Blog while you build. The blog exposes the design flaws.
Never draft a post for two weeks trying to make it perfect. Ship at 80%. The remaining 20% is polish, and polish does not teach.

A half-good blog post published this month is worth ten drafts sitting in your Notes app.

Three example teachings you should write¶

Here are three specific writeups to plan for. Not the only ones, but the ones that will land hardest for your positioning:

Month 3: “Three pointer mistakes I made while relearning C after two years of ML”¶

Set up the personal narrative: 24-year-old ML engineer, atrophied instincts, coming back to C.
Three specific bugs (dangling pointer to stack, missed free on error path, aliasing issue) each with the wrong code and the fixed code.
End with what your daily notebook now catches that it wouldn’t have on day one.
Why this works: every C reader has made these mistakes; you get “welcome home” vibes and credibility as an honest learner.

Month 6: “Building a simple allocator taught me what malloc actually does”¶

The bump allocator → free-list allocator progression.
What surprised you when you profiled it against malloc.
The one benchmark table with hygiene from 03_benchmark_hygiene.md.
Why this works: allocators are the classic mid-journey C project, and a measured writeup instantly separates you from the tutorial-follower crowd.

Month 9: “Why I write C in 2027, as an ML engineer”¶

Not defensive. Not “C is not dead.” Take the offensive: what C gives you that Python/Rust don’t for your specific ML-inference-kernel use case.
One concrete example: a SIMD kernel or a memory-mapped tensor loader with numbers.
End with the M13 pitch reframed for public: production, ML kernels, network services, and the 2 AM debugging skill.
Why this works: by M9 you have proof, not aspiration. The post signals to hiring managers that you are the kind of engineer who chose C on purpose, not as nostalgia.

The rule against ghost-drafting¶

Do not keep 12 drafts of blog posts you are “almost ready to publish.” That is not a portfolio, that is a graveyard. If a draft is older than 30 days and not published, either publish it as-is with a note (“this is rough, sharing for feedback”) or delete it. Drafts that hang around drain motivation more than blank pages do.

Return to README.md · Next: 06_failure_modes.md