Dangerous Minds: How we're getting developer education wrong
summary
Argument: beginner rules like avoid words like manager processor data and rigid naming mantras produce brittle APIs, wasted bike-shedding, and stalled careers. Examples: userData and amplinkInfo in real Android repos, ActivityManager in AOSP, KSP using generic get for discovery. Remedies: use static analysis/lint to codify team conventions, prefer fakes over mirror mocks, read Software Engineering at Google, create ADR/RFCs and design twice. Tests that mirror implementation create a double-entry testing trap; aim for intentful, low-fidelity doubles instead.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:28What defines a dangerous mind
- 3:15Expert beginner trap
- 4:21Naming advice pitfalls
- 8:43Naming conventions complexity
- 10:30Noun-heavy APIs pitfalls
- 11:58API design beyond rules
- 13:41Mr Bucket analogy
- 15:06Naming advice for experts
- 17:16Testing advice backfires
- 18:22Test double bookkeeping
- 20:50Google’s test doubles
- 23:17Unit test quantity not goal
- 24:42Books teaching trade-offs
- 25:48Software design options
- 26:32Beginners avoiding bad advice
- 29:03Avoiding bike-shedding
- 30:31Q&A
related talks
27m'The Art of Software Development'
25mFOMO - How an Android dev cut through the noise and build proactive learning habits
31mThe Effective Developer - Work Smarter, Not Harder
49mExtreme Professionalism - Software Craftsmanship.
33mReexamining Developer Advice from the First droidcon
30mLessons Learned: A Developer's Perspective on Teaching & Learning
34mBeing more than an Android developer
51mThe Art of Software Development