Do No Harm

In this segment, we discuss the principle of "Do No Harm"—a foundational mindset for writing safe, reliable code. While it's great to break large features into smaller diffs, it's essential that each individual diff stands alone as non-destructive and does not degrade the product or infrastructure if applied independently.

Key Takeaways:

• We ensure every diff is safe in isolation: Even in stacked diffs, each change must not break functionality or expose incomplete features. Every diff should be self-contained and ideally improve (or at least preserve) the integrity of the codebase.
• We avoid relying on future diffs to patch behavior: It's risky to land an unstable or unfinished diff assuming a follow-up will fix it. If that follow-up is delayed or rolled back (e.g., due to a production issue), the earlier diff could introduce bugs or break the app.
• We use feature gates wisely and early: When launching features behind flags, we gate the feature at the very beginning—not in later diffs—to avoid exposing half-baked functionality in production.
• We’re cautious with shared infrastructure: If a diff touches a shared module or critical system, we proactively reach out to other teams to confirm our changes won’t unintentionally break their workflows or apps.
• We understand our code lives in a larger system: Like parts of a giant elephant, changes in one place can affect parts we can’t see. Practicing empathy and caution helps us prevent cascading issues in complex, multi-team environments.

The “Do No Harm” principle reminds us that good engineering isn’t just about adding features—it’s about protecting trust, stability, and the broader system our code lives in.