reflections
i am, slowly, piecing together writings from my previous blog, scattered documentation across platforms i've abandoned and returned to, journals from hostel nights, and projects documented in cryptic git commits. these traces go back to when i first discovered what code could build, through raspberry pi experiments that taught me infrastructure exists to serve people, not impress them. some writings are unpolished. that's intentional. —2024.11
a few notes from building the things on my projects page. more later.
why i built a clearing engine i'll probably never run in production
2026.05 · rust, clearing & settlement, event sourcing
i kept reading the phrase "the clearing house novates the trade" and realising i didn't actually understand it. so i built one. open clearing engine takes executed trades and runs them through the same pipeline a real clearing corporation uses — novation, position keeping, multilateral netting, settlement — with a span risk engine on top.
the thing that surprised me wasn't the finance. it was how much the correctness requirements shape the code. i made it event-sourced and deterministic not because it's fashionable, but because that's the only way to replay a settlement run and prove it produces a byte-identical result. once you pin a golden output file and refuse to let the engine drift from it, you stop trusting your own assumptions and start trusting the tests.
i'll never run this against real money. that was never the point. i wanted the concept to live in my hands instead of in a textbook, and now it does.
a backtest that ignores costs is fiction
2026.05 · backtesting, point-in-time, quant
the first version of every backtest i wrote was a lie. it bought at the close, sold later, and reported a number that felt great. then i added the indian cost model to indie market analyst — stt, stamp duty, exchange charges, sebi fees, gst, brokerage — and a lot of "strategies" quietly died. good. they were never alive.
the second lie is subtler: lookahead. it's terrifyingly easy to let a backtest peek at data it couldn't have known yet. that's why in the alt-data platform i made point-in-time correctness structural — every feature carries the date it was published, and every read filters to what was knowable at the as-of moment. there's no api to see the future. you have to build the constraint into the foundation, because if you leave it to discipline, you will cheat without noticing.
honesty in financial software isn't a feature you add. it's the load-bearing wall.
i wrote a vm manager in c on purpose
2026.03 · c, gtk4, systems
i could have built vmmanager in an afternoon with electron and some shell calls. instead i wrote it in c, talking to libvirt as a library and to the incus rest api over a unix socket with libcurl. it took much longer. that was the trade i wanted.
high-level frameworks are wonderful at hiding complexity — which is exactly the problem when you're trying to learn where the complexity lives. doing manual memory management around gtk widgets, parsing json-glib responses, handling a socket that can just stop talking to you: that's where i actually learned how virtualization management works under the calm proxmox dashboard.
not every project should be built the hard way. but some should, on purpose, while you still have the time to.
rust keeps making me slower, and that's the point
2026.05 · rust, design, scope
rust does not let me lie to it. the borrow checker stops me at the exact moment i was about to do something i hadn't thought through. early on this felt like the language fighting me. now i think it's the closest thing i have to a senior engineer reading over my shoulder.
it also changed how i scope work. in rler i deferred deep reinforcement learning entirely and shipped honest tabular q-learning first, because i'd rather have a small correct thing than a big handwavy one. rust nudges you toward that mindset — make the states explicit, make the errors explicit, and the design follows.
i'm slower in rust. i'm also more sure of what i shipped. i'll take that trade most days.
building in public, even the unfinished and the archived
2026.04 · open source, learning in public
most of what's on this site is open source, and a fair bit of it isn't finished. cs archive is literally archived — i froze it at version 3 and left it live as a snapshot rather than pretending i'd keep maintaining it. that honesty matters more to me than a wall of "production-ready" badges.
building in public means letting people see the seams. the deferred features, the "iteration 1 complete" notes, the projects that taught me something and then stopped. my galley is the same instinct pointed at smaller, stranger things. none of it is a finished monument. all of it is a record of someone actually learning.
i'd rather show the workshop than the showroom.