Guide for lazy developer
summary
Advice focuses on actionable checks: confirm license like MIT/Apache and README present, scan PRs/issues and tests, read sample apps, and inspect code for performance or native bloat; note image libraries differ hugely by method count (Picasso ~1k methods, Glide ~3k, Fresco >10k). Use static Gradle versions, update after each release, and automate checks with Gradle versions plugin by Ben Manes. Start small, add an abstraction layer for replaceable pieces (analytics), and prefer well‑documented, actively maintained deps.
AI-written summary · about
chapters (27)
- 0:00GUIDE FOR THE LAZY DEVELOPER Working with dependencies
- 1:37Write minimum code
- 2:06Let others write it
- 2:36WHEN? Considering a dependency
- 3:34Somebody thought about it A LOT
- 4:13Focus on something else
- 4:47Dependencies evolve
- 6:35You need control
- 8:03Use the community
- 8:57Every app is different
- 9:11Check the license
- 10:34Check the readme
- 11:33Check pull requests
- 12:42Check issues
- 13:40Check past releases
- 14:16Be aware of risks
- 15:21Check the code
- 16:24Check the tests code
- 16:39Check the samples
- 17:05Check the dependencies samples tests code
- 18:28Picasso Glide
- 19:17Check the popularity
- 21:29WHICH? Choosing a dependency
- 23:56Keep them up to date
- 25:24Check the change log
- 31:49HOW? Integrating a dependency
- 32:19No choice is final
related talks
31mTips for Library Development (from a Startup Developer)
37mDon't Sweat the Small Stuff... Or How to Find Job in Development Through Small Things
43mBuilding for Developers
43mLibrary Developer Confidential
37mBuilding Apps that Scale
46mGetting the most out of code review
37mBecoming and Staying a Productive Developer with Build Scans, Build Validation Scripts and Gradle
36mImproving Gradle Builds