I’ve never been able to function well in a messy space. It’s not about neatness—it’s something…deeper. When things are scattered, mislabeled, blocked, it doesn’t just irritate me—it hurts my brain. I can’t think clearly when the environment is working against me.
Years ago, I worked at a warehouse, and it was a nightmare. Stock piled haphazardly, no paths cleared, nothing where it was supposed to be. One of the first things I did was pull a manager aside and explain—calmly, clearly—that the mess wasn’t just annoying, it was dangerous. Someone was going to trip. I was slower because I had to step around chaos. I couldn’t do my job safely or well.
Their response?
“There’s nothing we can do. That’s just how it is.”
Fast forward to now, and I hear the exact same thing.
About code.
Codebases full of landmines, missing labels, miswired logic, traps you don’t see until they spring. Teams limping along with TODOs like exposed nails and business rules only half remembered. And still: “That’s just how it is.”
But it’s not. That’s not how it has to be. We’ve just forgotten what “unsafe” looks like when the damage isn’t visible.
So let’s say it plainly:
Cognitive injury is injury.
Code that burns you out, gaslights your sense of competence, pushes you into late nights because the architecture actively resists understanding? That’s a safety issue. And if that sounds dramatic, ask yourself why it doesn’t sound dramatic when a forklift driver refuses to operate a machine with no brakes. Why is it different when it’s your mind being pushed past its limit?
Demanding safety is not a personal failure. You’re not being difficult. You’re being responsible. What you’re feeling is the same thing I felt standing by that conveyor belt, knowing I was the one who’d pay for someone else’s shortcuts.
Now I’m not ignoring the reality of a business. Because I get it. You’re under pressure to deliver. You don’t want another delay, another debate, another story point spent on something you can’t see. But here’s the truth: the mess is costing you. You’re paying for it in incidents, in missed handoffs, in onboarding times, in attrition. Just because the injuries don’t leave bruises doesn’t mean you’re not bleeding money.
You don’t have to become a code quality zealot.
You just have to recognize what every other industry already figured out:
Unsafe systems fail.
And if we treated cognitive environments like physical ones?
We’d never let some of this stuff ship.
What Makes Code Unsafe
Let’s start here:
Unsafe code doesn’t mean “ugly.” It doesn’t mean “not up to your standards.”
It means dangerous to work inside—mentally, emotionally, and operationally.
If you’ve ever opened a file and immediately felt your shoulders tense…
If you’ve ever lost 3 hours to a bug that turned out to be one line, tucked in the wrong abstraction…
If you’ve ever made a change, held your breath, and thought please don’t break anything—
you already know what unsafe code is.
You just might not have called it that yet.
And once you’ve lived in that environment long enough, here’s what happens:
You slow down, but not in a way management can see.
You start second-guessing yourself on basic tasks.
You carry more state in your head than the system does in memory.
You burn hours trying to predict failure modes instead of writing features.
You stop trusting your tools. You stop trusting yourself.
And then someone says, “What’s taking so long?”
And you don’t know how to answer without sounding like you’re making excuses.
So you say nothing.
That’s the injury.
And perhaps the worst part? You stop talking about it.
Not because you don’t care, but because it feels futile—or worse, risky.
And that silence is how unsafe systems survive.
A Safe Codebase Isn’t Just Easier—It’s Calmer
This part matters:
Safe code doesn’t just let you move faster. It lets you breathe.
It gives you confidence to make changes without gut fear. It lets you onboard a new dev without handing them a rosary and a support group.
Safety is not perfection. It’s predictability.
You don’t need padded walls. You just need rails that hold.
And here’s the part that’s both comforting and frustrating:
We already know how to make code safer.
We’ve just been treating safety as optional—like a courtesy, not a requirement.
But look around: we’ve already adopted a lot of safety equipment.
We use type systems. We use linters. And when someone disables them to move fast?
There’s a reason that gets side-eyed.
Because we know what it means.
It’s like someone taking off their helmet on a construction site and calling it “efficient.”
None of this is revolutionary. None of this is controversial.
But here’s the thing: safety gear only works when you use it.
And right now? Most of it is easy to bypass. Sometimes even encouraged to be bypassed.
Imagine telling a factory worker:
“Yeah, we’ve got gloves and goggles and ear protection—but we’re trying to hit deadline, so maybe skip all that today.”
Sound ridiculous? Or worse… familiar?
That’s exactly what it sounds like when someone says, “We don’t have time for tests.”
What OSHA Teaches Us
Here’s the thing about safety protocols:
Nobody wakes up one day and wants them. They show up after the injury.
OSHA didn’t spring into being because someone cared deeply about ladders.
It exists because too many people died doing work someone else asked them to do—without protection, without warning, and without recourse.
And when that harm became impossible to ignore, we didn’t say,
“Well, maybe workers just need to be tougher.”
We said: This was preventable. Let’s prevent it.
Software Has Its Own Graveyard—We Just Don’t Call It That
Our postmortems aren’t written in blood, but they’re still written in pain.
They’re full of sleepless nights. Lost weekends. Burnout. Escalations. Resignations.
They’re full of phrases like:
- “We didn’t realize how interconnected that system was.”
- “There wasn’t enough time to write tests.”
- “It was fragile, but we didn’t know how fragile.”
We call these incidents.
We treat them like lightning strikes.
But lightning doesn’t hit this often. And it doesn’t always strike the same file.
The Velocity Mirage
If you want to understand why software gets hurt, start here:
Velocity is a scalar.
It tells you how fast a team is moving.
It tells you nothing about why.
It doesn’t care if your speed comes from clean architecture or unpaid overtime.
It doesn’t distinguish between a team working joyfully in a maintainable system…
and a team sprinting across crumbling scaffolding with duct tape and coffee.
Velocity can be manufactured—by skipping safety.
But the crash still comes.
You just won’t see it in the sprint report.
What OSHA Got Right (and We Haven’t Yet)
OSHA doesn’t measure success by speed. It measures success by absence of injury.
That’s the lesson.
- Unsafe behavior isn’t a personal flaw—it’s a systems problem.
- Unsafe environments are more expensive over time—even if they’re faster short-term.
- Safety is cheaper than accidents. But only if you invest before the harm.
- And most importantly: it’s not on workers to enforce safety themselves.
A safe environment doesn’t rely on every person being brave.
It relies on the system not allowing unsafe behavior to proceed.
So What Does That Mean for Us?
It means your postmortem isn’t just a story—it’s a signal.
It means your “best practices” need to be more than suggestions.
And it means if we keep optimizing for scalar metrics like velocity, we’ll keep missing the actual story: who got hurt to hit that number.
Velocity without safety isn’t delivery.
It’s attrition on a delay.
It’s burnout, turnover, and failure—just scheduled later.
We don’t need to reinvent how to protect ourselves.
We just need to stop pretending this is fine.
The Choice
So here we are.
You’ve seen the injuries.
You’ve seen the workarounds.
You’ve seen the tools lying unused in the corner, next to the pile of deadlines.
Here’s the choice:
You can keep squeezing the system until something breaks—
a developer, a relationship, a core service at 3AM.
Or you can decide that safety matters.
Because the truth is simple:
Incidents are more expensive than prevention.
Burnout is not a rounding error.
Safety is a leadership decision.
And once you’ve seen it that way, it’s hard to unsee.
So now you know.
What kind of system do you want to be responsible for?
Because we’re all responsible for something.
And someone is going to inherit the next hazard.
Or remove it.
That part’s still up to you.