Learning in Public: Benefits and Risks
Why sharing what you learn publicly is the fastest way to grow as an engineer — and the real risks to watch out for.
Learning in Public: Benefits and Risks
Most engineers learn in private. They read docs, watch courses, take notes in a personal Notion — and none of it leaves their laptop. Learning in public means flipping that: you document what you learn and share it openly as you go.
The term was popularized by Shawn Wang (swyx) in his 2018 essay "Learn in Public." His core advice: "Make the thing you wish you had found when you were learning." The primary beneficiary is yourself. The audience is a byproduct.
What it looks like in practice: blog posts, TIL repos on GitHub, Twitter threads, open source contributions, conference talks, YouTube tutorials, technical zines. The format matters less than the habit.
Benefits
Forces you to actually understand. The Feynman Technique says: try to explain a concept as if teaching it. Where your explanation breaks down, that is where your understanding has gaps. Writing a blog post forces exactly this process — the areas where you struggle to explain reveal what you still need to learn. This is why learning in public beats private notes.
Builds reputation and network. Kent C. Dodds describes the progression: join a help Discord, start answering questions, turn your answers into blog posts. Less than 1% of people do that last step. He built 211 blog posts read over 950,000 times, which led to conference invitations, podcast appearances, and course deals.
Creates serendipity. People find you through your content — job offers, collaborations, mentorship. swyx describes how public learning attracts mentors organically: "They notice genuine learners." Opportunities come to you instead of requiring cold outreach.
Builds a personal archive. Tania Rascia started blogging in 2015 while transitioning from professional chef to software developer. She describes it as "writing documentation for herself" — her blog became both a personal reference and a career asset.
Compounds over time. Old blog posts continue to rank in search, attract readers, and build authority long after you write them. Your first articles may get zero readers. Over years, the accumulated body of work creates returns you cannot predict at the start.
You do not need to be an expert. The most useful content often comes from someone one step ahead, not ten. A beginner explaining what confused them about Docker Compose is often more helpful than a Docker maintainer writing about container orchestration internals — because the beginner remembers exactly what was confusing.
Risks
Fear of being wrong publicly. This is the number one barrier. Dan Abramov — a core React team member — addressed this by publishing "Things I Don't Know as of 2018," a long list of technologies he did not understand. His point: admitting gaps does not diminish your expertise. But he also acknowledged he could afford that vulnerability partly because of his position.
Imposter syndrome amplified. Publicly exposing what you are still learning can intensify self-doubt. The pressure to "always be shipping content" creates stress if you tie your self-worth to audience metrics.
Harsh criticism and gatekeepers. The "well actually..." crowd is real. Technical communities can be hostile to beginners sharing imprecise knowledge. swyx's advice: "Try your best to be right, but don't worry when you're wrong." Treat corrections as free education, not attacks.
Early silence. Your first posts will likely get zero readers. It often takes years of consistent output before content creates meaningful returns. The compounding only works if you survive the period when nobody is watching.
Content production displacing deep learning. There is a real risk of optimizing for output over understanding — writing a tutorial about something you skimmed rather than deeply engaged with. If you spend more time formatting blog posts than working through problems, you have inverted the priorities.
Spreading misinformation. When you share things you are still learning, you may get them wrong. This is especially sensitive in security, performance, or architecture. The mitigation: be explicit about your confidence level and frame posts as "here's what I found" rather than "here's how you should do it."
How to Do It Well
Start small. TIL (Today I Learned) posts, not 5,000-word tutorials. A few sentences plus example code. Simon Willison and Josh Branchaud maintain public TIL repos on GitHub with hundreds of concise daily learnings — low friction, high compounding.
Be honest about your level. "I'm learning X, here's what I found so far" is more honest and more useful than pretending to be an authority.
Accept being wrong as a feature. Being publicly corrected is uncomfortable but free education. The discomfort is evidence of growth.
Pick one medium and be consistent. Do not try to blog, tweet, stream, and speak at conferences all at once. Pick the format that matches your style. Kent C. Dodds built his career through blog posts. Julia Evans through zines and a blog. swyx through essays and podcasts.
Optimize for your own learning, not audience. If you write to impress, you will burn out. If you write to understand, the audience comes as a byproduct.
The 1% rule works in your favor. In any online community, roughly 90% lurk, 9% occasionally contribute, and 1% actively create. By creating, you differentiate yourself from 99% of participants.
Formats That Work for Engineers
| Format | Effort | Good for |
|---|---|---|
| TIL repos | Very low | Daily micro-learnings, CLI tricks, API quirks |
| Blog posts | Medium | Tutorials, problem-solving walkthroughs, design decisions |
| Twitter/X threads | Low | Quick explanations, conference notes, hot takes |
| YouTube / Twitch | High | Coding walkthroughs, pair programming, project builds |
| Open source | Medium-High | Real skills demonstration, library improvements, docs |
| Lightning talks (5 min) | Medium | One focused insight, tool demos |
The recommended starting point: a TIL repo or short blog posts. Lowest friction, fastest feedback loop.
swyx's Learning Gears
swyx later expanded the concept into three modes:
- Explorer — broad, fast exploration. Output is notes, gists, tweets. You do not know what you do not know.
- Connector — the recommended default. You create content for others: tutorials, talks, cheatsheets. "You know things many don't know. Hence you should share that."
- Miner — deep specialization. You go deep in one area until you become synonymous with it.
Most people should spend the majority of their time as Connectors.
Key Takeaways
- Learning in public is learning for yourself, shared openly. The audience is a byproduct, not the goal.
- It forces you to clarify your thinking, builds reputation over time, and creates serendipity you cannot plan for.
- The risks are real: fear of being wrong, imposter syndrome, early silence, and the temptation to produce content instead of actually learning.
- Start with TIL posts or short blog entries. Be honest about your level. Accept corrections as free education.
- The 1% rule means that simply creating puts you ahead of 99% of people in any community.
- It compounds. The best time to start was years ago. The second best time is today.