Why sharing work early is hard
The perfectionist instinct is real. You want the code to be clean, the README complete, the demo polished. So you keep working in private — and nothing ships.
Ship the ugly version first. You can always improve it later, but you can't improve what doesn't exist.
The moment I started pushing half-finished projects to GitHub, something shifted. People filed issues. Some even sent PRs. The project moved faster than when I was alone.
What "building in public" actually means
It doesn't mean live-streaming every keystroke. It means:
- Tagging releases even when the software is rough
- Writing a changelog — even one line per version
- Documenting the why, not just the what
- Answering issues promptly, even to say "not sure yet"
Building in public is a long game. The audience compounds slowly, but the feedback loop is immediate.
On imposter syndrome
It's permanent. Senior engineers feel it. The trick is to reframe it:
"I don't know enough to do this" → "I don't know this yet, so I'll learn it while doing it."
That reframe is the whole game.
A concrete example
Here's the commit message that started this site:
git commit -m "init: next.js skeleton, nothing works yet"
Terrible software. Shipped anyway. Now it has a blog.
Don't let "building in public" become a substitute for actually building. Post less, ship more.
Takeaways
- Small consistent progress beats large sporadic bursts
- Feedback from strangers is worth more than your own assumptions
- The fear of judgement fades after the first few pushes
- Nobody is watching as closely as you think — until suddenly they are
More posts as things get built. See you next time.