I'm trying a bit of both, and neither is free.

"Learn in public" has become a slogan. Like most slogans, it hides trade-offs. This post lays them out honestly, describes the compromise I'm testing, and offers a few rules for publishing things you're not fully sure about.

What "learning in public" means

It means sharing the process, not just the polished result: notes, small projects, questions, mistakes, half-formed ideas. The opposite, learning in private, means working things out on your own and showing the finished version, if at all.

Neither is better in general. They trade different costs.

Costs of public learning

You'll be wrong where people can see it

That's uncomfortable, and it's the main reason people don't do it. A wrong blog post stays findable, and it can feel like a permanent mark.

A way to think about it: most readers forget a wrong post quickly, and the ones who correct you are giving you a free lesson. But the discomfort is real and shouldn't be dismissed.

It takes time from building

A post, a thread or a video takes hours. Those hours aren't spent on the project. Done carelessly, writing about learning replaces learning.

Comparison

Public spaces show other people's polished results next to your messy middle. That makes it easy to feel behind. It's worth remembering you're comparing your process to their finished product.

The pull toward performance

When people can see you, there's a temptation to learn what looks good instead of what's useful, or to sound more certain than you are.

Costs of private learning

No feedback, so mistakes harden

If nobody sees your work, nobody tells you the thing you've been doing for a year is a bad habit. Feedback is the fastest way to find blind spots, and privacy shuts it off.

Nothing visible to show

When you're early in a career, visible evidence matters. A private skill is invisible to anyone deciding whether to give you a chance.

Isolation

If few people around you share your interest, working in private can feel lonely, and loneliness is a leading cause of giving up.

A compromise I'm testing

Learn in private, publish what I've verified.

  • If I can reproduce something, it can be a post.
  • If I'm unsure, the text says "I think" or "as far as I can tell".
  • If I've measured something, I say how. If I haven't, I say that too. (Whiteboard.ai's AI eval is a good example: I state plainly that it's written but not yet run.)
  • Opinions are labelled as opinions.

This keeps the public record accurate while still sharing early enough to get feedback.

Rules for publishing when you're not sure

  1. Separate facts from beliefs. "This query uses an index" is a fact you can check. "This is the best design" is a belief.
  2. Show the evidence. A command, a result, a link.
  3. State the limits. Where might this be wrong? What did you not test?
  4. Invite correction. End with a question, and mean it.
  5. Fix publicly. If someone corrects you, update the post and say what changed. It builds more trust than it costs.

Small ways to start

You don't need to begin with a blog.

  • Comment helpfully on other people's posts.
  • Answer a question you recently learned the answer to.
  • Share a short note instead of an essay: "Today I learned X, here's the smallest example."
  • Keep a public changelog of what you shipped.

Any of these is far less effort than a full article and gives you most of the feedback benefit.

What I'm hoping for from this series

Corrections in the comments. They teach faster than reading alone, and they're reason enough to keep writing in public. If I've got something wrong in any of these posts, please tell me, and I'll fix it and say what I changed.

A four-week "learn in public" starter plan

Gentle, and designed to survive a busy week.

Week 1: Notice. Keep a note on your phone of things you learned or fixed. One line each. No publishing yet.

Week 2: Shape. Pick the note that taught you the most. Write it as five short sections: the problem, what I tried, what worked, what I'm unsure about, a question.

Week 3: Share small. Post it somewhere you'll get responses: a developer community, a social post, a short article. Keep it under 500 words.

Week 4: Respond and refine. Reply to every comment. Correct what's wrong. Write down what you'd do differently.

By week four you've done the whole loop: capture, shape, share, learn from feedback.

Handling criticism

Public work gets public feedback. Not all of it is equally useful.

Type Example What to do
Correction "That query has an injection risk" Thank them, verify, fix, and update the post
Suggestion "You could use X instead" Consider honestly; reply with your reasoning
Disagreement "I think this approach is wrong" Ask for their reasoning; you might both be partly right
Noise Rudeness without content Ignore or mute; you owe no one a debate

A simple rule: respond to the content, not the tone. If the tone makes it impossible, step away for a day.

Publishing things you're unsure about

Use hedges honestly, not as armour.

  • "I tested this on X and it worked." (Specific, checkable.)
  • "I believe this works because…" (Reasoned but unverified.)
  • "I haven't tested the case where…" (Honest about the edge.)

Avoid hedging everything. A post where every sentence is "maybe" is as unhelpful as one where every sentence is certain.

Protecting yourself

Learning in public has real downsides worth managing:

  • Privacy. Don't publish your street address, phone number or anything that helps strangers find you. City and country is plenty.
  • Employer or school rules. Check whether you can discuss certain work publicly.
  • Secrets. Never paste API keys, tokens or private data into a post or screenshot. Scan images before publishing.
  • Pace. You're allowed to take a break. A paused blog is better than a burned-out writer.

What to share, and what to keep

Good public learning material:

  • A bug and how you fixed it.
  • A decision and the trade-offs.
  • A small tool or script.
  • A summary of something that confused you, once it stops confusing you.

Better kept private (at least at first):

  • Half-finished arguments you don't believe yet.
  • Anything about other people that they haven't agreed to.
  • Venting about teammates or employers.

The long game

Public learning compounds slowly. Most posts get few readers. A few get found months later by someone who needed exactly that. Treat each one as a lottery ticket you also learned from while writing. The learning is guaranteed; the audience isn't.

Key takeaways from day 19

Which side do you lean toward, and what's held you back from the other?

☕ Enjoyed this post? You can support my writing on Ko-fi.

Support me on Ko-fi