Leaving a legacy: a guide to being kind to those who come after
summary
Concrete steps to avoid leaving a rotten codebase: put docs in repo (markdown, versioned, reviewable, use Arc42), write short good‑first‑issue guides or pseudo‑code so new contributors solve a task in ~10 minutes, use ADRs to record rationale, prefer established frameworks (replaced three custom templating engines with Thymeleaf and it works), add realistic tests (mutation testing, Testcontainers), automate deployments, enable logging/monitoring and Renovate for deps, and keep ubiquitous domain language so maintainers can actually fix production faults.
AI-written summary · about
chapters (11)
- 0:00Welcome and introduction
- 6:20Onboarding new developers
- 17:23Legacy code and burnout
- 26:13Documentation best practices
- 32:34Frameworks and complexity
- 36:04Greenfield projects and defects
- 38:33Testing and code quality
- 41:04Maintenance team support
- 43:32Automate deployments
- 45:21Beyond the project
- 48:10Closing remarks
related talks
31mYour First Legacy Codebase
22mWrite Prose, Not just programs
40mWhat We Left Behind - 10 Valuable Skills From The 1990s
28mGet yourself heard in Open Source
36mAll the Things they didnt teach you at University
33mWhat it takes to become a great developer!
19mRoad To Maintainership: Shaping OpenSearch's Future
22mNotes to my younger self