Physics trains you to think in systems
My academic background is in physics. At the time, I didn’t fully understand how broadly applicable that training would be. What physics actually teaches you isn’t just formulas or problem sets. It teaches you how to think in systems.
You learn to break complex problems into smaller components, understand how those components interact, and reason about behavior under constraints. You learn to ask: what actually matters here, and what can be ignored?
That mindset has ended up being more valuable than any specific equation I learned.
Learning systems the hard way
After school, I spent several years in restaurant work and management. At first, that didn’t feel connected to my academic background at all. In hindsight, it was one of the most valuable systems educations I could have had.
Restaurants are real-time, high-pressure systems with constant variability. Staffing changes, supply issues, customer demand, and operational constraints all interact at once. There’s no pause button, and no clean abstraction layer.
You learn quickly that small breakdowns cascade, communication matters more than process documents, and “good enough” decisions made quickly are often better than perfect ones made too late.
It was the first time I had to think about systems not just as something to analyze, but as something to keep running.
From restaurant operations to restaurant systems
My first real move back toward technical work came through restaurant point-of-sale implementation. That role became a bridge between operations and software.
For the first time, I was working directly on systems that shaped how businesses actually functioned: workflows, reporting, configuration, and day-to-day operational visibility.
That transition mattered because it showed me that I didn’t have to choose between technical work and practical work. I was most interested in the space where the two met.
From operations into data
From there, my work shifted more directly into data. At first, that felt like another change in direction. In reality, it was the same kind of systems thinking applied to different materials.
Instead of physical systems or operational systems, I was now working with datasets, migrations, transformations, and reporting layers. The problems were less clean, the data was messier, and the constraints were often only partially visible.
That’s where I learned something important: real-world systems rarely behave as cleanly as theoretical ones. Most of the work isn’t in analysis alone. It’s in making the system usable, reliable, and understandable.
Where things either work or they don’t
Over time, that evolved into broader implementation and consulting work. In those roles, there’s no ambiguity about whether something is successful. Either the system works in production, or it doesn’t.
I spent years translating business requirements into working systems: analytics platforms, automation pipelines, reporting layers, and SaaS implementations. That meant dealing with incomplete information, evolving requirements, and real consequences when things broke.
Over time, I became less interested in individual tools and more interested in the systems themselves: how they were structured, where they failed, and how to make them more resilient.
Reintroducing the physical world
More recently, I started building again, this time in robotics.
Projects like my hexapod robot forced me to reconnect software with the physical world. Timing, power, coordination, and mechanical constraints suddenly mattered again in a very immediate way.
There’s no abstraction layer to hide behind in hardware. If something is wrong, you see it instantly.
That experience reinforced something I had started to suspect: the most interesting systems sit at the boundary between software and the real world.
From models to systems
AI is often discussed in terms of models: architectures, training methods, benchmarks. Those are important, but they’re only part of the picture.
In practice, AI systems have to exist inside larger systems: data pipelines, interfaces, feedback loops, and real-world constraints.
That’s where my background fits in.
I’m less interested in isolated models and more interested in how those models behave when they are part of a system that has to work end-to-end.
How do you make them reliable, observable, and useful to real people? How do you build systems around them so they can be monitored, improved, and trusted when the environment is messy and the stakes are real?
Toward applied and embodied systems
Right now, I’m most interested in systems that combine:
- Data and machine learning
- Real-time decision making
- Interaction with the physical world
That includes robotics, but also broader classes of systems where software has to operate under real constraints.
There’s a gap between what models can do in isolation and what systems can do in reality. That gap is where most of the interesting work is.
A consistent thread
Looking back, the path from physics to restaurant management to POS implementation to data to consulting to robotics and AI isn’t as disjointed as it might seem.
The common thread is systems thinking: understanding components, interactions, constraints, and behavior.
The tools have changed, but the underlying approach hasn’t.
The goal is still the same: take something complex, understand it, and make it work.