Sustainable Software Requires Empathy for Your Future Self

The Unseen Costs of "Done": Why Sustainable Software Demands Empathy for Your Future Self

This conversation with Robby Russell, creator of Oh My Zsh and founder of Planet Argon, reveals a critical truth often overlooked in the fast-paced tech world: software development is an act of profound commitment to one's future self and colleagues. Beyond the immediate thrill of creation lies the often-ignored burden of maintenance, technical debt, and the long-term sustainability of code. Russell argues that the industry's obsession with "new and shiny" blinds us to the reality that most developers are akin to plumbers and electricians, tasked with keeping existing systems running. The hidden consequence? A compounding technical debt that cripples productivity, fosters developer burnout, and can lead to critical knowledge silos. This discussion is essential for any engineer, team lead, or CTO who wants to build software that endures, not just launches, offering a strategic advantage by fostering a culture of empathy and long-term thinking that most organizations neglect.

The Long Shadow of "Finished": Unpacking the True Cost of Code

The software development lifecycle is often framed as a series of sprints culminating in a "finished" product. But as Robby Russell illustrates, particularly through his experience with Oh My Zsh and his consultancy work, "finished" is a misleading concept. Software is a promise to the future, a commitment that demands ongoing nurturing. This perspective shifts the focus from the immediate gratification of shipping to the enduring impact of design decisions.

Russell’s journey with Oh My Zsh, born from a desire to simply share his own terminal configurations with a few coworkers, snowballed into a tool used by millions. This wasn't a grand plan for a global phenomenon, but an organic evolution driven by collaboration and the need to manage complexity. The initial goal was simple: make his own work easier. When coworkers wanted to customize colors or add their own shortcuts, the system had to adapt. This led to the creation of themes and plugins, not as a strategic architectural decision, but as a practical response to user needs. This highlights a key systems-thinking insight: emergent properties often arise from simple, localized desires for efficiency and customization, eventually shaping the entire system.

"I think the spicy part is trying to find where let's say AI can be useful in terms of not just maintaining software but I think I think maybe my the spicy take on that tends to be I think AI is doing a really good job of getting people started with projects I don't think it's helping people finish projects and those are like two different things that I think we're not talking about enough in the industry."

This observation about AI is particularly potent. While AI tools can accelerate the initial stages of development, they don't inherently instill the discipline required for completion and long-term maintenance. The "getting started" phase is often the easiest, fueled by novelty and inspiration. The true challenge--and where AI currently falls short--is in the sustained effort of debugging, refactoring, documenting, and iterating over years. Russell's emphasis on "shipping" versus "finishing" underscores this: shipping is an event, while finishing implies a state of ongoing viability. The trap here is mistaking the ease of starting for the ease of sustaining, leading to a proliferation of unfinished experiments rather than robust, evolving software.

This reality is amplified when companies rely on a single "hero" developer--the one person who holds all the institutional knowledge. Russell notes that this situation, common in Ruby on Rails development due to its capacity for single-developer productivity, is a red flag. When a project is concentrated in one mind, best practices like thorough commit messages, comprehensive documentation, and robust automated testing often fall by the wayside. Why bother with detailed commit messages if only you will ever see them? Why maintain a README if you're the only one who needs to navigate the system?

"The things that I've often seen that happen developers when they're trying to put out a fire like when they're trying to fix something really quickly and they're testing rapid fire quick quick let me try this let me try this which pushes to deploy is this fix it is this cross your fingers and this pushes to staging nope let's try something else really quick and then your commit messages get very very very terse and then that just sometimes that'll just happen with a one developer across everything and there's a lack of documentation they stop updating the read me because no one else is on their head and they know you know they so they don't take that advantage of like keeping the context a more shared thing because there's no one else to share with."

This creates a dangerous feedback loop. The lack of documentation and tests makes the system harder to understand and modify, increasing the likelihood of errors and further entrenching the single-developer dependency. This dependency can lead to immense pressure and guilt for the individual, making them feel indispensable but also trapped, fearing that their departure would cause the entire project to crumble. The consequence is a system that is not truly sustainable, but rather fragile and dependent on a single point of failure. The "Internal Tooling Maturity Ladder" Russell developed is a framework to combat this, encouraging teams to start small with essential tooling and gradually build up, recognizing that these investments, while perhaps not immediately glamorous, are crucial for long-term health.

Key Action Items

• Define a Shared "Definition of Done": Establish clear criteria for task completion that must include essential elements like adequate documentation and automated tests. This shifts these items from optional extras to non-negotiable requirements.
• Embrace the "Future Self" Constraint: When starting new work or refactoring existing code, consciously ask: "How would I want to find this code in 18 months?" This mental exercise encourages better documentation, cleaner code, and more robust testing.
• Prioritize Documentation as a Core Task: Treat writing and updating documentation (READMEs, inline comments, architectural diagrams) as integral to development, not an afterthought. This is an immediate action that pays off by reducing onboarding time and knowledge silos.
• Invest in Automated Testing (Even Small Steps): Even if a comprehensive test suite isn't feasible immediately, commit to writing tests for critical paths or new features. This builds a foundation for future reliability and reduces the risk of regressions. This pays off in 3-6 months.
• Conduct Regular Code Audits (Focus on Context): If you are the sole maintainer or part of a small team, dedicate time to reviewing commit logs and updating documentation. This effort, though seemingly tedious, is crucial for capturing context before it's lost. Do this quarterly.
• Advocate for Tooling Investments: Make the case for investing in shared tooling and processes (like CI/CD, standardized linters, or better issue tracking) that support collaboration and maintainability, even if the immediate ROI isn't obvious. This pays off in 12-18 months.
• Cultivate Empathy for Legacy Code: Reframe legacy code not as a burden, but as a testament to past efforts. Approach maintenance with respect for the original developers and their constraints, focusing on iterative improvement rather than wholesale rewrites.