Noémi Ványi: Only Fix Problems That Are Actually Problems

Maintainable

Keep up to date with the Maintainable Podcast by joining the newsletter.

26:46

For many travelers, Antarctica is a bucket-list destination, a once-in-a-lifetime opportunity to touch all seven continents. In 2023, a record-breaking 100,000 tourists made the trip. But the journey begs a fundamental question: What do we risk by traveling to a place that is supposed to be uninhabited by humans? And as the climate warms, should we really be going to Antarctica in the first place? SHOW NOTES: Kara Weller: The Impossible Dilemma of a Polar Guide Marilyn Raphael: A twenty-first century structural change in Antarctica’s sea ice system Karl Watson: First Time in Antarctica Jeb Brooks : 7 Days in Antarctica (Journey to the South Pole) Metallica - Freeze 'Em All: Live in Antarctica Learn about your ad choices: dovetail.prx.org/ad-choices…

for ca. et år siden 42:01

MP3•Episode hjem

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 Mentioned

Book Recommendation

Lost in Thought: The Hidden Pleasures of an Intellectual Life by Zena Hitz

🍇Thanks to Our Sponsor!

Jelly is the simplest, most affordable way to deal with your “contact@...” emails.

Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And Jelly is actually affordable —team-based pricing means everyone can pitch in with your team’s conversations with customers, clients, and beyond.

Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable.

Subscribe to Maintainable on:

Or search "Maintainable" wherever you stream your podcasts.

212 episoder

#Programming #Software Development #Business #Software #Agile #Technical Debt #Best Practices #Web Development #Robby Russell #Tech #Careers #Legacy Code #Software Engineering #Software Programming #Code #Software Code

Noémi Ványi: Only Fix Problems That Are Actually Problems

Maintainable

148 subscribers

published for ca. et år siden

Del

MP3•Episode hjem

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 Mentioned

Book Recommendation

Lost in Thought: The Hidden Pleasures of an Intellectual Life by Zena Hitz

🍇Thanks to Our Sponsor!

Jelly is the simplest, most affordable way to deal with your “contact@...” emails.

Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable.

Subscribe to Maintainable on:

Or search "Maintainable" wherever you stream your podcasts.

Keep up to date with the Maintainable Podcast by joining the newsletter.

212 episoder

All episodes

Maintainable

1
Freedom Dumlao: What 70 Java Services Taught Me About Focus 1:03:19

for 21 hours siden1:03:19

1:03:19

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

Maintainable

1
Mercedes Bernard: Friendly Code Welcomes Everyone In 49:27

for 15 dage siden49:27

49:27

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

Maintainable

1
Evan Phoenix: The Why of the One Line 1:09:13

for 22 dage siden1:09:13

1:09:13

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

Maintainable

1
Chris Salvato: Building Developer Paradise by Sitting in the Problem Space 46:31

for 29 dage siden46:31

46:31

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 & Mentions Shopify Ruby on Rails Chris’s GitHub Chris’s LinkedIn Chris’s Twitter/X The One Thing by Gary Keller Titan: The Life of John D. Rockefeller, Sr. by Ron Chernow Martin Fowler on Microservices Domain-Driven Design 🍇 Thanks to Our Sponsor! Jelly is the simplest, most affordable way to deal with your “contact@...” emails. Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And Jelly is actually affordable — team-based pricing means everyone can pitch in with your team’s conversations with customers, clients, and beyond. Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable . Subscribe to Maintainable on: Apple Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Heimir Thor Sverrisson: Architecture First, Tech Debt Second 40:58

for 5 weeks siden40:58

40:58

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 & Links Heimir Thor Sverrisson on LinkedIn Heimir’s GitHub MojoTech AMSAT – Amateur Radio Satellite Organization Book Recmmendations The Man Who Broke Capitalism How to Make Things Faster 🍇 Thanks to Our Sponsor! Jelly is the simplest, most affordable way to deal with your “contact@...” emails. Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And Jelly is actually affordable — team-based pricing means everyone can pitch in with your team’s conversations with customers, clients, and beyond. Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable . 💡 Enjoyed this episode? Share it with someone who cares about maintainable architecture and technical debt management ! Subscribe to Maintainable on: Apple Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Noémi Ványi: Only Fix Problems That Are Actually Problems 42:01

for 6 weeks siden42:01

42:01

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 Mentioned Noémi Ványi’s Website Noémi Ványi on GitHub Elastic GitHub Pull Request Templates GitHub Book Recommendation Lost in Thought: The Hidden Pleasures of an Intellectual Life by Zena Hitz 🍇Thanks to Our Sponsor! Jelly is the simplest, most affordable way to deal with your “contact@...” emails. Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And Jelly is actually affordable — team-based pricing means everyone can pitch in with your team’s conversations with customers, clients, and beyond. Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable . Subscribe to Maintainable on: Apple Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Julia López: Code Tells a Story—Even the White Spaces 50:32

for 8 weeks siden50:32

50:32

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. 💡 Key Topics & Timestamps [00:00:22] Meet Julia López – Her background, role at Harvest, and passion for refactoring. [00:00:42] What Makes Software Maintainable? – A test suite you can trust and an engineering culture that values refactoring. [00:06:31] Leading Harvest’s Billing System Overhaul – Why a full rewrite made more sense than incremental improvements. [00:09:54] The Hidden Complexity of Billing Systems – Managing ACH, credit card, and invoice payments. [00:14:05] The Fear Factor in Large-Scale Refactoring – Why organizations hesitate and how to push forward. [00:18:47] Communication Challenges in Remote Teams – Why documentation and transparency matter beyond GitHub. [00:28:30] Finding and Enforcing Engineering Patterns – How teams can encourage consistency in a constantly evolving codebase. [00:35:45] Why Autonomy Matters for Developers – Learning through struggle and when to ask for help. [00:45:25] Advocating for Refactoring When Leadership Says No – Julia's approach: "Ask for forgiveness, not permission—but estimate higher." 🔗 Resources Mentioned Harvest – Julia's company Radical Candor by Kim Scott The Making of a Manager by Julie Zhuo Stripe – The payment processor used in Harvest’s billing system Git Blame – A tool for understanding code history 📢 Connect with Julia López Julia's Website LinkedIn GitHub BlueSky 🍇Thanks to Our Sponsor! Jelly is the simplest, most affordable way to deal with your “contact@...” emails. Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility, and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And, Jelly is actually affordable — team-based pricing means everyone can pitch in with your team’s conversations with customers, clients and beyond. Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable . Subscribe to Maintainable on: Apple Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Marty Haught: Rethinking Technical Debt—Is It Really Just Drift? 52:39

for 9 weeks siden52:39

52:39

Episode Overview Marty 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:34:00] Funding open source: Why corporate sponsorships are becoming essential. [00:38:20] Processes in distributed teams: Balancing structure with flexibility. [00:44:45] Advocating for technical debt work in teams: How to make a compelling case. Key Takeaways Technical 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 Mentioned Marty Haught on LinkedIn Marty Haught on Twitter Ruby Central RubyGems Auditing the Ruby Ecosystem’s Central Package Repository – Trail of Bits EU Cyber Resilience Act Overview What the EU's New Software Legislation Means for Developers (GitHub Blog) Ruby Central Open Source Program – Get Involved Corporate Sponsors Program Give and Take by Adam Grant Connect with Marty LinkedIn Twitter BlueSky Thanks to Our Sponsor! Jelly is the simplest, most affordable way to deal with your “contact@...” emails. Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility, and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And, Jelly is actually affordable — team-based pricing means everyone can pitch in with your team’s conversations with customers, clients and beyond. Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable . Subscribe to Maintainable on: Apple Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Mike Bowers - From ISAM to JSON—Navigating 40+ Years of Database Evolution 44:46

for 10 weeks siden44:46

44:46

Mike 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 roles Resources Mentioned FairCom Mike Bowers on LinkedIn FairCom on Twitter/X Book Recommendation: The Influential Product Manager by MSc Bucero Thanks to Our Sponsor! Need a smoother way to share your team's inbox? Jelly’s got you covered! 🍇✨ Jelly is perfect for small teams — because it was built by a small team. If you struggle with keeping your team’s knowledge organized and accessible, check out Jelly, a lightweight knowledge management tool designed to make finding answers easy—without all the clutter of traditional wikis. No more sticky situations or knowledge gaps—Jelly keeps everything smooth, and shareable. Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable, Subscribe to Maintainable on: Apple Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Lorna Mitchell: Writing Documentation Engineers Will Actually Read 43:18

for 12 weeks siden43:18

43:18

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 Website rst2pdf Project Simon Willison’s Post on One-Person Projects How to Take Smart Notes OpenAPI Specification Veil Prose Linter Follow Lorna: GitHub IndieWeb 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 Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Carola Lilienthal: Tackling Technical Debt with Patterns and Domain Knowledge 43:00

for 13 weeks siden43:00

43:00

Episode Summary In 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 Takeaways Modularity 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 Mentioned Carola’s LinkedIn WPS Website Carola’s books: Sustainable Software Architecture Domain-Driven Transformation (English version coming soon) Modularity Maturity Index Overview Books Carola recommends: Reinventing Organizations by Frédéric Laloux Team Topologies by Matthew Skelton and Manuel Pais Be 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 Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Joel Hawksley: The Hidden Costs of Frontend Complexity 46:13

for 14 weeks siden46:13

46:13

Topics Discussed The 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 Priority The 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 System Primer fosters consistency but introduces the challenge of making changes across a vast, interconnected system. [00:12:54] The Cost of Frontend Complexity Joel 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 Accessibility Joel 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. Resources Joel Hawksley’s Website Primer Design System Axe Accessibility Tools GitHub’s ViewComponent Framework Book Recommendation: How Buildings Learn by Stewart Brand Guest's Links Joel Hawksley on GitHub Joel Hawksley’s Website 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 Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Austin Story: Making Software Easier to Change, Remove, and Evolve 47:08

for 19 weeks siden47:08

47:08

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 Takeaways Simplicity 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 Mentioned YAGNI (You Aren’t Gonna Need It) GraphQL Federation Overview Doximity Technology Blog The Mom Test by Rob Fitzpatrick Austin Story on LinkedIn Austin Story's Website Stay Connected Follow Austin: LinkedIn Website 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 Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Dan Moore: Building Developer-Friendly Authentication Solutions 49:20

for 20 weeks siden49:20

49:20

Topics Covered Characteristics of Maintainable Software Dan 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 Systems Dan 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 Challenges As 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 Teams Advice 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 Role From 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 Takeaways Consistency 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 Mentioned FusionAuth Blog Dan's Personal Blog CIAM Weekly Newsletter Dan’s Book: Letters to a New Developer Zen and the Art of Motorcycle Maintenance The Asimov story mentioned Try FusionAuth Download FusionAuth : Get started with the self-hosted version today. Free Trial of FusionAuth : Experience the FusionAuth cloud for free! Connect with Dan LinkedIn BlueSky 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 Podcasts Spotify Or search "Maintainable" wherever you stream your podcasts. Keep up to date with the Maintainable Podcast by joining the newsletter.…

Maintainable

1
Tom Johnson: From Auto-Documentation to Better Collaboration 43:19

for 21 weeks siden43:19