05 — Teach To Learn

Output is not the reward for learning. Output is the mechanism.

The fastest way to expose your gaps is to try to explain something. The second you type “the way CompletableFuture works is…” you discover that you know about 60% of what you thought you knew. That gap is not a failure — it is exactly what teaching is for. It surfaces the fuzzy corners of your understanding so you can go back and firm them up.

This is the Feynman technique in one sentence: if you cannot explain it simply, you do not understand it. Reading feels like learning. Watching feels like learning. Neither actually is, most of the time. Writing something down for another human to read — that is where learning happens, because writing forces the incoherent parts of your understanding to become coherent, or fail publicly.

You will teach every sprint. That is the deal.

Why You Specifically Need This

You have not written public technical content before. You have been coding for a private employer with private codebases. The Internet does not know you as an engineer. This has three practical consequences over 13 months:

  1. Recruiters have nothing to find. When someone Googles you in August 2027, what shows up? A GitHub with 200 empty repos and a LinkedIn with “Zoho, applied ML.” That is not a signal.

  2. Your “proof of Java” is your word alone. No blog, no talks, no PRs. In an study loop, that becomes a weaker story than a candidate with a public trail.

  3. You lose the feedback loop. Public work invites comments. Comments correct you. Corrections accelerate learning. Private work has none of this.

Teaching in public fixes all three. It is not optional in this plan.

Where To Publish

Five channels, each with a different purpose. You do not need all five. Pick 2-3 for the first quarter and add more later.

1. yourname.dev blog — the anchor

Purpose: long-form, permanent, controllable. This is your home base. Stack: anything static. Astro, Hugo, or a Next.js starter. Do not spend more than a weekend on setup. The blog is not a coding project; it is a publishing surface. Cadence: 1 short post per sprint (biweekly), 1 long post per quarter. Owned by you. If Medium disappears, your posts survive. This is the deep archive.

2. Medium or dev.to — for reach

Purpose: distribution. Your personal blog will get ~10 readers in month one. dev.to and Medium can get you ~500-5000 for a decent post. Strategy: cross-post from your blog with a canonical link back. Not the other way around. The blog is source of truth. Cadence: cross-post everything.

3. LinkedIn — for recruiter surface

Purpose: recruiter discoverability and internal-Zoho visibility. Format: short posts (3-8 lines), one takeaway, link to full post. Screenshot of code is fine. Cadence: 1-2 posts per sprint. LinkedIn rewards frequency. Note for Indian market: LinkedIn is the primary hiring surface here, more than GitHub. Do not skip this if you plan to job-switch in 2027.

4. Twitter/X — for build-in-public

Purpose: live thinking, ambient community, following senior Java folks. Format: “TIL” tweets, short observations, replies to Java-Twitter people (Aleksey Shipilëv, Nicolai Parlog, Brian Goetz occasionally posts, Josh Long for Spring). Cadence: 1-3 tweets per week. Low-effort but consistent. Warning: Twitter is a time sink. Set app timers. 15 minutes a day maximum.

5. YouTube — optional, high-leverage if committed

Purpose: the strongest possible learning signal. Recording a 10-minute video on “how virtual threads work” will teach you more than reading three chapters, because you cannot fake fluency on camera. Cost: high. Editing takes 3-5 hours per finished minute if you are new to it. Only if: you can commit to 1 video per month and enjoy the recording process. Otherwise skip. A half-effort YouTube channel is worse than none.

Cadence Recap

Channel

Cadence

Time per unit

Blog (long)

1 per quarter

4-8 hours

Blog (short)

1 per sprint

1-2 hours

dev.to / Medium

Cross-post everything

10 min

LinkedIn

1-2 per sprint

20-30 min

Twitter/X

1-3 per week

5-10 min

YouTube (optional)

1 per month

10-20 hours

Budget roughly 10-15% of your Java hours for publishing. Not more. This is a support activity, not the main event. The main event is the code.

What To Write

Post ideas, ranked by learning-per-word:

High-value formats

  • “What I learned this sprint” — the retro turned public. Honest about what worked and what didn’t. Vulnerability signals credibility.

  • “The thing I got wrong” — write up a #surprised entry from your lab notebook. Explain the wrong mental model, the correction, the new mental model. This is the highest-value format in your entire toolkit.

  • “TIL X in Java 21” — short, focused, one feature. Great for LinkedIn.

  • “Benchmark: X vs Y” — with JMH raw output attached (see 03_benchmark_hygiene.md). These get shared.

  • “Notes on JEP N” — read a JEP, write a plain-English summary. Almost nobody does this and everyone appreciates it.

  • “How I built X” — project retrospective when you finish a phase project. Include what you’d do differently.

Low-value formats to skip

  • “5 tips for X” listicles — nobody remembers these and you learn nothing writing them.

  • “Java vs Python” flamebait — pointless.

  • Reposting someone else’s insight without adding your own experiment or angle — dishonest.

  • Motivational posts about your journey without technical content — they get engagement but they build an audience of people who want more motivational posts, not people who want to hire you as an engineer.

Post Template (Short Blog Post, 400-800 words)

# Title — one specific claim

**TL;DR:** one paragraph, the whole point.

## Context
What problem or question. 1-2 paragraphs.

## What I tried
Code. Actual code. Compilable if possible.

## What happened
Measured result. Benchmark numbers if applicable.
Before/after mental model.

## What I got wrong
The part that surprised me. Where my prediction was off.

## Takeaway
One sentence someone else can carry away.

Use it as a scaffold. It will feel constrained the first three times. By post 5, it will feel liberating.

The Vulnerability Rule

Write before you are an expert. Not after.

The strong instinct will be: “I don’t know enough yet. I’ll blog when I’m actually good at concurrency.” This is exactly wrong.

Beginner notes are more useful than expert notes for one specific reason: the beginner remembers the confusion. By the time you are an expert, you have forgotten what was confusing on day one. Your Phase 05 blog post about virtual threads, written while you are still slightly confused, is more useful to the next reader than a Brian Goetz post — not because you understand better, but because you understand the reader’s current confusion, which he does not.

The rule is: publish when you can explain the specific thing you just learned to your six-months-ago self. That is enough.

Do not wait for expertise. Expertise is what happens as a result of teaching.

Handling Being Wrong In Public

You will publish something wrong. Someone will correct you. This is not a disaster — it is the entire point of publishing.

Rules for being corrected:

  1. Thank the corrector. Genuinely. They just gave you a lab notebook entry for free.

  2. Update the post. Add a section: “Correction (2026-08-15): I was wrong about X. Actually Y. Thanks to @person for pointing this out.” Do not delete the wrong version. The correction is the value.

  3. Do not defend the wrong version. Ego is expensive. “I was wrong” is cheap. Say it fast.

  4. Never publish a takedown of someone else’s wrong post. Comment corrections privately or, if public, with kindness. Java Twitter is small; you will meet these people again.

A post with a public correction is a stronger signal than a post without one. It shows you learn.

Setup Checklist For Sprint 1

By the end of Sprint 1 (first two weeks), have all of this in place:

  • Personal blog live at some URL. Any URL. It does not need to be pretty.

  • hello-world post published on the blog — explains what the blog is about, your 13-month goal, and dates.

  • LinkedIn banner and headline updated to reflect “Java + ML engineer” positioning.

  • Twitter/X handle following: Aleksey Shipilëv, Nicolai Parlog, Brian Goetz, Josh Long, Marco Behler, at least 20 Java accounts.

  • dev.to account created.

  • First TIL tweet or LinkedIn post published.

All of this before the technical work is difficult. Because once Phase 03 hits, you will not have the energy for platform setup.

Next: 06_failure_modes.md Previous: 04_daily_practice.md