I build systems from the ground up, and I stay close to the codebase because that’s where I actually learn things. As a software architect who never stopped being an engineer, I try to hold both ends at once — the high-level design and the messy, production-ready details underneath it. Most of my time goes into cloud topologies that don’t fall over, data models that don’t need three diagrams to explain, and code I’m not embarrassed to reread six months later. The keys stay worn because I’ve found that the decisions worth trusting usually come from people still writing and maintaining the thing, not just sketching it and walking away — though I’ll be the first to admit that’s a bias, not a law.
I try to be pragmatic about new tech, especially AI and cloud infra, mostly because I’ve been burned by hype before. The industry moves fast and talks faster, so I’d rather wait and see what actually holds up under a real workload than take anyone’s word for it — including my own. Whether I’m wiring agentic AI into a dev workflow, going through a network security setup line by line, or just poking at a reasoning model to see where it breaks, I try to let the telemetry and the trade-offs do the talking. If something doesn’t earn its keep — in clarity, speed, or just not wasting my time — I drop it. I’m also aware I get this wrong sometimes, and I’d rather be corrected than stay confident.
Engineering, to me, is just a long process of noticing what’s clunky and fixing it — workflows, edge cases, the small frictions nobody budgets time for. This site is my running notebook of that process: things I’ve actually built and broken, patterns that held up, and the occasional dead end I’ll leave in for honesty’s sake. It’s less a highlight reel and more a working log, for anyone who’d rather see the real thing than a polished version of it.