Aging codebases can challenge even the most seasoned developers—especially when they’ve evolved into sprawling systems over many years. According to Chris Salvato, a Senior Staff Engineer at Shopify, the key to handling these legacy projects is to spend time in the “problem space” before making any changes. This episode explores how Chris shifts his mindset from immediate fixes to a deeper analysis of organizational pain points, drawing on strategies that benefit both newcomers and veterans of mature software projects.

Understanding the “Problem Space” First

Many developers, upon inheriting an older codebase, jump straight into files, modules, and test suites. Chris flips that script by scheduling one-on-one conversations with everyone involved: engineers, product managers, team leads, and even directors who may only tangentially interact with the software. This approach helps him grasp not only what the code looks like, but also what matters to the people who rely on it. He believes that if you don’t understand human frustrations—like deployment bottlenecks or domain confusion—then you’ll only ever patch symptoms. By aligning early on what genuinely needs attention, teams avoid the trap of endlessly rewriting code without addressing systemic issues.

Lean, Intuitive Domain Models

A consistent theme in Chris’s framework is cutting away “extraneous” code. In older systems, code accumulates through feature add-ons, quick hacks, and partial rewrites—often without robust cleanup cycles. Chris likens the result to an overgrown garden: you can plant new seeds, but everything is so dense that sunlight barely gets through. His solution starts with clarifying the domain model. A well-organized domain model (for instance, in a Ruby on Rails project) defines which parts of the software handle billing, user accounts, analytics, and so on. He references examples like Stripe having an elegant approach to domain modeling that makes their APIs nearly self-documenting.

This clarity benefits new developers who arrive with fresh eyes: they can intuit where new logic belongs and which files handle specific responsibilities. But it also supports advanced AI-based coding assistants, or Large Language Models, which rely on smaller, more cohesive contexts. When code becomes too large or too scattered, even powerful models fail to see the bigger picture, leading to incomplete suggestions or misunderstandings.

Building “Developer Paradise”

Chris uses the term “developer paradise” to describe a streamlined environment where the code is expressive enough to require little documentation. Instead of burying new hires under manuals, the structure of the classes and methods guides them to the correct place. In practice, this means having strong naming conventions, consistent file organization, and removing dead code so nothing misleads or confuses a developer. In a legacy environment—like a monolithic Rails app that dates back a decade or more—this can require substantial refactoring or strategic re-architecture. For those who see microservices as an escape hatch, Chris cautions that it only helps if the domain boundaries are clear. (See Martin Fowler’s article on microservices for an in-depth look at splitting systems along domain lines.) Without shared principles, moving a messy monolith into a microservices model just distributes the mess.

One-on-One Conversations for Trust and Clarity

A hallmark of Chris’s style is speaking individually with everyone, from junior developers to VPs. While some might see this as time-intensive, Chris emphasizes that quiet voices and critical details emerge only when people feel free to speak openly—something group meetings rarely facilitate. Those conversations also help identify “soft” barriers like emotional burnout or misaligned incentives. Once he’s gathered extensive feedback, Chris looks for common threads and recurring themes to form a shortlist of five or six core issues. This list is then refined in group discussions, transforming many voices into a shared perspective on which problems demand the most urgent attention.

From Problem Space to Focused Solutions

Solving problems effectively requires resisting the lure of solution-mode during feedback collection. Chris encourages teams to articulate the key question—like “How can we reduce confusion in the billing subsystem?”—as a way to funnel everyone’s energy into a single high-leverage goal. It’s easy to accumulate a backlog of 50 possible changes. But experience shows that scattering focus leads to a half-finished improvement here and a neglected fix there, never achieving genuine transformation. Chris references The One Thing by Gary Keller, which advocates strategic prioritization: solve the most impactful issue first, then move on.

Aligning Personal Ambitions with Company Goals

Robby and Chris also address a common reality: many developers won’t remain at a given company for more than a few years. Why invest in big, strategic refactoring if you’re likely to move on? Chris’s counterargument is that significant contributions not only strengthen a resume but also leave the organization better than you found it. By linking personal growth (learning new architectures, refining leadership skills) with a company’s need for cleaner code or faster deployment, engineers create a synergy that benefits both parties.

Leaving a Lasting Impact on Legacy Systems

Even short-term contributors can drive meaningful changes by helping unify a team around the real issues. Chris says that simply identifying the top pain points and broadcasting them clearly can reshape an entire roadmap. Whether the company chooses incremental refactoring or a larger rewrite, those discussions set a long-term direction. Over time, such clarity can reduce frustration, cut down on technical debt, and even boost product stability.

Drawing Inspiration from Biographies and Industry Wisdom

Chris is also a fan of reading biographies for leadership insights. He recommends Titan: The Life of John D. Rockefeller, Sr. by Ron Chernow, finding parallels between managing large-scale enterprises and orchestrating robust software. Echoing principles from Domain-Driven Design (DDD) or the broader microservices community, he says that focusing on the human side of code might just be the fastest route to shipping better features.

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.

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.

Resources & Mentions

Subscribe to Maintainable on:

Or search "Maintainable" wherever you stream your podcasts.

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

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

Maintainable