Lies we tell ourselves about developer infrastructure
summary
Argues that many in-house developer tools start from excitement not necessity, cites concrete pain: IDEs tuned for ~30,000 line projects, Visual Studio stress tests around 7 million lines, and TypeScript early adopters hitting 100,000+ lines—Facebook codebases are two orders larger—so rebuilds traded problems (slower compiles, bigger binaries, ABI headaches in Swift) for marginal gains. Recommends three checks before building: it helps end users, it has a finish line, and it truly unblocks product progress.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 4:35Why do I keep switching jobs
- 9:07Nobody is in control
- 11:15Developer tools
- 20:24Empathy
- 21:49Better tools make developers happy
- 27:55Time spent on new tools
- 32:52Good tools can solve unfamiliar problems
- 37:43Good tools need to work
- 40:13Think of the user
- 41:38Build tools you can finish
- 42:16Build tools to unblock progress
- 42:42Summary
related talks
43mBuild in Quality
27mWhat Makes a Great Developer Experience?
51mDeveloper productivity is waste
07mDevelopment setup: how an important part of your toolset is often overlooked
27mDeveloper Experience: It’s Time to Start Complaining
59mTechniques for writing high-quality code
54mDeveloper experience platforms
24mInvesting time into developer tools and experience