“It is a commonplace observation that work expands so as to fill the time available for its completion.” That’s the first sentence of C. Northcote Parkinson’s essay in The Economist, November 1955, better known as Parkinson’s law. His example is an “elderly lady of leisure” who spends a whole day sending one postcard to her niece at Bognor Regis, a job a busy man would finish in three minutes. Fun fact: that sentence isn’t even the law. The rest of the essay is about why government offices keep growing, with rules like “Officials make work for each other.” I never needed an official. I made work for myself just fine. ...

Six hours. I had planned to spend thirty minutes on a proof-of-concept. Engineers overrun estimates all the time. But this wasn’t a planning failure, it was something I’d spent my whole adult life recognizing too late: hyperfocus. The kind where time doesn’t slow down, it simply stops existing. My coffee went cold. I missed lunch. I blew past my 6pm hard stop with more working code than I’d shipped in the previous three days combined. ...

At 9:14 a.m. on a Wednesday, I open the laptop. The daily briefing for today is already there. Above the fold: a Whoop recovery score of 62 (fine), a Wakatime row showing 4h 21m on the OpenTelemetry Go compile-time instrumentation repo yesterday, three GitHub PRs waiting on review, and a Things 3 task that has been sliding forward for nine days: Review that thing from X. Each previous day the task migrated, and the journal entry from that day is one click away. The reason it kept slipping is in those entries somewhere. ...

The debugging loop is slow. You cannot reproduce the bug locally, so you add a log line and redeploy. Wrong place. You do it again. An agent alone does not fix this: it still has to pick a mechanism, and it has to know what that mechanism costs. This talk is about three approaches that take the source edit out of that loop. Each acts at a different point in the software lifecycle, and each inherits the strengths and constraints of its intervention point. ...

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, which manages the timer for you and keeps the loop body from being optimized away. 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. ...