I keep moving closer to the machine.

I studied Computing and Commerce at Queen’s (honours, 2022–2026), then spent the summer of 2025 working on the PySpark and Hive layer behind logistics forecasting at Shopee. I am now in the M.S.E. program in Electrical Engineering at the University of Pennsylvania (2026–2028), moving further into systems and hardware.

The projects here range from multi-GPU inference and cache-aware routing to C++ storage experiments and small local models. They look different, but I keep returning to the same question: what is happening underneath the abstraction, and how can I make it observable? This semester that question is extending into firmware, SoC architecture and VLSI.

Why I build

I first became interested in computing because ordinary software made me wonder what was happening underneath. What kept me there was the feedback: change the code, run it again, and something on the screen, or on a physical device, behaves differently. That feedback is part of why I chose to study Computing alongside Commerce.

I also dislike doing the same thing twice by hand. At Founder Securities and Brix that meant turning recurring reports into reusable tools. Now it means measuring the systems underneath: in RadixGates, a routing rule passed every simulated test but cut the cache hit rate on real llama.cpp workers, and that result stayed in the write-up.

How I approach a project

1. Start from a decision. The text-to-SQL project asks whether a small model should ship as an autonomous answerer, and the answer is written as a decision, not as a score. See the note.
2. Write down the acceptance criteria, and say where they came from. Mine were assumptions, and the README says so.
3. Report the condition with the number. “611 ms p95” means an Apple M1, one request at a time; with four in parallel it is 1.4 s.
4. Say what would change the conclusion. Every repository ends with its limits, and the routing result turned on the size of a cache. See the note.