Experience is directly proportional to the amount of equipment ruined.

That’s Harrisberger’s Fourth Law of the Lab. I stumbled across it recently and genuinely laughed out loud. Not because it’s clever (though it is), but because it’s the most honest description of how learning actually works.

We don’t talk about this enough.

There’s this weird expectation that professional development means attending courses, getting certifications, reading the right books. All very neat. Very tidy. Very… theoretical.

I’ve learned more from breaking things than I ever did from tutorials.

The messy reality#

My best lessons haven’t come from documentation. They’ve come from the aftermath.

The time I accidentally automated a process that broke 100 things at once. The debugging sessions at 11pm when something that “should work” definitely didn’t. The confident push that failed in ways I couldn’t have imagined.

Each disaster taught me something. Each broken thing made me better at not breaking things. Or at least, better at breaking them in more interesting ways.

I remember one particular day, years ago, working for an MSP. Routine ticket. Delete a mailbox in Exchange. Simple stuff. Done it hundreds of times.

Except I misread the ticket. And the mailbox I deleted belonged to the CEO.

Fine, I thought. Exchange keeps deleted mailboxes for 30 days by default. Some retention config. I’ll just restore it. No problem. Deep breath. This is recoverable.

Except… this particular Exchange server didn’t have that config set. I was sure it was a default. Apparently not.

That was a painful day. Phone calls I’d rather forget. The kind of silence from a client that makes your stomach drop.

Let’s not even talk about the days that followed.

The time I renamed everyone’s accounts and broke every login across the organisation. The time I configured SCIM and watched it helpfully remove everyone’s accounts so nobody could log in to anything.

Sensing a pattern here. Apparently my speciality is finding new and creative ways to stop people accessing their own stuff.

But I’ve never made those mistakes again. I now check configs before assuming anything. I rename instead of delete wherever possible. I test identity changes on a single account before rolling out to thousands. Every single time.

Those lessons cost me days I’d rather not relive. But they stuck in a way no training course ever could.

The permission to fail#

Most people wait for permission to experiment. They want a safe environment. A sandbox. A guarantee that nothing bad will happen.

Sandboxes have their place. I’m not saying burn it all down for the sake of learning. But no sandbox is ever truly like production. The data’s different. The scale’s different. The pressure’s different. The weird edge cases that only exist because someone made a strange decision in 2019? Not in your sandbox.

You can minimise failures. You absolutely should. But you can’t eliminate them entirely. And at some point, you have to do the thing for real.

That’s not recklessness. That’s just how expertise is built. You can’t develop intuition without first developing scars.

Somewhere along the way, we started treating failure as something to avoid rather than something to learn from. We optimised for looking competent instead of becoming competent.

Think about how we talk about mistakes at work. “Learnings” we call them, in that sanitised corporate way. Post-mortems. Retrospectives. All very clinical. All very much after the fact.

Nobody says “yeah, go break stuff. That’s how you’ll figure it out.”

But it is. It really is.

What actually works#

The best developers I know have broken things spectacularly. The best AI practitioners have hallucinated entire solutions that made no sense. The best enablers have rolled out tools that nobody used.

And they’re better for it.

I’ve watched people spend weeks researching the “right” way to set up a workflow. Reading comparisons. Watching tutorials. Waiting for the perfect moment when they understand everything.

Meanwhile, someone else just… starts. Gets it wrong. Fixes it. Gets it wrong differently. Fixes that too. Within a few days, they’ve got working knowledge that the researcher is still reading about.

Harrisberger understood something fundamental: the equipment isn’t the point. The ruining isn’t the point. The experience is the point.

You can’t shortcut your way to understanding. You have to earn it through trial, error, and occasionally explaining to an entire company why nobody can log in this morning.

A thought#

I keep this quote pinned now. Not as a joke, but as a reminder.

Whenever I’m hesitant to try something new. Whenever I catch myself waiting for the “right moment” or the “proper training.” Whenever I feel that familiar pull towards more research, more preparation, more safety.

The right moment is now. The proper training is doing it wrong until you do it right.

The equipment will survive. Mostly. And even when it doesn’t, you’ll come out the other side knowing something you couldn’t have learned any other way.