Learning in public changed how I build

For a long time, I kept work private until it looked finished. That made sharing feel safe, but it also meant feedback arrived after I'd become attached to the result.

I now prefer to show a small piece while I can still change it. A screenshot, a short recording, or a note about a decision is usually enough. I don't need to turn the whole project into a public diary.

Give people something to respond to

An unfinished screen on its own tends to get reactions about how it looks. That's fine if appearance is what I'm testing. If I'm unsure about the interaction, I need to show the interaction and ask about it.

“Does this make sense?” is difficult to answer usefully. A narrower question helps: can you tell which account this action affects? Would you expect this panel to stay open after saving?

I try to include enough context to make the question answerable without writing a case study. What was I trying to do, what did I try, and which part am I unsure about?

That also makes the post useful to someone who finds it later. They can understand the decision instead of seeing a screenshot with “work in progress” underneath.

Feedback needs interpretation

Public comments come from whoever happens to see the work. They may not use the product, share the intended user's constraints, or know what came before this screen.

I can still learn from them. A person noticing that text is hard to read doesn't need the full product brief. A request to add a major feature needs more context before it belongs on the roadmap.

I try to separate observations from proposed solutions. “I didn't notice the save button” is evidence worth investigating. “Make the button red” is one suggestion for what to do about it.

Some work should stay private

Before posting a screenshot, I check names, email addresses, browser tabs, and anything visible behind the main window. Demo data helps, but it still needs a second look.

Client work needs permission. So do customer quotes and internal discussions. A lesson can often be explained without identifying the project or exposing its data.

I also don't owe the internet a running account of every uncertainty. Some decisions need a quiet conversation with a colleague. Some experiments aren't interesting until I've understood why they failed.

Keep it attached to the work

A daily posting target can turn a useful habit into another production schedule. I don't want to invent a lesson because I haven't posted recently.

The material is already in the work: a bug with a surprising cause, two versions of a flow, a constraint that forced a different approach. When there's something worth sharing, I can capture it while the details are still fresh.

The most useful posts leave room for someone to change my mind. “Here's what I tried, and here's the part I haven't solved” is a perfectly good place to stop.