You solved a problem at work last Tuesday. Took you three hours. The fix was two lines of code, but finding those two lines required reading four Stack Overflow threads, two GitHub issues, and a blog post from 2019 that was mostly wrong but contained one crucial insight in the comments.

You moved on. The knowledge lives in your head now, and nowhere else.

Next month, someone else will spend three hours on the same problem. Maybe it’s a colleague. Maybe it’s a stranger. Maybe it’s you, having forgotten the fix.

This is the case for learning in public. Not as a personal brand strategy. Not as content marketing. Just as a practical habit of leaving breadcrumbs.

#What “Learning in Public” Actually Means

The phrase comes from Shawn Wang (swyx), who wrote about it in 2018. His argument was simple: the fastest way to learn is to create “learning exhaust” — blog posts, tutorials, notes, anything that documents what you’re figuring out.

The idea caught on, especially among developers. But somewhere along the way it got tangled up with personal branding advice, content calendars, and Twitter engagement strategies. The original impulse — just write down what you learned — got buried under a layer of performance anxiety.

Andy Matuschak has a better metaphor for what this should feel like: working with the garage door up. You’re in your garage, building something. The door happens to be open. You’re not performing for an audience. You’re not optimizing for reach. Someone walking by might glance in and learn something. That’s it.

The garage door framing removes the pressure that makes learning in public feel exhausting. You’re not creating content. You’re just not hiding your work.

#Why Most People Don’t Do It

It’s not laziness. It’s friction.

You learn something interesting. Writing it down would take ten minutes. But publishing it? That’s a different story. You need to open your blog’s CMS, or push to a git repo, or figure out why your static site generator broke after the last dependency update.

By the time you’ve dealt with the publishing infrastructure, the impulse to share has passed. You had a ten-minute idea and a thirty-minute publishing process, and the math doesn’t work.

So the knowledge stays private. Not because you decided it wasn’t worth sharing, but because sharing was harder than not sharing.

The habit of learning in public lives or dies on this ratio. If publishing is nearly as easy as not publishing, you’ll do it. If there’s a meaningful gap, you won’t — no matter how good your intentions.

#What to Actually Write

Here’s where people overthink it. They imagine learning-in-public posts need to be polished tutorials or comprehensive guides. They don’t.

The most useful format is the simplest: what I was trying to do, what went wrong, what fixed it.

That’s it. Three paragraphs and you’ve saved someone three hours.

Other things worth writing down:

• The thing that surprised you. “I assumed X worked like Y. It doesn’t. Here’s why.” These posts age incredibly well because they capture common misconceptions.

• The comparison you couldn’t find. “I evaluated these three libraries for this specific use case. Here’s what I found.” This is the kind of post that AI answer engines love to cite, because it’s specific and experiential.

• The thing you just learned. Not a tutorial. Just a clear explanation of a concept, written for yourself three months ago. Swyx’s original advice was exactly this: “make the thing you wish you had found when you were learning.”

• The decision and why. “I chose Postgres over SQLite for this project because…” Decision logs are useful to your future self and to anyone facing the same choice.

None of these require expertise. They require honesty about where you are in the learning process. A beginner’s perspective on a topic is often more useful to other beginners than an expert’s.

#The Compound Effect

One post doesn’t do much. Fifty posts over two years changes your career.

Not because you’ll go viral. Most learning-in-public posts get single-digit views. That’s fine. The value compounds in ways that aren’t visible in analytics.

You build a search-indexed body of work. When someone googles the same problem you solved, your post is a candidate to appear. Not every time. But often enough. And increasingly, it’s not just Google — it’s ChatGPT, Perplexity, and AI Overviews pulling from the same pool of documented human experience.

You clarify your own thinking. Writing forces you to find the gaps in your understanding. The Feynman technique isn’t just a study hack — it’s what happens naturally when you try to explain something you just learned.

You become findable. Not famous. Findable. When someone searches for a specific problem and lands on your post, they see a real person who solved a real problem. That’s more valuable than any LinkedIn optimization.

You build a reference library for yourself. Half the value of learning in public is being able to search your own blog six months later when you’ve forgotten how you fixed something.

#Keep the Bar Low

The enemy of learning in public is quality standards.

If you wait until a post is “good enough,” you’ll publish once a quarter. If you publish things that are merely accurate and helpful, you’ll publish weekly.

A rough post that exists is infinitely more useful than a polished post that doesn’t.

This doesn’t mean publishing garbage. It means accepting that a blog post can be four paragraphs long. It can have no introduction. It can start with “Here’s how to fix X” and end when you’ve explained how to fix X. No conclusion. No call to action. No “I hope this helped!”

The blog post is a byproduct of your learning. Treat it like one.

#The Publishing Setup That Gets Out of Your Way

The reason I keep coming back to this topic is that the tooling matters more than people admit.

If publishing requires five steps, you’ll do it when you’re motivated. If it requires one step, you’ll do it when you have something to say. Those are very different frequencies.

The ideal setup for learning in public:

1. Write in whatever app you already use. Obsidian, iA Writer, VS Code, a plain text editor — it doesn’t matter. Don’t adopt a new tool just for blogging.

2. Save as Markdown. It’s the lingua franca of technical writing, and it keeps your content portable. But even if you’re not technical, Markdown is just text with a few symbols for formatting.

3. Publish by saving a file. This is where most setups fail. The distance between “I wrote something” and “it’s on the internet” should be as close to zero as possible.

This is what I built FolderPress to do — you drop a Markdown file in a folder, and it’s a blog post. No build step, no deploy command, no CMS dashboard. But the principle applies regardless of what tool you use: minimize the gap between writing and publishing.

The best learning-in-public setup is one where you forget you have a blog, right up until the moment you save a file into a specific folder. Then you have a blog again.

#Start Before You’re Ready

You don’t need a content strategy. You don’t need a niche. You don’t need to know who your audience is.

You need to solve a problem, learn something, or form an opinion — and then write it down somewhere that isn’t just your notes app.

The garage door is already there. You just have to leave it open.