The Things I Wasn’t Supposed to Break

I never really learned best by sitting still and being told what to remember. That probably sounds like a neat personal brand sentence now, but growing up it was mostly inconvenient. The traditional way of learning always felt too clean for the way my brain worked. I did not want to accept the finished explanation first. I wanted to touch the thing, open it, test it, break it, and then understand why it behaved the way it did.

The first thing I remember taking apart was a Nintendo that my parents had been saving to buy me for Christmas. To them, it was a gift. To me, it was a mystery held together with screws. I wanted to know what was inside it and how it worked. Looking back, I imagine that was probably not the surprise they had in mind.

When my dad brought home a radio, a video cassette player, or some other bit of electronics, I saw two things at once. Everyone else saw the object. I saw the object and the question inside it. What happens if I open this? What connects to what? Why does this tiny part matter? Could I take it apart and put it back together again?

Sometimes the answer was yes. Sometimes the answer was technically yes, but with one screw left over and a suspicious rattle. Sometimes the answer was absolutely not, and I had to admit I had turned a working thing into an educational corpse.

Learning this way was not always painless. I gave myself the occasional electric shock by touching something I should not have. I stabbed my hand with a screwdriver more than once because I was in too much of a hurry or holding something the wrong way. Looking back, those were my learning scars. Small reminders that curiosity is valuable, but so is respecting the thing you are trying to understand.

Still, every version taught me something. I fixed things people thought were finished. I also broke things people assumed were unbreakable. Both were useful teachers, just with different levels of domestic diplomacy required afterwards.

The screw left over at the end used to annoy me. It was proof that I had missed something. A small metal receipt for incomplete understanding. That one screw could be the little thing holding everything together, or it could become the rattle that eventually shorts the whole device.

Over time, that changed. The leftover screw became a signal. It meant there was a part of the system I had not mapped yet. Something had gone back together well enough to look fixed, but not honestly enough to be understood.

There is a version of fixing where you make the obvious problem disappear and move on. The light turns on again. The error goes away. The machine starts. Fine. Useful. Necessary sometimes.

But that has never been enough for me. I want to know why it broke in the first place. I want to know what condition made the failure possible, what signal was ignored, what design made the mistake easy, and what would stop the same thing coming back next week wearing a different hat.

Looking back, I do not think I was obsessed with electronics. I was obsessed with systems. The Nintendo, the radio, the cassette player, they were simply the first systems I could hold in my hands. Years later I realised I was chasing the same thing in software, websites, automations, business processes, and just about everything else.

Taking things apart taught me that most systems are less magical once you can see their layers. A radio is not just a radio. It is casing, screws, board, wires, signal, power, speaker, failure points, tolerances, dust, age, and human assumptions. Code is the same, just less dusty and more smug about it.

When something fails, it usually fails through a chain. The visible symptom is rarely the whole story. The button does not work because the switch is bad, or the wire is loose, or the power is unstable, or the casing is pressing on something, or someone before you forced it closed and called it done.

That is the part I enjoy. Not the breaking itself, but the trail. The moment where the problem stops being a wall and becomes a map.

That habit followed me into everything else: daily tasks, systems, automations, websites, software, support problems, business processes. I do not like saying, “There, it is fixed,” and leaving the room like a magician with a screwdriver. I would rather explain what failed, why it failed, and what should happen differently next time.

Software development clicked for me when I stopped treating code like something sacred and started treating it like another machine on the bench. Open it. Change it. Run it. Break it. Read the error. Put it back together. Break it again, but in a more interesting way.

That is how I have been teaching myself. Not by pretending I have a perfect curriculum, but by collecting small pieces of understanding and forcing them to connect. I have too many little snippets, experiments, half solved problems, tiny automations, broken prototypes, and notes that looked useless until they suddenly became the missing part of something bigger.

One snippet on its own is rarely impressive. A function here, a script there, a fix for an API response, a small automation, a weird edge case, a lesson from some error message that ruined an afternoon. But when those pieces start to fit together, they become useful. That is the bit I care about. Not just having knowledge, but being able to assemble it under pressure.

The important part is not that I always know the answer. I usually do not. The important part is that I am comfortable staying inside the problem long enough to understand its shape.

• Fix the visible issue, but keep looking for the condition that made it possible.
• Explain the cause clearly enough that the next person is less dependent on guesswork.
• Turn the lesson into a prevention step, not just a finished ticket.

That does not mean turning every fix into a lecture. Nobody needs a TED Talk because a form field was misconfigured. But good work should leave people less dependent, not more confused. If I can explain the issue clearly, I probably understand it. If I cannot, I probably only patched the symptom.

There is also a confidence that comes from learning this way. Once you have broken enough things and put them back together, the unknown becomes less intimidating. New tools, new frameworks, new errors, new systems. They all start with the same question: what is this made of?

The trick is knowing when to be careful. Breaking things on purpose is not the same as being careless. It means creating a safe space to test assumptions. It means making backups, using drafts, working in branches, checking what changed, and respecting the cost of failure. Curiosity is useful. Recklessness just creates admin.

The messy middle is where most of the learning lives. The part where the tutorial no longer matches your screen. The part where the fix creates another problem. The part where one screw is still sitting on the desk judging you.

That is where I have learned the most. Not from the perfect first attempt, because those do not teach much. From the third attempt, when I finally understand why the first two were wrong. From the moment the system stops being mysterious and starts becoming familiar.

So yes, I learn by breaking things on purpose. I always have. Radios, cassette players, little bits of hardware, code, workflows, ideas. But the breaking was never the point. The point was learning how things hold together.

And if there is still a screw left over, good. That means there is another lesson waiting.