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.
- Official Google TMT Hackathon 2026 results May 8, 2026
- SANAD source repository May 2026
- Google TMT project context KU ILPRL
- 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.
- fix potential UAF in Bluetooth SSP passkey handlers April 13, 2026
- copy caller args in run_kernel to prevent mutation February 26, 2026
- skip stty when stdin is not a tty February 27, 2026
- add IPv6 address format tests for printf coverage April 2026
- extend cmdline KUnit with next_arg() regression tests April 2026
- export seq_buf_putmem_hex() and add KUnit coverage April 2026
- zero-initialize NXP SAR ADC DMA config, marked for stable April 2026
- 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.
- pull request #4601: returnArgAction validation, docs, and CRD sync April 29, 2026
- pull request #4631: Helm template extension cleanup February 24, 2026
- 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.
- merged fix for stub/interface descriptor semantics April 28, 2026
- pull request #3151 with maintainer approval and mypy_primer signal April 28, 2026
- status Merged into facebook/pyrefly
- scope Descriptor protocol / .pyi stubs / type inference
- evidence Regression test plus mypy_primer signal across real projects