Learning by Building
Learning by Building
I've always learned by doing.
My earliest "engineering" education didn't come from a classroom or a lab. It came from my grandparents' farm — working with my hands, tearing things apart, figuring out why they broke, and learning how to fix them. There was no abstraction layer. If something failed, it failed loudly. If you wanted it to work, you owned the outcome.
That mindset stuck.
Seat Time
As a teenager, motocross became my world. Racing taught me a different version of the same lesson: improvement comes from seat time. Repetition. Feedback. Ownership. You don't get better by talking about it — you get better by showing up and putting in the work.
Around the same time, I went through a battle with cancer. That experience didn't come with a neat takeaway, but it did leave a lasting imprint: time matters, progress compounds, and you don't always get a clean second chance.
Those ideas — ownership, practice, forward motion — still shape how I approach work today.
A Non-Linear Path into Technology
My path into technology wasn't linear or credential-driven. I didn't arrive with a clean computer science pedigree or a predefined role in mind. What I did have was curiosity and an instinct to build.
That started early — hours spent experimenting on an old laptop, breaking things, rebuilding them, and slowly understanding how software systems actually behaved. Over time, I found my rhythm in applied work: quickly mastering new tools, moving between layers of a system, and using technology to solve tangible problems.
I've worked across frontend, backend, infrastructure, and platform concerns — not out of indecision, but because many real-world problems don't respect neat boundaries.
Strategic Generalism (Without the Label)
Over time, I noticed a pattern in the work I gravitated toward. I was most effective when I could zoom out to understand the full system, then zoom back in to execute where it mattered.
That meant:
- Refining user experience while understanding backend constraints
- Making architectural decisions with operational consequences in mind
- Treating infrastructure, product, and reliability as connected concerns
Some people describe this as being a "Strategic Generalist." I don't hold tightly to the term. What matters more to me is judgment — knowing which details matter, when abstraction helps, and when it obscures reality.
Applied AI and Systems Thinking
Today, much of my work focuses on applied AI systems — particularly where excitement outpaces operational maturity.
I've spent time designing and shipping AI-powered features that have to live in the real world: under cost constraints, latency budgets, evaluation ambiguity, and organizational complexity. I care less about demos and more about whether a system can be trusted six months after launch.
Along the way, I've helped mentor engineers, contribute to internal technical communities, and document lessons learned — not as prescriptions, but as reflections from practice.
What Drives Me
At a core level, I'm motivated by reducing unnecessary friction.
I believe good software should help people achieve more with less — less confusion, less ceremony, less wasted effort. I'm drawn to environments that value ownership, clear thinking, and execution over performance or hype.
I'm always learning. Always refining my mental models. And always looking for the next problem where a practical, systems-oriented approach can make a meaningful difference.