The Right Kind of Abstraction
summary
Argues a practical checklist for introducing abstractions: nameable benefits, social cost to teams, and whether the abstraction becomes ready to hand or stays distracting as present at hand. Uses Go examples—map, generics, interfaces, Reader—to show when abstractions are unnecessary, emergent, or brittle, and explains recognition of algebraic structure (monoid for composing filters). Recommends testing ideas with small proofs of concept and treating abstractions as essential representations only after observing patterns in real code.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:12Unnecessary abstractions in Go
- 3:38Generics and interfaces
- 5:47Functions and machine code
- 7:52Defining abstractions
- 9:58What is an abstraction
- 12:46Why use abstractions
- 14:31Abstractions in Go
- 16:38Software as social activity
- 18:42Ready-to-hand vs present-at-hand
- 22:52Analytic and synthetic truths
- 27:46Essential truth and validity
- 30:13Algebra and pattern recognition
- 32:38Criteria for good abstractions
- 37:56Testing abstractions
- 39:06Abstractions in team talks
- 41:10Why map reduce isn’t idiomatic in Go
- 42:33Worst Go standard library abstractions
- 43:36Maligned Go abstractions
- 45:00Social cost of abstractions
- 46:02Q&A
related talks
36mThe Abstract Method, In General
01h 07mAbstractions: the good and the bad
01h 05mAbstraction Patterns: Making Code Reliably Better Without Deep Understanding
01h 18mAbstraction: The True Superpower of C++
57mAbstraction: The True Superpower of C++
01h 03mIt's Abstractions All the Way Down...
01h 31mWhen Abstractions Fix Too Much - Towards Flexible Library Design
36mWhy It's Worth Arguing for an Hour About Naming in Code Review