A benchmark is a measurement system. It can report a precise number while measuring removed work, an unstable sample, or an uncontrolled machine. This talk argues you should trust a Go benchmark only after answering three questions: Is the compiler measuring real work? Is the sample stable enough? Is the difference large relative to the noise? We work through three layers. Compiler honesty covers dead-code elimination, sinks, constant folding, inlining, timer ordering, and the B.Loop construct that fixes the non-terminating-timer case. Statistical interpretation covers repeated samples, benchstat, coefficient of variation, run-count discipline, and the p-hacking traps that inflate false positives. Environment control covers both local machines and CI: Linux frequency and isolation controls, perflock, benchdiff, and the bare-metal runners that shared CI instances are not. ...

Note This post was originally published on the OpenTelemetry blog on 2026-07-16. I wrote it for the OpenTelemetry community; this is a mirror on my personal blog with some added commentary. Why this milestone matters to me I have been involved with the Go Compile-Time Instrumentation SIG since it kicked off at the start of 2025, when Alibaba and Datadog decided to pool their efforts into a single vendor-neutral project. Watching it reach v1 last week felt genuinely satisfying — not because “v1” is a magic number, but because it marks the point where we stopped calling it experimental and started calling it something people should actually run in their builds. ...

The first post in this thread was about why I keep saying yes to mentorship. The second was the playbook for mentees. This one is for the people on the other side of the table: the maintainers, the SIG leads, the engineers in companies that depend on a project and are starting to wonder whether dependency is enough. The frame I’m borrowing comes from a piece my colleagues at Bloomberg published with the CNCF in March: Sustaining OpenTelemetry: Moving from Dependency Management to Stewardship (also on Bloomberg’s company stories). The phrase has stuck with me. It names something I’ve been trying to articulate for years, and gives me a concrete vocabulary for talking about what mentorship is for inside a project the size of OpenTelemetry. ...

Last time I wrote about why I keep saying yes to open-source mentorship. This post is the how: specifically, how to be a mentee in 2026. I’ve spent the last few years on the mentor side of CNCF LFX LFX Mentorship — the Linux Foundation’s structured mentorship program. Cohorts run quarterly, projects are scoped to ~12 weeks, and mentees receive a stipend. , Google Summer of Code ( GSoC A Google-funded program where students contribute to open-source projects over the summer, paired with mentors from those projects. ), and GoBridge, through Thanos, Prometheus, and now OpenTelemetry projects. Every cohort I’ve run, the same questions keep coming up from people who want to apply but don’t know how to start. ...

There’s a moment that keeps happening to me. Someone I mentored two or three years ago shows up in a SIG call, on a maintainers’ list, on a stage at KubeCon. They’ve shipped something I couldn’t have shipped alone. They’re answering questions I once answered for them. And the part that gets me: they’re already mentoring someone else. That moment is the thing. why why It’s also the only honest answer to “why do you keep doing this when it’s not your job?” The loop closes, and you get to watch. ↩ Everything else I write here is a footnote to that moment. ...