Starting Fresh
My job title says support analyst. That's accurate and also incomplete.
I'm a Business Technical Support Analyst II at UCLA Digital Technology Solutions. I work with the infrastructure that keeps parts of a major research university running. Identity systems, enterprise tooling, the kind of software that thousands of people depend on without thinking about it. I like the work. I'm good at it.
But professionally touching systems and genuinely understanding them are different things. That gap has been following me around for years.
The proximity problem
Working in enterprise IT puts you close to complex infrastructure without always giving you the depth to understand it fully. You learn what breaks, what to escalate, how to navigate vendor docs and support tickets. You build fluency at the service layer.
That fluency has limits. When something fails in an unusual way, the limits become visible. The mental model you built from the surface doesn't extend far enough.
I started noticing this pattern and decided to do something about it rather than work around it.
What I built instead
The answer was a personal infrastructure lab. A dedicated environment where I could run real systems, configure them from scratch, break them deliberately, and learn from the results without any of the consequences that make production environments so careful.
Proxmox for virtualization. Kubernetes for distributed systems. Docker containers for everything else. Tailscale for overlay networking. Ollama for local AI inference and agent workflows. The same open-source tools running global infrastructure, running on my hardware, configured by me.
Every layer I can touch directly is a layer I actually understand. That's the whole point.
Why write about it
Not to build an audience. Not to establish expertise I don't have. I write about this because the act of explaining something is the last test of whether you understand it. A lab notebook you never review is less useful than one you have to defend.
There's also something specific about working in public that changes how carefully you think. When you're only accountable to yourself, it's easy to handwave the parts you haven't figured out yet. Writing forces precision.
I also benefit from people who write like this. Engineers who document their actual setup, their actual mistakes, their actual reasoning. Not polished retrospectives, but work in progress. I want to contribute to that.
What this site is
The rule I try to follow: once you learn something, put it out.
Not because anyone is waiting for it. Because the act of publishing finishes the learning. Writing forces you to find the gaps in your own understanding. And if you struggled with something, someone else is struggling with it too.
So this is where I put things out. Infrastructure and systems, because that's what the lab produces. Security concepts as I work through them. AI and agent tooling as it evolves. Automation patterns. Tools I find useful. Whatever I'm learning at a given moment that feels worth articulating.
It is not a finished product. It is a record of learning in progress.
This post is the anchor. The rest is the work itself.