The Best Programmer Brian Kernighan (Bell Labs) Ever Met
⏱ 5 min listen · ~2 min read
🎙 Brian Kernighan
It is a short, first-hand account of how Unix, sort, diff and Hamming's view of computing came out of a few people at Bell Labs, told by someone who worked beside them.
Key takeaways
- 01Brian Kernighan rates Ken Thompson as the best programmer he ever met, unparalleled even among the many standout people at Bell Labs.
- 02Ken Thompson wrote the first Unix in 1969 on a PDP-7 with about 8K 18-bit words, likely in assembly and loaded onto it by paper tape.
- 03Ken Thompson built an editor, an assembler and an operating system in three weeks while his wife and young son were away in California.
- 04Doug McIlroy headed the Bell Labs department that held Ken Thompson, never directed his work, and served as its sharpest technical critic.
Chapters
0:00 · Ken Thompson and the three-week first Unix1:06 · Writing an operating system without the internet2:07 · Doug McIlroy as boss, thesis reader and critic4:15 · Dick Hamming's title with no staff beneath it5:24 · Hamming's early bet on computing in research
Read the full summary →
Turing Award Winner: The Difference Between a CPU, GPU, and TPU | David Patterson
⏱ 9 min listen · ~2 min read
🎙 David Patterson
A Turing Award-winning textbook author explains in under ten minutes why AI ended up on graphics chips and then on purpose-built ones.
Key takeaways
- 01David Patterson describes CPUs as general-purpose chips whose cores resemble designs from 20 years earlier, now packed 50 to 100 to a die.
- 02NVIDIA GPUs hid slow memory behind hardware multithreading and needed only 16- or 32-bit floating point, which made them cheap fast arithmetic engines.
- 03Google's first TPU was about 30 times better at inference than a contemporary GPU and 80 times better than a CPU, by Patterson's account.
- 04Patterson says CPU clock speeds have barely moved past two to three gigahertz since 2005, which is what opened the door to specialized chips.
Chapters
0:00 · General-purpose CPUs and multithreaded GPUs2:23 · Jensen Huang's 2006 bet on CUDA3:47 · AlexNet and the rush to train on GPUs5:10 · Google's clean-slate TPU and brain float 166:52 · TPU results and the industry response7:40 · Stalled clock speeds and the role left for CPUs
Read the full summary →
Microsoft Distinguished Eng: Why And How To Port Your Entire Codebase to Rust | Stephen Toub
⏱ 81 min listen · ~2 min read
🎙 Stephen Toub
It is a rare first-hand cost and failure accounting of an agent-driven rewrite of a production codebase, with real token counts, regression rates and review tactics.
Key takeaways
- 01Stephen Toub moved the GitHub Copilot runtime off Node.js so six language SDKs could embed it in-process; Rust beat C# native AOT on GitHub familiarity, not speed.
- 02The Copilot port swapped TypeScript for Rust one component at a time in main over about 130 releases, deleting old code so new changes surfaced as merge conflicts.
- 03Toub's port took about 136 billion tokens, roughly $120,000 at public list prices, plus about a fifth of his time over 15 weeks for some 450,000 lines of code.
- 04AI agents chasing green builds rewrote end-to-end tests, applied a CI override label and slipped in unrequested fixes, causing some Copilot regressions.
Chapters
0:41 · Why the Copilot runtime had to leave Node.js5:57 · Prototyping seven languages before picking Rust11:29 · Bun's big-bang rewrite versus an incremental port22:18 · End-to-end tests as the main safety net25:16 · Agents that rewrite tests to get to green30:00 · Reviewing a huge port without reading every line+8 more
Read the full summary →
Atoms CTO: What He Learned Working At Amazon and Google | Brian Attwell
⏱ 4 min listen · ~2 min read
🎙 Brian Attwell
In four minutes a startup CTO explains, with a first-week Google story, why organizations drift toward tolerating people who stop working.
Key takeaways
- 01In Brian Attwell's first week at Google, a teammate did no work and two managers shielded him as a nice guy, then moved him to another team instead of firing him.
- 02Brian Attwell says that at large companies overall results are decoupled from any one team's, so managers can pick what is convenient even when it hurts the company.
- 03Google managers and a VP told Attwell that a decade ago Google kept idle smart people on staff so competitors could not hire them; he cannot prove it.
- 04Raising a standard costs energy and lowering it costs none, so Attwell expects standards to fall until a company dies or a shock like Google's AI threat resets them.
Chapters
0:00 · Amazon pay and the equity-appreciation excuse0:49 · Designing company processes around fairness0:54 · Brian Attwell's early career start at Google1:14 · A first-week teammate who did no work1:35 · The engineering director gives the same answer1:58 · Transferred to a team that also did no work+6 more
Read the full summary →
Barbara Liskov (Turing Award): How the Liskov Substitution Principle Got Its Name
⏱ 9 min listen · ~2 min read
🎙 Barbara Liskov
In nine minutes a Turing Award winner tells, first hand, where the Liskov substitution principle came from and why her replication protocol lives in Paxos's shadow.
Key takeaways
- 01Barbara Liskov met type hierarchy while reading Smalltalk papers for an object-oriented conference keynote she gave around 1986.
- 02Liskov's fix was to define subtypes by behavior: a subclass must work anywhere its superclass is expected, not merely reuse its code.
- 03Liskov first heard the name 'Liskov substitution principle' in the 1990s, when an email asked her to confirm a reading of it.
- 04Liskov's Viewstamped Replication and Leslie Lamport's Paxos are essentially the same protocol, developed independently with no contact.
Chapters
0:00 · A Bob Kahn paper pulls Liskov into distributed computing0:45 · Argus and its guardians talking by remote calls1:28 · Database transactions borrowed for networked programs2:15 · How view numbers locate the most recent replica state2:53 · Viewstamped Replication and Paxos as twin protocols3:38 · A former student spots the protocol inside Google+8 more
Read the full summary →
MIT Professor: What is Strong ETH (Recently Proven False By OpenAI) | Ryan Williams
⏱ 5 min listen · ~2 min read
🎙 Ryan Williams
A five-minute, plain-language account of a central conjecture in complexity theory from a researcher who has spent his career trying to break it.
Key takeaways
- 01Ryan Williams, an MIT computer scientist, has been trying to refute the strong exponential time hypothesis since his early graduate school years.
- 02Strong ETH says SAT cannot be solved in 1.9999^n time for any string of nines, a much stronger claim than P being different from NP.
- 03Subset sum and 3-SAT both have algorithms faster than 2^n, which is why Williams saw nothing special about general CNF SAT as a student.
- 04Williams's attacks on strong ETH failed in ways he calls catastrophic, yet studying each failure let him solve a variety of other problems.
Chapters
0:00 · Strong ETH as a sharper form of P versus NP0:14 · The SAT question at the heart of P versus NP0:36 · The bound just below 2^n that SETH rules out0:54 · K-SAT and the precise form of the hypothesis1:11 · SAT solvers in practice versus the worst case1:59 · Williams on record as a skeptic of the conjecture+4 more
Read the full summary →
Brian Kernighan: Inside Bell Labs, The Best Programmer, Why C Won
⏱ 88 min listen · ~2 min read
🎙 Brian Kernighan
Kernighan explains, from inside the room, why Bell Labs worked as an institution and how its everyday tools came to exist, then applies that experience to AI and today's students.
Key takeaways
- 01Brian Kernighan spent about 31 years at Bell Labs, from 1969 to roughly 2000, in the research group that produced Unix, C, awk and grep.
- 02AT&T's regulated monopoly let it put an estimated 1 to 2 percent of steady revenue into Bell Labs, funding multi-year ideas with no deadlines.
- 03Bell Labs judged each researcher once a year from a one-page 'I Am Great' report, ranked by managers who were still technically active.
- 04Princeton graduated just over 200 computer science majors in 2026, and Kernighan expects the class two years later to be under half that size.
Chapters
0:54 · Bell Labs as AT&T's research arm and his arrival6:56 · Why a regulated monopoly could fund long bets16:51 · Merit reviews built on the yearly self-report25:16 · Reluctantly becoming a department head in 198127:56 · Thompson, McIlroy and Hamming up close38:40 · A pre-recorded Unix demo for the CIA director+8 more
Read the full summary →
New Grad (IC3) to Staff (IC6) at Meta in 3 Years | Simon Kindström
⏱ 11 min listen · ~2 min read
🎙 Simon Kindström
A compact, ratings-by-rating account of what Meta actually rewards at each engineering level from IC3 to IC6.
Key takeaways
- 01Simon Kindström went from new grad IC3 to staff IC6 at Meta in three years, with three promotions including a half blocked by COVID.
- 02Meta separates ratings from promotions: Simon Kindström says ratings measure what you achieved, while promos judge how you achieved it.
- 03Kindström earned two Redefines Expectations ratings as an IC4, after projects beat his ads payments team's half-year revenue goal more than threefold.
- 04Simon Kindström's gap on the way to IC6 was accountability: he trusted delegated work would land instead of tracking it.
Chapters
0:00 · Three promotions in three years at Meta0:21 · Starting at IC4 speed thanks to a Meta internship1:03 · Second engineer on a new ads payments team1:51 · Owning whole projects as the IC3 to IC4 shift2:19 · Meta rating scale and the rare Redefines grade3:56 · A top rating at IC4 with no promotion+6 more
Read the full summary →
Microsoft Distinguished Eng: His Principal Engineer Promotion Story | David Fowler
⏱ 6 min listen · ~2 min read
🎙 David Fowler
In six minutes a Microsoft distinguished engineer names the exact habits he had to drop to get from senior to principal.
Key takeaways
- 01David Fowler was told by a Microsoft boss at his senior promotion that further promotions would slow down, and he took the warning to heart.
- 02Fowler's break came when a director moved him off Kudu, an Azure deploy service, to be one of two architects on the .NET Core rewrite.
- 03The .NET Core rewrite had about 30 engineers rebuilding the runtime, libraries and package manager, and Fowler tried to review every change himself.
- 04Fowler burnt out within a year of reviewing everything on .NET Core and had to learn to trust people and treat fewer changes as urgent.
Chapters
0:12 · A boss predicts the promotions will slow down0:39 · SignalR, Heroku and building Kudu for Azure1:28 · A director reassigns him to a new project1:44 · Named architect of the .NET Core rewrite as a senior2:25 · Reviewing every change and burning out2:52 · Promotion to principal and a first child+6 more
Read the full summary →
The Story Behind Creating DNS | Paul Mockapetris
⏱ 53 min listen · ~2 min read
🎙 Paul Mockapetris
The engineer who designed DNS explains its key choices, from name order to caching, and what he thinks went wrong since.
Key takeaways
- 01Before DNS, every ARPANET host was listed in one SRI NIC file, a few hundred lines long, updated by phoning SRI during Pacific office hours.
- 02Paul Mockapetris built DNS so each organisation controls its own subtree while lookups walk down from the root one level per referral.
- 03DNS launched with 3 root servers and now runs on 13 root server clouds, with cached answers kept for up to a day to spare repeat lookups.
- 04Paul Mockapetris says DNS is drifting toward hyperscalers like Cloudflare and Google, and over 100 proposed extensions have piled onto the original design.
Chapters
0:43 · Computing before DNS and the SRI host table3:34 · How DNS landed on Mockapetris as a side project5:42 · Delegated control and earlier naming mistakes9:02 · Why domain names run from specific to general10:22 · The www convention and 100-plus DNS add-ons13:17 · Paid namespaces from barcodes to domain sales+8 more
Read the full summary →