The art of keeping your project from falling apart
summary
Argues that code must be written for programmers not compilers and gives concrete practices: assume humans hold about five items in working memory, prefer small merge requests, avoid premature DRY that inflates complexity, and make risky APIs harder to misuse via privilege-style interfaces. Recommends automated checks — CI, fuzzers, clang-tidy, static_asserts, and sanitizers like address sanitizer and UBSAN/TSAN — plus staged releases and telemetry. Shows examples that work: double-algorithm runtime checks find bugs, proto mismatches caught by compile-time assertions, and prefers std::optional over nested error codes.
AI-written summary · about
chapters (16)
- 0:00Start
- 1:35Who Do We Write the Code for What Is Our Audience
- 1:55The Target Audience
- 5:50Limits of Human Perceptions
- 9:00Recommendations
- 14:38Where Are those Code Reviews Done
- 15:50Code Review
- 21:27Attitude to Modern C + + Features
- 23:52The Runtime Debug Check
- 26:32How Many Merge Request Can Be Merged in a Day
- 27:22Documentation
- 32:31Part Constraints
- 35:12Google Protocol Buffers
- 35:48Error Handling
- 37:50Structured Bindings
- 54:39Design Reviews
related talks
48mA Personal Philosophy of Excellent Engineering
54mSeeing Like a Programmer - Resiliency, Limits, And Moral Hazards In SE
01h 00mDefensive Programming Done Right, Part I
16mBetter Stories, Better Software
32mMaking Sotware Better, Despite Having Users
01h 00mBuilding Software Capital: How to write the highest quality code and why
44mLies we tell ourselves about developer infrastructure
39mYou should stop writing code