"Learn in public" is solid advice that's quietly destroyed a lot of people's relationship with learning. The pitch is true: write about what you're figuring out, share your projects, and you'll learn faster, build a network, and maybe a reputation. What the pitch leaves out is that doing it the obvious way — loudly, constantly, performatively — is a fast track to burnout. The skill isn't sharing. It's sharing sustainably.
I've done both versions. The frantic one nearly put me off writing entirely. The slower one I've kept up for years. Here's what separates them.
The trap of the performance
The moment learning becomes content, something subtle shifts. You start choosing what to learn based on what makes a good post rather than what you actually need to know. You feel pressure to always be shipping something shareable, and the quiet, unglamorous study that real depth requires — rereading, getting stuck, sitting confused for days — doesn't photograph well, so you skip it. You end up optimising for the appearance of learning over the thing itself.
Then there's the metrics. Once you're posting publicly, the likes and the silence both start to matter, and they're terrible teachers. A genuinely useful thing you learned might get no engagement; a shallow hot take might fly. If your motivation hooks itself to that feedback, you're no longer learning in public — you're performing in public, and performance is exhausting in a way that learning isn't.
Share the artifact, not the performance
The version that lasts treats sharing as a byproduct, not a goal. You learn the thing for your own reasons, and then — because you took notes anyway — you tidy those notes into something others can use. The post is the exhaust of real learning, not its engine. This flips the pressure: you're never short of things to write because you're always learning something, and you only publish when there's a real artifact worth publishing.
It helps to lower the stakes of any single piece. Not every share needs to be a polished tutorial. A short "here's a thing that confused me and how I worked it out" is often more useful to a beginner than a grand definitive guide, and it costs you almost nothing. Resources like freeCodeCamp's news archive are full of exactly these — modest, specific write-ups from people one step ahead — and they're more helpful than most attempts at the comprehensive masterpiece nobody finishes.
Protect the private part
The most important habit is keeping some of your learning private. Not everything has to be content. You need space to be bad at things without an audience, to explore dead ends nobody will ever read about, to learn purely because you're curious with no thought of how it'll play. If every hour of study carries an implicit "what's the post?", learning stops being a refuge and becomes another job with a deadline.
Sustainable public learning, then, looks oddly quiet. You share less than the loud accounts and you share it less often, but you keep doing it for years instead of flaming out in six intense months. The compounding comes from consistency, not volume — a modest post every few weeks for a decade beats a daily torrent that ends in resentment by spring.
So learn in public, genuinely — it's still good advice. Just don't let the public part colonise the learning. Take the notes for yourself, publish the ones that might help someone, keep a private corner where you're allowed to be a beginner, and ignore the numbers. Do it that way and you'll still be sharing, and still enjoying it, long after the performers have burned out and gone quiet.
