Intro

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.