Search

Search work, writing, and fragments.

about

A little context behind the work.

I like software that is easy to use, hard to break, and still understandable after the first rush of shipping is over.

story

I study computer engineering, but most of my learning has come from projects that stopped being simple the moment they had to work for someone else. Building a Silent Payments differential harness taught me how to turn vague implementation disagreements into replayable evidence. Building an exam-paper archive taught me the other half: if retrieval still feels like work, the engineering underneath has missed the point.

I keep coming back to work that has to hold up from both directions. It should read clearly on first touch, make honest tradeoffs underneath, and still feel sensible to the person who has to change it later.

That is why upstream work matters to me. Review is a useful test of whether the reasoning survives outside my own repository.

  • what I do Product software, tooling, and verification-heavy systems.
  • how I work Start with the real use case, keep the failure modes legible, and leave the next maintainer something sane.
  • next Developer infrastructure, product systems, and correctness-heavy software where careful engineering changes the outcome.

principles

  • When a problem is hard, make the failure easier to inspect.
  • If a workflow asks for trust, design the internals so they can be checked.
  • Prefer structures a tired future maintainer can still reason about.
  • Keep choosing work that teaches judgment, not just speed.

What I want to work on

  • Systems where the engineering has to be solid because people actually rely on it.
  • Tools that get out of the way and make a hard workflow feel simple.
  • Environments that force me to understand the layers beneath the code I write.

recognition

Recognition belongs here only when it points back to the work: a real problem, a constrained build, and enough evidence that the result held up under review.

selected recognition

Google TMT Hackathon / 2026

1st place in the File Translation Tool Track with SANAD.

As team SPAN, a two-person team, we built SANAD for the Google TMT Hackathon 2026 under KU ILPRL's Google-supported Trilingual Machine Translation project. The product turns public-service documents into a reviewable translation workflow with protected-entity checks, scoped memory, risk flags, human review, and export-ready output.

  • result Winner, File Translation Tool Track
  • team SPAN, two-person team
  • scope English / Nepali / Tamang public-service document translation

upstream

I care about upstream work because it is one of the cleanest ways to test whether an idea survives outside my own repository. The contributions below are small on purpose: concrete enough to inspect, strict enough to review, and real enough to affect behavior that other people depend on.

selected contributions

Linux / Kernel / 2026

Upstream Linux kernel contributions across Bluetooth memory safety, KUnit, and core library paths.

The work spans a Bluetooth SSP passkey-handler UAF fix in mainline Linux plus KUnit tooling, cmdline regression coverage, printf IPv6 tests, seq_buf KUnit/export coverage, and an IIO DMA initialization fix marked for stable. Three patches are in mainline Linux; four additional patches are present in linux-next or subsystem trees.

  • status 3 commits in mainline Linux, 4 additional patches in linux-next or subsystem trees
  • scope Bluetooth memory safety / KUnit tooling / cmdline and seq_buf tests / printf IPv6 coverage / IIO DMA fix
  • through Maintainer-reviewed upstream workflow

also selected

Cilium Tetragon / eBPF / 2026

Kprobe return-path validation and schema clarification in Tetragon.

Merged in cilium/tetragon#4601, this series rejects unsupported returnArgAction values on kprobe return paths, adds regression coverage, and carries the clarified semantics through CRDs, docs, vendored schema copies, and examples. An earlier Helm template cleanup also merged in #4631.

  • status 2 merged pull requests in cilium/tetragon
  • scope Kprobe return-path validation / tracing-policy docs and CRDs / Helm packaging cleanup
  • evidence Regression coverage plus maintainer-reviewed upstream workflow

also selected

Pyrefly / Type checker / 2026

Stub descriptor semantics in Pyrefly.

Merged in facebook/pyrefly#3151, this fix makes stub and interface declarations use descriptor protocol lookup instead of exposing raw descriptor types. It closes #3045, adds regression coverage for inherited .pyi descriptors, and the mypy_primer run reported fewer real-world false positives.

  • status Merged into facebook/pyrefly
  • scope Descriptor protocol / .pyi stubs / type inference
  • evidence Regression test plus mypy_primer signal across real projects