Building Things Nobody Asked For: On Side Projects and Self-Education

My first real project was a command-line to-do app that I never used. It had no features anyone would want — no reminders, no priorities, no persistence across sessions. When you closed the terminal, everything vanished. I spent three weekends on it. I was proud of it in a way I still find hard to explain.

There is a particular kind of learning that happens when you build something no one asked for, with no deadline, no grade, and no one watching. It is slower than following a tutorial and messier than reading a textbook. But it is also, I think, the kind of learning that actually sticks.

The tutorial trap The internet has made it easier than ever to feel like you are learning. There are free courses on everything — data structures, machine learning, web development, systems programming. Platforms reward completion. Certificates pile up. Progress bars fill.

But there is a difference between understanding a concept as it is explained to you and understanding it well enough to use it when no one is guiding you. The first kind of knowledge is borrowed. The second is yours.

I spent months consuming content before I built anything. I watched videos on algorithms while lying in bed. I read documentation I did not quite understand. I felt productive because I was always absorbing something. The problem was that absorbing is passive. You can follow every step of a tutorial perfectly and still freeze when you open a blank file.

Why the blank file is the real teacher When you sit down to build something without instructions, the first thing you encounter is not a technical problem. It is a design problem. What should this thing actually do? What is the smallest version of it that is worth building? How do I even begin?

These questions do not appear in tutorials because tutorials have already answered them for you. The problem is pre-scoped. The solution is pre-validated. Your only job is to type fast enough to keep up.

Side projects strip all of that away. You are left with a vague intention and a cursor blinking at you. That discomfort — that gap between what you want to make and what you know how to make — is precisely where learning happens.

The to-do app that forgot everything when you closed it taught me more about program state than any lecture on the topic. Not because I read about state, but because I was confused about it, made wrong assumptions, and had to trace through my own code to figure out where things were going wrong.

The embarrassment is part of it Most side projects are bad. Not in a charming, endearing way — in a genuinely clunky, poorly structured, wouldn't-survive-a-code-review way. Early code is embarrassing. This is not a problem to be solved. It is a natural consequence of doing something you do not yet know how to do well.

The instinct to avoid sharing early work, or to polish endlessly before showing anyone, makes sense emotionally. But it is counterproductive. Showing something unfinished invites feedback that accelerates learning. Hiding it protects your ego at the cost of your growth.

Some of my most useful feedback has come from people pointing out that I was solving a problem in a way that made things much harder than they needed to be. That kind of correction is uncomfortable in the moment and invaluable in the long run.

What finishing teaches you that starting never can There is a specific kind of problem that only appears when you try to complete something. Requirements shift. Edge cases emerge. Features you thought were simple turn out to be complicated, and features you thought were complicated turn out to be unnecessary.

Most tutorials end before this phase begins. They walk you up to the point where the concept is demonstrated and then stop. Real projects keep going — into the messy middle where decisions have consequences and nothing fits together quite as cleanly as you hoped.

Finishing something, even something small, teaches you about trade-offs in a way that starting never can. You learn what to cut. You learn what actually matters versus what seemed important at the planning stage. You learn, often painfully, that good enough and shipped is worth more than perfect and abandoned.

On building without an audience There is cultural pressure, especially online, to build things that demonstrate skills to employers, that go viral on X, or that grow into startups. This pressure is not always harmful, but it can warp the purpose of making things.

Some of the best projects I have worked on were built for an audience of one: me. A script that automated something tedious. A small tool that visualized data I was curious about. Things that served no portfolio purpose and impressed no one but solved a real problem in my own life.

Building for yourself lowers the stakes enough that you can experiment honestly. You are less likely to cut corners to look impressive and more likely to go deep on the things you actually find interesting. That depth is where skill develops.

A quiet argument for making useless things The to-do app that forgot everything was not useless. It taught me something. So did the half-finished game, the abandoned weather dashboard, and the web scraper that only worked on one specific page. None of them were shipped. Most of them were bad. All of them moved something forward.

Self-education is not linear, and it is not always legible from the outside. It looks like unfinished projects and strange rabbit holes and months spent on things that did not pan out. From the inside, it feels like slowly getting better at noticing when you do not understand something — and caring enough to find out why.

The blank file is still there. The cursor is still blinking. That is not a problem. That is the work.