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

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 ...