Learning in public changed how I build

For years I kept my work private until it was polished. I'd spend weeks refining a project, then share it once it looked impressive. The feedback loop was painfully slow, and much of what I built never saw the light of day.

About 2 years ago I started doing the opposite. I posted screenshots of half-finished UIs, shared code snippets that solved tricky problems, and wrote about decisions I was making in real time.

The results surprised me.

Why we hide our work

There's a deep discomfort in showing something unfinished. We worry people will judge the rough edges, or that someone more experienced will point out a better approach and make us look foolish.

I felt all of this. The first time I posted a work-in-progress screenshot, I rewrote the caption 4 times trying to preemptively address every possible criticism.

Nobody criticized it. A few people said it looked cool. One person asked how I built the gradient effect.

That interaction taught me something: many people are curious about the process. They want to see how things come together, not only the final result.

What actually happens when you share early

Three things changed once I started sharing consistently.

Feedback arrived when I could still use it. When you share a finished product, feedback becomes a list of things you wish you'd known earlier. When you share during development, feedback becomes input that shapes the outcome.

Someone once mentioned that a color scheme I was using had accessibility issues with low vision users. I fixed it in 5 minutes. If I'd waited until launch, it would have been a redesign.

People started reaching out. Founders, other developers, designers. They could see how I think.

Sharing process creates a connection that sharing results rarely does. 2 of my best client relationships started from someone seeing a random progress tweet.

I got better faster. When you know people are watching, you pay more attention to your craft. Explaining your decisions to an audience, even a small one, forces clarity in your own thinking.

What to share and what to keep private

Not everything belongs in public. Here's how I think about it:

Share freely: technical decisions and trade-offs, design iterations, problems you solved, things you learned, tools, and workflows that work well.

Keep private: client details without permission, revenue numbers you're not comfortable with, ideas you haven't started executing on, and anything that feels forced.

The best posts come from genuine moments of insight or struggle. "I spent 3 hours debugging this and missed a semicolon" is more relatable and useful than "Here are my 10 tips for productive debugging."

The consistency trap

When people start sharing publicly, they often try to post every day or maintain some rigid schedule. This burns out fast and produces mediocre content.

I post when I have something worth sharing. Sometimes that's 3 times in a week. Sometimes I go quiet for 2 weeks because I'm deep in a build and don't have anything interesting to show yet.

The audience doesn't care about your schedule. They care about the quality of what you share.

The useful consistency is showing up over months and years. Daily posts and weekly newsletters matter less than a pattern of sharing your work that people can rely on seeing when they check in.

Start with what you're already doing

You can make parts of your existing work visible without creating a second content job for yourself.

Building a feature? Screenshot the before and after. Solved a bug? Write 3 sentences about what went wrong.

Learned a new library? Share the thing about it that surprised you.

The work is already happening. Sharing opens a window into it.

If you've been sitting on work waiting until it's ready to show, consider that it might already be interesting enough. The unfinished version, with all its rough edges and open questions, might be exactly what someone else needs to see today.