Advertise on podcast: Maintainable

Maintaining software over time rarely fails because of one bad decision. It fails because teams stop getting clear signals… and start guessing. In this episode, Robby talks with Lucas Roesler, Managing Partner and CTO at Contiamo. Lucas joins from Berlin to unpack what maintainability looks like in practice when you are dealing with real constraints… limited context, missing documentation, and systems that resist understanding. A big through-line is feedback. Lucas argues that long-lived systems become easier to change when they provide fast, trustworthy signals about what they are doing. That can look like tests that validate assumptions, tooling that makes runtime behavior visible, and a habit of designing for observability instead of treating it as a bolt-on. The conversation also gets concrete. Lucas shares a modernization effort built on a decade-old tangle of database logic… views, triggers, stored procedures, and materializations… created by a single engineer who was no longer around. With little documentation to lean on, the team had to build their own approach to “reading” the system and mapping dependencies before they could safely change anything. If you maintain software that has outlived its original authors, this is a grounded look at what helps teams move from uncertainty to confidence… without heroics, and without rewriting for sport. Episode Highlights[00:00:46] What well-maintained software has in common: Robby asks Lucas what traits show up in systems that hold together over time.[00:03:25] Readability at runtime: Lucas connects maintainability to observability and understanding what a system actually did.[00:16:08] Writing the system down as code: Infrastructure, CI/CD, and processes as code to reduce guesswork and improve reproducibility.[00:17:42] How client engagements work in practice: How Lucas’ team collaborates with internal engineering teams and hands work off.[00:25:21] The “rat’s nest” modernization story: Untangling a legacy data system with years of database logic and missing context.[00:29:40] Making data work testable: Why testability matters even when the “code” is SQL and pipelines.[00:34:59] Pivot back to feedback loops: Robby steers into why logs, metrics, and tracing shape better decision-making.[00:35:20] Why teams avoid metrics and tracing: The organizational friction of adding “one more component.”[00:42:59] Local observability with Grafana: Using visual feedback to spot waterfalls, sequential work, and hidden coupling.[00:50:00] Non-technical book recommendations: What Lucas reads and recommends outside of software.Links & ReferencesGuest and CompanyLucas Roesler: https://lucasroesler.com/Contiamo: https://contiamo.com/SocialMastodon: https://floss.social/@theaxerBluesky: https://bsky.app/profile/theaxer.bsky.socialBooks MentionedThe Wheel of Time (Robert Jordan): https://en.wikipedia.org/wiki/The_Wheel_of_TimeAccelerando (Charles Stross): https://en.wikipedia.org/wiki/AccelerandoCharles Stross: https://en.wikipedia.org/wiki/Charles_StrossThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Rewrites are seductive. Clean slates promise clarity, speed, and “doing it right this time.” In practice, they’re often late, over budget, and quietly demoralizing. In this episode of Maintainable, Robby sits down with Brittany Ellich, a Senior Software Engineer at GitHub, to talk about a different path. One rooted in stewardship, readability, and resisting the urge to start over. Brittany’s career began with a long string of rebuild projects. Over time, she noticed a pattern. The estimates were wrong. Feature development stalled. Teams burned energy reaching parity with systems they’d already had. That experience pushed her toward a strong belief: if software is in production and serving users, it’s usually worth maintaining. [00:00:57] What well-maintained software actually looks like For Brittany, readability is the first signal. If code can’t be understood, it can’t be changed safely. Maintenance begins with making systems approachable for the next person. [00:01:42] Rethinking technical debt She explains how her understanding of technical debt has evolved. Rather than a fixed category of work, it’s often anything that doesn’t map directly to new features. Bugs, reliability issues, and long-term risks frequently get lumped together, making prioritization harder than it needs to be. [00:05:49] Why AI changes the maintenance equation Brittany describes how coding agents have made it easier to tackle small, previously ignored maintenance tasks. Instead of waiting for debt to accumulate into massive projects, teams can chip away incrementally. (Related: GitHub Copilot and the Copilot coding agent workflow she’s explored.) [00:07:16] Context from GitHub’s billing systems Working on metered billing at GitHub means correctness and reliability matter more than flash. Billing should be boring. When it’s not, customers notice quickly. [00:11:43] Navigating a multi-era codebase GitHub’s original Rails codebase is still in active use. Brittany relies heavily on Git blame and old pull requests to understand why decisions were made, treating them as a form of living documentation. [00:25:27] Treating coding agents like teammates Rather than delegating massive changes, Brittany assigns agents small, well-scoped tasks. She approaches them the same way she would a new engineer: clear instructions, limited scope, and careful review. [00:36:00] Structuring the day to avoid cognitive overload She breaks agent interaction into focused windows, checking in a few times a day instead of constantly monitoring progress. This keeps deep work intact while still moving maintenance forward. [00:40:24] Low-risk ways to experiment Improving test coverage and generating repository instructions are safe entry points. These changes add value without risking production behavior. [00:54:10] Navigating team resistance and ethics Brittany acknowledges skepticism around AI and encourages teams to start with existing backlog problems rather than selling AI as a feature factory. [00:57:57] Books, habits, and staying balanced Outside of software, Brittany recommends Atomic Habits by James Clear, sharing how small routines help her stay focused. The takeaway is clear. AI doesn’t replace engineering judgment. Used thoughtfully, it can support the unglamorous work that keeps software alive. Good software doesn’t need a rewrite. It needs caretakers. References MentionedGitHub – Brittany’s current role and the primary environment discussedGitHub Universe – Where Brittany presented her coding agent workflowAtomic Habits by James Clear – Brittany’s recommended book outside of techOvercommitted - Podcast Brittany co-hostsThe Balanced Engineer Newsletter – Brittany’s monthly newsletter on engineering, leadership, and balanceBrittany Ellich’s website – Central hub for her writing and linksGitHub Copilot – The AI tooling discussed throughout the episodeHow the GitHub billing team uses the coding agent in GitHub Copilot to continuously burn down technical debt – GitHub blog post referencedThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Kent Beck: You’re Ignoring Optionality… and Paying for ItIn this episode of Maintainable, Robby speaks with Kent Beck, a foundational voice in modern software development and author of Tidy First?. Kent joins from California to explore why optionality is a central, often underestimated dimension of maintainable software. Kent begins by describing the tension between features and future flexibility. Shipping new capabilities is easy to measure. Creating options for what comes next is not. That imbalance is where maintainability either flourishes or collapses. Senior developers in particular must learn to navigate this tension because they have lived through the consequences when no one does. They reflect on how cost models have shifted across the last five decades. Early in Kent’s career, computers were expensive and programmers were cheap. Today the balance often flips depending on scale. At massive scale, electricity and compute time become meaningful costs again. That variability shapes whether teams optimize for hardware efficiency or developer efficiency. Episode Highlights[00:00:46] The Two Forms of Software Value Kent explains why software value comes from both current features and the options you preserve for future work. He describes optionality as the invisible half of maintainability. [00:03:35] When Computers Become “Expensive” Again Robby and Kent revisit the shift from hardware-optimized development to developer-optimized development and how large-scale systems have reintroduced compute cost pressures. [00:07:25] Why the Question Mark in Tidy First? Kent shares why tidying is always a judgment call and why he put a question mark in the title. [00:10:14] The Real Cost of Speculative Flexibility They discuss why adding configurability too early creates waste and why waiting until just before you need it increases value. [00:13:46] Making Hard Changes Easy Kent outlines his guiding idea. When you face a difficult change, make the change easy first, then make the easy change. [00:17:08] The Feature Saw Kent explains his features versus options graph and how teams repeatedly burn optionality until they hit zero. At that point, forward movement becomes painful. [00:19:37] Why 100 Percent Utilization Is a Trap Kent discusses how queuing theory shows that full utilization pushes wait times toward infinity. Overcommitted teams have no room for design work. [00:22:44] Split Teams Do Not Solve the Problem Robby talks about consulting scenarios where “tidy teams” and “feature teams” are separated. Kent argues that this splits incentives and prevents optionality from being sustained. [00:26:15] Structure and Behavior Should Not Ship Together Kent describes why feature changes are irreversible, structure changes are reversible, and why combining them increases risk for everyone. [00:30:37] Tidying Reveals Intent While cleaning up structure, developers often uncover logic flaws or misunderstandings that were previously hidden. [00:32:00] When Teams Discourage Testing Kent shares stories about environments where developers were punished for refactoring or writing tests. He explains why building career options is essential in those situations. [00:37:57] Why Tidying Is an Ethical Obligation Kent reframes optionality as a moral responsibility. No one should make work harder for the next person who touches the code. [00:41:33] Succession and Slicing Kent describes how nearly every structural change can be broken into small, safe steps, even when the change first appears atomic. [00:47:00] A Small Habit to Start Today Kent suggests adding a blank line to separate conceptual chunks in long functions. It is a small step that improves clarity immediately. Resources MentionedTidy First? by Kent BeckKent Beck on SubstackThe Timeless Way of Building by Christopher AlexanderThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Episode Highlights[00:00:48] What Makes Software Maintainable Don explains why unnecessary complexity is the biggest barrier to maintainability, drawing on themes from A Philosophy of Software Design. [00:03:14] The Cost of Clever Abstractions A real story from a Node.js API shows how an unused abstraction layer around MongoDB made everything harder without delivering value. [00:04:00] Shaping Teams and Developer Tools Don describes the structure of the Searchcraft engineering team and how the product grew out of recurring pain points in client projects. [00:06:36] Reducing Complexity Through SDK and Infra Design Why Searchcraft intentionally limits configuration to keep setup fast and predictable. [00:08:33] Lessons From Consulting Robby and Don compare consulting and product work, including how each environment shapes developers differently. [00:15:34] Inherited Software and Abandoned Dependencies Don shares the problems that crop up when community packages fall behind, especially in ecosystems like React Native. [00:18:00] Evaluating Third-Party Libraries Signals Don looks for before adopting a dependency: adoption, update cadence, issue activity, and whether the library is “done.” [00:19:40] Designing Code That Remains Understandable Why clear project structure and idiomatic naming matter more than cleverness. [00:20:29] RFCs as a Cultural Anchor How Don’s team uses RFCs to align on significant changes and avoid decision churn. [00:23:00] Documentation That Adds Context Documentation should explain why, not echo code. Don walks through how his team approaches this. [00:24:11] Type Systems and Maintainability How Don’s journey from PHP and JavaScript to TypeScript and Rust changed his approach to structure and communication. [00:27:05] Testing With Types Stable type contracts make tests cleaner and less ambiguous. [00:27:45] Building Trust in AI Systems Don discusses repeatability, hallucinations, and why tools like MCP matter for grounding LLM behavior. [00:29:28] AI in Developer Tools Search Craft’s MCP server lets developers talk to the platform conversationally instead of hunting through docs. [00:33:21] Improving Legacy Systems Slowly The Strangler pattern is a practical way to replace old systems one endpoint at a time. [00:34:11] Deep Work and Reducing Reactive Noise Don encourages developers to carve out time for uninterrupted thinking rather than bouncing between notifications. [00:36:09] Measuring Progress Build times, test speeds, and coverage provide signals teams can use to track actual improvement. [00:38:24] Changing Opinions Over a Career Why Don eventually embraced TypeScript after initially writing it off. [00:39:15] Industry Trends and Repeating Cycles SPAs, server rendering, and the familiar pendulum swing in web architecture. [00:41:26] Experimentation and Team Autonomy How POCs and side projects surface organically within Don’s team. [00:44:42] Growing Skills Through Intentional Goals Setting learning targets in 1:1s to support long-term developer growth. [00:47:19] Where to Find Don LinkedIn, Blue Sky, and his site: donmackinnon.dev. Resources MentionedA Philosophy of Software Design by John OusterhoutJohn Ousterhout’s Maintainable.fm Interview (Episode 131)SearchcraftElasticAlgoliaWordPress Plugin DirectoryRequest for Comments (RFC)Strangler Fig PatternC2 WikiModel Context Protocol (MCP)Glam AIAubrey/Maturin Series by Patrick O’BrianMaster and Commanderdonmackinnon.devThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Episode SummaryIn 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 MentionedBuild a Database ServerChris Zetter’s blogThe Mob Programming CLI ToolTuplePopTurn the Ship Around!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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Maintaining consistency across a sprawling codebase is one of the hardest challenges in software engineering. Denis Rechkunov, a Principal Software Engineer at Elastic, joins Robby to share how his team turned consistency into a cultural practice rather than a technical checklist. From managing open source projects with hundreds of contributors to experimenting safely with new patterns, Denis believes maintainability begins with shared ownership, not just clean code. He explains how Elastic introduced automation and linters to improve cohesion without discouraging creativity. Instead of enforcing perfection across the entire system, Denis’ team scopes their changes to manageable areas and rewards steady progress over sweeping rewrites. Their annual “On Week” tradition gives engineers space to fix what frustrates them most, showing how small, focused bursts of work can produce big leaps in stability and morale. The conversation also explores the human side of maintainability. Denis recalls early lessons about unclear expectations, the importance of documenting decisions in public pull requests, and how open feedback loops build trust across remote teams. Whether it’s stabilizing a flaky CI pipeline or mentoring new engineers, Denis argues that technical excellence thrives when consistency becomes a habit shared by everyone. Episode Highlights[00:01:02] Defining Well-Maintained Software Denis identifies consistency, documentation, testability, and agility as the key ingredients of maintainable systems. [00:02:22] Balancing Standards and Autonomy How automation and linters help preserve code cohesion while minimizing interpersonal friction. [00:04:08] Experimenting Safely Elastic scopes new patterns to low-risk modules before broader adoption, avoiding mass rewrites. [00:07:19] Incremental Cleanup Linters only apply to changed files, helping the team fix issues gradually without overwhelming contributors. [00:08:02] Maintainability as a People Problem Denis highlights that sustainable systems depend more on culture and mentorship than on architecture. [00:10:13] Lessons from Miscommunication An early experience showed the cost of undocumented conventions and unclear onboarding. [00:17:09] Making Space for Technical Debt Elastic’s engineers dedicate part of each sprint and an annual “On Week” to tackle maintenance work. [00:23:05] Restoring CI Reliability Denis shares how the team revived a pipeline with only a 10% success rate by categorizing failures and focusing on data. [00:32:00] Practicing Software Archaeology He stresses the value of documenting discussions in pull requests to avoid historical guesswork later. [00:36:09] Feedback and Trust Open communication, humility, and mutual feedback loops form the backbone of a maintainable culture. [00:51:00] Embracing Chaos in Open Source Denis encourages teams to accept a degree of entropy and focus their efforts on user-facing stability. [01:00:00] Security and Privacy Why maintainability, trust, and privacy are inseparable pillars of long-term sustainability. [01:01:06] Where to Start Instead of rewriting code, start by cultivating maintainability as a shared value across the team. Resources MentionedElasticgolangci-lintAppSignalThe Caves of Steel by Isaac Asimov — Denis’ recommendation inspired Robby to finally pick up a copy and start reading it himself.Denis’s Blog – rdner.deDenis on GitHubDenis on MastodonDenis on LinkedInThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Episode NotesThe discussion moves into how standards evolve beyond tools, the trade-offs of monocultures vs. consensus-driven teams, and why ownership matters when the original authors move on. Nathan also unpacks the cost of neglect, describing defects as anything that slows developers down—not just issues that impact end users. Later in the conversation, Nathan recounts a migration from a React SPA to Turbo and Stimulus that removed barriers between designers and developers. He highlights how keeping all problems on the radar together prevents teams from falling into local optima. The episode closes with reflections on TestBench, blind spots in testing, continuous improvement in remote teams, and advice for developers who feel stuck raising maintenance concerns. Episode Highlights[00:01:07] Defining Well-Maintained Software: Nathan shares his three key markers—up-to-date dependencies, adherence to team standards, and fixing defects immediately. [00:02:53] From Tools to Tacit Knowledge: Why norms start with tool-enforced rules like RuboCop but evolve into cultural agreements within teams. [00:04:49] Speed vs. Durability: Teams built on monoculture move quickly early on, but diverse, consensus-driven cultures go farther. [00:11:11] Owning the Architecture: When original developers leave, new teams must take responsibility for architecture rather than defer decisions. [00:13:37] The Cost of Neglect: Dependencies, drifting standards, and defects interact in compounding ways. Nathan reframes defects as “anything that impedes developer effectiveness.” [00:17:46] React → Turbo + Stimulus Migration: A costly SPA and siloed design team gave way to a simpler approach that reduced rework and empowered designers to contribute directly. [00:22:44] Avoiding Local Optima: Tackling problems in isolation creates dead ends—addressing them holistically opens real paths forward. [00:24:32] Who We Seek Validation From: Developer identities often align with whose approval they value—shaping front-end vs. back-end divides. [00:27:34] Comfort vs. Maintenance Burden: Silos built for comfort create tomorrow’s maintenance problems. [00:33:45] Relentless Improvement in Remote Teams: Start as an ensemble, evolve into autonomous work cells, and use work logs to sustain consensus. [00:38:33] What’s Missing from Remote Work: Nathan reflects on lost “hallway conversations” and the challenge of building social glue remotely. [00:40:50] The Story Behind TestBench: Dissatisfaction with existing frameworks and a desire for simplicity led to TestBench’s creation. [00:47:38] Testing Blind Spots: The biggest blind spot is equating testing with automation—interactive testing and intelligible output remain essential. [00:50:35] Advice for Stuck Engineers: Nathan encourages developers to study quality traditions, connect with peers, and embrace continuous improvement. [00:53:16] Book Recommendations: Deming’s Out of the Crisis and The New Economics, Toyota’s product development work, and Rawls’ A Theory of Justice. Tools & Resources MentionedBrightworks Digital – Nathan’s current company, where he serves as Principal.Nathan Ladd on LinkedIn – Connect with Nathan and follow his work.TestBench – A Ruby testing framework co-created by Nathan.Turbo – Hotwire framework for building modern, fast applications without heavy JavaScript.Stimulus – A modest JavaScript framework for enhancing HTML with small, reusable controllers.RSpec – A popular Ruby testing tool for behavior-driven development.Minitest – A simple and fast Ruby testing framework.RuboCop – A Ruby static code analyzer and formatter.Lessons Learned in Software Testing – Classic book on testing by Cem Kaner, James Bach, and Bret Pettichord.Out of the Crisis – W. Edwards Deming’s influential work on quality and systems thinking.The New Economics – Deming’s follow-up book on continuous improvement.A Theory of Justice – John Rawls’ seminal work on moral and political philosophy.The Toyota Product Development System – Insights into Toyota’s continuous improvement and development practices.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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Taylor Otwell, creator of Laravel and CEO of Laravel LLC, joins Robby to reflect on his 14-year journey building and maintaining one of the most popular web frameworks in the world. From its PHP 5.3 origins to a full-time business with a 70-person team, Taylor shares what he's learned about code maintainability, developer experience, and what it means to evolve without overcomplicating things. He discusses the importance of simplicity in software design, why sticking to framework conventions leads to better long-term outcomes, and how his minimalist mindset continues to shape Laravel today. Taylor also opens up about the moment he felt out of ideas, how Laravel’s 2024 funding round marked a new chapter, and what it’s like to hand off more responsibility while staying involved in the open source core. Episode Highlights[00:01:07] Taylor’s Definition of Maintainable Software   Simplicity, understandability, and confidence in making changes are key themes in Taylor's approach to longevity in software. [00:02:13] Kenny vs. the Terminator: A Metaphor for Code   Why Taylor believes software should be disposable and adaptable, not rigid and overbuilt. [00:05:39] Laravel’s Unexpected Traction   Taylor shares the early days of Laravel and the moment he realized the project had legs. [00:10:30] Who Laravel Is Built For   Taylor talks about designing for the “average developer” and balancing his own preferences with those of a broader community. [00:14:50] Curating a Growing Project—Solo   Despite Laravel’s scale, Taylor remains the sole curator of the open source core and explains why that hasn’t changed (yet). [00:18:00] From Scripts to Business   How Laravel’s first commercial product came out of a personal need—and pushed Taylor to go full time. [00:20:00] Making Breaking Changes   Taylor explains Laravel’s evolution and why he now tries to avoid breaking backward compatibility. [00:25:00] Stick to the Conventions   The Laravel apps that age best are the ones that don’t get too clever, Taylor says—because the clever dev always moves on. [00:27:00] Recognizing “Cleverness” as a Smell   Advice for developers who may unknowingly be over-engineering their way into future technical debt. [00:30:00] Making Decisions by Comparing Real Code   Taylor explains why he always brings discussions back to reality by looking at code side-by-side. [00:34:00] Dependency Injection vs. Facades   Why most Laravel developers stick with facades, and how architectural trends have changed. [00:41:00] Laravel’s Evolution Around Static Analysis   Taylor talks about embracing PHP's maturing type system while staying true to the dynamic roots of the framework. [00:43:00] A Shift in Laravel’s Testing Culture   How Adam Wathan’s course reshaped the community’s approach to feature testing in Laravel apps. [00:48:09] What Keeps Laravel Interesting Now   Taylor reflects on transitioning from solving his own problems to empowering a larger team—and why that’s the new challenge. Resources & LinksLaravelLaravel ChangelogTaylor on X (Twitter)Taylor on BlueskyElements of Style – William Strunk Jr.Adam Wathan's “Test-Driven Laravel” courseThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Robby is joined by Sara Jackson, Senior Developer at thoughtbot, to explore the practical ways teams can foster resilience—not just in their infrastructure, but in their everyday habits. They talk about why documentation is more than a chore, how to build trust in test suites, and how Chaos Engineering at the application layer can help make the case for long-term investment in maintainability. Sara shares why she advocates for writing documentation on day one, how “WET” test practices have helped her avoid brittle test suites, and why she sees ports as a powerful alternative to full rewrites. They also dive into why so many teams overlook failure scenarios that matter deeply to end users—and how being proactive about those situations can shape better products and stronger teams. Episode Highlights[00:01:28] What Well-Maintained Software Looks Like: Sara champions documentation that’s trusted, updated, and valued by the team. [00:07:23] Invisible Work and Team Culture: Robby and Sara discuss how small documentation improvements often go unrecognized—and why leadership buy-in matters. [00:10:34] Why Documentation Should Start on Day One: Sara offers a “hot take” about writing things down early to reduce cognitive load. [00:16:00] What Chaos Engineering Really Is: Sara explains the scientific roots of the practice and its DevOps origins. [00:20:00] Application-Layer Chaos Engineering: How fault injection can reveal blind spots in the user experience. [00:24:36] Observability First: Why you need the right visibility before meaningful chaos experiments can begin. [00:28:32] Pitching Resilience to Stakeholders: Robby and Sara explore how chaos experiments can justify broader investments in system quality. [00:33:24] WET Tests vs. DRY Tests: Sara explains why test clarity and context matter more than clever abstractions. [00:40:43] Working on Client Refactors: How Sara approaches improving test coverage before diving into major changes. [00:42:11] Rewrite vs. Refactor vs. Port: Sara introduces “porting” as a more intentional middle path for teams looking to evolve their systems. [00:50:45] Delete More Code: Why letting go of unused features can create forward momentum. [00:51:13] Recommended Reading: Being Wrong by Kathryn Schulz. Resources & LinksSara on MastodonthoughtbotRubyConf 2024 Talk – Chaos Engineering on the Death StarBook: Being Wrong by Kathryn SchulzFlu Shot on GitHubChaosRB on GitHubSemian from Shopify — a chaos engineering toolkit for RubyThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

CTO coach Joel Chippindale joins Robby to share what he's learned over two decades of building and leading software teams. Joel argues that maintainability has less to do with “clean code” and more to do with how teams communicate, prioritize, and make progress visible. Drawing on his time at Unmade and his current coaching practice, Joel outlines practical ways teams can build trust, navigate brittle systems, and stop letting technical debt conversations get lost in translation. Episode Highlights[00:01:10] A Working Definition of Maintainability Joel explains why “software that’s easy to keep changing” is the gold standard—and why context matters as much as code. [00:05:24] The Pitfalls of Pre-Optimization How developers can trap themselves by designing for futures that may never arrive. [00:10:40] Challenging the Iron Triangle Joel pushes back on the idea that teams must sacrifice quality for speed or cost. [00:15:31] Quality Is a Team Conversation Why code quality starts long before you open your editor. [00:20:00] Unmade Case Study: From Chaos to Confidence How Joel helped a struggling team at Unmade regain trust by delivering less—and showing more. [00:28:08] Helping Business Stakeholders Buy Into Maintenance Work How to reframe backend investments in terms that resonate across departments. [00:33:40] First Steps for Fragile Systems What Joel looks for when coaching teams overwhelmed by legacy code. [00:41:32] The Value of Boring Technology Why solving real problems matters more than chasing resume polish. [00:45:20] The Case for Coaching What makes leadership coaching valuable—and why it's not a sign of weakness. [00:51:10] Building Your Manager Voltron Joel shares why every developer should cultivate their own support system, including mentors, peers, and coaches. Resources & MentionsJoel’s Coaching Site – Monkey’s ThumbJoel on Mastodon“Take Back Control of Code Quality” – Joel’s Blog Post“Manager Voltron” by Lara HoganNever Split the Difference by Chris VossThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Melanie Sumner: Why Continuous Accessibility Is a Strategic AdvantageMelanie Sumner, Product Accessibility Lead for Design Systems at HashiCorp, joins Robby to talk about what it takes to scale accessibility across legacy products—and how aligning design and engineering processes creates lasting change. Melanie shares her work making Ember.js more accessible, her team’s philosophy behind their design system, and why she treats accessibility like any other technical concern. From the pitfalls of nested interactive elements to the strengths of Ember's conventions and codemods, this conversation offers a roadmap for integrating accessibility into every layer of product development. Melanie also reflects on why she trademarked the term Continuous Accessibility, how it fits into product lifecycles, and what other frameworks can learn from the Ember community’s approach. “Accessibility is a technical problem with a technical solution.” Melanie joins us from Chicago, Illinois. Episode Highlights[00:01:00] What Well-Maintained Software Looks Like: Consistency, purpose, and bridging design and engineering [00:02:30] Building a Unified Design System Across 10+ Legacy Products [00:03:30] Creating Component Requirements Before Design or Code [00:05:00] Designing with Accessibility Defaults—and Providing Bridges for Legacy [00:07:00] How Ember’s Conventions Help Scale Front-End Systems [00:09:30] Who Uses Ember—and Why It's a Fit for Teams with Big Requirements [00:13:30] Technical Debt in Design Systems and the Cost of Rushing [00:16:30] How They Future-Proof Components and Avoid Over-Engineering [00:19:00] What “Continuous Accessibility” Means in Practice [00:21:00] Accessibility Testing and the Limits of Automation [00:23:00] Common Accessibility Mistakes: Nested Interactives and Misused DIVs [00:24:30] Keyboard Navigation as a Litmus Test [00:26:00] Text Adventure Games and Accessibility as a Playable Experience [00:28:30] The Origin of Her Accessibility Journey at UNC Chapel Hill [00:31:00] Why She Avoids Framing Accessibility in Emotional Terms [00:32:45] Compliance as a Business Driver for Accessibility [00:35:00] Open Source Work on Testing Rules Across Frameworks [00:38:00] The Navigation API and Fixing Single-Page App Accessibility [00:40:30] HTML’s Forgiveness and the Illusion of “Good Enough” [00:43:00] Advice for Engineers Advocating for Accessibility Without Authority [00:46:45] Book Recommendation: Cradle Series by Will Wight [00:48:30] Where to Follow Melanie: melanie.codes Links and ResourcesMelanie's WebsiteHelios Design System at HashiCorpCradle Series by Will WightEmber Community SurveyA11y Automation GitHub ProjectAxe-coreFollow Melanie: GitHubLinkedInThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode of Maintainable, Robby speaks with Joe Masilotti, an independent consultant who helps Rails teams ship mobile apps using Hotwire Native. Joe shares his perspective on what makes software maintainable—especially for consultants who need to onboard quickly. He explains why setup scripts often add unnecessary complexity, and how he evaluates a project’s maintainability by how quickly he can go from clone to coding. Robby and Joe also discuss how hybrid mobile development can offer faster delivery, fewer bugs, and better long-term flexibility—especially when teams reuse their existing Rails web views. Joe explains how Hotwire Native allows teams to incrementally introduce native features without rewriting their entire app. Whether you’re maintaining a mobile shell built two years ago or just starting to explore native development, Joe offers actionable advice on setting expectations, scoping client work, and navigating modern mobile tech stacks. ⏱️ Episode Highlights[00:01:17] Onboarding as a Measure of Maintainability Joe shares how quickly he can spin up a Rails app often reflects how maintainable it is. [00:05:12] Being a Good Guest in Someone Else’s Codebase Joe outlines his ideal onboarding checklist and how he adapts to unfamiliar environments. [00:08:00] Setting Communication and Collaboration Expectations The three questions Joe asks every client to understand how their team works. [00:13:02] Offering Opinions—Only Where Invited Why Joe stays scoped to the work he’s hired for, even when tempted to fix more. [00:14:15] When Technical Debt Enters the Conversation Joe explains how debt discussions usually emerge after version one is shipped. [00:15:33] Who Should Read Hotwire Native for Rails Developers Joe describes the type of developer his book is written for and what it covers. [00:18:01] Choosing Native vs. Hybrid for Your Rails App A framework comparison based on your current frontend architecture. [00:20:00] Introducing the Hotwire Native Mindset Why logic belongs on the server and the client should stay thin. [00:21:00] Bridge Components: How Rails, iOS, and Android Connect Joe walks through how native and web technologies pass data between layers. [00:24:00] Why Even a Web View-Based App is Worth Shipping The practical benefits of discoverability, push notifications, and native APIs. [00:28:01] Replacing Unmaintainable Apps with Hotwire Native Joe describes how hybrid rewrites often reduce mobile code by 90%. [00:31:33] Letting Go of Feature Parity Why most clients end up cutting features they originally wanted to preserve. [00:32:18] Scoping and Estimating Project-Based Work How Joe uses repeatable patterns to price fixed-fee consulting engagements. [00:35:15] Using AI to Translate Between Tech Stacks Joe shares how he leverages LLMs to explore unfamiliar languages like Kotlin. [00:42:26] Long-Term Maintainability and When to Touch the Code Why some apps don’t need changes for years—and that’s okay. [00:43:43] Why Hybrid Apps Are Easier to Replace Joe explains why hybrid apps are often more disposable and less risky than monolithic web apps. 🔗 Resources Mentioned:Joe’s Book: Hotwire Native for Rails DevelopersJoe’s NewsletterHotwire Native Mindset ArticlePlease Unsubscribe, Thanks by Julio Vincent GambutoFollow Joe on X (formerly Twitter) and visit masilotti.com to learn more. 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Freedom Dumlao (CTO at Vestmark) joins Robby to explore what it means to maintain software at scale—and why teams sometimes need to unlearn the hype. With two decades of experience supporting financial systems, Freedom shares how his team manages a Java monolith that oversees $1.6 trillion in assets. But what’s most surprising? His story of how a team working on 70+ microservices rebuilt their platform as a single Ruby on Rails monolith—and started shipping faster than ever before. Episode Highlights[00:02:00] Why Respecting Legacy Code Matters Freedom reflects on a lesson he learned at Amazon: "Respect what came before." He discusses the value of honoring the decisions of past developers—especially when their context is unknown. [00:05:00] How Tests Help (and Where They Don’t) Freedom discusses how tests can clarify system behavior but not always intent—especially when market logic or business-specific rules come into play. [00:07:00] The Value of Understudies in Engineering Freedom shares how his team intentionally pairs subject matter experts with understudies to reduce risk and transfer knowledge. [00:09:30] Rethinking Technical Debt He challenges the fear-based framing of technical debt, comparing it instead to a strategic mortgage. [00:17:00] From 70 Services to 1 Monolith At FlexCar, Freedom led an unconventional rewrite—consolidating 70 Java microservices into a single Rails app. The result? A dramatic increase in velocity and ownership. [00:25:00] Choosing Rails Over Phoenix, Laravel, and Django After evaluating multiple frameworks, Rails' cohesiveness, Hotwire, and quick developer ramp-up made it the clear winner—even converting skeptical team members. [00:31:00] How Rails Changed Team Dynamics By reducing dependency handoffs, the new Rails app enabled solo engineers to own complete features. The impact? Faster delivery and more engaged developers. [00:36:30] Why Rails Still Makes Sense at a 20-Year-Old Company Even with a large Java codebase, Vestmark uses Rails for rapid prototyping and new product development. [00:41:00] Using AI to Navigate Legacy Systems Freedom explains how his team uses retrieval-augmented generation (RAG) to surface relevant code—but also the limitations of AI on older or less common codebases. [00:51:00] Seek Feedback, Not Consensus Freedom explains why aiming for alignment slows teams down—and how decision-makers can be inclusive without waiting for full agreement. Links and ResourcesFreedom Dumlao on LinkedInVestmarkNo Rules RulesDungeon Crawler Carl seriesThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Mercedes Bernard, Staff Software Engineer at Kit, joins Robby to talk about what it really means to write code that lasts—and who it should be written for. In this episode of Maintainable, Mercedes shares a thoughtful and practical perspective on working with legacy codebases, managing technical debt, and creating a team culture that values maintainability without fear or shame. Her guiding principle? Well-maintained software is friendly software—code that is understandable and approachable, especially for early-career developers. Together, they discuss how to audit and stabilize older systems, avoid full rewrites, and create consistent developer experiences in large applications. Mercedes reflects on her decade in consulting and how that shaped her approach to navigating incomplete documentation, missing historical context, and multiple competing patterns in a codebase. She breaks down different types of technical debt, explains why not all of it is inherently bad, and offers strategies for advocating for maintenance work across engineering and product teams. The conversation also touches on architecture patterns like job fan-out, measuring performance regressions, reducing infrastructure load, and building momentum for improvements even when leadership isn’t actively prioritizing them. If you’ve ever felt overwhelmed by a messy project or struggled to justify maintenance work, this episode will leave you with a fresh mindset—and a few practical tactics—for making code more sustainable and inclusive. Episode Highlights[00:01:08] Defining Well-Maintained Software Mercedes explains her top metric: software that feels friendly, especially to early-career developers navigating the codebase for the first time. [00:03:00] What Friendly Code Actually Looks Like She shares why consistency, discoverability, and light documentation (like class comments or UML snippets) can make a huge difference. [00:05:00] Assessing Code Like a House Tour Mercedes introduces her metaphor of giving a house tour to evaluate code: does everything feel like it’s in the right place—or is the stove in the cabinet? [00:06:53] Consulting Mindset: Being a Guest in the Codebase With a decade of consulting experience, Mercedes shares how she navigates legacy systems when historical context is long gone. [00:10:40] Stabilizing a Startup’s Tangled Architecture She walks through an in-depth case study where she helped a client with multiple abandoned services get back to stability—without a rewrite. [00:17:00] The Power of a One-Line Fix Mercedes shares how a missing check caused a job to fan out 30 million no-op background jobs a day—and how one line of code reduced that by 75%. [00:23:40] Why State Checks Belong Everywhere She explains how defense-in-depth patterns help avoid job queue flooding and protect system resources early in the fan-out process. [00:24:59] Reframing Technical Debt Not all debt is bad. Mercedes outlines three types—intentional, evolutionary, and time-based—and how to approach each one differently. [00:28:00] Why Teams Fall Behind Without Realizing It Mercedes and Robby talk about communication gaps between engineers and product stakeholders—and why it’s not always clear when tech debt starts piling up. [00:34:00] Quantifying Developer Friction Mercedes recommends expressing technical debt in terms of lost time, slow features, and increased cost rather than vague frustrations. [00:42:00] Getting Momentum Without Permission Her advice to individual contributors: start small. Break down your frustrations into bite-sized RFCs or tickets and show the impact. [00:45:40] Letting the Team Drive Standards Mercedes encourages team-led conventions over top-down declarations, and explains why having any decision is better than indecision. [00:47:54] Recommended Reading She shares a surprising favorite: The Secret Life of Groceries, a systems-thinking deep dive into the grocery industry by Benjamin Lorr. Resources & Links🧠 Mercedes Bernard’s website🛠 Kit📘 The Secret Life of Groceries by Benjamin Lorr🔎 Fan-out Pattern – Martin Fowler (for deeper context on fan-out job strategies)💬 Mercedes on LinkedInThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.

Evan Phoenix (@evanphx), CEO of Miren, joins Robby to explore the subtle but powerful difference between writing code that works and writing code that explains itself. They discuss the role of clarity in maintainable systems, why splitting a monolith can backfire, and what developers can learn from artists and tradespeople alike. Episode Highlights[00:01:30] What Makes Software Maintainable? Evan defines maintainability as how easily a newcomer can make a change with minimal context. [00:02:30] Why Business Logic Should Be Obvious A discussion on domain knowledge leakage and abstracting rules like “can we sell today?” [00:05:00] Programming 'Mouthfeel' and the Trap of Prefactoring Evan explains why prematurely optimizing for reuse can lead to unnecessary complexity. [00:07:00] When to Extract Logic: The Copy/Paste Signal A practical approach to identifying reusable components by spotting repeated code. [00:08:00] Technical Debt as a Reflection of Cognitive Load Why forgetting your own code doesn’t automatically mean it’s “bad” code. [00:10:30] Testing as Emotional Insurance How writing even basic checks can build team confidence—especially when test coverage is weak. [00:13:00] Daily Integration Tests: A Low-Pressure Safety Net Using nightly integration runs to catch invisible bugs in complex systems. [00:14:00] Confidence > 100% Test Coverage Why fast feedback loops matter more than aiming for exhaustive tests. [00:20:00] Splitting the Monolith: A Cautionary Tale Evan shares how decoupling apps without decoupling the database created chaos. [00:22:00] Shared Models, Split Repos, and Hidden Pitfalls The unexpected bugs that emerge when two apps maintain duplicate models and validations. [00:23:00] Better Alternatives to Splitting Codebases How separate deployments and tooling can mimic team separation without architectural debt. [00:28:00] The Hidden Cost of Diverging Business Domains When apps evolve independently, business logic begins to drift—undermining consistency. [00:29:00] Building Miren and Staying Motivated How Evan approaches early-stage product development with curiosity and detachment. [00:36:00] How to Know When Your Open Source Project Is “Done” Reframing “dead” projects as complete—and why stability is often a feature. [01:01:00] Signals for Trusting Open Source Dependencies Evan’s mental checklist for evaluating if a library is worth adopting. [01:07:00] The Importance of Hiring Junior Developers Why investing in beginners is crucial for the future of our industry. [01:08:00] Book Recommendations Evan recommends The Inner Game of Tennis and Snow Crash. Links and ResourcesEvan Phoenix’s WebsiteEvan on GitHubEvan on MastodonBook RecommendationsThe Inner Game of Tennis (book)Snow Crash by Neal StephensonThanks 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: Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.