What Poetry Workshops Teach Us about Code Review
summary
Code review borrows concrete practices from poetry workshops: break work into small, fast cycles so reviews catch defects before divergence, record performances on a smartphone to let authors watch and act on audience reactions, prefer changes under about 200 lines to keep scrutiny effective, and use a lightweight priority taxonomy (boulder/rock/pebble) like Netlify’s model. In a PCI project with 17 microservices a team rule requires 1 reviewer (2–3 for security-critical changes); peer reviews plus ~40–50% pairing yields faster learning, better readability, and fewer late surprises.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 0:17About me
- 0:58My background
- 1:33Poetry residency
- 5:37Feedback
- 12:45Relationship with Software Development
- 14:40Low throughput
- 15:45Faster cycle time
- 17:12My first developer job
- 21:32Is there a better name
- 22:11Implicit goal
- 24:01Mental model
- 25:20Sharing power
- 29:02Shared language
- 29:57Prefer smaller changes
- 31:14Obstacles to code reviews
- 33:18The paradox of code reviews
- 35:51Audit your code reviews
- 36:54Conclusion
