Building in Public: What 60 Days of Coding Taught Me (And Why I Shared My GitHub)

#buildinpublic #webdev #learning #github

Let’s be honest: starting a coding challenge is easy. Opening your IDE on Day 1 with high hopes, clean folders, and big dreams takes zero effort. But what happens when Day 15 rolls around, life gets chaotic, and your logic breaks at midnight?

Over the last 60 days, I decided to stop just reading about development concepts and actually build things out in the open. I pushed code step-by-step to my GitHub account (@ayindeyusuf1999-max), dealt with the messy reality of debugging, and came out the other side with a clearer head and stronger skills.

Here is the honest breakdown of how the journey went, what I learned, and why building in public changes everything.

Why I Decided to Share My GitHub Account

When writing a tech blog or sharing a milestone, dropping a link to your repository is the ultimate proof of work. Anyone can write about how they planned to code, but green contribution squares and commit histories don't lie.

If you visit my profile, you won’t find overly polished, corporate-perfect repos—you’ll find real experimentation, messy commits, and iterative fixes. That is what growth actually looks like.

📌 Check out my profile & repos: You can view all my code, commits, and projects on GitHub at github.com/ayindeyusuf1999-max.

The Reality of the Journey

Phase 1: The Initial Spark (Days 1–20)

The beginning felt amazing. Setting up the repo, mapping out the architecture, and getting the first core features working gave me an incredible rush of momentum.

Phase 2: Facing the Wall (Days 21–40)

This was the danger zone. Motivation dipped, bugs started multiplying, and edge cases I hadn't anticipated completely derailed my schedule for a few days. Instead of quitting, I learned to slow down, break problems into tiny chunks, and lean on commit messages to keep track of my thoughts.

Phase 3: Crossing the Finish Line (Days 41–60)

The final stretch wasn't about adding fancy new features; it was about refactoring, cleaning up messy code, and making sure everything actually worked smoothly.

3 Key Takeaways for Anyone Doing a Challenge

Commit often, write clear messages: Your future self (and anyone reading your blog) will thank you when your commit history tells a clear story of how you solved a problem.
Embrace the mess: Not every line of code needs to be a masterpiece on the first try. Writing bad code and refactoring it later is a core part of the process.
Consistency beats perfection: Showing up for 30 to 45 minutes every day does way more for your skills than waiting for an elusive 8-hour weekend block of free time.