Self-Taught to Shipped: A Journey — umxir.com

I didn’t go to school for this. I taught myself to code because I wanted to build things, and the only way to learn to build things is to build things.

Here’s what that journey actually looked like.

The beginning: hobby projects nobody saw

The first two years were projects that lived on my local machine and nowhere else. A to-do app. A weather dashboard. A little automation script that saved me 20 minutes a week. Classic beginner trajectory.

The code was bad. But it was functional, and functional is the most important property code can have.

The mistake I made: keeping it local. Shipping — even a rough version, even to nobody — is a skill, and I didn’t practice it until much later than I should have.

The shift: building for others instead of myself

At some point I stopped asking “what would I find cool to build?” and started asking “what does a real person actually need?”

That reframe changed everything. A project for yourself has no user. A project for someone else has to work, has to be clear, has to solve the actual problem rather than the problem you assumed they had.

My first externally-facing tool was an automation for someone who was doing a repetitive task in a spreadsheet. It took four hours to build, saved them multiple hours per week. That feedback loop — building something, watching it help — is addictive in the right way.

What self-teaching taught me that a curriculum wouldn’t

Resourcefulness. When you’re stuck, there’s no TA to ask. You figure it out, or you don’t ship. I’ve read more documentation, dug through more GitHub issues, and traced more stack traces than I can count. That skill compounds.

Scope control. Nobody told me what a reasonable project was. I had to learn it by over-engineering things that didn’t need it and under-specifying things that did. Both failure modes teach you quickly.

Shipping is a skill. Getting something from “it works on my machine” to “it’s deployed and someone else can use it” is non-trivial. It involves deployment, configuration, basic security thinking, error handling, and the ability to finish rather than endlessly refine.

The tools I use now

My stack has settled. Astro for sites like this one. TypeScript everywhere — it catches mistakes before they reach users. Cloudflare for hosting. AI tools for the parts of the process that benefit from automation.

The tools aren’t the point. The discipline of shipping is the point. Good tooling just lowers the friction between idea and shipped product.

What comes next

I’m still learning. The gap between where I am and where I want to be is large, and that’s the point — it means there’s still interesting work to do.

The projects on this site are the evidence of the journey. Some are polished, some aren’t. All of them taught me something that I couldn’t have learned any other way.

Build something. Ship it. See what happens. That’s the whole method.