i write about software, systems, and random thoughts/rabbit-holes.
undergrad computer engineering student @ uwaterloo. currently working on high-performance networking for Starlink & Colossus @ SpaceXAI. previously, i’ve worked at tesla autopilot & meta’s recommendation systems.
always open to talking tech, feel free to reach out.
i’ve been thinking more about what it actually takes to change a running network. choosing a better route is one problem. getting traffic onto that new route, while the network is still carrying packets is whole different ball game. i hadn’t given that second part much thought until lately. my first instinct was pretty straightforward: calculate the new routes, check that they work, and push the forwarding rules to the switches. this instinct was without consideration that the switches probably won’t all apply those rules at the same time, and while they’re updating, packets are still moving between them. ...
in high school, i was extremely good at school. i don’t mean that in the vague, linkedin way where everyone was apparently a visionary at seventeen. i mean that i understood the system, optimized for it, and the system rewarded me. i graduated as a top ontario scholar and received the governor general’s academic medal. i also got accepted into waterloo’s computer engineering program, which felt like the natural conclusion to all of it. ...
i’ve always been trying to learn more from first principles about topics i care about. not because it sounds intellectually impressive, but because i’ve noticed that most shortcuts stop being useful the moment someone asks me a slightly deeper question. analogies are probably the worst offender. they’re supposed to make unfamiliar concepts easier to understand by connecting them to familar ones. most of the time, this shit actually works. but, they also quietly replace the thing being explained (AI explanations do this a lot). instead of understanding the actual mechanism, i end up understanding a watered-down version that behaves similarly under some narrow set of conditions. ...
to be quite frank, i’m very proud of my technical progression as a software engineer. when i was admitted into ece at the university of waterloo, i knew how to code in the sense that i could make things work, but i had very little of the judgment or depth that i now associate with actually being an engineer. i wasn’t thinking seriously about architecture, performance, failure modes, maintainability, or what was happening beneath the abstractions i was using. i was mostly just excited that the code ran lmfao (why did i think commenting was the shit back then). ...
these days, the more i read about modern ai inference, the more i start to draw these web of connections to HFT (high-frequency trading). replace market data with tokens, NICs with GPUs, and order execution with inference, and suddenly… you’re reading the same playbook. not to mention, the underlying skill set is a near exact match. in HFT, engineers obsess over shaving microseconds off the critical path. we bypass the kernel to eliminate unnecessary context switches, build lock-free structures so threads never wait on each other (on a side note: the mutex strategy generally wins over lock-free lol), organize memory to maximize cache locality, vectorize hot-paths with SIMD instructions, and profile everything like maniacs because every cache miss has a measurable cost. ...