Building side projects in public is the single most effective way to grow as a developer and build a real career. I’ve hired developers, and I’ll always choose the candidate with a messy, public GitHub over the one with a polished resume and no visible work. Your public portfolio is your proof of skill, and it starts with shipping code others can see.
When I started sharing my work, even the unfinished parts, it transformed how I learned and connected with opportunities. It’s not about vanity metrics; it’s about creating a verifiable track record. Here’s why you should start today and how to do it right.
How to start building in public without burning out
The biggest mistake is aiming for a monumental, perfect launch. You’ll never ship. Instead, start with a tiny, useful script or a clone of a feature you find interesting. The goal is to establish the habit of committing and pushing, not to build the next big thing.
I began by automating a tedious data-fetching task I did manually at work. I put the 150-line Node.js script on GitHub. It was trivial, but it solved a real problem. That first repository was the catalyst. Your initial project should take a weekend, not a month. Consistency beats intensity.
// Example: A simple, public utility function
// This is the type of focused, reusable code that makes a great starting point.
/**
* Formats a timestamp into a relative time string (e.g., "2 hours ago").
* Published as part of a date-utils library on my GitHub.
*/
export function formatRelativeTime(timestamp: number): string {
const now = Date.now();
const diffInSeconds = Math.floor((now - timestamp) / 1000);
if (diffInSeconds < 60) return 'just now';
// ... rest of logic
}
What should you actually put on your public GitHub?
Everything that isn’t proprietary to your employer. This includes:
- Learning experiments: Tutorial code, algorithm implementations, new framework explorations.
- Problem solutions: Scripts that fix a specific annoyance.
- Project skeletons: Your preferred, opinionated starter templates for Next.js, Express, etc.
- Failed projects: These are incredibly valuable. They show you can navigate dead ends.
The key is to write clear READMEs. A README should explain the why, the how, and the what. Documenting your thought process is as important as the code itself. It turns a repository from a code dump into a story.
Do you really need to write about your projects?
Yes. Code alone doesn’t communicate context. Writing a short technical blog post—even on Dev.to or Hashnode—about a challenge you solved forces you to understand it deeply. It also makes your work discoverable.
I write about my projects on suhailroushan.com. Explaining how I debugged a tricky WebSocket memory leak or designed a database schema solidified my own knowledge and led to direct consulting inquiries. Your writing is the narrative that frames your code.
How public building leads to real opportunities
A public profile acts as a continuous, passive outreach tool. Recruiters and founders use GitHub search. When they find your active profile with documented problem-solving, you’re no longer a resume; you’re a known quantity.
I founded Anjeer Labs based on expertise demonstrated through public work. Clients have approached me because they saw a specific library or technical deep-dive that matched their need. This would never happen if my work was trapped in private repositories. Your next job or client is more likely to find you through your public code than a job application.
When should you keep a project private?
Only when it contains sensitive data (API keys, personal data), is directly owned by your employer, or is an unfinished core product for a startup you’re monetizing. The fear that someone will "steal your idea" is vastly overrated. Execution is everything, and public validation early on is more valuable than secret, misguided work.
Start by making your next learning project public from commit #1. That’s the habit.