Chris Zetter: Building a Database to Better Understand Maintainability
Maintainable
Focus on Structural Debt and Boundaries
Chris reflects on evolving from worrying about long files to prioritizing architecture, boundaries, and naming to improve changeability.
Episode Summary
In this conversation, Robby sits down with software engineer and author Chris Zetter to explore what building a relational database from scratch can teach us about maintainability, architectural thinking, and team culture. Chris shares why documentation often matters more than perfectly shaped code, why pairing accelerates learning and quality, and why “boring technology” is sometimes the most responsible choice. Together they examine how teams get stuck in local maxima, how junior engineers build confidence, and how coding agents perform when asked to implement a database.
Episode Highlights
[00:01:00] What Makes Software Maintainable
Chris explains that well-maintained software is defined by how effectively it helps teams deliver value and respond to change. In some domains—like payroll systems—the maintainability burden shifts toward documentation rather than code organization.
[00:03:50] Documentation vs. Code Comments
He describes visual docs, system diagrams, and commit–ticket links as more durable sources of truth than inline comments, which tend to rot and discourage refactoring.
[00:05:15] Rethinking Technical Debt
Chris argues that teams overuse the metaphor. He prefers naming the specific reason something is slow or brittle—like outdated libraries or rushed decisions—because that builds trust and clarity with product partners.
[00:07:45] Where Core Debt Really Lives
Earlier in his career he obsessed over long files; now he focuses on structural issues. Architecture, boundaries, and naming affect changeability far more than messy internals.
[00:08:15] Pairing as the Default Tool
Chris loves pairing for its speed, clarity, and shared context. Remote pairing has removed obstacles like mismatched keyboard setups or cramped office seating. Tools like Tuple and Pop keep it smooth.
[00:10:20] The Mob Tool and Fast Driver Switching
He explains how the Mob CLI tool makes switching drivers nearly instant, which keeps energy high and lets everyone work in their own editor environment, reducing friction and fatigue.
[00:13:45] Pairing with Junior Engineers
Pairing helps newer developers avoid painful pull-request rework and builds confidence. But teams must balance pairing with opportunities for engineers to build autonomy.
[00:20:50] Getting Feedback Sooner
Chris emphasizes speed of feedback: showing progress early to stakeholders prevents wasted days—and sometimes weeks—of heading in the wrong direction.
[00:21:10] Boring Technology as a Feature
After being burned by abandoned frameworks, Chris champions predictable, well-supported tools for the big layers: language, framework, database. Novelty is great—but only in places where rollback is cheap.
[00:23:20] Balancing Professional Development with Organizational Needs
Developers want experience with new technology; organizations want stability. Chris describes how leaders can channel curiosity safely and productively.
[00:27:20] Build a Database Server
Chris’s book, Build a Database Server, is a practical, language-agnostic guide to building a relational database from scratch. It uses a test suite as a feedback loop so developers can experiment, refactor, and learn architectural trade-offs along the way.
[00:31:45] What Writing the Book Taught Him
Creating a database deepened his appreciation for Postgres maintainers. He highlights the number of moving parts—storage engine, type system, query planner, wire protocol—and how academic papers often skip hands-on guidance.
[00:33:00] Experimenting with Coding Agents
Chris tested coding agents by giving them the book’s test suite. They passed many tests but produced brittle, incoherent architecture. Without a feedback loop for quality, the agents aimed only to satisfy test conditions—not build maintainable systems.
[00:36:55] Escaping a Local Maxima Through a Design Sprint
Chris shares a story of a team stuck maintaining a system that no longer fit business needs. A design sprint gave them space to reimagine the system, clarify naming, validate concepts, and identify which pieces were worth reusing.
[00:40:40] Rewrite vs. Refactor
He leans toward refactor for large systems but supports small, isolated rewrites when boundaries are clear.
[00:41:40] Building Trust in Legacy Code
When inheriting an old codebase, Chris advises starting with a small bug fix or UI tweak to understand deployment pipelines, test coverage, and failure modes before tackling bigger improvements.
[00:43:20] Recommended Reading
Chris recommends _Turn the Ship Around! for its lessons on empowering teams to act with intent instead of waiting for permission.
Resources Mentioned
Thanks to Our Sponsor!
Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.
It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.
Keep your coding cool and error-free, one line at a time!
Use the code maintainable to get a 10% discount for your first year. Check them out!
Subscribe to Maintainable on:
Or search "Maintainable" wherever you stream your podcasts.
Keep up to date with the Maintainable Podcast by joining the newsletter.
The AI-powered Podcast Player
