I built a stupid little weather app last October. Nobody asked me to. Nobody was paying me for it. I just wanted to mess around with a new API I'd found, and three weekends later I had this janky thing that told you the weather in emoji form.

It was terrible. The icons were wrong half the time. It crashed on iPhones. My friend called it "aggressively ugly."

But here's what's weird — I learned more from that dumb project than I did in six months at my day job.

The day job problem

Don't get me wrong. I like my job. The team's solid. The pay's fine. But after two years of working on the same enterprise codebase, I realized something uncomfortable: I wasn't really learning anymore. I was just... maintaining.

Fixing bugs in code someone wrote in 2019. Adding features to a system I didn't design. Following patterns someone else established. It's good, honest work. But it doesn't stretch you.

And that's the trap, right? You get comfortable. You know where everything lives. You can fix most issues from muscle memory. Your brain stops having to actually think hard about anything.

I didn't notice it was happening until I tried to build something from scratch and realized I'd forgotten how.

Starting from zero is humbling

My weather app forced me to make decisions I hadn't made in years. What framework? What hosting? How do I structure the folders? What's my deployment story?

At work, all of that was decided before I joined. I just followed the existing patterns. Which is fine — that's how teams work. But it meant I'd been coasting on someone else's architectural decisions for two years.

The weather app had no architecture. It was just me, a blank VS Code window, and a vague idea. And honestly? The first version was a mess. I put everything in one file. I hard-coded the API key right in the frontend. I didn't even have error handling.

But I shipped it. To my three friends who humored me by actually using it.

What I actually learned

The technical stuff was nice — I picked up some React patterns I hadn't used before, figured out how Vercel's edge functions work, got better at CSS grid (finally). But the real lessons were softer than that.

I remembered what it feels like to be stuck with nobody to ask. At work, I can ping a senior dev on Slack. On my side project at 11 PM on a Saturday? It's just me and Stack Overflow. That kind of problem-solving muscle atrophies if you don't use it.

I also learned that shipping something imperfect is way more valuable than planning something perfect. I spent zero time on architecture diagrams or technical specs for the weather app. I just built stuff, broke stuff, fixed stuff. The iteration speed was incredible compared to the three-sprint planning cycles at work.

And — this sounds corny but whatever — I remembered why I got into programming in the first place. Not because I wanted to maintain enterprise CRUD apps. Because building things is fun. Making something exist that didn't exist before is genuinely exciting, even when it's small and stupid.

You don't need a big idea

I think people overthink side projects. They want to build the next big thing, so they never start. Or they start something ambitious, get overwhelmed, and quit.

My advice? Build something useless. Seriously. A weather app nobody needs. A bot that tells you a random fact every morning. A website that just shows pictures of your cat.

The point isn't the product. The point is that you're making decisions, hitting walls, solving problems, and shipping code without anyone telling you what to do. That's where the growth happens.

I'm working on a new side project now. It's equally pointless — a Chrome extension that replaces every stock photo on the internet with pictures of dogs. Will anyone use it? Probably not. Will I learn a bunch of stuff about browser extensions that I can bring back to my day job?

Already have.