How I work — tap each
works below the surface
reads the source
measures before claiming
ships incrementally
works between codebases
builds tools that don't yet exist
Most of what I work on lives below the product — configuration, logging, dependency injection, build pipelines. Pieces that 1.4 billion+ runtimes depend on without anyone naming. The framework is supposed to feel reliable; I'm not supposed to be visible. That's by design.
Most of the work was debugging things other people wrote, in codebases nobody fully understood. I stay in the source until the mystery disappears. That's the whole method.
I added cache metrics, built A/B experiment infrastructure, instrumented LSP calls with correlation IDs. Every claim backed by telemetry. A performance improvement that isn't measured isn't an improvement.
I learned early that shipping a complete feature in one massive PR increased risk and churn for reviewers. Moved to deliberate, incremental delivery. Smaller changes, more trust, less rework.
The work crossed codebases. I coordinated across .NET Libraries, ASP.NET, R9 (Teams backend), Roslyn, and DevDiv research simultaneously. The cross-codebase work that doesn't show up in a single repo but is often what makes a feature actually ship.
Built the ML.NET issue labeler before triage tooling was a category — 86% PR labeling accuracy across ~10 .NET repos. Built BugBuddy, an agentic AI prototype using RAG and tool-calling, before "agentic" was a buzzword — recognized internally as a model for how DevDiv should explore new AI experiences. The pattern: see the gap, build the missing thing.
Community · built in the open
A proven open source maintainer. Day-job work surfaced publicly through three channels — receipts below.