DevX Experience is broken… and you should be pissed
summary
2018 Docker launch hits a blocker: vulnerability counts differ between frontend and backend, the single expert has left, launch is two days away and reading that critical code would take “a month,” causing team-wide panic. Argues that our default just-in-time understanding is broken and proposes continuous code understanding — live visualizations, execution maps and dynamic docs that stay linked to code. Describes building Codesy to record executions, show code paths and surface downstream effects, and lists concrete fixes: write the why, link decision docs, and keep tests.
AI-written summary · about
chapters (13)
- 0:00Intro
- 0:40Our internal experience as developers suck!
- 1:01docker
- 3:46Our ability to understand how our systems work.
- 4:20The process of reading and understanding code is inefficient
- 4:59The way we understand code is missing key information.
- 5:29Every engineer is building up their own unique understanding of how the codebase works
- 10:56Continuous Code Understanding
- 11:59Write code that is easy to read, and avoid being clever.
- 12:14Write down the why, not just the what
- 12:39Actually put links to decision and planning docs in your pull requests. Even right in the code!
- 13:12Write tests!
- 13:48Build better tools!
related talks
46mPanel: DevX Past & Future
35mAn introduction to developer experience, and the role of a documentarian
27mYellow Brick Code: Lessons from The Wizard of Oz on Enhancing DevEx
25mDeveloper Experience is central to DevOps success
53mLet's talk about DX, Baby!
29mDX is UX
20mtech organizations are not agile...at all with Daniel France and Jaden Lemmon
22mSecurity vs Dev Experience Threat … or Opportunity