(01)
The long version
How a mechanical engineer ended up writing generative models and a novel.
I started in mechanical engineering because I wanted to know how things physically work, and I picked up an electrical engineering minor almost immediately because it turned out you cannot finish most modern mechanisms without it. Santa Clara gave me the whole classical sequence — machine design, thermodynamics, fluids, dynamics, materials, manufacturing — plus circuits, logic design, and electromagnetics, and enough applied mathematics that differential equations stopped being intimidating and started being a tool.
The projects from that period are still the most honest description of how I work: an apple juicer that had to be human-powered, core the fruit, filter the juice, and then come apart to be washed; a writing robot on an Arduino that took second in the innovation show; and a mountain board designed from scratch in SolidWorks with 130 parts, which taught me more about tolerance stacks than any course did. Then a term at LTH in Sweden, and a summer at a $1B food distributor working on the logistics of installing an automated storage system — engineering at the scale where the drawing has to be right because the crane is already scheduled.
Somewhere in there I started writing code seriously. It began as data analysis in MATLAB and Python for coursework, turned into a real product when two clients — a mortgage banker and a former fund manager — asked whether anomalous options volume could be read systematically, and that project is still running six years later as Bablytics. Learning to build software properly was not a career pivot; it was the same instinct applied to a cheaper prototyping material.
Now I am a PhD candidate in electrical engineering at the University of Notre Dame, in the MiniRo Lab, working on robots that move through places that punish rigid machines — soil, sand, confined channels. Five first-author papers so far, at IEEE ICRA, IROS, and ISER. The research is where the three disciplines finally stopped being separate: a soft burrowing robot is a mechanical design problem, an actuation and sensing problem, a control-theory problem, and a machine-learning problem, and you do not get to solve any of them in isolation.
Everything else on this site is what happens on the other side of that. Games, because building a world is the most demanding systems-design exercise I know. A novel and its escape-room adaptation, because narrative has structure and structure is engineering with different vocabulary. Two faith apps built for families, one of which stitches a Rosary together from recordings of relatives — including ones who have died. And a consulting practice, because the span turns out to be the rare part.
How I work
- Write the reasoning down. Every project in the portfolio has a document explaining why the architecture is what it is. The next engineer should not have to guess.
- Prove it, don't demo it. A solver that walks every room. A decoder checked numerically against PyTorch. A test that fires with nobody watching.
- Constraints first. What the link carries, what the regulation permits, what the power budget allows — before the fun part, not after.
- Degrade gracefully. No API key, no network, no problem. Anything that only works on the happy path is not finished.
- Finish things. The hardest and least glamorous skill, and the one the whole portfolio is really evidence of.
Outside the lab
- Eagle Scout, and 150+ hours of service to get there
- Wilderness First Responder certified; led hikes and camping trips for a university outdoors club, then ran its $90k budget across 100+ trips a year
- A 30-day service immersion in Peru — and the grant proposal that funded the next year's
- Volleyball and basketball, both badly and enthusiastically
- Writing fiction, which is the only hobby here that has ever produced a print-ready book