What Shipping Side Projects Taught Me About Engineering

Most of what I know about building software I did not learn at work — I learned it shipping small things on my own, alone, with no deadline and no one to bail me out. Here are a few lessons that stuck.

Scope is the real skill

The hardest part of a side project is not the code, it is deciding what not to build. Every feature you cut is a feature you do not have to design, test, document, and maintain forever. I now start by writing down the smallest version that is still worth using, and I treat everything else as "later."

Finishing is a separate muscle

Starting is easy and fun. Finishing — the last 20% of polish, error states, empty states, the README — is where projects quietly die. I learned to budget as much time for finishing as for building, because an unfinished project teaches you far less than a shipped one.

Boring technology wins

Early on I chose tools because they were new and exciting. Then I spent my limited evenings debugging the tools instead of building the thing. Now I reach for boring, well-documented technology by default and save my "innovation budget" for the one part of the project that is actually novel.

Write it down while it hurts

The best blog posts come from problems you just solved, while the frustration is still fresh. A week later you will have forgotten the dead ends that made the solution non-obvious — and the dead ends are the useful part. This blog exists because of that habit.

The takeaway

Side projects are a low-stakes gym for high-stakes skills: scoping, finishing, choosing tools, and communicating. You do not need a big idea. You need a small one you will actually ship.