POPULARITY
Episode Highlights[00:00:48] What Makes Software MaintainableDon 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 AbstractionsA 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 ToolsDon describes the structure of the Search Craft engineering team and how the product grew out of recurring pain points in client projects.[00:06:36] Reducing Complexity Through SDK and Infra DesignWhy Search Craft intentionally limits configuration to keep setup fast and predictable.[00:08:33] Lessons From ConsultingRobby and Don compare consulting and product work, including how each environment shapes developers differently.[00:15:34] Inherited Software and Abandoned DependenciesDon shares the problems that crop up when community packages fall behind—especially in ecosystems like React Native.[00:18:00] Evaluating Third-Party LibrariesSignals 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 UnderstandableWhy clear project structure and idiomatic naming matter more than cleverness.[00:20:29] RFCs as a Cultural AnchorHow Don's team uses RFCs to align on significant changes and avoid decision churn.[00:23:00] Documentation That Adds ContextDocumentation should explain why, not echo code. Don walks through how his team approaches this.[00:24:11] Type Systems and MaintainabilityHow Don's journey from PHP and JavaScript to TypeScript and Rust changed his approach to structure and communication.[00:27:05] Testing With TypesStable type contracts make tests cleaner and less ambiguous.[00:27:45] Building Trust in AI SystemsDon discusses repeatability, hallucinations, and why tools like MCP matter for grounding LLM behavior.[00:29:28] AI in Developer ToolsSearch Craft's MCP server lets developers talk to the platform conversationally instead of hunting through docs.[00:33:21] Improving Legacy Systems SlowlyThe Strangler pattern as a practical way to replace old systems one endpoint at a time.[00:34:11] Deep Work and Reducing Reactive NoiseDon encourages developers to carve out time for uninterrupted thinking rather than bouncing between notifications.[00:36:09] Measuring ProgressBuild times, test speeds, and coverage provide signals teams can use to track actual improvement.[00:38:24] Changing Opinions Over a CareerWhy Don eventually embraced TypeScript after originally writing it off.[00:39:15] Industry Trends and Repeating CyclesSPAs, server rendering, and the familiar pendulum swing in web architecture.[00:41:26] Experimentation and Team AutonomyHow POCs and side projects surface organically within Don's team.[00:44:42] Growing Skills Through Intentional GoalsSetting learning targets in 1:1s to support long-term developer growth.[00:47:19] Where to Find DonLinkedIn, Blue Sky, and his site: donmckinnon.dev.Resources MentionedA Philosophy of Software Design by John OusterhoutJohn Ousterhout's Maintainable.fm Interview (Episode 131)Search CraftElasticAlgoliaWordPress Plugin DirectoryRequest for Comments (RFC)Strangler Fig PatternC2 WikiModel Context Protocol (MCP)Glam AIAubrey/Maturin Series by Patrick O'BrianMaster and Commanderdonmckinnon.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.
This interview was recorded for GOTO Unscripted.https://gotopia.techAndrew Harmel-Law - Technical Principal at Thoughtworks & Author of "Facilitating Software Architecture"Marit van Dijk - Developer Advocate at JetBrains, Java Champion & Open Source ContributorRESOURCESAndrewhttps://bsky.app/profile/andrewhl.bsky.socialhttps://www.linkedin.com/in/andrewharmellawhttps://andrewharmellaw.github.ioMarithttps://bsky.app/profile/maritvandijk.bsky.socialhttps://linkedin.com/in/maritvandijkhttps://medium.com/@mlvandijkhttps://maritvandijk.comLinkshttps://facilitatingsoftwarearchitecture.comhttps://ruthmalan.comhttps://www.linkedin.com/pulseDESCRIPTIONAndrew Harmel-Law discusses their book "Facilitating Software Architecture" and how traditional architecture approaches often become bottlenecks that slow down high-performing development teams.Rather than architects making top-down decisions in isolation, they advocate for a facilitation approach centered on the "advice process".This collaborative method shifts the architect's role from decision-maker to conversation facilitator. The approach has proven successful even in traditional corporate environments, ultimately creating more maintainable code bases where development teams actually enjoy working and can respond effectively to changing requirements.RECOMMENDED BOOKAndrew Harmel-Law • Facilitating Software Architecture • https://amzn.eu/d/5kZKVfUPsst! The Folium Diary has something it wants to tell you - please come a little closer...YOU can change the world - you do it every day. Let's change it for the better, together.Listen on: Apple Podcasts SpotifyBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!
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 MaintainableChris 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 CommentsHe 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 DebtChris 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 LivesEarlier 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 ToolChris 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 SwitchingHe 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 EngineersPairing 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 SoonerChris 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 FeatureAfter 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 NeedsDevelopers want experience with new technology; organizations want stability. Chris describes how leaders can channel curiosity safely and productively.[00:27:20] Build a Database ServerChris'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 HimCreating 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 AgentsChris 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 SprintChris 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. RefactorHe leans toward refactor for large systems but supports small, isolated rewrites when boundaries are clear.[00:41:40] Building Trust in Legacy CodeWhen 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 ReadingChris 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.
This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview here:https://gotopia.tech/episodes/389Alessandro Colla - Partner & Head of Development at Evoluzione & Co-Author of "Domain-Driven Refactoring"Alberto Acerbis - Software Architect at Intré & Co-Author of "Domain-Driven Refactoring"Xin Yao - Independent Consultant Contextualizing DDD & Sociotechnical ArchitectureRESOURCESAlessandrohttps://www.linkedin.com/in/alessandrocollahttps://www.alessandrocolla.comAlbertohttps://www.linkedin.com/in/aacerbishttps://albertoacerbis.comXinhttps://bsky.app/profile/settling-mud.bsky.socialhttps://www.linkedin.com/in/xinxinLinkshttps://github.com/PacktPublishing/Domain-driven-Refactoringhttps://github.com/BrewUpDESCRIPTIONLegacy code isn't just old - it's a treasure chest of lost business knowledge waiting to be rediscovered. Alessandro Colla and Alberto Acerbis share their battle-tested approach to domain-driven refactoring, explaining why you should start with understanding the business problem before touching a single line of code. Like Michelangelo seeing the statue of David hidden in marble, they show how the right solution already exists within your legacy codebase—you just need the right tools and techniques to set it free.From event storming workshops over beer to modular monoliths as stepping stones, these "double-A battery" developers prove that thoughtful, incremental refactoring beats flashy microservices migrations every time.RECOMMENDED BOOKSColla & Acerbis • Domain-Driven Refactoring • https://amzn.to/3I3I7zfEvans • Domain-Driven Design • https://amzn.to/3tnGhwmVernon • Implementing Domain-Driven Design • https://amzn.to/44r39PBNilsson • Applying Domain-Driven Design and Patterns • https://amzn.to/3GoxYwInspiring Tech Leaders - The Technology PodcastInterviews with Tech Leaders and insights on the latest emerging technology trends.Listen on: Apple Podcasts SpotifyBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!
Stell dir vor, du arbeitest an einer Software, die sich mit jeder technologischen Welle weiterentwickelt – ganz ohne dass du sie neu schreiben musst. Kein Stress, keine Angst vor Legacy-Code, kein „Das funktioniert mit dem neuen Framework nicht mehr“. Klingt nach Science-Fiction? Nicht mehr lange. Die Softwareentwicklung befindet sich in einem radikalen Wandel: Was früher Wochen dauerte, entsteht heute in Stunden – und das oft ohne eine einzige Zeile klassischen Codes. Low-Code-Plattformen und KI-gestützte Tools verschieben die Grenzen dessen, was möglich ist. Doch was bedeutet das für die Zukunft der Entwicklung? Und wie schaffen wir es, Geschwindigkeit zu gewinnen, ohne die Kontrolle zu verlieren? In dieser Episode sprechen Claudia Koschtial und Carsten Czarski über das Prinzip der Abstraktion und warum sie der wahre Gamechanger ist, wenn es um nachhaltige Innovation geht. Denn eines ist klar: Der Code von heute ist morgen schon veraltet. Doch wer auf Abstraktion setzt, behält die Funktionalität – unabhängig davon, wie sich die Technologien darunter verändern.
Technische Schulden: Code veröffentlichen und weiterziehen oder doch erst aufräumen?Technische Schulden fühlen sich oft nach Ballast an, können aber dein stärkster Hebel für Speed sein. Der Knackpunkt ist, sie bewusst und sichtbar einzugehen und konsequent wieder abzubauen. In dieser Episode sprechen wir darüber, wie wir technische Schulden strategisch nutzen, ohne uns langfristig festzufahren.Ward Cunningham sagt: Technische Schulden sind nicht automatisch schlechter Code. Wir ordnen ein, was wirklich als “Debt” zählt und warum Provisorien oft länger leben als geplant. Dann erweitern wir die Perspektive von der Code‑ und Architektur‑Ebene auf People und Prozesse: Knowledge Silos, fehlendes Code Review und organisatorische Entscheidungen können genauso Schulden sein wie ein any in TypeScript. Wir diskutieren sinnvolle Indikatoren wie DORA Metriken, zyklomatische Komplexität und den CRAP Index, aber auch ihre Grenzen. Warum Trends über Releases hilfreicher sind als Einzelwerte oder wie Teamskalierung die Kennzahlen beeinflusst. Dazu die Business Seite: reale Kosten, Produktivitätsverluste, Frust im Team und Fluktuation. Als Anschauung dient der Sonos App Rewrite als teures Lehrstück für akkumulierte Schulden.Wenn du wissen willst, wie du in deinem Team Technical Debt als Werkzeug nutzt, Metriken und Kultur klug kombinierst und den Business Impact sauber argumentierst, dann ist diese Episode für dich.Bonus: Wir verraten, warum Legacy allein keine Schuld ist und wie Open Source, Plattformteams und Standardisierung dir echte Zinsen sparen können.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:
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.
OpenAI's Codex has already shipped hundreds of thousands of pull requests in its first month. But what is it really, and how will coding agents change the future of software?In this episode, General Partner Anjney Midha goes behind the scenes with one of Codex's product leads- Alexander Embiricos - to unpack its origin story, why its PR success rate is so high, the safety challenges of autonomous agents, and what this all means for developers, students, and the future of coding. Timecodes:0:00 Intro: The Vision for AI Agents1:25 Codex's Origin and Naming3:20 Early Prototypes and Agent Form Factors6:00 Cloud Agents: Safety and Security9:40 Prompt Injection and Attack Vectors12:00 PR Merging: Metrics and Transparency17:00 The Future of Code Review and Automation20:00 User Adoption: Internal vs. External Surprises22:00 Multi-Turn Interactions and Product Learnings29:30 Best-of-N, Slot Machine Analogy, and Creativity33:00 Human Taste, Iteration, and Collaboration40:00 AI's Impact on Software Engineering Careers45:00 Education, CS Degrees, and AI Integration49:00 Prototyping, Hackathons, and Speed to Magic55:00 Legacy Code, Modernization, and Global Adoption1:00:00 Enterprise, Security, and Air-Gapped Environments1:05:00 Product Roadmap and Future of Codex1:10:00 Advice for Founders and Startups1:15:00 Education Reform and Project-Based Learning1:20:00 Hiring, Building, and New Grad Advice Resources: Find Alex on X: https://x.com/embiricoFind Anjney on X: https://twitter.com/AnjneyMidha Stay Updated: If you enjoyed this episode, be sure to like, subscribe, and share with your friends!Find a16z on X: https://x.com/a16zFind a16z on LinkedIn: https://www.linkedin.com/company/a16zListen to the a16z Podcast on Spotify: https://open.spotify.com/show/5bC65RDvs3oxnLyqqvkUYXListen to the a16z Podcast on Apple Podcasts: https://podcasts.apple.com/us/podcast/a16z-podcast/id842818711Follow our host: https://x.com/eriktorenbergPlease note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Stay Updated:Find a16z on XFind a16z on LinkedInListen to the a16z Podcast on SpotifyListen to the a16z Podcast on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
In this episode, Dave interviews Neeraj Abhyankar, vice president and practice head of Data, Analytics, and Generative AI at R Systems.They discuss: The role of AI in modernizationThe evolution of AI throughout technology historyThe importance of "human in the loop" when working with AI
Refactoring Legacy Code with Alessandro Di GioiaIn this episode, join Alessandro Di Gioia — co-founder of Alcor Academy, co-author of Agile Technical Practices Distilled, and trainer at Avanscoperta — as he shares practical refactoring techniques to breathe new life into forgotten systems, even without test coverage. With technology evolving faster than ever in 2025, knowing how to modernize legacy code is essential to keep your systems adaptable, reliable, and future-ready. You'll learn how to:Refactor without fearBreak dependencies safelyTurn code chaos into clarityWith 20 years of experience and a passion for tidy, expressive, and practical code, Alessandro reveals his proven strategies for taming legacy systems: retrofitting tests, breaking dependencies, and navigating the dreaded “big ball of mud” with confidence.
Refactoring Legacy Code with Alessandro Di GioiaIn this episode, join Alessandro Di Gioia — co-founder of Alcor Academy, co-author of Agile Technical Practices Distilled, and trainer at Avanscoperta — as he shares practical refactoring techniques to breathe new life into forgotten systems, even without test coverage. With technology evolving faster than ever in 2025, knowing how to modernize legacy code is essential to keep your systems adaptable, reliable, and future-ready. You'll learn how to:Refactor without fearBreak dependencies safelyTurn code chaos into clarityWith 20 years of experience and a passion for tidy, expressive, and practical code, Alessandro reveals his proven strategies for taming legacy systems: retrofitting tests, breaking dependencies, and navigating the dreaded “big ball of mud” with confidence.
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.
Is AI the silver bullet for modernizing our aging software systems, or is it a fast track to creating the next generation of unmaintainable "slopware"?In this episode, I sit down with Marianne Bellotti, author of the amazing book "Kill It With Fire," to discuss the complex reality of legacy system modernization in the age of AI. We explore why understanding the cultural and human history of a codebase is critical, and how the current AI hype cycle isn't a silver bullet for legacy IT modernization efforts.Marianne breaks down a recent disastrous "vibe coding" experiment, the risk of replacing simple human errors with catastrophic automated ones, and the massive disconnect between the promises of AI agents and the daily reality of a practitioner just trying to get a service account from IT.Join us for a pragmatic and no-BS conversation about the real challenges in software, the practical ways to leverage LLMs as an expert partner, and why good old-fashioned systems thinking is more important than ever.Find Marianne Bellotti:Socials: @BellmarWebsite: https://belladotte.tech/Book, "Kill It With Fire": https://nostarch.com/kill-it-fire
This interview was recorded for GOTO Unscripted.https://gotopia.techRead the full transcription of this interview hereMarit van Dijk - Developer Advocate at JetBrains, Java Champion & Open Source ContributorHannes Lowette - Principal Consultant at Axxes, Monolith Advocate, Speaker & Whiskey LoverRESOURCESMarithttps://bsky.app/profile/maritvandijk.bsky.socialhttps://linkedin.com/in/maritvandijkhttps://github.com/mlvandijkhttps://medium.com/@mlvandijkhttps://maritvandijk.comHanneshttps://bsky.app/profile/hanneslowette.nethttps://twitter.com/hannes_lowettehttps://github.com/Belenarhttps://linkedin.com/in/hanneslowetteLinkshttps://www.felienne.comhttps://codereading.clubhttps://github.com/neontribe/code-reading-clubDESCRIPTIONReading code is a critical yet often underappreciated skill in software development. Marit van Dijk & Hannes Lowette highlight that while developers are trained to write code, they spend most of their time understanding existing codebases—often with incomplete documentation and evolving complexity.They discuss research-backed strategies, such as structured code reading exercises, participation in communities like the Code Reading Club, and leveraging modern IDE tools to navigate and comprehend unfamiliar code. The conversation underscores the importance of empathy in code reviews, writing clear commit messages, and using tests as documentation to improve collaboration and maintainability. By practicing code reading deliberately and utilizing available resources, developers can become more effective and adaptable in their work.RECOMMENDED BOOKSFelienne Hermans • The Programmer's BrainAdrienne Braganza Tacke • "Looks Good to Me": Constructive Code ReviewsDuncan McGregor & Nat Pryce • Java to KotlinSaleem Siddiqui • Learning Test-Driven DevelopmentRoy Osherove • The Art of Unit TestingTrisha Gee & Helen Scott • Getting to Know IntelliJ IDEAJacqui Read • Communication PattBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!
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 MaintainabilityJoel 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-OptimizationHow developers can trap themselves by designing for futures that may never arrive.[00:10:40] Challenging the Iron TriangleJoel pushes back on the idea that teams must sacrifice quality for speed or cost.[00:15:31] Quality Is a Team ConversationWhy code quality starts long before you open your editor.[00:20:00] Unmade Case Study: From Chaos to ConfidenceHow Joel helped a struggling team at Unmade regain trust by delivering less—and showing more.[00:28:08] Helping Business Stakeholders Buy Into Maintenance WorkHow to reframe backend investments in terms that resonate across departments.[00:33:40] First Steps for Fragile SystemsWhat Joel looks for when coaching teams overwhelmed by legacy code.[00:41:32] The Value of Boring TechnologyWhy solving real problems matters more than chasing resume polish.[00:45:20] The Case for CoachingWhat makes leadership coaching valuable—and why it's not a sign of weakness.[00:51:10] Building Your Manager VoltronJoel 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.
What if your most critical systems run on code that no one fully understands?In this episode, Omer Rosenbaum, CTO and co-founder of Swimm, explains how to use AI to close the knowledge gap in your legacy codebase. Discover the limitations of AI in understanding legacy code and learn novel approaches to automatically document complex systems, ensuring their critical business logic is preserved and understood within the organization. Beyond legacy systems, Omer also shares practical advice for how junior developers can thrive in the AI era and how teams and organizations can conduct more effective research.Key topics discussed:How junior developers can thrive in the age of AIThe danger of shipping code you don't fully understandWhy AI can't deduce everything from your code aloneHow writing documentation becomes more critical now with AIHow to analyze code that even LLMs struggle to read, like COBOLHow to keep your organization's knowledge base trustworthy and up to dateThe real danger of letting AI agents run uncheckedA practical approach to conducting more effective research Timestamps:(00:00) Trailer & Intro(02:10) Career Turning Points(05:24) What Juniors Should Do in the Age of AI(11:05) Junior Developer's Responsbility When Using AI(14:50) AI and Critical Thinking(16:20) Understanding & Preserving Domain Knowledge(18:11) The Importance of Written Knowledge for AI Usage(21:51) Limitations of AI in Understanding Knowledge Base(26:34) The Limitations of LLM in Navigating Legacy Codebases (e.g. COBOL)(32:38) Effective Knowledge Sharing Culture in the Age of AI(34:54) Keeping Knowledge Base Up-to-Date(36:55) Keeping the Organization Knowledge Base Accurate(39:08) Fact Checking and Preventing AI Hallucination(41:24) The Potential of MCP(43:24) The Danger of AI Agents Hallucinating with Each Other(45:00) How to Get Better at Research(53:41) The Importance of Investing in Research(57:18) 3 Tech Lead Wisdom_____Omer Rosenbaum's BioOmer Rosenbaum is the CTO and co-founder of Swimm, a platform reinventing the way engineering organizations manage internal knowledge about their code base. Omer founded the Check Point Security Academy and was the Cyber Security Lead at ITC, an educational organization that trains talented professionals to develop careers in technology. Omer has a MA in Linguistics from Tel Aviv University and is the creator behind the Brief YouTube Channel.Follow Omer:LinkedIn – linkedin.com/in/omer-rosenbaum-034a08b9Twitter – x.com/Omer_RosSwimm – swimm.ioEmail – omer@swimm.io
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.codesLinks 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 MaintainabilityJoe 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 CodebaseJoe outlines his ideal onboarding checklist and how he adapts to unfamiliar environments.[00:08:00] Setting Communication and Collaboration ExpectationsThe three questions Joe asks every client to understand how their team works.[00:13:02] Offering Opinions—Only Where InvitedWhy Joe stays scoped to the work he's hired for, even when tempted to fix more.[00:14:15] When Technical Debt Enters the ConversationJoe explains how debt discussions usually emerge after version one is shipped.[00:15:33] Who Should Read Hotwire Native for Rails DevelopersJoe describes the type of developer his book is written for and what it covers.[00:18:01] Choosing Native vs. Hybrid for Your Rails AppA framework comparison based on your current frontend architecture.[00:20:00] Introducing the Hotwire Native MindsetWhy logic belongs on the server and the client should stay thin.[00:21:00] Bridge Components: How Rails, iOS, and Android ConnectJoe walks through how native and web technologies pass data between layers.[00:24:00] Why Even a Web View-Based App is Worth ShippingThe practical benefits of discoverability, push notifications, and native APIs.[00:28:01] Replacing Unmaintainable Apps with Hotwire NativeJoe describes how hybrid rewrites often reduce mobile code by 90%.[00:31:33] Letting Go of Feature ParityWhy most clients end up cutting features they originally wanted to preserve.[00:32:18] Scoping and Estimating Project-Based WorkHow Joe uses repeatable patterns to price fixed-fee consulting engagements.[00:35:15] Using AI to Translate Between Tech StacksJoe shares how he leverages LLMs to explore unfamiliar languages like Kotlin.[00:42:26] Long-Term Maintainability and When to Touch the CodeWhy some apps don't need changes for years—and that's okay.[00:43:43] Why Hybrid Apps Are Easier to ReplaceJoe explains why hybrid apps are often more disposable and less risky than monolithic web apps.
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 MattersFreedom 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 EngineeringFreedom shares how his team intentionally pairs subject matter experts with understudies to reduce risk and transfer knowledge.[00:09:30] Rethinking Technical DebtHe challenges the fear-based framing of technical debt, comparing it instead to a strategic mortgage.[00:17:00] From 70 Services to 1 MonolithAt 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 DjangoAfter 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 DynamicsBy 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 CompanyEven with a large Java codebase, Vestmark uses Rails for rapid prototyping and new product development.[00:41:00] Using AI to Navigate Legacy SystemsFreedom 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 ConsensusFreedom 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 SoftwareMercedes 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 LikeShe 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 TourMercedes 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 CodebaseWith 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 ArchitectureShe 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 FixMercedes 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 EverywhereShe 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 DebtNot 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 ItMercedes 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 FrictionMercedes recommends expressing technical debt in terms of lost time, slow features, and increased cost rather than vague frustrations.[00:42:00] Getting Momentum Without PermissionHer 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 StandardsMercedes encourages team-led conventions over top-down declarations, and explains why having any decision is better than indecision.[00:47:54] Recommended ReadingShe shares a surprising favorite: The Secret Life of Groceries, a systems-thinking deep dive into the grocery industry by Benjamin Lorr.Resources & Links
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 ObviousA discussion on domain knowledge leakage and abstracting rules like “can we sell today?”[00:05:00] Programming 'Mouthfeel' and the Trap of PrefactoringEvan explains why prematurely optimizing for reuse can lead to unnecessary complexity.[00:07:00] When to Extract Logic: The Copy/Paste SignalA practical approach to identifying reusable components by spotting repeated code.[00:08:00] Technical Debt as a Reflection of Cognitive LoadWhy forgetting your own code doesn't automatically mean it's “bad” code.[00:10:30] Testing as Emotional InsuranceHow writing even basic checks can build team confidence—especially when test coverage is weak.[00:13:00] Daily Integration Tests: A Low-Pressure Safety NetUsing nightly integration runs to catch invisible bugs in complex systems.[00:14:00] Confidence > 100% Test CoverageWhy fast feedback loops matter more than aiming for exhaustive tests.[00:20:00] Splitting the Monolith: A Cautionary TaleEvan shares how decoupling apps without decoupling the database created chaos.[00:22:00] Shared Models, Split Repos, and Hidden PitfallsThe unexpected bugs that emerge when two apps maintain duplicate models and validations.[00:23:00] Better Alternatives to Splitting CodebasesHow separate deployments and tooling can mimic team separation without architectural debt.[00:28:00] The Hidden Cost of Diverging Business DomainsWhen apps evolve independently, business logic begins to drift—undermining consistency.[00:29:00] Building Miren and Staying MotivatedHow 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 DependenciesEvan's mental checklist for evaluating if a library is worth adopting.[01:07:00] The Importance of Hiring Junior DevelopersWhy investing in beginners is crucial for the future of our industry.[01:08:00] Book RecommendationsEvan 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.
Software isn't always about rapid iteration. Sometimes, the real challenge lies in carefully assessing the existing environment. Chris Salvato, a Senior Staff Engineer at Shopify, believes that spending time in the “problem space” is vital for any long-lived application. Rather than diving immediately into controllers and tests, he begins by talking to everyone who interacts with the code—engineers, product owners, even directors who oversee strategy. This approach reveals hidden friction points that rarely come to light in larger, more formal meetings.When code grows organically over years, a range of issues emerges. Small workarounds might accumulate, new features can overlap with older ones, and domain boundaries become murky. Chris suggests mapping these overlaps through in-depth conversations so the team can pinpoint what genuinely obstructs productivity. He emphasizes that many developers may focus on surface fixes—updating a library here, renaming a class there—without acknowledging underlying confusion in the domain model itself. Removing extraneous code, clarifying domain entities, and aligning the team's understanding can drastically reduce missteps.An interesting aspect of Chris's method is his view of “developer paradise.” A codebase reaches this state when new contributors can navigate it with minimal help. Instead of sifting through endless documentation or complex wikis, they can figure out how classes, modules, and services connect simply by reading the code. Chris notes that achieving this often involves pruning unnecessary files or responsibilities. The end result is software that “self-documents,” easing onboarding and reducing reliance on external explanations.The conversation also touches on how large language models (LLMs) fit into the puzzle. Many organizations see AI-driven coding assistants as a way to accelerate development. Chris agrees they have potential, yet highlights a critical requirement: the code must be well-organized. If the system is sprawling and inconsistent, these tools may only add confusion. Lean, carefully segmented projects let both people and AI more effectively track what's happening under the hood.Reducing code bloat leads naturally to discussions about prioritizing. Chris encourages teams not to tackle every annoyance at once. He references the importance of framing a unifying question, such as “Which feature or aspect of the app causes the greatest confusion among team members?” Spending too little time on this question, he warns, results in half-hearted improvements that eventually revert back to chaos. By contrast, devoting a few dedicated sprints—guided by thoughtful one-on-one interviews—can create lasting changes that set the entire codebase on a better trajectory.One intriguing theme is how personal growth ties into organizational impact. Chris acknowledges that developers often switch companies every few years, which might discourage them from investing deeply in a legacy codebase they won't maintain long-term. Yet taking the lead in clarifying domain logic or reorganizing outdated sections is a skill-building opportunity. Future employers also notice engineers who can transform messy architectures into clear, future-friendly systems. In that sense, there's a mutual benefit: the company gains maintainable software, while the developer acquires project leadership experience.The idea of “sitting in the problem space” resonates throughout Chris's remarks. He encourages engineers to resist the reflex to propose solutions too early. Instead, they should keep asking why a particular annoyance or bug persists. Is it a symptom of a misaligned feature set, or is it rooted in limited domain knowledge among contributors? By reframing those frustrations as questions about responsibilities, the team often discovers simpler fixes than a heavy-handed rewrite. Conversely, where deeper rewrites are indeed warranted, Chris believes it's best for the team to see that direction as unanimous rather than dictated from the top.Long-standing software also carries emotional baggage. People might have strong feelings about how something “ought” to be done, or they may have encountered recurring hurdles. Chris advocates using one-on-one conversations to let these concerns surface naturally, free from the pressure of group settings where quieter voices might hold back. Once everyone's perspective is heard, common threads become clearer, enabling the team to converge on a smaller list of genuinely important tasks. When the group reconvenes, the sense of shared purpose helps unify efforts in a way that scattered brainstorming rarely achieves.The conversation also highlights resourceful domain modeling, which draws some inspiration from the microservices world but doesn't necessarily require the code to be broken up into tiny services. Instead, Chris suggests that well-defined boundaries within a monolith can deliver comparable clarity—if the team respects those boundaries. He points to examples like Stripe or reading materials on Domain-Driven Design to show how cohesive object structures can help avoid big architectural hurdles.His closing thoughts revolve around long-term sustainability. Even if an engineer isn't planning to remain on a project indefinitely, they can leave a meaningful legacy by clarifying crucial parts of the code, championing simpler naming conventions, and encouraging more open dialogue among team members. The impact, Chris notes, goes beyond the immediate project: every person who touches that code later benefits from these improvements, often for years to come.Time-Stamped Highlights[00:00:00] Welcome and Well-Maintained Software:Robby opens by asking Chris about foundational traits of dependable, long-lasting codebases.[00:00:58] Defining “Well Maintained”:They explore how clear conventions and minimal bloat not only reduce confusion but also prolong the life of a system.[00:01:28] LLMs and Context Windows:Chris delves into why large codebases challenge AI-driven coding assistants—and how trim, well-modeled systems sidestep this pitfall.[00:02:00] Joining Shopify and Facing Legacy Systems:Chris recalls his early days at Shopify, realizing that older Rails apps demanded a more structured method of discovery.[00:03:08] Concept of “Developer Paradise”:He shares his perspective on how removing unneeded documentation and extraneous complexity makes daily development more enjoyable.[00:05:32] Framework for Tackling Old Code:Chris outlines his signature approach: booking numerous 1-on-1 meetings to gather honest feedback from stakeholders before touching the code.[00:07:15] Finding High-Leverage Problems:Robby and Chris discuss distilling this feedback into a shortlist of real bottlenecks that the team can tackle together.[00:15:00] From Problem Space to Solutions:They spotlight the value of framing a single unifying question—like “How do we reduce confusion?”—to keep everyone working toward the same outcome.[00:20:07] Balancing Personal Goals and Company Needs:Chris underlines how aligning individual ambitions with business objectives fosters commitment to sustained improvement.[00:32:00] Long-Term Value and Leadership:Closing out, Robby and Chris consider how short-tenure engineers can leave a lasting impact by helping a team focus on its biggest pain points.Resources & MentionsShopifyRuby on RailsChris's GitHubChris's LinkedInChris's Twitter/XThe One Thing by Gary KellerTitan: The Life of John D. Rockefeller, Sr. by Ron ChernowMartin Fowler on MicroservicesDomain-Driven Design
Heimir Thor Sverrisson joins Robby to discuss the importance of software architecture in long-term maintainability. With over four decades in the industry, Heimir has witnessed firsthand how poor architectural decisions can set teams up for failure. He shares his experiences mentoring engineers, tackling technical debt, and solving large-scale performance problems—including one bank's misguided attempt to fix system slowness by simply adding more CPUs.Heimir also discusses his work at MojoTech, the value of code reviews in consulting, and his volunteer efforts designing radiation-tolerant software for satellites.Episode Highlights[00:01:12] Why architecture is the foundation of maintainability – Heimir explains why starting with the wrong architecture dooms software projects.[00:02:20] Upfront design vs. agile methodologies – The tension between planning and iterative development.[00:03:33] When architecture becomes the problem – How business pivots can render initial designs obsolete.[00:05:06] The rising demand for rapid software delivery – Why modern projects have less time for deep architectural planning.[00:06:15] Defining technical debt in practical terms – How to clean up code without waiting for permission.[00:09:56] The rewrite that never launched – What happens when a company cancels a multi-million-dollar software project.[00:12:43] How a major bank tackled system slowness the wrong way – Adding CPUs didn't solve their performance problems.[00:15:00] Performance tuning as an ongoing process – Why fixing one bottleneck only reveals the next.[00:22:34] How MojoTech mentors instead of manages – Heimir explains how their consultancy approaches team development.[00:27:54] Building software for space – How AMSAT develops radiation-resistant software for satellites.[00:32:52] Staying relevant after four decades in tech – The power of curiosity in a constantly changing industry.[00:34:26] How AI might (or might not) help maintainable software – Heimir shares his cautious optimism.[00:37:14] Non-technical book recommendation – The Man Who Broke Capitalism and its relevance to the tech industry.Resources & LinksHeimir Thor Sverrisson on LinkedInHeimir's GitHubMojoTechAMSAT – Amateur Radio Satellite OrganizationThe Man Who Broke CapitalismHow to Make Things Faster
Not every messy piece of code needs a refactor. Noémi Ványi, Senior Software Engineer at Xata, joins Robby to discuss how to develop the intuition to know when refactoring is truly necessary and when it's just unnecessary churn. She shares her approach to balancing pragmatism and maintainability, how product teams and developers can work better together, and why developer autonomy is key to sustainable software.Drawing from her experience working on both open-source and closed-source projects, Noémi reflects on the unique challenges each presents—whether it's dealing with unresponsive GitHub issue reporters, handling unanticipated user behaviors, or navigating large-scale refactors in existing systems. She also shares her philosophy on technical debt: not all of it needs to be paid down, and some of it can actually be strategic.Robby and Noémi also explore the importance of writing meaningful commit messages, the hidden benefits of reviewing open-source pull requests, and why developers should stop waiting for permission to clean up their codebases.Episode Highlights[00:01:00] The characteristics of well-maintained software: modular design, good tests, and observability.[00:02:00] Open source vs. closed source software: Why communication matters more than you think.[00:04:50] Not all technical debt is worth paying down—how to decide when to refactor.[00:06:20] Developing engineering intuition: How experience shapes decision-making.[00:11:08] Lessons from refactoring a log processing system at Elastic.[00:17:09] Strategies for modernizing legacy systems without unnecessary rewrites.[00:19:52] Why maintainability is a business requirement, not an afterthought.[00:24:03] Should developers ask for permission to clean up code or just do it?[00:27:00] The impact of good commit messages and pull request documentation (GitHub PR Templates).[00:30:00] Are issue templates in open source a helpful guardrail or a barrier?[00:32:00] How to gain autonomy as a developer and advocate for technical improvements.[00:39:00] Noémi's advice: Only fix problems that are actually problems.Resources MentionedNoémi Ványi's WebsiteNoémi Ványi on GitHubElasticGitHub Pull Request TemplatesGitHubBook RecommendationLost in Thought: The Hidden Pleasures of an Intellectual Life by Zena Hitz
How much can legacy code tell us beyond just functionality? Julia López, Senior Software Engineer at Harvest, believes that even small details—such as white spaces, variable names, and formatting choices—can reveal a system's history.In this episode, Julia and Robby discuss the importance of refactoring and how a strong engineering culture can make or break a team's ability to maintain and improve software over time. Julia shares her experience leading a multi-year overhaul of Harvest's billing system, balancing stakeholder expectations while ensuring the rewrite delivered real value.They explore how refactoring decisions evolve as teams grow, how to mentor newer developers to feel empowered to make changes, and why Julia doesn't always trust her own estimations (for good reason). She also opens up about the complexities of transitioning a live billing system while supporting customers, finance teams, and engineering operations—all without disrupting payments.Beyond technical decisions, they also dive into the challenges of communication in remote teams, the value of autonomy in software development, and how teams can make a case for technical debt reduction even when leadership isn't prioritizing it. If you've ever struggled with refactoring legacy systems or advocating for improvements, this conversation is packed with practical lessons.
Software Engineering Radio - The Podcast for Professional Software Developers
Ivett Ördög speaks with host Sam Taggart about rewrite versus refactor -- a choice that many projects face as they grow. It's a topic that inspires a lot of dogmatic feelings. They discuss how companies and projects end up at this crossroads and consider some strategies to try to avoid it. Ivett challenges the myth that you should never rewrite but points to two key factors that need to be present for a successful large-scale rewrite or refactor. They end by talking about how to get management on board for such large-scale rewrite or refactor projects. Brought to you by IEEE Computer Society and IEEE Software magazine.
Episode OverviewMarty Haught joins Robby to discuss the sustainability of open-source projects, the challenges of maintaining RubyGems, and why the metaphor of technical debt may not fully capture how software ages. Instead, he suggests thinking of it as drift—the natural misalignment of software with its evolving purpose over time.They also dig into security challenges in package management, including how Ruby Central worked with Trail of Bits to audit RubyGems. Marty also shares insights on the EU Cyber Resilience Act and how it might affect open-source maintainers worldwide. Finally, they explore how companies can support open-source sustainability through corporate sponsorships and individual contributions.Topics Discussed[00:01:00] The two pillars of maintainable software: good tests and readability.[00:02:40] From Perl to Ruby: How readability changed Marty's approach to programming.[00:07:20] Is technical debt the right metaphor? Why "drift" might be a better fit.[00:11:00] What does it take to maintain RubyGems? Marty's role at Ruby Central.[00:14:00] Security in package management: How RubyGems handles vulnerabilities.[00:16:40] The role of external audits: Partnering with Trail of Bits for security improvements.[00:20:40] EU Cyber Resilience Act: How new regulations might affect open-source projects.[00:26:00] Funding open source: Why corporate sponsorships are becoming essential.[00:33:40] Advocating for technical debt work in teams: How to make a compelling case.[00:38:20] Processes in distributed teams: Balancing structure with flexibility.Key TakeawaysTechnical debt is often misunderstood. The real issue may not be shortcuts taken in the past, but the way software naturally drifts from its original purpose.Security in package management is a growing concern. Open-source ecosystems like RubyGems require continuous investment to remain secure.Open source needs sustainable funding. Relying on volunteers is not a long-term solution—companies need to contribute via corporate sponsorships.Advocating for code improvements requires strategy. Engineers should frame technical debt discussions around business impact, not just code quality.Resources MentionedMarty Haught on LinkedInMarty Haught on TwitterRuby CentralRubyGemsAuditing the Ruby Ecosystem's Central Package Repository – Trail of BitsEU Cyber Resilience Act OverviewWhat the EU's New Software Legislation Means for Developers (GitHub Blog)Ruby Central Open Source Program – Get InvolvedCorporate Sponsors ProgramGive and Take by Adam GrantConnect with MartyLinkedInTwitterBlueSkyThanks to Our Sponsor!Need a smoother way to share your team's inbox? Jelly's got you covered!
Show NotesMike Bowers, Chief Architect at FairCom, has spent decades navigating the evolution of database technology. In this conversation, he and Robby explore the challenges of maintaining a 40+ year-old codebase, balancing legacy constraints with forward-thinking design, and the realities of technical debt.Mike shares how FairCom transitioned from ISAM-based databases to modern JSON-driven APIs, the trade-offs between strict schemas and flexible document stores, and how software architecture plays a critical role in long-term maintainability. He also explains why human-readable JSON simplifies debugging, how documentation-driven development improves API usability, and why many software teams struggle with refactoring at the right time.Topics covered[00:05:32] The role of software architecture in long-term maintainability[00:10:45] Why FairCom's legacy ISAM technology still matters today[00:14:20] Transitioning to a JSON-based API for modern developers[00:19:40] The challenges of maintaining 40+ years of C code[00:24:10] Technical debt: What it really means and how to manage it[00:28:50] The trade-offs between strict schemas and flexible NoSQL approaches[00:34:00] When to refactor vs. when to start over from scratch[00:38:15] The influence of product management thinking on software architecture[00:42:30] Advice for engineers considering a shift into architecture rolesResources mentionedFairComMike Bowers on LinkedInFairCom on Twitter/XBook Recommendation: The Influential Product Manager by MSc BuceroThanks to Our Sponsor!Need a smoother way to share your team's inbox? Jelly's got you covered!
Stride's Michael Carlson and Michael Wytock join this week's episode to share how Stride's groundbreaking 100x service is transforming legacy code modernization. They explore how Generative AI and automation are breaking down the barriers that have long made updating outdated systems slow, risky, and politically challenging.The duo shares how Stride 100x streamlines the modernization process by automatically tracing and understanding even the most complex legacy systems. The approach reduces what used to take weeks—or even months—to mere hours, enabling companies to modernize without disrupting their day-to-day operations. Plus, the two explore real-world legacy software challenges, from unknown system dependencies to hidden code risks, and explain how 100x eliminates these pain points through cutting-edge technology. They also explore how Stride 100x differs from popular tools like GitHub Copilot. If your organization is stuck in the old legacy systems, tune in now and discover how Stride 100x can help you modernize your systems. You can learn more about the service at https://www.stride.build/100x or chat with the team for a personalized demo. “Re-architecting and modernizing your applications as the business needs arise is not something that's going counter to what the business is trying to do. Actually, it will help the business move forward.” ~ Michael CarlsonIn This Episode:- Introducing Stride 100x: modernizing legacy applications- The birth of 100x from understanding client pain points- Identifying common legacy software struggles- Step 1 of 100x: code tracing in legacy systems- Speeding up the modernization process: real-world examples - Continuous monitoring and iteration with 100x- Stride 100x vs. popular AI coding tools- The future of legacy code modernization with Stride 100xAnd much more!Learn More About Stride 100x:https://www.stride.build/100xConnect with Debbie Madden:Website - https://www.stride.build/LinkedIn - https://www.linkedin.com/in/debbiemadden1/LinkedIn - https://www.linkedin.com/company/stride-consulting/
Join Robby as he chats with Lorna Mitchell, open source advocate and technical writer, about the art of creating documentation that doesn't gather dust. Lorna shares her experiences as a maintainer of the open source project RST2PDF, the value of API governance, and how documentation bridges gaps in developer experience.Highlights:What Makes Software Maintainable: Characteristics like great documentation, automated tests, and onboarding ease.Documentation's Role in Long-Lived Software: Why it's crucial for internal tools and open source projects alike.Open Source in Practice: Lorna's journey with RST2PDF and adopting a tech stack she wasn't initially fluent in.API Governance Simplified: Lorna explains the four levels of API readiness and how teams can work toward more usable APIs.Writing Documentation for Engineers: How style guides can empower contributors without overwhelming them.Using Tools to Improve Documentation: From linters to prose-checking tools like Veil, Lorna discusses practical tips.Key Takeaways:[00:01:00] What makes software well-maintained: documentation, accessibility, and automated tests.[00:03:10] Why documentation isn't just for new users—Lorna's experience with revisiting her own open source projects.[00:06:30] Diving into rst2pdf: Challenges in maintaining an abandoned project.[00:13:45] Balancing ownership and transitioning open source projects to new maintainers.[00:15:30] What is OpenAPI, and how does API governance impact usability?[00:26:10] The art of concise yet helpful documentation for different audiences.[00:33:00] Using examples in APIs to enhance clarity and reduce confusion.[00:40:00] Tools for improving writing, from prose linters to markdown syntax checkers.Resources Mentioned:Lorna Mitchell's Websiterst2pdf ProjectSimon Willison's Post on One-Person ProjectsHow to Take Smart NotesOpenAPI SpecificationVeil Prose LinterFollow Lorna:GitHubIndieWebThanks 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 episode of Maintainable, Robby sits down with Carola Lilienthal, Software Architect and Managing Director at WPS. Together, they explore the intersection of cognitive science and software architecture, strategies for tackling technical debt, and why simplicity, modularity, and domain knowledge are crucial for maintainability.Carola shares her approach to improving legacy systems, fostering domain-driven development, and introducing sustainable patterns into software design. She also discusses the Modularity Maturity Index (MMI), a tool her team has used to assess and improve over 300 systems.Topics Covered[00:00:43] What makes software maintainable?[00:01:24] The importance of clear structure, modularity, and simplicity in software.[00:02:38] How patterns help reduce complexity and onboard developers faster.[00:04:42] Addressing the challenges of systems with mixed architectural patterns.[00:06:20] Strategies for fostering creativity while maintaining simplicity.[00:07:05] How to guide teams to balance technical experimentation and maintainability.[00:14:03] Practical techniques for documenting architecture and decisions.[00:16:17] What is the Modularity Maturity Index (MMI), and how does it measure system health?[00:18:02] Common mistakes in managing technical debt and how to avoid them.[00:21:20] Why domain knowledge is essential for innovation and problem-solving.[00:33:03] Evolving legacy systems with domain-driven design and transformation.Key TakeawaysModularity matters: Simplified, modular systems with high cohesion and loose coupling reduce cognitive load and technical debt.Patterns as a shared language: Establishing a pattern language within your team creates consistency and eases onboarding.Cognitive science in software: Architecture aligned with how our brains process complexity results in more maintainable systems.Domain knowledge drives innovation: Teams should focus their creativity on solving domain-specific problems, not over-complicating the architecture.The value of architecture documentation: Keeping clear decision records helps teams navigate legacy code and onboard new developers.Resources MentionedCarola's LinkedInWPS WebsiteCarola's books:Sustainable Software ArchitectureDomain-Driven Transformation (English version coming soon)Modularity Maturity Index OverviewBooks Carola recommends:Reinventing Organizations by Frédéric LalouxTeam Topologies by Matthew Skelton and Manuel PaisBe sure to follow Carola on LinkedIn and X.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.
Topics DiscussedThe importance of changeability as a core characteristic of well-maintained software.How GitHub has approached accessibility as a business and legal imperative.The evolution of GitHub's frontend system, spanning over 2,000 pages, and the concept of "frontend vintages."Primer: GitHub's design system and the paradox of its success—consistency vs. changeability.The disproportionate maintenance costs of frontend systems compared to backend systems.Using tools like Axe and keyboard-only tests to identify and resolve accessibility issues.The philosophical balance between creativity and usability in software design.Practical advice for teams starting their accessibility journey with limited resources.How frontend complexity affects scalability, especially in app-like experiences.Joel's advocacy for adopting off-the-shelf components to reduce complexity for smaller teams.Key Takeaways[00:01:12] What Defines Well-Maintained Software?Joel explains how changeability—the confidence to make and deploy changes—provides the foundation for high-quality software.[00:03:05] Accessibility as a PriorityThe Microsoft acquisition drove GitHub's investment in accessibility, introducing SLAs, automated tools, and manual processes to track progress.[00:08:49] Primer: GitHub's Design SystemPrimer fosters consistency but introduces the challenge of making changes across a vast, interconnected system.[00:12:54] The Cost of Frontend ComplexityJoel shares how browser quirks, device diversity, and other variables make frontend maintenance far more expensive than backend systems.[00:28:05] Where to Start with AccessibilityJoel recommends focusing on key user workflows like signing up, making payments, and completing core tasks. He emphasizes the importance of tools like Axe and keyboard-driven tests.Notable Time-Stamps[00:01:12] What Makes Software Well-Maintained? Joel shares how changeability drives quality.[00:03:05] GitHub's Accessibility Journey: The role of SLAs, audits, and automation.[00:08:49] Primer and Design Systems: Balancing consistency with innovation.[00:12:54] The Hidden Costs of Frontend Complexity: Lessons learned at GitHub.[00:20:33] Balancing Creativity with Usability: Joel reflects on the intersection of design and functionality.[00:28:05] Accessibility Best Practices: Where teams should focus their initial efforts.ResourcesJoel Hawksley's WebsitePrimer Design SystemAxe Accessibility ToolsGitHub's ViewComponent FrameworkBook Recommendation:How Buildings Learn by Stewart BrandGuest's LinksJoel Hawksley on GitHubJoel Hawksley's WebsiteThanks 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.
Austin Story, Senior Engineering Director at Doximity, joins Robby to explore the intricacies of building maintainable systems, fostering team accountability, and enabling faster iteration without sacrificing quality. Austin shares how his team approached migrating from a monolithic GraphQL architecture to a federated model, why simplicity matters for long-term success, and how guiding principles like YAGNI influence his decision-making.Doximity is a leading digital platform for medical professionals, and their technology blog offers deep dives into the systems and tools that power their innovative solutions.Key Topics Discussed[00:00:41] What is maintainable software? Austin highlights key traits, including testability, simplicity, and ease of removal.[00:02:09] Designing for removability: Why it's important and how it enables iterative progress.[00:03:05] YAGNI (You Aren't Gonna Need It): How this principle shapes Austin's approach to feature development.[00:04:13] Migrating to GraphQL Federation: Benefits of breaking up a monolithic GraphQL server and the challenges faced during the transition.[00:05:56] GraphQL vs. REST: How GraphQL aids developer productivity while maintaining backward compatibility.[00:10:53] Collaboration between data and application teams: Using tools like Kafka to bridge gaps and improve workflow.[00:17:00] Upgrading Ruby on Rails applications: Balancing autonomy with central guidance for seamless updates.[00:27:55] Fostering ownership on teams: The cultural practices that empower engineers to take initiative and drive results.[00:34:29] Prioritizing work effectively: How Austin's team uses quarterly planning and measurable "goalposts" to align efforts with impact.[00:40:00] Avoiding bike-shedding: Keeping meetings and reviews focused on meaningful progress.Key TakeawaysSimplicity Wins: Maintainable software is easier to adapt, remove, and iterate on when it's kept simple.Iterate and Refine: Use principles like YAGNI to avoid over-engineering and ensure systems are built to evolve.Collaboration Drives Success: Bridging communication between specialized teams can unlock untapped potential.Focus on Outcomes: Define clear goals and track measurable results to ensure projects align with business needs.Resources MentionedYAGNI (You Aren't Gonna Need It)GraphQL Federation OverviewDoximity Technology BlogThe Mom Test by Rob FitzpatrickAustin Story on LinkedInAustin Story's WebsiteStay ConnectedFollow Austin:LinkedInWebsiteThanks 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.
Topics CoveredCharacteristics of Maintainable SoftwareDan emphasizes the importance of internal consistency in codebases, automated tests, and proper documentation to preserve decision-making context.[00:05:32] Internal consistency: Why it matters.[00:08:09] Lessons from maintaining legacy codebases.Working with Legacy SystemsDan shares stories of upgrading ORM frameworks, introducing caching systems, and transitioning to bug tracking tools.[00:09:52] Replacing custom ORM systems with Hibernate and Ehcache.[00:13:10] Tackling high-risk components with automated testing.Modern Authentication ChallengesAs part of FusionAuth, Dan discusses building developer-friendly tools that balance local flexibility with SaaS convenience.[00:21:05] FusionAuth's role in secure authentication.[00:28:13] Testing authentication flows locally and in CI pipelines.Navigating Constraints in TeamsAdvice for managing technical debt, advocating for team priorities, and communicating with stakeholders during lean times.[00:16:39] Communicating the impact of resource constraints.[00:19:27] Tracing single requests to understand complex systems.Industry Trends and AI's RoleFrom managed services to the impact of AI on coding languages, Dan reflects on how the industry continues to evolve.[00:35:05] Managed services as accelerators for maintainability.[00:41:25] The potential and limits of AI in software development.Key TakeawaysConsistency and documentation in codebases reduce cognitive overhead for developers.Understand how your software fits into the business to prioritize effectively.AI might reshape the industry, but it won't replace the need for thoughtful problem-solving.Opinionated frameworks like Ruby on Rails continue to offer exceptional developer ergonomics.Resources MentionedFusionAuth BlogDan's Personal BlogCIAM Weekly NewsletterDan's Book: Letters to a New DeveloperZen and the Art of Motorcycle MaintenanceThe Asimov story mentionedTry FusionAuthDownload FusionAuth: Get started with the self-hosted version today.Free Trial of FusionAuth: Experience the FusionAuth cloud for free!Connect with DanLinkedInBlueSkyThanks 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 Tom Johnson, Co-Founder and CEO of Multiplayer. Tom shares his perspectives on the evolving landscape of distributed systems, the challenges of maintaining legacy software, and how innovative tools are transforming the way teams collaborate.Topics DiscussedCharacteristics of well-maintained software, from system-level documentation to effective workflows.The importance of debugging tools tailored for distributed systems.Anecdotes about managing technical debt, including cutting off a CEO's database access.How auto-documentation and design branches in Multiplayer streamline team collaboration.Practical strategies for tackling technical debt and fostering developer morale.Key Takeaways[00:01:16] Defining Well-Maintained Software: Tom explains why documentation, tests, and collaborative workflows are essential.[00:06:14] The Case for Locking Down Production: Lessons learned from a humorous but cautionary tale.[00:18:11] Debugging Distributed Systems: How Multiplayer's tools simplify the debugging process.[00:25:00] Design Branches and Team Collaboration: Enhancing communication through shared documentation.[00:31:39] Prioritizing Technical Debt: Identifying customer and developer pain points.Resources MentionedMultiplayerTom Johnson on LinkedInTom Johnson on TwitterBook Recommendation: Making Comics by Scott McCloudThanks 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 sits down with Justine Gehring, an AI Research Engineer at Moderne, to explore how AI tools are transforming code maintenance and scalability. They dive into the unique ways AI can support refactoring for massive and legacy codebases, from retrieval-augmented generation (RAG) to lossless semantic trees, and discuss how developers can benefit from AI-assisted planning and refactoring.Justine shares her background transitioning from academia to industry and reflects on the essential role of reproducibility in AI, why maintainable code is often overlooked in research, and the challenges of balancing innovation with real-world reliability in software projects.Topics DiscussedWhat Makes Software Maintainable: Justine's take on good documentation, reusable code, and ensuring new team members can quickly navigate a codebase. [00:00:42]Academia vs. Industry in Code Maintainability: Why reproducibility and code maintenance often diverge in research settings, and how industry standards address this gap. [00:01:14]From Academia to AI Engineering: Justine shares her journey and how her background in machine learning led to a career in AI-focused software maintenance. [00:04:48]Scaling Refactoring with OpenRewrite: An introduction to OpenRewrite, the open-source tool that facilitates large-scale code transformations, developed by Moderne. [00:12:15]Lossless Semantic Trees: The benefits of LSTs for detailed code analysis, retaining essential syntax and type information critical for reliable AI refactoring. [00:20:24]Retrieval-Augmented Generation (RAG): Justine explains RAG's significance in allowing AI models to provide context-specific responses without heavy re-training. [00:26:00]Trust and Validation in AI-Generated Code: The importance of robust test cases and human oversight when leveraging AI-generated code to avoid cascading errors. [00:31:36]AI as a Planning Tool for Refactoring Projects: Justine's insights on using AI as a collaborative coding assistant, offering developers suggestions for planning refactoring and maintenance tasks. [00:35:24]Real-World Example of Scaling Refactoring: Justine recounts a case study where Moderne used OpenRewrite to facilitate large-scale code migration involving multiple frameworks. [00:42:00]Advocating for AI Tools in Code Maintenance: Tips for developers interested in introducing AI tools and approaches within their teams or organizations. [00:42:31]Key TakeawaysAI Supports Reproducibility and Reliability: Ensuring reproducibility in AI-driven tools can enhance both credibility and usability for complex codebases.Prioritize Planning Before Refactoring: Understanding code dependencies and structure is key to successful refactoring; AI tools like OpenRewrite can automate targeted changes.Human Expertise Remains Essential: AI can be an effective coding assistant, but human oversight is necessary to ensure accuracy and quality.Experiment and Scale: Start with small, impactful AI-assisted refactoring recipes and scale up once the process is reliable, saving significant development hours over time.ResourcesModerneJustine Gehring's LinkedInOpenRewrite DocumentationGetting to Yes by Roger Fisher and William UryThanks 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.
As a product advocate at Nx, Katerina Skroumpelou combines her engineering skills with a knack for connecting with clients. In this episode, she shares how clear documentation, scalable architectures, and a collaborative culture can transform software development for the better.Key Takeaways[00:01:25] Katerina's Background: Robby and Katerina discuss her career journey, starting in engineering and recently moving into product advocacy.[00:02:29] Characteristics of Well-Maintained Software: Katerina highlights key aspects of maintainable software—readability, scalability, and reliability.[00:04:39] Product Advocacy at Nx: Katerina describes her unique role, bridging technical support and customer outreach to ensure clients make the most of Nx tools.[00:07:01] White Glove Approach: The “white glove” service approach allows Katerina to dive deep into clients' codebases, offering a hands-on approach to using Nx effectively.[00:09:52] Scalable Documentation Practices: Balancing clarity and detail, Katerina provides tips on structuring code comments and READMEs to be concise yet thorough.[00:12:09] Managing Technical Debt: Robby and Katerina discuss the importance of keeping code up-to-date and scalable, especially in large systems with high demands.[00:16:00] The Importance of Collaboration: Moving from solo work to team-based code reviews taught Katerina the value of a collaborative approach to maintainable code.[00:19:15] Nx's Monorepo Solution: How Nx provides cache and build tools to optimize mono-repo performance, boosting both speed and organization within projects.[00:22:12] Nx Cloud and CI: Katerina discusses Nx Cloud's role in enhancing CI workflows by allowing parallel tasks and cache sharing across teams.[00:24:07] When to Consider Monorepos: Katerina explains the benefits of monorepos for organizing codebases and improving scalability.[00:26:37] AI Tools in Development: Katerina shares her enthusiasm for new AI tools like StackBlitz's Bolt and their potential to streamline app development.[00:29:00] Finding Motivation at Work: Advice for developers who feel stuck or unmotivated in their current roles and ways to reconnect with the work they enjoy.Resources MentionedNx DevStackBlitz Bolt.newBooks:The Three-Body Problem by Cixin LiuCryptonomicon by Neal StephensonSlaughterhouse-Five by Kurt VonnegutKaterina's social profiles:LinkedInTwitterBlueskyThanks 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.
AI is being integrated and adopted across much of the IT world, but can it work magic in transforming old legacy code into shiny modern code? When it comes to this magic trick, it’s important to look behind the curtain. On today’s Day Two DevOps podcast we discuss the reality of AI in refactoring code... Read more »
AI is being integrated and adopted across much of the IT world, but can it work magic in transforming old legacy code into shiny modern code? When it comes to this magic trick, it’s important to look behind the curtain. On today’s Day Two DevOps podcast we discuss the reality of AI in refactoring code... Read more »
AI is being integrated and adopted across much of the IT world, but can it work magic in transforming old legacy code into shiny modern code? When it comes to this magic trick, it’s important to look behind the curtain. On today’s Day Two DevOps podcast we discuss the reality of AI in refactoring code... Read more »
Welcome to another engaging episode of the Maintainable Software Podcast! In this episode, Robby sits down with Moriel Schottlender, Principal Software Engineer at the Wikimedia Foundation, to explore the complex journey of modernizing MediaWiki, the software behind Wikipedia. Moriel shares her insights on what it takes to keep an enormous monolithic codebase maintainable while supporting an ever-growing and diverse set of global users. She highlights the importance of modularization, ownership, and the delicate balance between flexibility and stability in open-source software.Key Takeaways[00:00:51] Characteristics of Well-Maintained Software: Moriel discusses the three crucial characteristics of well-maintained software: ownership, modularization, and documentation.[00:01:09] Ownership and Rules for Contribution: Ownership goes beyond just fixing bugs—it involves understanding the architectural purpose and maintaining consistency even as teams change.[00:03:35] Product Vision's Role in Maintainability: Why a clear product vision is essential for maintaining software, even in the face of organic growth.[00:07:14] Balancing Experimentation and Long-Term Planning: Moriel shares insights into how Wikimedia balances rapid experimentation with careful, long-term architectural planning.[00:07:32] The Evolution of MediaWiki: MediaWiki's growth from a small project to the backbone of Wikipedia, now supporting over 900 wikis, and the challenges that come with scaling.[00:14:18] Modernizing a 23-Year-Old Monolith: Robby and Moriel dive into the challenges of modernizing MediaWiki's architecture, including the difficulties of updating a monolithic structure.[00:17:15]Wikitext vs. Markdown: Moriel explains why MediaWiki uses its own Wikitext language instead of Markdown and the unique challenges it presents.[00:22:25] Architectural Flexibility for the Future: The importance of having a flexible architecture that can adapt to the evolving needs of users and technologies.[00:26:04] Technical Debt and Modularization: How Wikimedia approaches technical debt in MediaWiki and prioritizes architectural interventions to improve modularity and maintainability.[00:39:00] Community Contributions to MediaWiki: Strategies for increasing developer contributions and how Wikimedia empowers volunteers while maintaining software quality.[00:41:59] Advice for Aspiring Open Source Contributors: Moriel shares encouraging words for anyone looking to contribute to open-source projects, emphasizing that everyone can make a meaningful impact.[00:35:44] The Role of Documentation: Moriel discusses Wikimedia's efforts to improve documentation and ensure it's useful for both developers and end-users, leveraging the strengths of wiki-based contributions.[00:30:29] Celebrating Small Wins: Moriel talks about how Wikimedia celebrates small victories to keep team morale high in the face of big challenges.Resources MentionedMoriel's WebsiteMoriel on MastodonMediaWiki DocumentationBook Recommendation:Year Zero by Rob ReidConnect with MorielMoriel on LinkedInInstagramTwitterGitHubMastodonThanks 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.
Welcome to another engaging episode of Maintainable! Robby sits down with Kate Holterhoff, Ph.D., a Senior Analyst at RedMonk and former front-end engineer, to explore the intricate world of software maintenance, documentation, and the future of developer roles. Kate brings her unique perspective from her time as a practitioner at a digital marketing agency, her academic background, and her current role in developer advocacy.Topics Explored[00:00:00] Introduction to Kate's Background: Robby and Kate discuss her journey from academia to front-end engineering and now to being a Senior Analyst at RedMonk. Kate shares how her experiences have shaped her perspective on software maintenance.[00:04:00] Well-Maintained Software: Kate dives into her definition of well-maintained software, emphasizing modularity, semantic readability, and the importance of considering future developers who will interact with the code.[00:11:30] The Challenges of Agency Work: Kate reflects on her time at a digital marketing agency, where she often worked on projects that had passed through many hands. She discusses the importance of balancing quick deliverables with maintainability.[00:20:45] The Role of Documentation: Kate shares insights on the value of documentation for distributed teams, highlighting her experience organizing documentation sessions ("documentation paloozas") to capture team knowledge and ensure maintainability.[00:30:00] RedMonk and Developer Advocacy: Kate explains her role at RedMonk and how the firm differs from traditional analyst firms like Gartner. She discusses RedMonk's focus on developers as key decision-makers in the tech landscape.[00:39:15] Front-End Developers as Kingmakers: Robby and Kate explore how front-end engineers are increasingly influencing the adoption of tools and technologies within organizations. Kate describes this trend as front-end developers becoming "kingmakers" in the industry.[00:49:50] AI and Developer Tools: Kate discusses the integration of AI into developer tools, the potential benefits, and challenges for junior developers. She emphasizes the importance of understanding how to read code in an AI-assisted world.Key Takeaways:Emphasize modularity and semantic readability to ensure code can be easily maintained by future developers.Documentation is crucial for maintainability, especially in distributed and contractor-heavy teams.Front-end developers are becoming key decision-makers, influencing tool and technology adoption.AI is increasingly integrated into developer workflows, making it essential for developers to focus on reading and understanding code.The definition of a 'developer' is evolving, with more abstracted tools and AI playing a larger role in development processes.Resources Mentioned:RedMonkKate Holterhoff on LinkedInKate Holterhoff on TwitterDarwin's The Origin of SpeciesEpisode Highlights:[00:00:00] Introduction to Kate's Background[00:04:00] Characteristics of Well-Maintained Software[00:20:45] The Importance of Documentation[00:30:00] What Does a Senior Analyst at RedMonk Do?[00:39:15] Front-End Developers as Kingmakers[00:49:50] The Role of AI in Developer ToolsThanks 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.
Alan Ridlehoover: Building Robust Systems Through Behavior-Centric TestingIn this episode of Maintainable, Robby speaks with Alan Ridlehoover, Senior Engineering Manager at Cisco Meraki. Alan shares his perspective on building well-maintained software by focusing on behavior-centric testing, clear code ownership, and thoughtful technical decisions that stand the test of time.Alan discusses his experience working in both startup environments and large-scale engineering teams, including how he navigates the unique challenges of each. He provides practical advice on managing conditional logic in code, scaling with third-party dependencies, and ensuring that testing strategies remain effective as systems grow in complexity.Key Takeaways:The characteristics of well-maintained software: behavior-centric testing, solid code principles, and ownership boundaries.Balancing the needs of startups vs. large enterprises when it comes to software maintenance.Alan's approach to handling conditional logic with a technique called "rehydration" to simplify complex code.Why focusing on behavior, not implementation, is critical for scalable, maintainable tests.The importance of interfaces and facades for managing third-party dependencies and future scalability.How to approach technical debt as a conscious trade-off, not an inevitable burden.Best practices for addressing flaky tests, including managing non-determinism, order dependencies, and race conditions.How to set up effective monitoring and alerting systems to maintain a healthy software environment.The role of team structure and product ownership in delivering sustainable, high-quality software.Episode Highlights:[00:05:32] Introduction to the Guest's Background: Robby and Alan discuss Alan's work at Cisco Meraki and his approach to well-maintained software.[00:15:10] The Importance of Behavior-Centric Testing: Alan explains why focusing on behavior, not implementation, helps in both startups and large-scale environments.[00:24:30] Rehydration: A Strategy for Managing Conditional Logic in Code: Alan shares his method for simplifying code with many conditionals.[00:35:00] Navigating Technical Debt: Alan offers advice on how to strategically manage technical debt without slowing down business needs.[00:45:18] Monitoring and Alerting: Alan's tips on keeping systems healthy and avoiding customer-facing issues through smart monitoring setups.Resources Mentioned:Radical Candor by Kim ScottThe Code GardenerConnect with Alan Ridlehoover:LinkedInThe Code Gardener Blog 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 April Wensel, Founder and Owner of Compassionate Coding. April shares her journey in the software industry and how she came to embrace compassion as a core value in coding and team dynamics. She explains why empathy is critical when working with legacy code, mentoring junior developers, and addressing technical debt.Episode Highlights[00:05:32] Introduction to Compassionate Coding: April discusses the mission behind Compassionate Coding and why human-centered development is essential.[00:13:36] Compassion and Technical Debt: How fostering a compassionate mindset helps teams navigate the challenges of maintaining legacy code and tackling technical debt.[00:20:10] Empathy in Code Reviews: April talks about the role of compassion in creating healthy, constructive code review cultures.[00:26:30] Onboarding with Compassion: The importance of pairing and empathy in onboarding new engineers, whether junior or senior.[00:31:55] The Refactor vs. Rewrite Debate: April explains why she usually sides with refactoring over rewriting code, and how compassion can inform that decision.[00:41:20] The Role of Leadership in Code Quality: How leaders can set the tone for compassionate coding by prioritizing better documentation and creating a supportive team environment.[00:44:56] Community Service and Building Empathy: April shares how volunteering outside of tech has helped her develop empathy that translates into better teamwork and communication in the workplace.Key Takeaways:Compassion in coding isn't just about clean code; it's about how we treat ourselves and others in the process of writing and maintaining software.Legacy code doesn't have to be a source of frustration; by embracing empathy and self-compassion, teams can tackle it with a positive mindset.Pairing and mentorship are powerful tools in onboarding, helping to bring new team members into a supportive, inclusive environment.Effective communication with stakeholders about technical debt requires empathy and understanding of their priorities.Compassionate coding also extends beyond the development team, influencing interactions with non-engineers, users, and the broader community.Resources:Compassionate CodingApril's Twitter12 Steps to a Compassionate Life by Karen ArmstrongFollow April Wensel:LinkedInTwitterWebsiteThanks 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 the Maintainable Software Podcast, Robby sits down with Saron Yitbarek, founder and CEO of DiscoLink, to explore the challenges of maintaining early-stage software while balancing multiple streams of income. Saron shares her journey from being a solo developer to hiring her first teammate and the lessons learned along the way about code maintainability and business logic.Episode Highlights[00:05:32] Introduction to Saron's Background: Robby and Saron discuss her startup, DiscoLink, and the initial development of its MVP.[00:10:50] The Importance of Context in Code: Saron emphasizes why understanding the business decisions behind code is crucial for maintainability.[00:15:10] Onboarding a New Developer: Saron shares her experience hiring her first developer and how it changed her approach to software maintenance.[00:20:32] Multiple Streams of Income: Saron explains her motivation behind building DiscoLink to help professionals manage different revenue streams.[00:25:40] Transparency Around Money: A candid conversation about developers' fears around charging for their work and how to overcome them.[00:30:45] Ethics and Side Projects: Robby and Saron discuss ethical considerations when working on side projects while employed full-time.[00:35:12] How Podcasting Shaped Saron's Career: Saron talks about how being a podcast host impacted her career growth and networking.Key TakeawaysMaintainability Beyond Code: Saron highlights the importance of documenting not just the code but also the business rationale behind decisions.Onboarding Challenges: Bringing a new developer into a solo-built project requires strong communication, context sharing, and flexible documentation practices.The Power of Multiple Income Streams: Saron's vision with DiscoLink focuses on helping tech professionals build financial security through various revenue channels.Confronting Money Anxiety: Many developers struggle with charging for their work, but transparency and community conversations help break down those barriers.Ethical Side Projects: It's important to consider the ethical implications of using work-learned skills for personal projects.ResourcesSaron Yitbarek on LinkedInSaron Yitbarek on TwitterDiscoLink WebsiteBook Recommendation: Formerly Known as Food by Kristin LawlessLinks:My newsletter: https://themultihyphenate.ck.page/newsletterThanks 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.
Ruben Casas discusses software migrations at scale, understanding different migration patterns, making critical decisions on whether a full rewrite is necessary, and more. This episode covers all the essentials you need to navigate your next big software transformation. Links https://www.linkedin.com/in/ruben-casas-17100383 github.com/infoxicator https://www.infoxicator.com/ https://x.com/Infoxicador https://www.youtube.com/c/RubenCasas We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr)
IntroductionIn this episode of Maintainable, Robby speaks with Lutz Hühnken, Head of Engineering Excellence at Upvest, about the transformative power of event-driven architecture in software development. Lutz brings his extensive experience to the table, discussing how breaking down complex systems into manageable modules and leveraging event-driven design can lead to more resilient and maintainable software.Topics Discussed[00:05:32] Introduction to Well-Maintained Software: Lutz shares his thoughts on the key characteristics of maintainable software, emphasizing modularity and simplicity.[00:10:24] Challenges with "Magic" in Code: The pitfalls of relying too much on frameworks and ORMs, including examples from Lutz's experience with Hibernate.[00:11:16] Understanding Event-Driven Architecture: Lutz explains the fundamentals of event-driven architecture and its advantages over traditional command-driven approaches.[00:13:50] The Role of Promises in Event-Driven Systems: How clear design-time responsibilities ensure reliability in event-driven communication.[00:15:43] Choreography vs. Orchestration: The debate between these two approaches to managing workflows and why Lutz favors choreography for most systems.[00:17:57] Onboarding Developers in Event-Driven Systems: Tips for effectively integrating new team members into an event-driven architecture.[00:26:52] The Role of Engineering Excellence at Upvest: Lutz discusses his new role and the importance of systems thinking in guiding architectural decisions.[00:34:55] Managing Technical Debt: Lutz offers insights into balancing feature development with addressing technical debt, emphasizing the importance of a healthy investment distribution.Key TakeawaysBreaking down large systems into smaller modules with clear boundaries can significantly enhance maintainability.Event-driven architecture offers a powerful way to decouple system components, making them more resilient and scalable.Developers should be cautious of "magic" in code, such as heavy reliance on ORMs, which can obscure underlying complexities and hinder maintainability.Choreography often provides a more scalable and maintainable approach than orchestration in managing complex workflows.Technical debt should be managed proactively, with regular investments in refactoring and productivity enhancements to maintain long-term software health.Resources MentionedLutz Hühnken's BlogEvent-Driven Architecture by Martin FowlerThe Open Society and Its Enemies by Karl PopperConnect with Lutz HühnkenLinkedInTwitterThanks 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 the Maintainable Software Podcast, Robby sits down with Cassidy Williams, Developer Advocate at GitHub, to explore the dynamic nature of a tech career, the delicate balance between clever code and maintainability, and the evolving trends in software development.Cassidy begins by discussing what makes software truly maintainable—starting with the ease of onboarding for new developers. She emphasizes the importance of clear documentation and warns against the pitfalls of writing overly clever code that might be difficult to maintain in the future.They then delve into the challenges of joining an existing codebase and managing technical debt. Cassidy shares her experiences, noting how codebases often start pristine but become more cumbersome as projects evolve and pivot.The Importance of Onboarding: Cassidy explains how fast someone can jump in and start working on code as a key indicator of well-maintained software.[00:10:21] Balancing Cleverness and Maintainability: Cassidy elaborates on why writing clever code can be a double-edged sword when it comes to long-term maintainability.[00:16:00] Navigating Career Pivots: Cassidy reflects on her own career journey, likening it to a "career jungle gym" where paths are non-linear and require thoughtful decision-making.[00:18:36] Working at Netlify: Cassidy shares her experience with upgrading a router within an existing codebase, highlighting the importance of collaboration and bringing in external expertise.[00:24:00] Local-First Software: Robby and Cassidy explore the trend of local-first software, emphasizing the benefits of data ownership and the ability to work offline.[00:26:30] Developer Wishlists: Cassidy suggests creating personal and communal wishlists for addressing technical debt, fostering a collaborative approach to maintaining software.[00:31:50] Jumbile - Cassidy's Side Project: Cassidy introduces her word game, Jumbile, detailing its development process and the unique challenges she faced.Cassidy also discusses her love for Brandon Sanderson's books, specifically the Mistborn trilogy, and the importance of owning your data in today's digital landscape.Key Takeaways:Maintainable software allows new developers to quickly contribute, thanks to clear documentation and readable code.Clever code can be a joy to write but may lead to maintenance challenges down the line.A career in tech often resembles a jungle gym, requiring flexibility and thoughtful navigation.Involving open-source maintainers in large codebase changes can provide invaluable insights and streamline the process.Local-first software is gaining traction, offering benefits in data ownership and offline functionality.Resources Mentioned:Cassidy's WebsiteCassidy on LinkedInCassidy on TwitterJumbile - Word GameReact RouterMistborn Trilogy by Brandon SandersonThanks 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! 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.