Stop Treating All Code Like It's Going to Kill Someone

I was three days into a feature when my senior engineer asked me a question that genuinely bothered me: "What's the worst thing that happens if this breaks?"

I gave him the usual answer—downtime, lost data, angry users—but he cut me off. He meant specifically. Not in theory. In practice, on this Tuesday afternoon, what actually breaks? And how do I fix it? It was such a simple question that I'd never been taught to ask, and it completely changed how I approach every commit I push.

I spent the first two years of my career treating every line of code like it was the CrowdStrike update that crashed 8.5 million Windows machines. I'd write three lines and then obsess over edge cases that would never happen in production. I was slow. Not thorough—slow. And I was slower on the things that actually mattered because I'd burned all my caution on the stuff that didn't.

The Blast Radius Is What Matters

The original article nails something that gets glossed over in every "software risk" checklist I've ever seen: not all mistakes cost the same.

When I'm tweaking an internal dashboard that maybe five people use, a bug is an inconvenience I fix at lunch. When I'm changing billing logic, a bug is potentially a legal problem. The skill isn't following the same process for both. The skill is reading the blast radius of what I'm about to touch and letting that decide how careful I need to be.

Most developers I've watched either go too slow on everything or too fast on everything. There's rarely a middle ground. And both extremes hurt the business in different ways.

One-Way Doors vs. Two-Way Doors

The mental model that stuck with me is this: Can I undo it?

A feature flag deployment? That's a two-way door. I can flip it back in seconds. A database migration that rewrites core customer records? That's a one-way door. I can't unsee that data if I screwed up the transformation. The reversibility matters more than we admit.

I've started applying this to everything I touch. If I can roll it back in one click, I'm comfortable moving fast. If a rollback would take hours or require manual customer support outreach, I'm slowing down. Not glacially, but measurably. More testing. More code review. Maybe a staged rollout instead of all-at-once.

What I Actually Do Differently Now

I've built this into my PR process. Before I push anything, I write a quick assessment:

• What breaks if this is wrong?
• How do I know I'm wrong? (How do we detect the failure?)
• How do I fix it?

If the answer to "how do I fix it" is "manually," that changes everything. If the answer is "revert the commit," that's completely different. The time I spend thinking through those answers up front saves me hours of firefighting later.

On catastrophic-risk code—anything touching payments, mass notifications, or automated processes at scale—I pair that with actual test coverage. Not 100% coverage theater. Tests on the paths that actually hurt if they break. For a checkout flow, that's the payment processing path. For a bulk email job, that's whether we're sending to the right recipients and only once per person.

Where I Disagree (A Little)

The article makes it sound straightforward, and in principle it is. But there's a gray area where I find myself stuck: most of the work I do lives in that "serious but recoverable" middle rung. It's customer-facing, it matters, but it's not rocket-science catastrophic.

How do I know if I'm spending the right amount of caution there? I've occasionally gone too light and caught regressions in staging that should have been caught earlier. I've also gone too heavy and spent two days testing something that probably didn't need it. I haven't found a formula yet, which means I'm still relying on judgment and experience.

The Question That Actually Matters

This all comes down to something nobody teaches you in school or coding bootcamps: the ability to make risk calls. To look at a change and genuinely understand what's at stake. To separate the work that deserves rigor from the work that just needs to be done.

If you're reading this and you're early in your career, start asking that question on every PR: What's the worst thing that happens if I'm wrong here? Then let that answer guide your process. You'll be faster and safer.

What's a change you've made recently that surprised you with its actual blast radius? I'm curious whether I'm the only one who's misjudged the stakes.

Source: This post was inspired by "Risks in Software Development: How to Match Your Caution to What's Actually at Stake" by Dev.to. Read the original article