Avoiding work is work - but it pays off!
summary
Developer Productivity Engineering treats slow builds and flaky tests as measurable technical problems and shows concrete fixes: use Gradle Enterprise with deep structured telemetry, use a cache to avoid work already done, apply predictive test selection to run only affected tests, and distribute and parallelize work so slow suites drop from 47→16 minutes. Spring projects report saving 53 hours per day and five days per week in test time. Expect some upfront effort to make tests parallelizable, then large, provable ROI.
AI-written summary · about
chapters (22)
- 0:00Introduction
- 0:24Engineering teams strive to be productive
- 1:44How much is something unproductive
- 2:16We need data
- 2:48Make informed decisions
- 3:04Impact of changes
- 3:33Root cause
- 4:10Capture data
- 6:29Get deep insights
- 6:40Work with data
- 7:55Performance
- 8:33Cognitive fatigue
- 9:05Less fast delivery
- 9:21Faster feedback
- 10:57How to accelerate feedback
- 13:04Spring example
- 14:01chatty example
- 14:24acceleration technologies
- 15:49high return
- 16:16productivity
- 16:36optimization
- 17:50Hiring
related talks
36mDeveloper Productivity Engineering: What's in it for me?
44mDeveloper Productivity Engineering: What's in it for Java Developers?
27mDeveloper Experience: It’s Time to Start Complaining
45mDeveloper Productivity Engineering – The Next Big Thing in Software Development
43mDeveloper Productivity Engineering – The Next Big Thing in SW Development
54mDeveloper Productivity Engineering Deep Dive
37mImproving developer productivity with Gradle Enterprise in 2023
02h 31mDeveloper Productivity Engineering - Extended Session