Why do you have to make it so complicated?
summary
A practical framework and two‑page handout maps concrete tradeoffs: when code moves from notebook→module→package to multi‑repo; when to adopt git, GitHub, git branches and pull requests and tagging; when to add pytest, CI, or just a single unit test (pytest and CI); when to use docstrings, Sphinx/ReadTheDocs or full narrative docs; when to prefer simple tracebacks versus structured logging and custom exceptions. The exercise runs live with audience surveys and yields actionable, team‑specific cutoffs.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:25Why complexity feels justified
- 3:09Interactive survey framework
- 6:39Code modularization
- 16:39Version control
- 25:13Error handling levels
- 29:05Testing strategies
- 35:05Documentation necessity
- 42:25Open-source dependencies
- 45:30Conclusions
related talks
41mCracking the Code Review from Guesswork to Automated Guidance
01h 01mYour code is just a detail
17mHow to Ensure Code Quality and Consistency in Distributed Teams
59mCode Reviews - Why, what and how
01h 09mPlenary: Coping With Other People's C++ Code
29mLeveling Up from Planning to Production
18mHow To Review Someone's Code While Not Being A Jerk!
29mCode review, do you speak it?