Back to Blog

Lessons from Building in Public

6 min read
metaindie-hackinglearning

Lessons from Building in Public

There's a particular anxiety that comes with putting your work on the internet. Unlike a university assignment where only your professor sees it, or a job where feedback is limited to colleagues, building in public means strangers see your code, your decisions, your mistakes.

Over the past year, I've deliberately shifted toward building more of my projects publicly—sharing on GitHub, writing about my process, documenting failures alongside successes. This has been one of the most valuable decisions I've made as an engineer, but the journey to get here was filled with self-doubt.

The Impostor Syndrome Trap

I spent years as a "private builder." I'd write code, get it working, but then I wouldn't share it. My internal monologue was something like:

"This code isn't polished enough. What if someone finds a bug? What if someone smarter than me looks at this and judges my abilities? What if I make a mistake and someone corrects me publicly?"

These fears are understandable but ultimately paralyzing. And they're based on a faulty assumption: that the value of your work is your personal worth as an engineer.

Sharing publicly taught me something different. Your code doesn't have to be perfect. Your solutions don't have to be novel. Your understanding doesn't have to be complete. What matters is that you're learning, iterating, and willing to be transparent about it.

When someone corrects you in a GitHub issue, that's not a failure—that's feedback. It's a chance to improve. And more importantly, other people reading that exchange get to see how you handle feedback, which is often more valuable than the code itself.

What Changed

1. Better Code Quality

Ironically, knowing people would see my code made me write better code. I added comments where I usually wouldn't. I wrote tests more rigorously. I didn't just get something working, I thought about whether someone unfamiliar with the project could understand the code.

This is a positive side effect. You're naturally incentivized to do better work.

2. Real Feedback

When you build in private, your feedback loop is limited to your own perspective. You only find issues you think to look for. When you build in public, other people point out problems, edge cases, and improvements you didn't consider.

I had someone fork one of my projects and add a feature I'd never thought of. I had someone report a bug that only manifested on certain systems I don't have. I had someone refactor a section of code and show me a more elegant approach.

All of this feedback was free. In a corporate setting, this kind of code review would be part of your job. Publicly, people volunteer it.

3. Unexpected Opportunities

Putting work publicly opens doors you don't expect. People reach out asking for help. People invite you to contribute to their projects. People recommend you for opportunities based on code they've seen.

This isn't why I built in public (validation should be its own reward), but it's been a real benefit. Some of my best professional opportunities came through demonstrating competence publicly.

4. Reduced Anxiety Over Time

The first time you post your code online, the anxiety is real. Will people judge me? Will I regret this?

After a few months, you realize: nobody cares as much as you think they do. People are busy with their own projects. A handful of people will genuinely engage with your work. Most will scroll past.

And of those who engage, most are kind. They understand that learning is a journey. Even critical feedback is usually delivered respectfully and constructively.

Over time, this reduces the anxiety substantially. You realize that being transparent about your learning process isn't a vulnerability, it's actually endearing.

Practical Lessons

1. Document Your Thinking

When you build publicly, explain not just what you did, but why. What problem were you solving? What alternatives did you consider? What trade-offs did you make?

This is valuable for two reasons:

  • It helps others understand your work
  • It forces you to think deeply about your decisions

Often, while writing an explanation, you realize a flaw in your thinking. This is a feature, not a bug.

2. Embrace the Process

One instinct is to only share "finished" projects. Resist this. Share projects in progress. Share failed experiments. Share half-baked ideas.

Some of my most engaged GitHub repositories are ones that are clearly unfinished. People appreciate the transparency. They understand that real engineering is messy.

3. Write for Your Future Self

When you build publicly, you're partly writing documentation for your future self. Next year, when you come back to a project, you'll be grateful for clear comments and thoughtful commit messages. And if someone else contributes, clear documentation helps them understand your vision.

4. Handle Criticism Gracefully

You'll get criticism. Some will be constructive, some will be harsh, and some will be misguided. The key is developing a thick skin without becoming defensive.

The framework I use: If 3+ people mention the same issue independently, there's probably something there. If it's one critical voice, weigh their expertise before taking action. And always remember: a criticism of your code isn't a criticism of you.

On Sharing Failures

One anxiety I had was sharing failures. What if my distributed systems implementation had bugs? What if my robotics project lost a competition?

Sharing this honestly has been incredibly valuable. When I write about a bug I encountered and how I fixed it, people learn from the experience. When I discuss a tournament loss and what I'd do differently, others going through the same thing find comfort and actionable advice.

Failures are often more educational than successes. And sharing them publicly amplifies their educational value.

Conclusion

Building in public isn't for everyone. If you're in a very competitive field where proprietary advantages matter, or if you have strong privacy concerns, there are good reasons not to.

But if you're learning and growing, sharing your work publicly amplifies the learning. You get feedback, opportunities, and a community. The anxiety fades quickly. And you might be surprised by how much value you provide to others by being transparent about your journey.

Start small if you need to. Share one project. See how it feels. You might find that the vulnerabilities you feared become your greatest strength.