Characters: - Wei, the Teacher — 20+ years of experience across various roles and organizations - Kamal, the Enthusiast — 3 years of experience, eager to make an impact quickly - Marcus, the Manager — 8 years of experience, responsible for team delivery and well-being
Kamal: (excitedly showing his screen) Look at this! I just finished implementing three features since yesterday. I even stayed up until 2 AM to get that notification system working.
Marcus: That's impressive speed, Kamal. But I'm a bit concerned about the late hours. We've talked about sustainable pace before.
Kamal: (dismissively) I don't mind. When I'm in the zone, I don't want to stop. Besides, isn't that what great engineers do? Put in the extra hours to ship features faster?
Wei: (joining the conversation) I've noticed we're having this discussion more frequently. Perhaps we should talk about what sustainable engineering actually means and why it matters.
Marcus: That would be helpful. I'm caught between appreciating Kamal's enthusiasm and worrying about both burnout and the quality of rushed work.
Wei: It's a common tension. Let's start with a fundamental truth: in software engineering, nothing counts unless it makes it all the way to production and customers are actually using it.
Kamal: Exactly! That's why I push so hard to get features finished quickly.
Wei: But "finished" is a more nuanced concept than many realize. A feature isn't truly finished when it's coded—it's finished when it's serving users reliably in production, with minimal need for rework or emergency fixes.
Marcus: And that's where I see potential issues. When we rush, we often end up spending more time on fixes later.
Wei: Precisely. There's an old saying that I think applies here: "It is the nature of the wise to resist pleasures, but the foolish to be a slave to them."
Kamal: (confused) What does pleasure have to do with coding?
Wei: There's a certain pleasure in the quick win—the dopamine hit of marking a feature complete, pushing code, and moving to the next thing. But sustainable engineering requires resisting that immediate gratification in favor of more enduring satisfaction.
Marcus: Like the satisfaction of building something that lasts and doesn't wake you up at 3 AM with production alerts?
Wei: (smiling) Exactly. Sustainable engineering practices balance several dimensions: the velocity of feature delivery, the quality of code, the health of the system architecture, and—critically—the well-being of the engineers themselves.
Kamal: But doesn't moving slower mean we deliver less value to our users?
Wei: It's not about moving slower; it's about moving more purposefully. Consider the Japanese concept of "nemawashi"—the careful preparation of the ground before planting. In engineering terms, this means investing in proper planning, testing, and infrastructure before rushing to implement features.
Marcus: I've also heard it described as "going slow to go fast"—taking the time upfront to avoid speed-limiting problems later.
Wei: Exactly. Let me share some principles that have helped teams I've worked with maintain sustainable practices while still delivering value consistently.
Kamal: (with grudging interest) I'm listening.
Wei: First, work should be merged all the way to the main branch daily. This isn't just a technical practice—it's about maintaining a sustainable cadence. When work stays in branches for days or weeks, integration becomes increasingly painful.
Marcus: We've certainly experienced that pain. The longer a branch lives, the harder the merge becomes.
Wei: And it's not just about technical friction. Long-lived branches create psychological weight—unfinished work accumulates, priorities become confused, and the team loses its sense of steady progress.
Kamal: But sometimes features take longer than a day to build.
Wei: Of course, but large features can almost always be broken down into smaller, independently valuable changes that can be integrated daily. This approach reduces risk, enables earlier feedback, and maintains team momentum.
Marcus: I've noticed our most productive weeks are when we have multiple small, focused pull requests rather than a few massive ones.
Wei: (nodding) Which brings me to another principle: limit work in progress. Human minds aren't designed for multitasking. When engineers try to juggle multiple tickets simultaneously, context switching consumes mental energy and increases error rates.
Kamal: But what if I'm blocked on one ticket? Shouldn't I start another one while waiting?
Wei: That's where team communication becomes vital. When you're blocked, make it visible immediately so the team can help remove the obstacle. Starting another task often just creates two half-finished pieces of work instead of collaboratively solving the blocker.
Marcus: What about deadlines? Sometimes business needs require us to work at a faster pace.
Wei: Deadlines themselves aren't the issue—it's how we approach them. Instead of compressing all quality practices to meet a fixed scope by a fixed date, we should question the scope itself. What's the minimal valuable implementation that addresses the core need?
Kamal: (skeptically) So we deliver less?
Wei: We deliver what matters most first. This is sustainable because it focuses effort on high-impact work and reduces the complexity of each deployment. Remember, features that never make it to production have zero value, regardless of how impressive they might be in development.
Marcus: I've also found that unrealistic deadlines often lead to hidden costs—technical debt, team burnout, and quality issues that eventually slow us down more than a realistic timeline would have.
Wei: Absolutely. Which brings me to what I call "The 30 Minute Rule"—a simple practice that saves tremendous time and frustration.
Kamal: What's that?
Wei: If you find yourself stuck on a problem for more than 30 minutes without making progress, it's time to take a break or seek help. The human mind needs variety and rest to solve complex problems effectively.
Kamal: (with realization) I've definitely experienced that feeling of spinning my wheels and getting nowhere.
Wei: Most of us have. There are no problems in software engineering that should consume days and days without progress. Anyone who spends that long stuck is usually missing something fundamental that fresh eyes or a different perspective would quickly identify.
Marcus: This reminds me of our own challenges with maintaining work-life boundaries, especially with remote work. Any thoughts on that aspect of sustainability?
Wei: Remote work makes sustainable practices both more important and more challenging. Without the natural boundaries of an office environment, it's easy for work to expand to fill all available time.
Kamal: That's definitely happened to me. Work is always just a laptop away.
Wei: Which is why explicit agreements about availability are essential. Core working hours when everyone is expected to be available for collaboration, combined with clear signals about when you're working and when you're not, help establish healthy boundaries.
Marcus: I've noticed our most sustainable performers aren't necessarily working the longest hours—they're the ones who are fully present during work time and fully disconnected during personal time.
Wei: (nodding) The mind needs genuine rest to perform at its best. The myth of the programmer working 80-hour weeks and producing brilliant code is largely that—a myth. More often, those hours produce technical debt that someone else will eventually have to address.
Kamal: (thoughtfully) I've noticed that my late-night coding sessions often require significant revision the next day.
Wei: That's a common experience. Another dimension of sustainability is continuous learning. The technology landscape evolves rapidly, and engineers who don't allocate time for professional development eventually find their skills obsolete.
Marcus: We've been trying to encourage our team to dedicate regular time to learning, but it's often the first thing sacrificed when deadlines loom.
Wei: That's a false economy. Learning shouldn't be viewed as separate from "real work"—it's an essential component of long-term productivity. The most sustainable teams I've been part of treat learning as non-negotiable, even during busy periods.
Kamal: All of this sounds reasonable in theory, but how do you actually implement these practices when there's constant pressure for more features?
Wei: It starts with making the cost of unsustainable practices visible. When we rush and accumulate technical debt, we should track that debt explicitly—document it, quantify its impact on velocity, and include its repayment in future planning.
Marcus: That visibility helps product and business stakeholders understand the true cost of shortcuts.
Wei: Exactly. It's also important to celebrate the right behaviors. If we only recognize shipping features quickly, regardless of quality or sustainability, that's what the team will optimize for. Instead, we should highlight and reward thorough testing, thoughtful design, knowledge sharing, and code that requires minimal maintenance.
Kamal: (considering) So I might get more recognition for building something that doesn't generate support tickets than for building three features that each need multiple fixes?
Wei: In a healthy engineering culture, absolutely. Quality and sustainability should be valued as highly as raw productivity. The goal isn't to build as much as possible; it's to build what delivers the most value with the least ongoing cost.
Marcus: How does this connect to team structures and specialization? We're constantly debating whether engineers should be specialists or generalists.
Wei: That's an important dimension of sustainability. Teams composed entirely of specialists can build highly optimized components that integrate poorly. Teams of only generalists might build coherent but unexceptional systems. The most effective teams leverage both profiles.
Kamal: So it's not either-or?
Wei: Rarely is it that simple in software engineering. Most successful engineers develop what I call a "specialty core with adaptable edges"—deep expertise in something fundamental but enough breadth to collaborate effectively across domains.
Marcus: (nodding) That matches my observation. Our most valuable team members aren't necessarily those who know the most about everything, but those who combine depth in key areas with the adaptability to work across boundaries.
Wei: The final aspect of sustainable engineering I'd emphasize is a focus on measuring what matters. Many teams track activity metrics—lines of code, tickets closed, hours worked—rather than outcome metrics like user value delivered, reduction in support cases, or system reliability.
Kamal: How do you measure those less tangible outcomes?
Wei: It requires thoughtful instrumentation and a willingness to look beyond the obvious. For example, rather than counting features shipped, measure how many users actively engage with those features. Instead of tracking hours worked, track the mean time between failures or the average time to recover from incidents.
Marcus: Those metrics would certainly give us a better picture of whether we're building sustainably.
Wei: (summarizing) Sustainable engineering isn't about moving slowly. It's about moving intentionally—choosing the pace and practices that optimize for long-term value delivery rather than short-term appearances of progress.
Kamal: (reflectively) I think I've been too focused on appearing productive rather than being truly effective. Building things that last does seem more satisfying than just building things quickly.
Marcus: And from a management perspective, sustainable practices reduce the chaos and stress that make leading a team difficult. When everyone is constantly in emergency mode, real leadership becomes nearly impossible.
Wei: Precisely. The most elegant code, the most impactful features, and the most satisfying careers rarely emerge from constant pressure and exhaustion. They come from thoughtful, deliberate effort applied consistently over time.
Kamal: So what's one practice I could start with to be more sustainable?
Wei: Begin with the daily merge discipline. Commit to having your work integrated into the main branch each day, no matter how small the increment. This creates a natural pressure to work in small, manageable chunks and to resolve integration issues immediately rather than letting them accumulate.
Marcus: And I'll work on making our team's invisible work more visible—the refactoring, the learning, the collaboration that doesn't immediately result in shipped features but enables us to ship sustainably in the future.
Wei: (with approval) Those are excellent starting points. Remember, sustainable engineering isn't just about technical practices—it's about creating an environment where people can do their best work not just today, but for years to come. It's as much about nurturing the engineers as it is about nurturing the code.
[The conversation continues, with Wei sharing specific examples from his experience of teams transforming their practices to become more sustainable, while Kamal asks pointed questions about applying these principles to their current projects.]