Learning in Public

Table of content

Most developers learn in private. They consume tutorials, read docs, watch videos. Then move on without leaving a trace.

Learning in public means creating “learning exhaust”: blog posts, tutorials, talks, tweets, videos. You document what you learn as you learn it. The output doesn’t have to be polished. You’re talking to yourself from three months ago.

Shawn Wang (swyx) coined the term in 2018. It became a career strategy for developers: build in the open, share your process, let the internet correct you.

Why it works

Three mechanisms make learning in public effective:

Teaching forces understanding. You can’t explain what you don’t grasp. Writing exposes gaps in your knowledge. The Feynman technique, formalized.

You become searchable. 80% of developers never write or speak publicly. By producing content, you signal expertise you might not feel. When someone Googles a problem you solved, they find you.

Mentors find you. Senior developers notice genuine learners. They offer help, answer questions, share opportunities. You can’t buy this access. But you can earn it by being visible.

The golden rule

Make the thing you wish existed when you were learning.

Don’t optimize for likes or retweets. Write for past you. Keep an almost-daily dev blog written for no one else but yourself.

Others benefiting is bonus. The main audience is future you, reviewing what past you figured out.

What counts as learning exhaust

Swyx’s original list:

The format matters less than consistency. Pick what feels sustainable.

Avoid walled gardens like Slack and Discord for your main output. They’re not searchable. Put your best thinking where Google can index it.

Pick up what they put down

This is the “hack” version of learning in public.

Find people doing work you admire. When they ask for help (“Anyone want to tackle X?”), volunteer. When they release something, try it and give feedback. When they write about a problem, extend their thinking.

You help them. They notice you. They teach you. You amplify what they teach. Everyone wins.

This works because senior engineers are busy. They have more ideas than time. If you can execute on their ideas, they’ll invest in you.

The beginner’s advantage

“Why would anyone help me? There are so many junior developers.”

Because you have a beginner’s mind. You see problems experts have gone blind to. You can explain things at a level experts can’t reach anymore.

When someone teaches you, they teach everyone reading your output. You’re a force multiplier for their knowledge.

Handle being wrong

You will be wrong in public. This is the price of admission.

The mindset: try your best to be right, but don’t worry when you’re wrong. Wear your inexperience openly. When someone says you got it wrong, thank them. Ask them to explain why. Learn. Update your post.

Getting corrected by the internet is free education from experts who otherwise wouldn’t give you the time of day.

From public learner to paid expert

The progression swyx describes:

  1. You learn in public
  2. People notice genuine effort
  3. They start asking you questions
  4. You answer best you can, escalate what you can’t
  5. Eventually, people want to pay for your help

The timeline varies. But the pattern repeats: visibility creates opportunity.

Connection to digital gardens

Learning in public and digital gardens overlap but differ in emphasis.

Learning in public is a behavior: share what you learn as you learn it. Digital gardens are a format: a growing collection of notes organized by topic, not time.

Many practitioners combine both. They learn in public by tending a digital garden. The garden becomes a persistent knowledge base that compounds over time.

As swyx puts it: “Open source your knowledge.”

What You Can Steal

Start a TIL file. “Today I Learned” entries are low-pressure. One paragraph per day adds up. See the TIL System guide for implementation.

Talk while you code. Explain your thinking during pair programming or screen shares. This builds the muscle for public explanation.

Thank creators who teach you. Reach out to people whose content helped you. Ask a follow-up question. This starts relationships.

Clone projects to understand them. Rebuild tools you use from scratch. Write about what surprised you.

Make PRs to libraries you use. Documentation fixes count. You’re contributing and learning the codebase.

Summarize conferences. Attend talks, write up what you learned. Speakers notice and appreciate this.

See also: Digital Gardens covers the format for persistent public knowledge. TIL System walks through daily learning documentation.

Next: Digital Gardens

Topics: learning-in-public writing career content-creation