A Documentation Talk
summary
Claims that GitHub adds docs to every method and that writing the README first — README-driven development — forces API clarity and saves time. Describes using TomDoc inline comments with public/private flags, typed arguments, examples and return values, which leads to smaller methods, clearer edge cases and stronger tests. Notes a 40-person codebase where docs live next to code, must be updated with changes, and serve as the source of truth.
AI-written summary · about
chapters (36)
- 0:00Intro
- 1:05Documentation
- 1:46Zach Holman
- 2:28Why Documentation
- 2:40I Hate Documentation
- 3:45Selfish Documentation
- 3:56Documentation Helps
- 4:54Projects
- 5:33Tom Frederick Warner
- 6:06Installation Steps
- 6:25The Most Interesting Part
- 7:35The Readme
- 8:04Stratocaster
- 8:55Read Me
- 10:43GitHub
- 11:28TomDoc
- 11:55Documentation Overview
- 12:37Labeling Arguments
- 13:16Examples
- 14:03What it returns
- 14:25Why is it important
- 15:08Language
- 15:28Explicit
- 15:55Flexible
- 16:28Tiny Methods
- 17:06Smarter Methods
- 17:28Better Tests
- 18:14Tom Docs
- 18:45Rage
- 19:13Reactions
- 19:39Documentation is always stale
- 20:13Dont skimp on documentation
- 20:44Intentions
- 20:59Edge Cases
- 21:44Test Driven Development
- 22:28Questions
related talks
29mHumanizing Your Documentation
44mUseful and Beautiful Developer Docs and How to Create Them
51mTechnically speaking improve your code documentation
52mTechnically Speaking: improve your code with documentation
35mThe Art of Documentation and Readme.md for Open Source Projects
28mHumanizing Your Documentation
31mREADME Driven Development
46mTechnically Speaking: Improve your code with documentation