Side projects are my favorite small laboratories

I have a deep affection for side projects that are too small to impress LinkedIn and too useful to be dismissed as hobbies.

They are one of the best ways I know to learn quickly.

A good side project lets you compress the whole product loop into a manageable space. You get to choose the problem, define the constraints, design the rough edges, ship something imperfect, observe what happens, and decide whether the idea deserves another weekend. It is a tiny laboratory with fewer meetings.

The scale is small, the lessons are not

People sometimes talk about side projects as if their main purpose is to become startups. That seems unnecessarily dramatic.

Sometimes the value of a side project is not commercial at all. Sometimes it teaches you:

• a new framework
• a better deployment habit
• what kind of product taste you actually have
• whether you like a problem enough to keep living with it
• how to recognize a bad idea earlier, which is a wildly underrated skill

Small projects are forgiving enough to invite risk. That makes them perfect for experiments.

The real superpower is tight feedback loops

In a side project, the cycle from thought to outcome can be very short.

You can have an idea after dinner, test it before midnight, and wake up knowing whether the thing has a pulse. That pace changes how you think. It rewards directness. It also exposes hand-wavy instincts very quickly.

I have learned more from shipping tiny broken experiments than from polishing speculative architecture for projects that never left the document stage.

There is a reason I keep a bias toward this pattern:

idea -> prototype -> discomfort -> revision -> shipping -> notes

That loop does not make every project successful, but it does make almost every project educational.

Side projects reveal your real interests

One thing I love about unsupervised work is that it tells the truth.

Nobody assigned you the problem. Nobody put it on a roadmap. Nobody scheduled a kickoff. If you keep coming back to a certain kind of project anyway, that usually means something. For me, it tends to be developer tooling, AI-assisted workflows, small utilities with sharp edges, and ideas that sit somewhere between engineering and writing.

Patterns like that are useful. They tell you what kinds of problems keep generating energy rather than draining it.

That matters more than people admit. Sustained interest is a competitive advantage.

Not every project deserves to become a company

I think the internet over-applies startup logic to personal work.

Some projects should become products. Some should stay experiments. Some should simply exist long enough to teach you one durable lesson and then be archived with dignity. A side project does not fail just because it did not turn into a business. It might still have given you a design instinct, a technical shortcut, a portfolio piece, or a better question for the next attempt.

That is a good return.

The notebook matters as much as the code

One of the best side-project habits I have developed is writing short reflections after each build cycle. Nothing fancy. Usually just:

• what I tried
• what was annoying
• what turned out better than expected
• what I would cut if I rebuilt it

Those notes make the project more valuable because they preserve the reasoning, not just the result. Six months later, I can revisit the code and remember what I was optimizing for instead of staring at my own decisions like they were made by an unusually stubborn ghost.

Why I keep doing this

Side projects keep me honest.

They force me to move beyond opinions into artifacts. They keep my curiosity connected to execution. They remind me that the fastest way to understand a thing is often to build the smallest version of it that can embarrass you usefully.

Also, they are fun.

That part should not be underrated. The industry is full of people who talk like enjoyment is somehow unserious. I disagree. Delight is one of the strongest reasons to keep learning.

So yes, I will probably keep making small laboratories out of weekends, half-baked ideas, and a suspicious number of markdown notes. It has been one of the most reliable ways to get better.