The Most Dangerous Software You'll Ever Run

The Software Nobody Talks About

One of the more uncomfortable ideas I have been wrestling with recently is this: most of the problems in my life were not caused by bad intentions. They were caused by bad software.

Not software running on my laptop. Software running in my head.

For most of my career, I have made a living building software systems. When software behaves strangely, programmers do not immediately conclude that reality itself has malfunctioned. We assume there is a flaw somewhere in the logic. An assumption is wrong. An input is unexpected. A condition exists that nobody accounted for. Somewhere inside the system, a bug has quietly taken up residence and is now causing chaos while pretending everything is perfectly normal.

Human beings are not all that different.

The software we run is assembled from assumptions, beliefs, mental models and stories about how the world works. Some are useful. Some are inherited. Some were written by experience. Others were written by fear, which is a notoriously unreliable author. The interesting thing is that most of us stop seeing them as software at all. They become so familiar that they vanish into the background. We stop saying, “I believe this,” and start saying, “This is how the world works.”

That transition matters more than it appears. The moment an assumption becomes invisible, it stops being something we examine and becomes something we obey.

The Bug Hidden In Plain Sight

One of the more humbling discoveries of adulthood is that common sense is often nothing more than software that has been running for so long that nobody remembers installing it.

Consider how many assumptions quietly govern our decisions. Failure is embarrassing. Successful people know what they are doing. Money is complicated. Criticism is an attack. I need perfect conditions before I begin. Most of these assumptions do not arrive through careful analysis. They drift into our heads from parents, teachers, friends, social expectations and personal experiences that our minds, with their extreme capacity for delusion, have since promoted to the status of universal law. Some were useful at the time they were installed. Others were nonsense from the very beginning. Unfortunately, software does not become reliable simply because it has been running for a long time.

The trouble is that assumptions disguise themselves as reality. An inaccurate map does not announce that it is inaccurate. It simply guides you confidently in the wrong direction, and with considerable enthusiasm. The same thing happens with mental models. An assumption does not become true because it feels true, because it is popular, or because it arrived from somebody older, smarter or more credentialed. It becomes true when it survives contact with reality.

That distinction sounds obvious. It isn’t. Entire careers, relationships, businesses and political movements have been constructed upon assumptions that nobody bothered to test, which is only slightly less embarrassing than discovering a structural fault in a building after the opening ceremony.

Action Is A Testing Framework For Assumptions

For years I thought learning happened primarily through thinking. Read more books. Gather more information. Consume more ideas. Surely wisdom would emerge from the pile.

Reality disagreed.

The longer I have been programming, creating content, running businesses and generally stumbling through adulthood, the more convinced I have become that action is a testing framework for assumptions. If you believe something is true, perform an action that tests it. Then pay attention to the result.

That sounds embarrassingly simple, which is probably why so few people actually do it. Many assumptions survive not because they are correct, but because they are never tested. They live their entire lives in a comfortable laboratory where reality is never invited inside. They sit in the warm dark of the mind, deeply certain of themselves, never once having to justify their existence to anything as inconvenient as evidence.

I have a personal case study in this. Actually, I have several, but two will do before this thing turns into a memoir with debugging metaphors.

The first involves running. For years I wanted to become a runner, but the idea sat on the list of things I would do once conditions were right, a list that, if I am being honest, was essentially a well-organised retirement home for abandoned ambitions. I needed proper running shoes. I needed the right outfit. I needed the right weather, the right route and the right motivational state. Eventually, out of frustration and mild self-disgust, I went for a run wearing old tennis shoes, a work t-shirt and heavy jeans. It was uncomfortable, undignified and not the sort of thing Nike would put in an advert unless they had been taken hostage by a committee of accountants.

But the run existed, and that was the important part.

That first ugly run invalidated the excuse. I had been using the absence of proper kit as a reason not to start. Reality showed me that the assumption was false. I did not have ideal conditions, but I still showed up. The bug was right there in the code. Almost 15,000 kilometres later, I am still challenging assumptions about running. I would not have lasted this long if I wasn’t.

The second case study involves a camera that was not quite what it claimed to be. When I decided to start making videos, the same software was running. I needed professional equipment. Serious creators had serious cameras, serious lighting and serious microphones. I had a fake Samsung Galaxy S20 Ultra and fluorescent lights that gave the impression of filming inside a hospital corridor. This was not ideal.

I made the video anyway.

The result was hideous. Looking back, the production quality had all the visual elegance of a hostage recording filmed inside a broom cupboard. I exposed myself to the world when I was nowhere near my best, and that ate me up more than I expected. There is a particular kind of discomfort that comes from publishing work you know is not good enough, but that discomfort turned out to be the doorway rather than the warning sign.

Here is what that video gave me: a testing environment.

My next videos were not dramatically better, but I was no longer paralysed. I experimented with talking-head formats, voiceovers, Canva graphics, different editing approaches and filming in daylight. Every attempt generated feedback. Every failure contained information that I could not have accessed by continuing to wait. Close to a hundred videos across different channels later, this part of my journey is still in its infancy, but I cannot afford to stop now because I have seen the power of taking imperfect action at full tilt.

On the other side of every poorly lit video, incoherent first draft and embarrassing early attempt is a collection of lessons. Lessons that compound. Lessons that eventually lead somewhere worth going.

The assumption was wrong. The software required an update.

Reality Is The Ultimate QA Department

One of my favourite observations about software is that bugs do not care about your intentions. The computer does not reward effort. It rewards correctness.

You can spend six hours passionately defending a broken piece of code. You can insist that the design makes sense, argue with colleagues and become emotionally attached to the implementation. None of this matters. The machine remains gloriously indifferent to your feelings, which is deeply inconvenient for everyone involved. Eventually the logs pile up, the outputs refuse to cooperate and the debugger points towards an uncomfortable truth: the bug exists whether you approve of it or not.

Human beings encounter exactly the same phenomenon. The world has a habit of collecting unpaid invoices from bad assumptions. Unfortunately, reality operates more like a loan shark than a bank. It is often willing to wait years before demanding payment.

A poor assumption about money might not hurt you this month. A poor assumption about health might not catch up with you this year. A poor assumption about relationships might survive for a decade before finally collapsing under its own weight. The delay creates the illusion that the software is working. Then one day the bill arrives all at once, and people convince themselves they were unlucky, when in truth they were merely running a bug they had stopped noticing a very long time ago.

This is why reality is the ultimate QA department. Software engineers decide when their code gets tested. Reality performs its tests continuously. Every decision, every conversation, every neglected responsibility and every repeated mistake generates feedback. The testing never stops. The only question is whether we are paying attention to the results.

Why Software Updates Hurt

One of the stranger similarities between computers and people is that neither particularly enjoys being updated.

Software updates arrive carrying an implicit criticism. Somewhere, somebody discovered a flaw in the current version. A vulnerability has been exposed. A limitation has been identified. Something needs to change. Human beings react to this in much the same way, except we usually add more ego, more self-deception and a small internal legal team dedicated to proving that we were right all along.

Every time reality disproves one of our assumptions, it presents us with a software update. The update itself is rarely the difficult part. The difficult part is accepting that the previous version was wrong.

That is where pride enters the conversation.

Most people claim they want truth. What they usually want is confirmation. Confirmation tells us that we were right all along. Truth is less polite. Truth walks into the room, points at the bug and refuses to leave until somebody acknowledges it. This is why genuine growth often feels humiliating before it feels liberating. Every meaningful software update begins with a sentence that nobody enjoys saying:

“I was wrong.”

Not misunderstood. Not misrepresented. Wrong.

Reality presents the evidence. The update becomes available. The installation prompt appears, and many of us click Remind Me Later for months, years, sometimes entire decades, all while wondering why the system keeps behaving strangely.

Intelligence Is Not The Same Thing As Accuracy

The older I get, the less convinced I am that intelligence is the determining factor in good decision-making.

I have met highly intelligent people running spectacularly bad software. People capable of discussing economics, philosophy, politics and science in remarkable detail, yet somehow incapable of examining the assumptions governing their own lives. Their cognitive acuity is not in question. Their relationship with reality is another matter entirely.

I have also met remarkably ordinary people running surprisingly good software. They make sensible decisions not because they are brilliant, but because they have cultivated an honest relationship with feedback. They listen carefully. They update when the evidence changes. They do not treat being wrong as a threat to their identity.

The difference is rarely intelligence. It is usually whether a person can tolerate being wrong.

A brilliant person running faulty software can still produce terrible outcomes. Reality does not grade people on intellectual horsepower. It grades them on results. If you are too proud of what you know, or too attached to how good you think you are, you will learn less, make inferior decisions and fall short of your potential. Ray Dalio built much of his philosophy around dragging problems and disagreements into the open so better decisions could be made. Most organisations find that principle deeply uncomfortable. Most people do too.

Which is unfortunate, because feedback is not an insult. It is information with a bad bedside manner.

Solitude And Signal Detection

This is one reason I have grown increasingly suspicious of constant distraction.

Modern life provides a practically inexhaustible supply of opportunities to avoid examining ourselves. Every spare moment can be filled with information, entertainment, outrage, commentary, notifications or somebody else’s opinion. We are surrounded by an incessant avalanche of sound, most of it clamouring for attention while offering very little nourishment. The result is that many people spend their lives downloading information and very little time processing it.

Some of the most important software updates I have ever received arrived during long walks, long runs and periods of solitude. Not because solitude is magical, but because it removes enough noise for reality to become audible again. The world is remarkably good at telling us where our assumptions are failing. The problem is that the signal is often faint, and it is difficult to hear error messages while surrounded by noise.

If your attention is permanently occupied, there is very little opportunity to inspect the software you are running. Sometimes the most productive thing you can do is sit quietly long enough for reality to finish its sentence.

Debugging The Source Code

The longer I live, the more I suspect that self-improvement has less to do with accumulating knowledge and more to do with identifying bad assumptions.

People often imagine growth as accumulation. More books. More skills. More information. More answers. More productivity systems. More frameworks. More acronyms invented by somebody trying to sell a course while standing in front of a bookshelf arranged by colour. Sometimes growth looks like the opposite. Sometimes growth is simply the removal of a bug.

You realise that an assumption you have carried for years is no longer supported by reality. The software changes. The decisions change. The outcomes change. Everything else follows.

This is why I have become increasingly interested in reflection. Not because reflection is pleasant, because quite often it is not. Reflection is debugging. It is the deliberate process of examining the assumptions generating the outputs in your life.

When software behaves strangely, programmers inspect the logic. When life behaves strangely, many people inspect everything except the logic. They blame luck, politics, the economy, their boss, their parents, the algorithm, Mercury being in retrograde, or whatever explanation happens to be fashionable this week. Occasionally those things are the problem. Often they are not.

Often the bug is much closer to home.

The Most Dangerous Software You'll Ever Run

The most dangerous software you will ever run is not Windows, Linux, Android or iOS. It is the collection of assumptions you carry through life without ever testing against reality.

The assumptions you inherited. The assumptions you absorbed. The assumptions you stopped noticing.

Broken software on your laptop might cost you a day’s work. Broken software in your head can cost you years: a relationship, a career, a business, a future you never build because you kept repainting the ambulance instead of fixing the wound.

Every human being is running software. The question is not whether you have mental models. The question is whether those mental models accurately describe reality.

If they do, reality becomes an ally. If they do not, reality eventually sends an error message.

The fortunate people are not the ones who never discover bugs. They are the ones willing to investigate them. To run the ugly first version. To publish the hideous video. To go out in the jeans and the battered tennis shoes when the alternative is standing still.

And if they are lucky, they discover the bug before reality sends the invoice.