In the main segment, Tim unpacks the deceptive nature of utilization reports that FinOps teams rely on to identify "waste" in infrastructure. While industry statistics show servers running at shockingly low utilization rates—often 12-50%—Tim argues that acting on these numbers without context is like "performing surgery with a chainsaw." He explores how CPU utilization percentages are fundamentally misleading with modern processors, why databases legitimately need low utilization for disaster recovery and peak loads, and how operational realities like global teams, inherited systems, and technical debt create legitimate reasons for apparent over-provisioning.

The news segment covers significant security and policy developments: researchers demonstrate TEE.fail, a new physical attack that defeats trusted execution environments from Nvidia, AMD, and Intel using under $1,000 in equipment. The Python Software Foundation rejected a $1.5 million NSF security grant rather than comply with new anti-DEI requirements, highlighting how political decisions now directly affect open-source development. Plus coverage of Nvidia hitting a $5 trillion valuation, Amazon's 14,000-person layoffs targeting multiple departments, and analysis of OneUptime's bare-metal migration claiming $1.2M in annual savings.

Tim emphasizes that good FinOps requires understanding the full picture—technical constraints, business requirements, and human factors—rather than simply optimizing utilization metrics. The episode concludes that sustainable cost management comes from partnering with teams and recognizing that some "inefficiency" is actually necessary insurance for reliable operations.

• Tim O'Brien: "FinOps and Utilization Reports: It's More Complicated Than That"
• Brendan Gregg: "CPU Utilization is Wrong"
• Brendan Gregg: Systems Performance Book
• Brendan Gregg: The USE Method
• Gartner: "How to Make the Data Center Eco-Friendly"
• Uptime Institute: Enterprise data center utilization studies
• WifiTalents: Server Statistics and Industry Reports
• David Kopp: Server Utilization Research Notes

• FinOps: AWS to Bare Metal Two Years Later
• Security: New physical attacks are quickly diluting secure enclave defenses from Nvidia, AMD, and Intel
• Programming: Python plan to boost software security foiled by Trump admin's anti-DEI rules
• Weird: Man accidentally gets a leech up his nose. It took 20 days to figure it out.
• Nvidia hits record $5 trillion mark as CEO dismisses AI bubble concerns
• Amazon plans to lay off approximately 14,000 employees

In the main segment, we unpack “The Humble Programmer” (1972) and why it still reads like a briefing for 2025. Dijkstra’s claim that “programming will remain very difficult” lands squarely in the age of AI code generation: as tools remove circumstantial cumbersomeness, our ambitions expand and the problems get harder. We connect his call to “prepare ourselves for the shock” with today’s anxieties about what changes (tooling, surface syntax) versus what persists (the intellectual work of modeling complex systems, making tradeoffs, and ensuring software actually works).

We also look at the economic and perception cycles Dijkstra flagged—how developers oscillate between being overpraised and undervalued—and argue for humility plus discipline over curmudgeonly fatalism. The takeaway: better tools don’t trivialize programming; they raise the ceiling on what we attempt.

Then in the news roundup: (1) Chrome will warn by default on first‑time HTTP navigations, effectively finishing the move to HTTPS‑everywhere; (2) Apache Fory Rust promises zero‑copy, cross‑language, high‑throughput serialization; and (3) Samsung makes idle‑screen ads official on high‑end smart fridges.

• Original blog post: 53 Years Later, The Humble Programmer Still Explains Our Existential Panic
• E. W. Dijkstra — The Humble Programmer (EWD340), PDF
• E. W. Dijkstra — The Humble Programmer (EWD340), HTML transcription
• Edsger W. Dijkstra — Wikipedia
• “Go To Statement Considered Harmful” — DOI
• Dijkstra's algorithm — Wikipedia
• Structured programming — Wikipedia
• ALGOL — Wikipedia
• Fortran — Wikipedia
• Lisp (programming language) — Wikipedia

• Chrome to warn on unencrypted HTTP by default
• Introducing Apache Fory Rust: A Versatile Serialization Framework for the Modern Age
• Samsung makes ads on $3,499 smart fridges official

In the main segment, we challenge the rewrite-first mindset and make the case for durability, maintenance, and reuse as creative acts. Drawing from experience upgrading decades-old scientific code and from industry examples that outlive frameworks and fads, we explore the high cost of throwing software away and the value of architecture that separates what changes from what doesn’t. We also consider how AI assistants can help us understand and maintain existing systems rather than reflexively rewriting them. Read the original post for context: Your Code Might Outlive You.

Then in the news roundup: (1) Cisco’s open-source MCP-Scanner uses YARA rules and LLM-based analysis to hunt for risks in Model Context Protocol servers; (2) a proposal to bring a reactive programming DSL to Go, nudging developers beyond goroutines-and-channels for event streams; and (3) a bit of rail magic — the sleeper train from Milan to Sicily that still rides a ferry across the Strait of Messina — and the 13.5B€ bridge that could end the ritual.

• Your Code Might Outlive You (blog post)
• Things You Should Never Do, Part I — Joel Spolsky
• Hexagonal Architecture (Ports & Adapters) — Alistair Cockburn
• Apache Log4j 2 — Project page
• COBOL — Wikipedia
• Upgrading to React 18 — React Blog
• Software maintenance — Wikipedia

• MCP-Scanner — Scan MCP servers for vulnerabilities (GitHub)
• Go beyond Goroutines: introducing the Reactive paradigm (Substack)
• ro — Reactive programming for Go (GitHub)
• The last European train that travels by sea (BBC Travel)