Be Awesome By Being Boring
summary
Claim: choose stable proven tools unless a specific bottleneck demands otherwise. Examples: a postcard ingestion prototype fails to scale for Comcast network data so the team rewrites on Hadoop and pays months of engineering; Docker API changes force rebuilds; caching with Redis or a relational store like Postgres solves 99% of problems; prefer JSON over HTTP for service APIs, use protocol buffers or 0mq only for measured low-latency hotspots. Roll out new tech incrementally, keep rollback plans, and avoid adopting multiple bleeding‑edge systems at once.
AI-written summary · about
chapters (9)
- 0:00Intro
- 3:22The spectrum of acceptable risk
- 9:06The language
- 12:22The platform
- 13:22Services
- 17:45Other Technologies
- 18:43Service Discovery
- 21:00When not to use DNS
- 23:16Conclusion
related talks
22mA Plea for Boring Tech
28mAvoid overengineering & big ball of mud- 7 lessons for maintaining the balance
01h 13mThe most boring decision: how to choose technologies when you're no longer a startup
38mSimplicity: The Key to Software Success
05mEngineering Without Dogma: When to Ignore the Best Practices
43mThinking Architecturally
50mMove Fast, Think Big
44mAvoiding the pitfalls of rebuilding software