Why I Started Building in Public (And Why You Should Too)

About a year ago, I started putting my work on GitHub not just finished projects, but works in progress, experiments, and even the occasional embarrassing commit message. It felt vulnerable at first. Now I think it's one of the best decisions I've made as an engineer. The Myth of the Perfect Portfolio For a long time, I waited until something was "finished" before I'd show it to anyone. I wanted my GitHub to look like a highlight reel polished repos with great READMEs and clean commit histories. The problem is that "finished" is a myth in software. Every project I've shipped has rough edges. Every codebase I'm proud of started as something messy. Waiting for perfection meant waiting forever. Building in public forced me to let go of that. Now I commit regularly, document my thinking in README files, and don't stress about imperfect code. The result? I've learned faster, gotten better feedback, and built a portfolio that actually reflects how I work. What You Learn by Teaching When you write about what you're building even just in commit messages and documentation you're forced to articulate your thinking. And articulating your thinking reveals gaps you didn't know you had. I've caught bugs while writing READMEs. I've realized my architecture was wrong while explaining it in a comment. The act of teaching, even to an imaginary reader, sharpens your own understanding. The Network Effect Open source work compounds. A project you built two years ago can still get stars, issues, and pull requests today. People you've never met can learn from your code and improve it. Collaborations happen organically. I've gotten job leads, mentorship conversations, and genuine friendships from open source work. Not because I was trying to network, but because I was doing work in the open that other people found useful. Getting Started You don't need a viral repo to build in public. Start small. Comment your code as if you're explaining it to a junior developer. Write honest READMEs that include what didn't work, not just what did. Share your learning process on GitHub Discussions or a blog. Don't delete projects — a broken experiment still tells a story. The engineers I respect most aren't the ones with the most impressive portfolios. They're the ones who build in the open, learn out loud, and make the rest of us better in the process.