Seeing Like a Programmer - Resiliency, Limits, And Moral Hazards In SE
summary
Claims that types, DDD, TDD and even formal proofs improve robustness but hit real limits; cites a LinkedIn memory‑leak incident that takes the site down after long weekends despite the problematic service being <1% of servers. Recommends concrete tools: make illegal states unrepresentable, F and Lean for crypto, property‑based tests, observability, tracing, backoff/backpressure and Erlang‑style let it crash. Warns against high‑modernist legibility; values flexible affordances like spreadsheets as flexible tools*.
AI-written summary · about
chapters (9)
- 0:00Introduction to software
- 2:39Software as artifact & system
- 8:14Engineering better software
- 13:50Building resilient systems
- 18:20The programmer's mental model
- 24:43Judgment and hand knowledge
- 29:03Dangers of legibility
- 34:15Responsibility in engineering
- 39:28Creating flexible tools
related talks
56mThe art of keeping your project from falling apart
01h 02mZen and the Art of Code Lifecycle Maintenance
46mThoughtful Software Engineering
52mDeveloper Responsability Principle
33mDon't Hang Me Out To DRY
29mThe Curious SRE: Cultivating a Mindset for System Resilience
25mMental Models for SREs
28mI am bad at things – And that’s okay