The Source Code of Broken Systems

A broken process does not warn you on paper. You feel the drag in your gut before you can find the words. It hits like a cross-threaded bolt. No looking away. The cover comes off, the lines are traced and the fault is stripped to the bare metal.

Growing up working class in Nottinghamshire does not teach you soft excuses. It teaches you hard, physical weight.

It started at five years old, holding a yellow screwdriver in both hands while a wooden block rested steady in my grandad's palm.

A screw does not care about good intentions. You set the tip square, bite into the grain and drive it home, or you strip the head and ruin the job. That was the first lesson in how things actually hold together.

Then came frequency and pitch: a silver keyboard on the carpet, then a drum kit and a piano. Dyslexia scrambles flat letters, but rhythm is straight numbers. A beat is a hard count.

In a clean white dobok with a yellow belt tied tight, Taekwondo taught me that holding your ground is not about shouting. It is planting your boots and keeping your balance so solid that pressure breaks against your frame.

Thirty feet up on swinging planks between the pines, fear is just uncalculated weight. You check the wire, test the plank and take the next stride.

For me that language was never pencil drawings or small talk. It was torque, timing, wiring and physical load. Those early years were not separate hobbies. They were the workshop where my brain learned how reality is built.

The edge-case test

A rule written for the typical case looks sound until a capable but atypical case meets it. That is how you find where a process is really weak.

The same engineering got turned on my own life: waste cut, deadweight stripped, and three years of hard study and graft spent building self-sufficiency without leaning on external crutches. It taught me what a system does when someone does not fit its template.

A capable applicant, supplier, driver, patient or customer who does not fit the usual profile shows where the process stops. Who can override it, and whether the override is recorded, shows the rest. A process that handles the edge case by a quiet favour is working through people, not through its design. Every condition meets the same question: what is it for, and does it protect against the risk it was written for?