Learn in Public: What It Means and How to Start

Learn in public means sharing what you are learning while you learn it: notes, small projects, questions and mistakes, posted where others can see them. Instead of keeping a private notebook, you write a short post, push the repo or answer someone’s question. Shawn Wang (swyx) made the idea popular among developers with his essay “Learn In Public”. Done steadily, it can help you spot gaps sooner, get corrected by readers and build a public record of your work.

What does learn in public mean?

At its core, learning in public is making your learning visible. You do not wait until you are an expert to write. You write at the level you are at, for people one step behind you.

It can look like:

• A blog post explaining something you figured out yesterday
• A GitHub repo for a small project, with a clear README
• A thread on X summarizing a course chapter in your own words
• An answer on a forum to a question you struggled with last month
• A short video walking through a bug you fixed

The key is that the work is public and done while you learn, not after.

How is learning in public different from building in public?

The two are close cousins. Building in public is about a product: you share progress, decisions and sometimes numbers as you build something to sell. Learning in public is about a skill: you share what you understand as you learn.

	Learn in public	Build in public
Focus	A skill or topic	A product or business
Typical post	“Here is how X works”	“Here is what I shipped”
Audience	Learners one step behind	Users and other builders
Main payoff	Faster learning, reputation	Users, feedback, launch audience
Pressure	Low	Higher (it is your business)

Some developers start by learning in public and move into building in public once they have something to ship.

Why should developers learn in public?

The problem: learning alone

A common way to learn is in private: you watch tutorials, take notes nobody reads and quietly give up when you get stuck.

The cost

Private learning can be slow and fragile. You may not notice the gaps in your understanding, because nobody checks your work. When you get stuck, nobody knows to help. And when you finish, you have little to show for it beyond a certificate.

The fix

Learning in public flips each of those:

• Explaining forces understanding. If you cannot write it simply, you do not get it yet. Writing shows you the gaps.
• Mistakes get corrected. Post something slightly wrong and someone will often tell you. It stings, but corrections like that tend to stick.
• Your work becomes a portfolio. Posts and repos show what you can do in a way a resume line cannot.
• People find you. Over time, others who learn the same things start to follow, and some of them become friends, collaborators or employers.

What can you share when you learn in public?

You might feel you have nothing worth sharing as a beginner. In my view you usually do, because someone is a step behind you. Here are formats, roughly from easiest to hardest:

1. Today I learned (TIL) notes. One small fact, a code snippet and why it matters. Five minutes each.
2. Annotated bookmarks. Share a great article and add two lines on what you took from it.
3. Questions. A well-written question is a public contribution. Show what you tried.
4. Small projects. A finished weekend project with a README. If you need ideas, start with these coding projects for beginners.
5. Explainer posts. Teach a concept you recently understood, for someone who has not yet.
6. Talks or videos. Once you have written about something a few times, present it.

I have found the same thing with my own work: writing up what I learned shipping a product made the lesson stick far better than just shipping it.

How do you start learning in public?

Keep the first step small enough that you will actually do it.

1. Pick one place. A simple blog, GitHub, or X. A blog has the advantage that posts can keep getting found through search long after you write them.
2. Choose one topic you are learning now. Not your whole career. One language, framework or concept.
3. Publish one small thing this week. A TIL note or a project README is enough.
4. Set a light rhythm. One post a week is plenty. Consistency matters more than size.
5. Link your work together. Each new post can link to an earlier one. Over time it becomes a map of what you know.

Pair the writing with real code. Pick something from these programming project ideas, build it, and write down what surprised you.

What are the risks of learning in public?

It is worth being honest about the downsides:

• Being wrong in public. It will happen sometimes. Write with humility (“here is how I understand it”) and update posts when you learn more.
• Harsh replies. Some people online are rude. Ignore them, keep the useful part of the criticism and move on.
• Comparing yourself to others. There is almost always someone further ahead. Your audience is the person behind you, not the expert ahead.
• Writing instead of learning. If you spend more time polishing posts than coding, cut the posts shorter.

None of these are reasons to stop. They are reasons to keep posts small and honest.

Learn in public FAQ

Do I need to be an expert to learn in public?

No. That is the point of the practice. You write at your current level for people one step behind you, and you say clearly that you are still learning.

Where should I learn in public as a developer?

A personal blog and GitHub are a solid base. Add X or LinkedIn if you want conversation around your posts.

What if nobody reads my posts?

At first, few people will. The posts still help you learn, and they build a record that people may find later through search or links.

Can learning in public help me get a job?

It can help. Public projects and clear writing give a hiring manager something concrete to look at, beyond a resume. It is not a guarantee, but it gives you something to point to in an interview.

What is your next step?

Pick the thing you learned most recently, even something small, and write it up in under 300 words today. Publish it, then do it again next week. If you want to go further, read about what an indie hacker is: learning in public is a common first step before building in public.