Science usually starts with a simple itch: curiosity. It’s that moment where we just want to know something. But simply wanting to know isn’t enough. Scientific thinking is the specific discipline of channeling that raw curiosity into a structure that produces reliable, load-bearing knowledge. It is the operating system we use to figure out new things about life, the universe, and everything else.

To understand why this specific “operating system” is necessary, we have to look at the relationship between three heavy concepts: Reality, Truth, and Knowledge. It sounds straightforward, but it gets messy immediately. For science to work, we generally have to assume that there is a stable, secured Reality out there and that there is a specific Truth about that reality that we can discover. That seems like an acceptable baseline. However, we have to acknowledge that this is an assumption. We could, theoretically, be living in a computer simulation. If we are, the term “Reality” becomes completely meaningless, and “Truth” becomes something else entirely. This isn’t just high-grade philosophical weed-talk; philosopher Nick Bostrom formalized this in 2003 with his paper Are you living in a computer simulation?, and modern physics actually grapples with similar questions constantly.

But let’s put the simulation theory on the back burner for a moment. Even if we assume there is a single, physical reality, we run into a massive problem: Can we actually know the truth about it? If truth is unreachable, why do we assume reality exists at all? Before we get lost in epistemology, we need to audit the only tool we have for observing this reality: the human brain.

The Conjecture: Our Hardware is Compromised

To test our ability to observe reality, we are going to run three experiments. A good experiment starts with a conjecture — a guess about what will happen. Our conjecture for this entire section is this: Our perception and our thinking are not capable of conveying reliable information about the world.

For the purposes of this discussion, we aren’t drawing a sharp line between “perception” (the sensory input) and “thinking” (the processing). Whether the error happens in the eye or the cortex doesn’t matter; we are interested in the reliability of the system as a whole. This aligns with the “Critical Thinking” models where we treat the human cognitive stack as a single, often flawed, unit.

Experiment 1: The Blind Spot

Let’s look at the human eye. It is, frankly, a bit of a design disaster. In humans, the nerve fibers run in front of the retina. For those nerves to exit the eye and travel to the brain, they have to punch a hole through the retina. Where that hole exists, there are no photoreceptors. No rods, no cones, nothing. This is the blind spot. It is a structural failure in our vision. Interestingly, this wasn’t inevitable; cephalopods (like octopuses) have nerve fibers running behind the retina, meaning they have no blind spot and get better light throughput. We got the short end of the evolutionary stick here.

You can verify this glitch right now. Imagine a black dot and a black “X” on a piece of paper, separated by about 10 centimeters. If you close your left eye and stare directly at the dot with your right eye, the “X” is in your peripheral vision. If you move your head back and forth — usually finding the sweet spot around 20 centimeters away — the “X” will suddenly vanish. It is gone. The image of the “X” is hitting exactly where your optic nerve punches through the retina.

But here is where it gets terrifying. Keep staring at the dot. Don’t look away. Try to perceive what is in the empty space where the “X” used to be. You do not see a black void. You do not see a hole. If the background is white, you see white. If you run this experiment on a page full of text, replacing the “X” with a word, something even stranger happens. When the word hits your blind spot, you don’t just see a gap. Your brain fills it in with “text.” It is blurry, unreadable, and logically invalid text, but your brain generates the texture of writing to patch the hole.

This is a biological version of the “Content-Aware Fill” or “Inpainting” found in modern image editing software. Your brain knows there is no data there, but it refuses to show you the lack of data. It constructs a lie — a plausible texture — and presents it to you as reality. You are seeing something that you know, with 100% certainty, does not exist.

Experiment 2: The Checker Shadow Illusion

We can dismiss the blind spot as a mechanical error, but the processing errors are worse. Consider the famous Checker Shadow Illusion published by neuroscientist Edward Adelson in 1995. The image depicts a 3D checkerboard with light and dark squares, with a green cylinder casting a shadow over the board. There is a dark square outside the shadow labeled “A” and a light square inside the shadow labeled “B”.

Here is the kicker: Square A and Square B are exactly the same shade of grey. If you use a color picker tool or physically print it out and fold the paper to touch them together, they are identical pixel values.

But you cannot see it. No matter how hard you concentrate, your brain refuses to let you see them as the same color. This happens because your visual system is not a physical light meter. Its job is not to report the raw data of photons hitting the retina. Its job is to break image information down into meaningful components to identify objects. Your brain sees the shadow, understands how shadows work (they darken surfaces), and automatically “brightens” the interpretation of square B to help you identify it as a “light check” on the board.

Adelson argues this demonstrates the success of the visual system, not its failure, because it allows us to identify objects regardless of lighting conditions. But for a scientist trying to observe raw data? It is a catastrophic failure. Our thinking refuses to acknowledge the truth (that the grey values are equal) in favor of a useful story (that one is a white square in a shadow). We are incapable of visually verifying the truth.

Experiment 3: The Rubber Hand Illusion

If vision is unreliable, surely we can trust our own bodies? Enter the Rubber Hand Illusion. In this experiment, a participant sits with their real hand hidden behind a screen. A fake, often crude, rubber hand is placed on the table in front of them. The experimenter then strokes both the hidden real hand and the visible rubber hand simultaneously with a brush.

After a short period of synchronous stroking, the participant experiences proprioceptive drift. Their sense of body ownership shifts. They start to “feel” the brush on the rubber hand. The brain decides that the visual input (seeing the rubber hand being touched) is more important than the proprioceptive data (knowing where your real hand is).

This works even if the rubber hand doesn’t look particularly realistic. If the experimenter suddenly smashes the rubber hand with a hammer, the participant will flinch in genuine fear. We can trick the fundamental sense of “self” and body location with a few cheap parlor tricks. Our rational mind knows it is plastic, but our sensory processing overrides that knowledge completely.

The Evolutionary Trap: The Cognitive Miser

Let’s return to our conjecture: “Our perception and thinking are not capable of conveying reliable information about the world.” None of these experiments disproved this. In fact, they confirmed it. Our hardware is untrustworthy.

But the most damning realization is that our rational thinking cannot override these errors. Even when you know the “X” is there, you can’t see it. Even when you know the squares are the same grey, they look different. Even when you know the hand is rubber, you feel it.

Why are we built this way? Because our thinking is the result of millions of years of evolution, and evolution does not care about “Truth.” Evolution cares about “Survival.” For the vast majority of our history, knowing the exact hex-code value of a grey pixel didn’t matter. Recognizing a pattern quickly — identifying a tiger in the shadows — mattered.

We are designed to project Meaning (Sinn) onto the world. We are storytelling engines, constantly connecting dots to create a coherent narrative. We discussed this in Critical Thinking under the concept of the “Cognitive Miser.” As Richerson & Boyd noted in 2005: “In effect, all animals are under stringent selection pressure to be as stupid as they can get away with.” Processing power is expensive (calories), so the brain takes shortcuts. It biases towards meaning and speed, not accuracy.

The Truth-Meaning Gap

This creates a “Meaning-Truth Scissors” — a divergence between what feels true (Meaning) and what is factually true (Truth). The brain’s strategy of projecting sense onto the world is so dominant that it interferes with our ability to observe the world as it actually is.

This leads us to the Big Idea — the “OG” concept of scientific thinking:

If we want to learn anything about the real world, we must radically distrust our senses. We cannot just be “careful.” We cannot just “double-check.” We have to operate on the assumption that our perception is actively lying to us. Nothing our senses tell us can be accepted as reliable data until it has been stripped of human interpretation.

Science, therefore, isn’t just a collection of smart people looking at things. It is a rigorous methodology designed to bypass the human brain’s inherent inability to see the truth.

Next up: We travel back in time to see how Francis Bacon and a few forgotten global thinkers fought to build a system that could bypass these biological glitches.

Part 2: Deconstructing the Narrative (History, Alchemy, and the Real Roots of Reason)

We established in the previous section that your brain is a survival engine, not a truth engine. If we want to get anywhere near objective reality, we need a system that assumes our senses are compromised. This realization didn’t happen overnight, and it wasn’t the product of a single “Eureka” moment. It was a slow, messy, and often politically dangerous evolution of thought.

To understand where our modern scientific operating system comes from, we have to look at the people who first started documenting the glitches in the human mind.

The Four Idols of the Mind (Sir Francis Bacon)

In 1620, Francis Bacon published Novum Organum (The New Instrument), essentially a user manual for bypassing human stupidity. Bacon identified four specific “Idols” — systematic errors or illusions — that prevent us from seeing the truth. These aren’t physical statues; they are categories of cognitive failure.

First, he identified the Idola Tribus (Idols of the Tribe). This refers to the errors inherent to human nature itself. This is exactly what we covered in Part 1: the biological limitations of our senses, our tendency to find patterns where none exist, and our evolutionary baggage. These are the bugs hardcoded into the firmware of the human species.

Second are the Idola Specus (Idols of the Cave). These are the errors specific to the individual. We all grow up in a “cave” — our specific culture, upbringing, education, and reading habits. This personal context filters the light of reality, meaning no two people see the world exactly the same way because they are looking out from different caves.

Third, and perhaps most insidious, are the Idola Fori (Idols of the Market). This refers to the “Marketplace of Ideas,” or language itself. We use words to describe the world, but language is imprecise, loaded, and often defined by the masses, not the experts. We get trapped by definitions and semantics, arguing over words rather than the reality those words are supposed to represent. The framework of our language limits the framework of our thinking.

Finally, the Idola Theatri (Idols of the Theater). These are the dogmas and received systems of philosophy. Bacon called them this because he viewed previous philosophical systems (like Aristotelian logic) as stage plays — artificial worlds created for entertainment or comfort that have no bearing on reality. It is the tendency to accept established academic or scientific authority without question, creating a resistance to fundamentally new ideas.

It is worth noting that while Bacon’s ideas were revolutionary, the man himself was … complicated. By all historical accounts, he was a fairly nasty piece of work. As Lord Chancellor, he justified corruption, was bribable himself, operated as a ruthless opportunist, and was generally disliked. But even a corrupt opportunist can spot a system failure. Bacon proposed a new method to escape these Idols: rather than testing assumptions until they are confirmed (confirmation bias), we should draw well-founded conclusions from experimental data. He explicitly argued for focusing on negative instances — evidence that disproves a theory — because that is where the real information hides. He rejected the Church’s stance that “all knowledge is already in the Bible” and demanded work that was systematic (repeatable), empirical (observation-based), and inductive.

The Cartesian Cleanroom

Around the same time, in 1632, René Descartes took a slightly different but equally radical approach. He published Discours de la méthode (Discourse on the Method), proposing a universal way to search for truth. If Bacon was about empirical data, Descartes was about rigorous logical hygiene.

His method was simple but brutal: accept nothing as true unless you can verify it yourself through analysis and logical reflection. He demanded rigorous deduction — deriving conclusions only from facts that are already proven — and championed mathematics as the only language reliable enough to formulate these insights. Mathematics, unlike spoken language (Bacon’s Idola Fori), leaves little room for ambiguity.

The full title of his work is Discourse on the Method of Rightly Conducting One’s Reason and of Seeking Truth in the Sciences. Interestingly, Descartes published this anonymously in Leiden, Netherlands. Why hide his name? Because in 1632, claiming you had a new method for finding truth that bypassed the Church was a good way to get in serious trouble. He was navigating a minefield of authority.

Alchemy: The Introverted Cousin of Science

We often have a cartoonish view of the era preceding this “Scientific Revolution.” We imagine Alchemists as crazy wizards trying to turn lead into gold or finding the Philosopher’s Stone. This is a massive distortion. Alchemy was proto-science.

Alchemists were doing the heavy lifting of material science long before we had a periodic table. European alchemists (re)discovered porcelain and gunpowder. Isaac Newton, arguably the poster child of the scientific revolution, considered himself an alchemist and wrote extensively on the subject using terms like “spirits” and “active principles.”

The problem with Alchemy wasn’t the intelligence of the people involved; it was the protocol. Alchemy was obsessed with secrecy. The motivation wasn’t public knowledge; it was private gain (gold, immortality, weaponizable powder). Therefore, alchemists worked in code, hid their findings, and never shared their data.

This secrecy was fatal to progress. Because no one shared their lab notes, no one could learn from anyone else’s mistakes. Every alchemist had to start from scratch, committing the same errors over and over again. Science, as we define it today, only began when we inverted this dynamic. The shift from “Knowledge is Power (so hide it)” to “Knowledge is Progress (so share it)” was the critical software update.

The Great Whitewashing: It Wasn’t Just Europe

We love to tell the story that Europe “invented” science, drawing a straight line from the ancient Greeks to Bacon and Descartes. This is a fabrication of history. The sparks that ignited the scientific revolution didn’t just fly in London and Paris; they were burning globally for centuries. The European narrative is the result of selective forgetting and, frankly, imperialist history writing.

Consider Ibn Rushd (1130–1198), a Cordoban scholar who argued that men and women possessed equal intellect and should have equal rights — a radical idea for the 12th century. He also argued that a concept could not be theologically true but philosophically false (and vice versa), laying the groundwork for separating faith from reason.

Then there is Al-Haytham (965–1040) from Cairo. If anyone deserves the title of “Father of the Scientific Method,” it is him. Centuries before Bacon’s Novum Organum, Al-Haytham was running systematic experiments and formulating theories. He explicitly warned against the Idols of authority long before Bacon gave them a name. In his writings, he stated that the seeker of truth is not the one who trusts the writings of the ancients, but the one who “suspects his faith in them” and “attacks [the text] from every side.” He argued that to find the truth, one must make oneself an enemy of everything one reads.

Perhaps most striking is the story of Zera Yacob (1599–1693), an Ethiopian philosopher. Working from a cave in Ethiopia between 1630 and 1632 (exact contemporaries with Descartes), he developed a rationalist philosophy that mirrored the best of the European Enlightenment. He argued for the supremacy of reason, the equality of all humans (male and female), and the evil of slavery, and he critiqued established religions. He did this in isolation, far from the European salons.

Why do we not know these names? As historian Dag Herbjørnsrud points out, the “Age of Reason” in Europe coincided with an age of brutal imperialism. The West didn’t win the world because its ideas were superior; it won because it was superior at organized violence. To justify colonization, the narrative of “Reason” became racially coded. The contributions of Africa and Asia were systematically erased to support the idea that rational thought was a uniquely white, European trait. This “closing of the European mind” in the 18th century cemented the false history we are often taught today.

The Hardware Upgrade: The Printing Press & The Fight for Doubt

The final piece of the puzzle was a technological disruption: the Printing Press. Before print, knowledge was expensive and controlled. The Church and the State decided what was copied. The printing press broke this monopoly. It allowed for the dissemination of not just holy texts, but any text.

This sparked a rebellion. In the mid-17th century, the first scientific societies (like the Royal Society in the UK and the French Academy of Sciences) were founded. These were essentially unions of researchers rebelling against their patrons. They argued that the goal should be advancing science through exchange, not just satisfying the whims of a funding lord. It was similar to the founding of “United Artists” in 1919, where filmmakers unionized to take control back from the studios.

This era defined the First Pillar of Science: Doubt.

Previously, Truth was the property of authority. If the Pope or the King said it, it was true. Questioning it was treason or heresy. Think of Galileo and Kepler, who were harassed and punished for doubting the geocentric model. But the printing press made doubt resilient. You couldn’t burn all the books if they were being printed faster than you could find them. A scene developed of mobile printing presses — literally printing banned books on ships to evade jurisdiction — using censorship lists as market research to see what people wanted to read.

This solidified the rule: Everything may be doubted.

This is not easy. Doubt is uncomfortable. In a pragmatic sense, you can’t doubt everything all the time (you wouldn’t get a rocket to the moon if you spent every meeting debating if the earth is flat). But in principle, nothing is off-limits. Religions often ban doubt; authoritarian regimes criminalize it; conspiracy theorists weaponize it (doubting the mainstream to enforce their own dogma). But in science, doubt is the engine. It is the refusal to accept “because I said so” as a valid argument.

Next up: We break down the engine itself — how we took this philosophy of doubt and turned it into the rigorous, error-checking machine we call the Scientific Method.

Part 3: The Engine of Truth (The Method, Hypotheses, and the Causality Trap)

We established in the previous sections that our brains are glitchy survival engines and that we need a culture of doubt to bypass authoritarian control. Now, we have to build the machine itself. To operationalize that doubt, early scientists — building on the legacy of Bacon and Descartes — formalized a specific set of heuristics to keep us honest.

The first move was to replace our biological senses with instruments. Since we cannot trust our eyes to judge brightness or our skin to judge temperature objectively, we build devices like thermometers, photometers, and rulers. These tools don’t hallucinate, though they aren’t magic; they are built by humans and can reflect human bias. The polygraph, or lie detector, is a perfect example of a broken instrument. It measures biological stress (sweat, heart rate), which has no proven correlation with truth-telling. It measures anxiety, not lies, yet we often treat the needle on the chart as an oracle.

We also shifted our language. Spoken languages are messy and loaded with cultural baggage — Bacon’s Idols of the Market. To escape this, science adopted mathematics as its core language. Math expresses very little in terms of emotion or nuance, but what it does express, it expresses without ambiguity. Finally, we agreed on a hierarchy of argument where measurable data and verified facts sit at the top, displacing opinion and authority.

Defining the Indefinable

Before we break down the mechanics, we need a working definition of what we are actually doing. Science is best defined as the continuous process of describing the world in our symbolic representations — be that language, math, or code — such that the description withstands every critical examination.

It is critical to understand that science is not a static list of facts or a dusty encyclopedia. It is the act of refining a description until you can no longer poke holes in it. It is also not a belief system. Religion seeks salvation; science seeks insight. As the Science Busters motto puts it, science is what holds true even if you don’t believe in it. To navigate this, philosophers use three specific coordinates. We ask what exists (Ontology), what we can actually know about it (Epistemology), and what that means for our values and ethics (Axiology).

The Four Archetypes of the Method

To understand how this abstract definition hits the pavement, we can look at four historical examples that defined the “Classical Scientific Method.”

First, consider John Snow during the 1854 London cholera outbreak. While the city was dying and officials blamed “miasma” (bad air), Snow suspected the water supply. He didn’t just argue; he visualized. He took a map of SoHo and plotted a black bar for every death at a specific address. The visualization revealed a clustering of death around a single point: the water pump on Broadwick Street. He used this data to convince officials to remove the pump handle, stopping the outbreak. It was later confirmed a cesspit was leaking into the well. Snow used data visualization to make a hypothesis actionable.

Second, we have Isaac Newton. Still operating with the mindset of an alchemist, Newton was the first to model a physical force mathematically. He stood on the shoulders of Galileo, who had hypothesized that objects of different masses fall at the same speed if you ignore air resistance. This was visually proven centuries later during the Apollo 15 mission, when Commander David Scott dropped a geological hammer and a falcon feather on the airless lunar surface. They hit the dust at the exact same instant. Newton took this physical reality and encoded it into math that allowed us to predict planetary movement without interpretive wiggle room.

Third is Fitts’s Law, a cornerstone of Human-Computer Interaction established by psychologist Paul Fitts in 1954. He mathematically modeled human movement, discovering that the time required to move a pointer to a target is a function of the distance to the target divided by the size of the target. This is why the “OK” button on your software interface is usually large, and why the corners of your screen are considered “infinite width” targets because you can’t overshoot them with a mouse. It is a biological truth encoded into a formula ($ID = \log_2(2D/W)$).

Finally, Alan Turing proposed the “Imitation Game” in 1950 to handle the slippery definition of artificial intelligence. Since “intelligence” is hard to ontologically define, he operationalized it: if a machine can trick a human into thinking it is human via text chat, it passes. While we now know this test is flawed — ChatGPT can pass it without possessing understanding — it was a crucial attempt to turn a philosophical question into an experimental procedure.

The Algorithm: The Classical Scientific Method

These examples reveal a specific loop which forms the second pillar of science: Systematic Procedure. The loop generally flows from observation to speculation, then to the formulation of a hypothesis, followed by an experiment, and finally a conclusion where the hypothesis is either accepted or rejected.

The Hypothesis is the critical firewall in this process. It stops us from simply telling stories about what we see. A scientific hypothesis is an inductive leap — a grounded guess that we assume is true until proven otherwise. However, not every statement qualifies. A hypothesis must be testable. Saying “There is an invisible entity controlling the universe” is a bad hypothesis because it cannot be tested. Saying “Cholera is caused by this specific water pump” is a good hypothesis because you can test it by removing the pump handle.

In statistics, we often use the Null Hypothesis ($H_0$), which effectively assumes “innocence until proven guilty.” The Null Hypothesis states that there is no connection between two variables — for example, that video games do not cause violence. We hold this as true until the data overwhelmingly forces us to reject it. In the specific case of video games and violence, meta-studies by researchers like Prescott, Sargent, and Hull suggest we might technically reject the Null Hypothesis, but the effect size is so tiny compared to other factors that it is practically negligible.

There is a “dirty secret” here. The second step of the method — speculation and hypothesis generation — is the only part of science we don’t know how to automate. It requires intuition and creativity. It is the one moment where creative thinking is the dominant force in the rigorous scientific process.

Falsifiability and the Experiment

Once a hypothesis is set, we run into the harsh reality of logic introduced by philosopher Karl Popper. Popper argued that you can never prove a theory is true; you can only prove it is false. This concept is called Falsifiability. No matter how many white swans you see, you have not proven the statement “All swans are white.” But seeing a single black swan definitively proves the statement false. Therefore, science isn’t a collection of truths; it is a collection of statements that haven’t been proven wrong yet.

To try and falsify our hypotheses, we run experiments where we manipulate reality. We identify an Independent Variable (the thing we change, like a game version) and measure a Dependent Variable (the result, like a player’s heart rate). Crucially, we must hold everything else constant as Control Variables. If you change the game version and the age of the test subject at the same time, the experiment is ruined. You can no longer tell which variable caused the change in heart rate. This seems like basic hygiene, yet it is a frequent point of failure in research.

The Trap: Correlation vs. Causation

Interpreting experimental data brings us to the most common glitch in human reasoning: confusing correlation with causation. Correlation describes a mathematical relationship where two values move together. Causation means one thing actually triggers the other.

Our brains love to assume causation. If the temperature of a heater goes up, the room temperature goes up; that is causal. But often, the world offers us Spurious Correlations. Tyler Vigen created a famous website demonstrating this by graphing variables that match perfectly but have no connection. For instance, the graph showing the distance of Jupiter from the Sun matches the graph showing the number of administrative assistants in Alaska almost perfectly. The math says they are related; reality says that is nonsense.

A more subtle example is the Uncanny Valley. In 1970, Masahiro Mori hypothesized that as robots become more human-like, our empathy increases, until they get too close and we feel revulsion. For decades, this was just a correlation based on observation. It wasn’t until 2016 that researchers began to experimentally prove the causality behind it, linking it to categorization failure in the brain. Until that causal link is forged, a correlation is just a coincidence waiting to be debunked.

Theory: The Holy Grail

When a hypothesis survives enough attempts to kill it, it graduates to a Theory. A theory is a consolidated explanation of a slice of reality. A good theory, like Einstein’s Theory of Relativity, solves open questions and predicts things we haven’t seen yet — like black holes — without falling apart under testing.

But theories can also be traps. In the late 19th century, the accepted theory of aerodynamics suggested that heavier-than-air flight was effectively impossible or impractical. This was a “bad theory,” but it was socially accepted. The Wright Brothers succeeded because they chose to actively doubt the theory. They built their own wind tunnel, generated their own data, and ignored the scientific consensus. Theories are cognitive artifacts that let us think new thoughts, but they are also social artifacts. If the Wright Brothers hadn’t flown, the bad theory of aerodynamics might have persisted for another fifty years simply because the experts agreed on it.

Next up: We enter the messy world of “Paradigms” — why the rules of science change depending on whether you are studying an iron cube or a group of nuns.

Part 4: Whose Truth Is It Anyway? (Paradigms, Bias, and the Limits of Objectivity)

We have built the machine (the Scientific Method), but now we have to decide where to point it. This brings us to the concept of Paradigms. A paradigm is essentially a framework of beliefs and assumptions that defines how we look at the world. It dictates what questions we are allowed to ask and what kind of answers we accept as valid.

The scientific revolution ushered in the age of Modernism. This was the era of the Industrial Revolution, where we began to view the world as an objective, measurable reality and ourselves as rational, complex machines. It birthed a kind of “techno-solutionism” — the belief that any problem, no matter how human, could be solved with enough engineering. You can see this optimism in the art of the time, like Italian Futurism, which worshipped speed and machinery. But you also see the anxiety in early science fiction. H.G. Wells and Aldous Huxley wrote warnings, but the most striking was perhaps Yevgeny Zamyatin’s 1920 novel We, which depicted a dystopian world ruled entirely by cold mathematical logic.

The Reign of Positivism

The dominant operating system of Modernism was Positivism. This view holds that the world exists entirely independently of us. It is out there, solid and separate. Therefore, knowledge can only be derived from actual, verifiable phenomena. In its most radical form, Positivism assumes that everything in reality can be described mathematically.

This works incredibly well for physics. If you want to study an iron cube, Positivism is your friend. You can measure its weight, density, and temperature. The cube doesn’t care that you are measuring it, and your feelings about the cube don’t change its mass. But this approach hits a wall when you try to study a human brain or a society. As researchers Paley and Litford argued in 2011, reality isn’t actually fragmented into variables; variables are just things we invented to measure reality. When we reduce a human being to a set of numbers, we are making a choice to leave things out.

The Blind Spot of Objectivity: The Viking Warrior

The failure of strict Positivism becomes obvious when we look at how “objective” scientists handle history. In 1878, archaeologists in Sweden found a Viking grave (Bj 581) in Birka. The grave was loaded with weapons and gaming pieces, which indicated high tactical and military rank. The scientific consensus was immediate and absolute: this was a high-ranking male warrior. For over a century, this was the “truth.”

It wasn’t until 2017 that a genomic analysis revealed the skeleton was XX. Female. The scientific community had been looking at a skeleton with wide hips, but because their internal paradigm said “Warriors are Men,” they literally couldn’t see the biological data in front of them. They assumed the weapons were ceremonial or heirlooms. Positivism claimed to be value-free, but it had no mechanism to account for the sexist bias of the researchers. The Axiology (values) of Positivism says “values don’t matter,” which ironically allows the researcher’s values to contaminate the data unchecked.

Post-Positivism: The “Yes, But” Approach

As the cracks in Positivism showed, we moved toward Post-Positivism. This framework accepts that an objective reality exists, but admits we can never see it perfectly. It relies heavily on Karl Popper’s insight that observation is always selective. You cannot just “observe”; you always observe something based on your interests and theories.

Post-Positivism trades certainty for probability. It dominates fields like medicine and experimental psychology. A great example of why this is necessary is the study of eHealth systems. Researchers Greenhalgh and Russell (2010) found that digital health tools often worked perfectly in controlled trials (the Positivist “Lab” view) but failed miserably in real hospitals. The chaotic reality of a hospital introduced variables that the “clean” science had stripped away. Post-Positivism tries to account for this context, admitting that while the truth is out there, we are looking at it through a foggy window.

Critical Theory: It’s All About Power

If Post-Positivism is an update to the old system, Critical Theory is a jailbreak. This paradigm isn’t interested in just describing the world; it wants to know why the world is the way it is, usually focusing on power structures. It argues that science is never neutral. As early computer scientist Joe Weizenbaum pointed out, the choice of which questions we ask is itself a value judgment.

In this view, knowledge is “co-constructed” between the researcher and the participant. A classic example is the “Prayer Companion” designed by Bill Gaver. Instead of just building a “user-friendly” device for nuns, the team investigated the specific spiritual needs of a convent. The device scrolled news headlines so the nuns could direct their prayers toward current world suffering. A Positivist might ask “Is the device efficient?” Critical Theory asks “Does this device empower the nuns within their specific cultural context?”

Constructivism: Reality is a Gentleman’s Agreement

Finally, we have Constructivism. This paradigm argues that much of what we consider “reality” is just a social agreement. An iron cube is real, but money? The Supreme Court? Gender roles? Those are social constructs. They only exist because we agree they exist.

When we ignore this, we fail. Consider the digitalization of hospital forms. A study by Geraldine Fitzpatrick showed that paper forms in hospitals weren’t just data containers. Nurses scribbled notes in the margins; they used the physical location of the clipboard to signal status; they used the paper as a communication tool in ways not defined by the “fields.” When IT consultants tried to digitize this by simply turning text fields into database rows, the system failed. They captured the “data” (Positivism) but destroyed the “social construction” of the work (Constructivism).

The Cockpit: A Grand Unification

So, which paradigm is the “correct” one? This is a childish question. Good science can be done under any paradigm, provided you stick to the three pillars: Doubt, Method, and Openness. The choice of paradigm depends entirely on the question you need to answer.

Let’s look at an airplane cockpit.

If you are a Positivist, you ask: “Does the altimeter provide the correct altitude within 0.1% accuracy?” You are testing hardware and software correctness. This is vital.

If you are a Critical Theorist, you ask: “Why is the cockpit designed this way? Does it favor a certain type of pilot (e.g., male, Western)? Does the hierarchy between the pilot and co-pilot prevent safety checks?”

If you are a Constructivist, you ask: “How do the pilots feel about the automation? Do they trust it? How does the culture of the airline influence how they use the autopilot?”

For a long time, aviation focused heavily on the Positivist view (engineering). But a 2013 FAA study found that this focus created a new danger: pilots were becoming over-reliant on automation. When the systems failed, the pilots didn’t know how to fly the plane manually. The pure engineering approach missed the human factor. By ignoring the Constructivist questions (how do humans interact with the machine?), the industry created a new class of accidents.

We need all the lenses. If you only have a hammer, every problem looks like a nail. If you only have Positivism, every problem looks like a math equation. And sometimes, the problem is a Viking woman, a nun, or a pilot who has forgotten how to fly.

Next up: The ugly truth about the academic industry — fraud, the “Publish or Perish” meat grinder, and how to survive it all with your integrity intact.

Part 5: The Academic Game & How to Play It (Fraud, Metrics, and Practical Wisdom)

We have spent four sections building up the ideal of science: a noble, rigorous pursuit of truth built on doubt and systematic checking. Now, we have to look at the reality of the industry of science. Because science is done by humans, and humans are prone to greed, laziness, and gaming the system, the “Temple of Reason” has a fair amount of rot in the foundations.

The Hall of Shame: When Science is Faked

Between the ideal of the Scientific Method and the reality of a career in research, a gray zone emerges. Sometimes, it’s not just gray; it is pitch black. Take James Mellaart, a celebrated British archaeologist. For decades, he was a titan in the field, discovering Neolithic sites in Turkey. It wasn’t until he died in 2012 that researchers went through his archives and realized he had been systematically faking sketches and “finds” since the 1960s to support his theories. He played the long con, and because of his authority, nobody checked the receipts while he was alive.

But sometimes the fraud is designed to expose the system, not exploit it. In 1994, Austrian researchers Werner Purgathofer, Eduard Gröller, and Martin Feda suspected that the VIDEA '95 conference had zero quality control. To prove it, they submitted four completely absurd abstracts filled with subversive humor and technical nonsense. All four were accepted. They went public with the “Beware of VIDEA!” manifesto to shame the organizers.

This tradition of “sting operations” continued. In 2005, three MIT students built SCIgen, a software that automatically generates grammatically correct but meaningless computer science papers. They submitted a paper titled “Rooter: A Methodology for the Typical Unification of Access Points and Redundancy” to a conference, and it was accepted. In 2009, Philip Davis from Cornell used similar software to submit a paper to The Open Information Science Journal. The journal accepted it, asking only for an $800 publication fee. They didn’t care about the science; they cared about the check.

The most recent and grotesque example dropped in 2024, when the journal Frontiers in Cell Development and Biology — supposedly a peer-reviewed publication — published a paper containing AI-generated diagrams. One diagram featured a rat with a biologically impossible, gargantuan reproductive organ, labeled with gibberish text like “dck.” The image went viral on social media, the paper was retracted, and the reviewers claimed it “wasn’t their job” to check the images. These aren’t just funny anecdotes; they are structural failures showing that the “critical collective review” we rely on is often asleep at the wheel.

The Grind: Publish or Perish

Why is the quality control failing? Because the economic incentives of science are broken. We call this culture Publish or Perish. In the academic world, published papers are currency. You pay for your career advancements, grants, and tenure with PDFs.

This creates a pressure cooker. Instead of spending five years working on one major breakthrough, researchers are incentivized to slice their work into the smallest possible “publishable units” (salami slicing) to get three papers out of one experiment. Even worse, the business model is bizarre: Scientists do the research (paid by taxpayers), write the papers (for free), review other scientists’ papers (for free), and edit the journals (for free). Then, for-profit publishers take this content and sell it back to the universities for exorbitant subscription fees.

The Scoreboard: The h-Index and Goodhart’s Law

To make matters worse, administrators love to quantify “excellence.” They want a number that tells them if a scientist is “good.” The most common metric is the h-Index, proposed by Jorge Hirsch. Your h-Index is $X$ if you have $X$ papers that have been cited at least $X$ times. It sounds objective, but it turns science into a video game.

If you tell a smart person how the score is calculated, they will optimize for the score, not the science. This is Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.” Researchers can game their h-Index by citing themselves relentlessly or by writing “Review Papers” (summaries of other people’s work) which get cited often but add no new knowledge.

Marc A. Edwards and Siddhartha Roy analyzed this in 2017, documenting the “Perverse Incentives” of academia. The system rewards quantity over quality. As astrophysicist Paul M. Sutter notes in his book Rescuing Science, the current incentive is “Keep publishing, dang it.” There is zero incentive to do careful peer reviews, replicate results (which is boring and gets no citations), or publish negative results. The system is designed to produce noise, not truth.

Praxistipps: How to Think Like a Scientist (Without Losing Your Soul)

Despite the systemic issues, the core toolkit of scientific thinking is the most powerful mental software you can install. Here is how to apply it to your actual life and career.

1. Cultivate Functional Doubt The first tip is the hardest: Learn to doubt. But you must distinguish between Functional Doubt (doubting ideas) and Dysfunctional Doubt (doubting yourself). Functional doubt drives you to check sources and test assumptions. Dysfunctional doubt (Identity Doubt) paralyzes you. You should doubt your hypothesis, but do not let that curdle into Imposter Syndrome where you doubt your ability to think.

2. The Receipt Strategy (Sources) When you are researching or arguing a point, look for sources that confirm your view and sources that contradict it. If you can’t find a source that disagrees with you, you aren’t looking hard enough. Also, drop the ego about “originality.” Extensive citing isn’t cheating; it’s proof of quality. It shows you have done the work to map the territory.

3. Discourse Control When someone attacks your idea, your lizard brain thinks they are attacking you. You will feel the urge to get defensive. Fight this. Count to ten. Science happens in the Discourse — the cool, detached exchange of arguments — not in a heated debate. If you get emotional, you have lost the ability to think critically.

4. Scientific Reasoning (Induction vs. Deduction) Understand the difference in how you build arguments.

• Induction is bottom-up. You see 100 specific cases and guess a general rule. (e.g., “I’ve only seen dangerous drivers on this street, so this street is dangerous.”) This is useful but probabilistic. It generates hypotheses.
• Deduction is top-down. You take established facts and logically derive a conclusion. (e.g., “All men are mortal. Socrates is a man. Therefore, Socrates is mortal.”) This is logically sound, provided your premises are correct.

5. The Final Warning: Correlation is still not Causation We end where we began. Your brain is a pattern-matching machine that wants to connect dots. It sees a correlation (e.g., “I washed my car, and then it rained”) and invents a cause (“Washing the car causes rain”). Fight this instinct. Always assume a correlation is a coincidence until you have a mechanism to explain the causality.

Summary

Scientific Thinking is simply a systematic, traceable form of curiosity. It requires admitting that we are easily fooled, that our senses are flawed, and that our biases are strong. It demands that we build systems — peer review, open data, falsification — to protect us from our own nature. Whether you are debugging code, diagnosing a patient, or just reading the news, the goal is the same: to describe the world in a way that withstands critical scrutiny.

End of Series. That was it!

The Burglar’s Philosophy

When we talk about building secure systems, there is an aphorism that gets thrown around constantly in the security industry: “Think like a burglar.” This isn’t just a catchy phrase; it is the fundamental motivation behind understanding criminal thinking. As engineers and developers, we are trained to build things that work. We optimize for uptime, for throughput, for the “happy path” where the user clicks the right buttons and the database responds correctly. But that perspective is dangerous because it ignores the reality of entropy and malice. The idea that it is sufficient to implement a system well, without errors, and with thoughtful architecture is fundamentally challenged by the criminal mindset.

To truly secure a system, you have to invert your thinking. You cannot just ask, “How do I make this work?” You must ask, “How do I make this fail?” This concept is explored deeply in the “Mental Models & Security” framework, which argues that we need to adopt specific cognitive strategies to anticipate security problems before they manifest. These strategies include Inversion (looking at the problem backwards), Second-Order Thinking (asking “and then what?”), and Probabilistic Thinking.

These mental models act as the bridge between a “builder” and a “breaker.” Builders operate under the assumption that technology works in the normal case. Criminal thinkers operate under the assumption that technology will fail, or can be forced to fail. In cybersecurity, failing to plan for that failure isn’t just an oversight; it is the core definition of negligence. We need to stop designing only for functionality and start designing for the inevitable breach.

The ATM: A Public Vault with a Weak Interface

Let’s ground this philosophy in a tangible example that has evolved over decades: the ATM. Fundamentally, an ATM is just a safe sitting in public. Physically “cracking” the safe itself is incredibly difficult. It usually requires heavy machinery, explosives, or ripping the entire unit out of the wall with a truck — methods that are loud, dangerous, and conspicuous. Because the vault is hard to break, criminal thinkers target the interface instead. It is significantly easier to intercept the data flow between the customer and the bank than it is to steal the physical cash.

This is where Skimmers come into play. A skimmer is a device added to the existing interaction hardware — the card reader and the keypad — to capture user data.

There is a fascinating nuance in how we design these interfaces that actually aids the attacker. Have you ever wondered why ATMs force you to type your PIN on a physical, rubberized keypad rather than a sleek touchscreen? It’s a security feature. If you used a touchscreen, software could log the coordinates of your tap (a software keylogger). Even more simply, the grease from your fingers would leave residual smudges on the screen, allowing a thief to shine a light on the glass and see exactly which numbers you pressed. By using a physical keypad, the system offloads authentication to the card itself without storing the PIN in an easily accessible software layer.

However, this physical separation creates a new vulnerability. Because the keypad is a distinct physical component, it can be manipulated. Attackers have developed overlay keypads — thin, realistic-looking plastic shells that sit directly on top of the real keypad. When you type your PIN, you are actually pressing the attacker’s buttons, which record the keystrokes and pass the pressure down to the real buttons below. The transaction works perfectly, but your PIN has been compromised.

We can see this vulnerability even without high-tech overlays. If you look closely at older keypads, you can sometimes see the PIN simply by observing the wear and tear. If the “1,” “2,” “3,” and “4” keys are rubbed smooth while the rest are dusty, the PIN is almost certainly a permutation of those digits. This is the “Smoker’s Finger” effect: the physical evidence of digital secrets.

The Vienna Case Study: What Was Missed?

A few years ago, a security researcher named Ben Tedesco uploaded a video that went viral. He was visiting St. Stephen’s Cathedral (Stephansplatz) in Vienna and spotted something off about an ATM. In the video, he grabs the green plastic housing surrounding the card slot and gives it a firm wiggle. With a bit of force, the entire plastic molding pops off. It was a 3D-printed replica containing magnetic read heads and a battery, designed to sit over the real slot and skim the magnetic stripe data as the card was inserted.

It was a great catch, but here is the terrifying detail that most people — including Tedesco at the moment — missed. He found the card skimmer, but he missed the second half of the apparatus.

To steal money, you need two things: the card data (PAN) and the PIN. The plastic overlay he removed only captured the card data. To get the PIN, the attackers had installed a micro-camera hidden in a molding strip directly above the keypad. This camera was angled perfectly to record the user’s fingers as they typed. The attackers had covered all bases, and the hardware was designed to blend seamlessly into the machine’s aesthetic. It is a perfect example of criminal competence: they didn’t just hack the machine; they engineered a physical overlay that mimicked the industrial design of the bank’s hardware.

The Evolutionary Arms Race

The relationship between security engineers and criminals is a perpetual arms race. Every time we introduce a new defense, the “criminal thinker” finds a workaround.

When skimming became an epidemic, the industry moved from magnetic stripes to EMV Chips. The logic was that chips couldn’t be cloned as easily as a magnetic stripe. Did this stop the criminals? No. It just changed their vector. We started seeing “Shimmers” — incredibly thin, flexible circuit boards that slide into the card slot with the card, sitting between the chip and the reader to intercept the communication.

Then came “Deep Insert” skimmers. These are wafer-thin devices that are shoved deep inside the machine, completely invisible from the outside, utilizing tiny batteries and storage to harvest data for weeks.

As we moved to contactless (NFC) payments to avoid physical contact entirely, the attackers shifted again. We are now seeing Android malware like NGate that uses the NFC reader on a compromised phone to relay data from a victim’s card in their pocket to an attacker’s device, effectively cloning the card wirelessly. Or consider the “Ghost-Tap,” where hackers exploit vulnerabilities in mobile payment protocols. The medium changes, but the methodology remains constant: find the input, intercept the data, monetize the access.

A critical piece of advice: If you ever spot a skimmer, do not pull a “Ben Tedesco” and rip it off yourself. Criminal gangs often monitor these devices from a parked car nearby to retrieve the data or the hardware. They can be extremely aggressive if they see you tampering with their livelihood. The correct move is to walk away and call the police.

The “Lahore” Connection: Physical Meets Syntactic

We can categorize these attacks by their nature. Some are purely physical (glue on a cash dispenser), some are syntactic (SQL injection), and some are a hybrid.

A chilling example of a hybrid attack was discovered in the credit card terminals of a large discount grocery chain. Security teams found small, foreign circuit boards soldered inside the legitimate card readers. These weren’t just storing data; they were equipped with GSM modems.

Every day, these devices would wake up, bundle the captured credit card numbers, and transmit them via the mobile network to a phone number in Lahore, Pakistan. The sophistication here is high: the attack was hardware-based, but the exfiltration was purely telecommunications.

The only reason this was discovered wasn’t because of a software audit or a firewall alert. It was discovered because a security guard at the store noticed that his own cell phone was making that rhythmic “buzzing” interference noise you hear when a device is transmitting data nearby. He heard the interference near the checkout counter when no one was using a phone, realized something was broadcasting, and called the police. This incident underscores that criminal thinking is global, hardware-agnostic, and often invisible until a side channel — like audio interference — gives it away.

Coming up in Part 2: We leave the hardware behind to profile the “Black Hat” — tracing their evolution from curious pranksters to the ruthless architects of the malware economy.

Part 2: Profiling the Adversary – Motivations & The Malware Economy

The Color of Intent

Before we can understand the attack, we have to understand the attacker. In the short history of computer science, we’ve developed a shorthand to categorize these actors based on the metaphorical color of their hats. It’s a bit of a cliché, but it’s useful for setting the stage.

You have your White Hats, the security professionals and researchers finding bugs to fix them. You have Grey Hats, who operate in the nebulous middle ground, perhaps breaking the law to reveal a vulnerability but without malicious intent. There are Red Hats, the vigilantes who actively attack the attackers. But for the purpose of “Criminal Thinking,” we are almost exclusively interested in the Black Hats. These are the actors motivated by malice, profit, or political ideology.

It is also worth debunking a persistent stereotype right now: the image of the hacker as a lonely, hoodie-wearing guy in a basement is outdated and inaccurate. If you look at the history of notorious hackers, you find names like Susan Headley, Ying Cracke, and Kristina Vladimirovna Svechinskaya. The demographic is diverse, but the intent is what matters. In this industry, we try to avoid using the word “hacker” as a synonym for “criminal” because hacking is fundamentally just a creative engagement with technology. When that creativity is applied to theft or destruction, the correct terms are “Cybercriminal” or “Black Hat.”

The Evolution of the Hustle

If we trace the timeline of cyber threats, we see a distinct shift in motivation. In the early days, hacking was largely driven by curiosity, intellectual challenge, and a bit of ego. It was about seeing if you could get into a system just to prove it was possible. But as the internet matured, the “why” changed dramatically.

Today, malware is a business model. We often talk about “Internet Background Radiation” — the constant, low-level hum of automated attacks hitting every public IP address. This isn’t personal; it’s capitalism. Hackers make money by aggregating massive fleets of compromised home computers — bots — and leasing them out. They earn commissions for every piece of spyware or adware they successfully plant on an infected machine. As discussed in a 2021 TWiT podcast segment, this commercialization is the primary engine driving modern threats. The romantic idea of the lone genius has been replaced by the reality of the supply chain manager.

The DDoS Timeline: From Pranks to Politics

A perfect illustration of this evolution is the history of Distributed Denial of Service (DDoS) attacks. Fifteen years ago, if you looked at a timeline of DDoS incidents, the motivations were chaotic. They were often “for the lulz” — kids testing scripts to knock a game server offline or just to see what would break. The attacks were characterized by a lack of clear purpose.

Over the last decade and a half, that randomness has hardened into strategy. The motivation shifted first to extortion — “pay us 5 Bitcoin or your e-commerce site stays down” — and then to political warfare. We now see massive spikes in traffic directed against gaming companies or media outlets that appear to be retaliation for sociopolitical stances. While it’s hard to prove attribution in real-time, the correlation between controversial public statements and massive packet floods is undeniable.

The scale has also become terrifying. Since 2008, the sheer volume of DDoS attacks has increased roughly 30-fold. We don’t measure these campaigns in “attacks per day” anymore; we measure them in “attacks per hour.” And thanks to the efficiency of modern tools, attackers can do more with less. A few years ago, you might have needed a botnet of 1,000,000 infected devices to cripple a target. Today, with smarter application-layer attacks and the assistance of generative AI to script complex attack vectors, you might achieve the same result with only 50,000 bots. The barrier to entry has lowered, but the destructive potential has skyrocketed.

The Industrialization of Scamming

The profit motive has reshaped entire economies. As reported by the Guardian in October 2025, we are witnessing the rise of “cybercrime villages” in places like rural India. As traditional agricultural jobs vanish, entire regions are pivoting to call centers dedicated to global fraud.

This is “scamming as farming.” The goal is to harvest capital from victims on the other side of the planet — stealing identities, draining bank accounts, and installing remote access trojans. This is a global information system with no corresponding global justice system. A scammer in a jurisdiction with lax enforcement faces almost zero risk of prosecution for defrauding a grandmother in Ohio. This accountability vacuum leads to bizarre outcomes, such as the rise of “glitterbombing” vigilantes like Mark Rober, who use engineering to exact the only form of justice available: pranking the scammers back. It’s entertaining, but it highlights a systemic failure of law enforcement to adapt to a borderless crime wave.

Ransomware: The Predator of Infrastructure

The “start signal” for the modern era of high-stakes cybercrime was the emergence of Ransomware. This is the ultimate distillation of the criminal business model: encrypt the victim’s data and sell them the decryption key.

Around 2016, we saw a massive wave of ransomware targeting hospitals. Why hospitals? Because they were the perfect “soft targets.” They rely on immediate access to patient data to save lives, their IT infrastructure is often legacy and underfunded, and they have the money to pay.

The case of the Lukaskrankenhaus in Neuss, Germany, is a prime example. A virus infected their IT systems, forcing them to shut down nearly all digital operations. While they stated that patient data was safe due to backups, the hospital was effectively paralyzed, operating with severely limited functionality. This incident revealed a brutal truth: having a backup is not enough if the time required to restore that backup causes operational collapse.

The attackers realized that public infrastructure was a goldmine. By 2019, the target list expanded to city governments. New Orleans had to declare a state of emergency following a cyberattack that crippled the police department, courts, and emergency medical services.

The human cost of this is not theoretical. In 2020, a patient in Germany died after being diverted to a different hospital because the nearest facility was in the midst of a ransomware lockout. The delay in treatment proved fatal. This tragedy underscores the danger of viewing IT security as a cost center rather than a safety requirement. When organizations like Sony (in 2007) or local hospitals decide that “hardening the database costs $10 million, but the breach only costs $1 million,” they are making a business calculation that ignores the catastrophic reputational and human damage that modern black hats can inflict.

Coming up in Part 3: We examine the “Opportunity” that lets these attacks happen — from the persistence of “Zero Day” vulnerabilities and bad code to the looming threat of AI-generated exploits.

Part 3: The Opportunity Landscape – Zero Days, Policy Failures, and AI

The Window of Vulnerability

If motivation is the “why” and malware is the “how,” then opportunity is the “when.” A central concept in understanding this opportunity is the Zero Day. This term refers to a software vulnerability that is unknown to the vendor or the public, meaning there is effectively zero days of warning before an attack could theoretically happen. In the hands of a Black Hat, a Zero Day is a master key. But the opportunity doesn’t close the moment a vulnerability is discovered; it often widens due to the sluggishness of human response.

Consider the case of Heartbleed, a critical vulnerability discovered in the OpenSSL cryptographic library in 2014. OpenSSL is the bedrock of secure internet communication, used by approximately two-thirds of all web servers at the time. The bug allowed anyone on the internet to read the memory of systems protected by the vulnerable versions, potentially exposing passwords, encryption keys, and user data.

When Heartbleed was announced, the fix was released simultaneously. In a perfect world, the story ends there. But in the real world, the announcement was just the starting gun for a race between administrators patching their servers and criminals scanning for vulnerable targets. The technical fix was instant; the deployment was agonizingly slow. One year after the vulnerability was disclosed, fewer than 50% of the affected servers in Germany had been patched. Two years later, tens of thousands of systems were still bleeding. This illustrates a critical failure in the security lifecycle: solving the problem mathematically does not solve it operationally. Millions of systems remain vulnerable simply because they are running legacy software that no one bothers to update.

The Myth of Calculated Risk

Historically, organizations have rationalized this sluggishness through cold financial calculus. A notorious example from 2007 involves a security executive at Sony, who essentially argued that if hardening a legacy database costs $10 million, but the cost of notifying customers after a breach is only $1 million, the valid business decision is to accept the risk of the hack. This “calculated negligence” was the industry standard for a long time.

That logic has now collapsed. The cost of a breach is no longer just the immediate cleanup bill. Today, we have regulatory hammers like the GDPR (General Data Protection Regulation) in Europe, which mandate that personal data must be protected according to the “state of the art.” The penalties for negligence are now astronomical. For instance, the Greek mobile operator COSMOTE was fined €6 million after a hack exposed customer data. Beyond the fines, there is the devastating loss of reputation. In the modern tech economy, trust is a currency. When companies lose customer data, they lose that trust, and the market punishes them far more severely than the cost of a firewall upgrade.

The AI Double-Edged Sword

The opportunity landscape is shifting again with the rise of Generative AI. This technology acts as an accelerant for both sides of the security equation. On one hand, we are seeing a massive influx of “Bad Code” generated by AI assistants. Studies suggest that a significant percentage of code produced by tools like GitHub Copilot contains security vulnerabilities. When developers blindly trust AI-generated snippets without rigorous auditing, they are baking flaws into their software supply chain at a speed we haven’t seen before.

On the other side, Black Hats are using the same tools to sharpen their attacks. AI can write convincing phishing emails, generate polymorphic malware that changes its code to evade detection, and even help script complex exploits. While the security industry sometimes reacts with panic, the reality is undeniable: AI lowers the barrier to entry for cybercrime. It allows less skilled attackers to operate with the sophistication of advanced groups, effectively democratizing the ability to cause chaos.

The Admin Gap

We often blame the “end-user” for security failures — the receptionist who clicked a link or the grandfather who shared his password. But we need to turn that scrutiny toward the professionals. System administrators and IT staff are often assumed to be the “strong link,” but research challenges this.

Two scientific studies from the environment of TU Wien investigated how well system administrators actually understand the security measures they deploy. The titles alone — On the Usability of Deploying HTTPS and If HTTPS Were Secure, I Wouldn’t Need 2FA — point to the problem. The findings were concerning: not only were there significant knowledge gaps among the professionals, but the security products themselves suffered from massive usability issues.

If the tool for configuring a secure server is confusing, the administrator will likely misconfigure it. This is a “System 2” failure. It’s not just that people are lazy; it’s that the complexity of modern infrastructure has outpaced the usability of our management tools. When we say “humans are the weakest link,” we must include the architects and administrators in that statement. A poorly designed interface for a firewall is just as dangerous as a weak password.

Coming up in Part 4: We dive into the psychology of the “Human Factor,” exploring how distance emboldens attackers and how Social Engineering hacks the human operating system.

Part 4: The Human Factor – Social Engineering & The Identity Crisis

Distance as a Weapon

One of the most powerful enablers of criminal thinking is a concept that predates the internet entirely: distance. It is a well-documented psychological phenomenon that it is easier to be cruel, aggressive, or destructive when you don’t have to look your victim in the eye. We see this in the toxicity of anonymous online comment sections, but in the realm of cybersecurity, this distance transforms crime into a game.

Hackers operate remotely, far removed from the tangible consequences of their code. A chilling demonstration of this was the famous remote hacking of a Jeep Cherokee by researchers Charlie Miller and Chris Valasek. In their demonstration, they didn’t just tamper with the radio; they killed the engine while the car was driving down a highway. In the video documentation of the hack, you can hear the researchers laughing as the driver struggles with a dead vehicle. To them, sitting comfortably miles away with their laptops, it was an intellectual triumph — a successful execution of code. To the driver, it was a terrifying loss of physical control. This emotional disconnect allows attackers to perform dangerous acts with the casual demeanor of someone playing a video game, making the threat landscape far more volatile than traditional physical crime.

Professionals Target People

There is a saying by security guru Bruce Schneier: “Amateurs tend to attack machines, whereas professionals target people.” This brings us to the domain of Social Engineering, which is arguably the most reliable way to breach a complex system. Why spend months trying to crack 256-bit encryption when you can just ask the receptionist for the password?

Social engineering is the art of manipulating people into breaking their own security rules. In pop culture, this is often depicted as a hacker guessing a password because it’s the name of the target’s dog. While that happens (reconnaissance into private lives is real), the reality is often much more physical and immediate. It exploits our social norms. For example, if you are walking towards a secure office door carrying a heavy box, and you ask the person in front of you to “hold the door,” they almost certainly will. In that moment, their desire to be polite overrides their training to prevent “tailgating.” You are now inside the building, and the firewall doesn’t matter anymore.

The industry is full of legends who specialize in this. Jason E. Street is a notorious penetration tester who has given talks at DevCon detailing how he breaks into banks and secure facilities not with code, but with a smile and a clipboard. He exploits the fact that people want to be helpful. Similarly, a photo of Eric Corley (founder of 2600 magazine) captures the essence of this “low-tech” hacking. In the image, he is simply working a payphone, yet through sheer verbal manipulation, he once managed to get a Taco Bell to shut down all their registers for five minutes and convinced a KMart manager to patch him into the store-wide PA system so he could announce that “everything in Aisle 6 is free.” Even security experts are vulnerable; Youtuber Max Fosh demonstrated that he could infiltrate a security convention, proving that the very people who mock end-users for being the “weakest link” are just as susceptible to a clipboard and a confident demeanor.

The “Stupidity” Paradox

We frequently blame end-users for security breaches, labeling them as the “weakest link” in the chain. This is a lazy and dangerous simplification. It is like a driver in a traffic jam complaining about traffic, failing to realize they are the traffic.

When we look at security failures, we often find that the “user error” was actually a design failure. Remember the ATM keypad discussed in Part 1? If the keys are worn down, revealing the PIN, that isn’t the user’s fault; it’s the fault of the system administrator who failed to replace the hardware. If a user chooses a weak password, it’s often because the system didn’t enforce a better policy or provide a usable password manager.

A tragic example of this “blame the user” mentality failing is the WannaCry ransomware outbreak. When the news broke that a massive cyberattack was encrypting computers worldwide, panic set in. People were terrified. In their desperation to protect themselves, thousands of Android users rushed to the Google Play Store and searched for “WannaCry Protection.” They downloaded the top results, thinking they were being responsible.

The tragic irony was that these apps were fake. Malware authors had anticipated the panic and flooded the store with “protection” apps that were actually malware themselves. The users were infected not because they were reckless, but because they were trying to be safe in an ecosystem that failed to protect them. The media’s incompetent reporting on the technical details only fueled the fire, driving people straight into the arms of the attackers.

The Crisis of Digital Identity

Perhaps the deepest systemic failure we face today is the lack of a verifiable digital identity. The internet was built without an identity layer. We have no standard, global way to prove who we are online. Instead, we have a fragmented mess of “Login with Facebook,” “Login with Google,” and hundreds of isolated user accounts.

This fragmentation forces users to manage impossible numbers of credentials, leading to password reuse and identity theft. But the consequences are getting far more severe with the advent of Deepfakes. Because we cannot cryptographically prove our identity in a standard way, we rely on our senses: “I see your face on the video call, I hear your voice, therefore it is you.”

That heuristic is now obsolete. In a staggering case from Hong Kong, a finance worker at a multinational firm was invited to a video conference call with the company’s Chief Financial Officer (CFO). The worker joined the call and saw the CFO and several other colleagues he recognized. They discussed a confidential transaction, and the CFO instructed him to transfer 200 million Hong Kong dollars (approx. €20 million).

The worker made the transfer. It was only later that he discovered the truth: everyone else on that video call was a deepfake. The attackers had used publicly available footage to reconstruct the faces and voices of the executive team in real-time. The worker wasn’t negligent; he was overpowered by a technological reality that our identity systems are not equipped to handle. Until we solve the problem of digital identity verification, “seeing is believing” will remain a critical vulnerability.

Coming up in Part 5: The final frontier — how billions of cheap, unsecure IoT devices are creating a zombie army, and why we might need a “Center for Disease Control” for the internet.

Part 5: The IoT Apocalypse & A New Defense Paradigm

The Landfill of Unsecured “Smart” Junk

While the security industry loves to hyperventilate about Artificial Intelligence, the most immediate and pervasive threat isn’t a super-intelligent rogue AI. It’s your toaster. Or your cheap webcam. Or that Wi-Fi-connected fish tank thermometer. We are living through the explosion of the Internet of Things (IoT), and frankly, it is a security disaster.

We need to make a sharp distinction here. When you buy a high-end “always-on” device like a Google Home or Amazon Echo, you are generally buying into a managed ecosystem. These companies have security teams, and crucially, they push firmware updates. If a vulnerability is found, it gets patched.

The danger lies in the “long tail” of cheap electronics. The market is flooded with white-label “smart” devices produced by manufacturers that act like mayflies — they exist for a year or two to flood the market with cheap hardware, and then they vanish. These devices are sold with no plan for software maintenance. They have hardcoded passwords (often just “admin/admin”), open Telnet ports, and unpatchable firmware. Once a vulnerability is discovered in one of these “zombie” devices, it is there forever.

This creates a terrifying dynamic: we are filling our homes and offices with millions of tiny, powerful computers that are permanently vulnerable. And because the people buying them are regular consumers, not sysadmins, these devices are almost never monitored. They just sit there, connected to the internet, waiting to be conscripted.

Mirai and the Million-Bot Army

The wake-up call for this threat was the Mirai Botnet in 2016. Mirai didn’t attack sophisticated servers; it scanned the internet for those cheap IoT devices — digital video recorders (DVRs) and IP cameras — and tried default usernames and passwords. It worked terrifyingly well.

Mirai amassed an army of hundreds of thousands of hijacked devices. When the controllers gave the order, this swarm launched a Distributed Denial of Service (DDoS) attack of unprecedented scale against Dyn, a major DNS provider. The result? Huge chunks of the internet, including Twitter, Netflix, and Reddit, simply vanished for users across the US and Europe.

Since then, the problem has only metastasized. A 2023 threat intelligence report from Nokia revealed that the number of IoT devices engaged in botnet-driven DDoS attacks skyrocketed from 200,000 to approximately 1 million devices in a single year. The graph of IoT attacks in 2022 mimics the exponential curve of malware growth in general. Today, the majority of malware activity isn’t targeting your laptop; it’s targeting your smart infrastructure. We have inadvertently built a global supercomputer for criminals, powered by our own cheap gadgets.

The “Creepy” Factor: When the Hacker is in the Bedroom

The threat isn’t just about DDoS attacks knocking websites offline; it is deeply personal. These devices often include cameras and microphones, and they are frequently installed in our most private spaces.

There is a horrifying, well-documented case involving a Ring camera installed in a children’s bedroom. The parents put it there for safety. A hacker managed to compromise the device. The parents later reviewed the footage to find the hacker playing the eerie song “Tiptoe Through the Tulips” through the camera’s speaker. When the eight-year-old girl in the room stopped and asked, “Who’s there?”, the hacker replied: “It’s Santa. It’s your best friend.”

This is the nightmare scenario. It has become so prevalent that the FBI issued warnings about “Swatting” attacks originating from compromised smart home devices.

Simultaneously, we are seeing a massive erosion of trust. Consumers are starting to realize that “smart” often means “spy.” Stories of smart TVs serving intrusive ads or an LG washing machine seemingly uploading 11GB of traffic to the internet have made people skeptical. As one tech commentator noted, trust is the hardest thing to earn and the easiest to lose. We are approaching a tipping point where users might simply refuse to connect these appliances, turning “smart” features into dead silicon.

“Click Here to Kill Everybody”

Security expert Bruce Schneier argues that the term “Cybersecurity” is becoming obsolete. We should just call it “Security.” Why? Because everything is a computer now. Your car is a computer with wheels. Your pacemaker is a computer in your chest. Your power grid is a distributed computer system.

This means that software vulnerabilities now have kinetic consequences. We are moving from a world where a hack means “data loss” to a world where a hack means “physical harm.”

Compounding this is the “Snyk 2023 AI Code Security Report,” which highlights a dangerous feedback loop. 96% of development teams are now using AI coding tools to write software faster. However, over half of those teams report that these AI tools consistently generate insecure code. We are using machines to write bad code faster than humans can audit it, deploying it into critical infrastructure that controls the physical world.

A New Model: The CDC for Cyber

So, how do we fix this? The lecture proposes a radical shift in how we think about digital safety: The Public Health Model.

In the 19th century, we didn’t solve cholera by telling everyone to “just be more careful” with their water. We solved it by building sewage systems and establishing public health institutions. We need a similar approach for the internet.

Imagine a Center for Disease Control (CDC) for Cybersecurity. Instead of blaming the user, this institution would operate at a systemic level. Its responsibilities would include:

• Epidemiology: Tracking the spread of malware and vulnerabilities like a biological virus.
• Regulation & Certification: Just as you can’t sell a toaster that explodes, you shouldn’t be allowed to sell a webcam that can’t be patched. This body would test and certify hardware before it hits the shelves.
• Public Warnings: Issuing authoritative alerts about specific dangerous products (e.g., “Do not buy Brand X Baby Monitor”).
• Hygiene Education: Moving beyond “make a strong password” to teaching genuine digital literacy and resilience.

We cannot “firewall” our way out of this individually. Resilience comes from systemic changes — automated backups, incident response protocols, and diversity in software ecosystems to prevent monoculture failures. We need to stop treating security as a feature and start treating it as a prerequisite for civilization, backed by policy, law, and robust institutions.

This brings us to the edge of technology and into the realm of governance. But that is a story for the next chapter: Policy Thinking.

This concludes the “Criminal Thinking” blog series. Thanks for reading!

Here’s the deal: Computer Science is the unruly teenager of the academic and professional world. Unlike medicine, where doctors have operated under strict ethical codes and confidentiality oaths for centuries, the tech industry has spent most of its existence in a “move fast and break things” wild west. We are only just now seeing the emergence of serious regulatory frameworks, such as the GDPR in Europe, attempting to impose order on a chaotic system. This friction between society’s need for stability and the industry’s drive for unbridled innovation is defining the current era of technology. It is a massive problem, and as we saw with the EU’s recent AI Directive, the regulators are often one step behind — publishing rules that were already obsolete because they failed to account for generative AI.

The Policy Stack

When we talk about “policies” in IT, we aren’t just talking about government laws. We are talking about a multi-layered stack of rules that come in vastly different flavors. You interact with these every day, often without realizing the power dynamics at play.

1. The Regulatory Hammer: GDPR The General Data Protection Regulation (GDPR) is arguably the most famous piece of IT policy in existence. It regulates the fundamental rights of EU citizens regarding data protection. It gets a lot of hate, mostly because people associate it with annoying cookie banners (which, for the record, were mandatory before GDPR). But looking past the UI annoyance, it ushered in a massive shift in how we handle data. It forced companies to actually care about what they store and why. It is a “hard” policy — ignoring it costs millions.

2. The Financial Lever: Technology Funding This is a subtler form of policy. Governments use funding programs to shape the local technology landscape. It’s a way to counter the influence of powerful corporate lobbies by injecting cash into specific areas society deems valuable. However, this is a double-edged sword; sometimes these programs achieve the exact opposite of their intent, distorting the market rather than fixing it.

3. The Corporate Shield: Privacy Policies This is where the deception happens. Companies like Google, Meta, or local media outlets issue these policies to “explain” how they use your data. In reality, the “I have read and agree to the Terms of Service” checkbox is the biggest lie on the planet. Nobody reads them. If you did, you’d find walls of text in BLOCK CAPITALS written in a dialect of legalese that is indecipherable to anyone without a law degree. Yet, we have no choice. If you don’t click the box, you are exiled from digital society. It is forced consent.

4. The Programmatic Gatekeeper: Password Policies This is a unique beast because it is a policy that can be programmatically enforced. You cannot proceed until you satisfy the regex: eight characters, one uppercase, one number, one symbol. Here is the kicker: the guy who originally invented these rules (Bill Burr at NIST) has since apologized. He admits these rules actually make passwords less secure because they force predictable patterns (like Password1!) and frequent changes that lead to people writing passwords on sticky notes. Yet, the policy persists in corporate IT systems globally, zombie-like, enforcing bad security practices because “it’s policy.”

5. The Community Contract: Open Source (OSS) Policies These regulate the flow of free software. If you use OSS in your company, you have obligations. If you contribute to a project, you face quality assurance policies. It’s the bureaucracy of the free web, ensuring that “free” doesn’t mean “chaos.”

6. The Hardware Consensus: Standards (e.g., USB-C) Standards are policies defined by massive, cross-company committees. They are great for consumers because they ensure interoperability (your charger works with your laptop). But don’t be naive — industries often rush to standardize voluntarily specifically to prevent the government from stepping in with stricter laws. It’s regulation as a defense mechanism.

The Discrepancy of Speed

We are currently witnessing a massive divergence in where policy energy is being spent. In the AI sector, policies are popping up like mushrooms after rain. Every week there is a new framework, a new guideline, a new panic. Meanwhile, the policies governing our physical legacy infrastructure are being quietly dismantled.

Consider the humble telephone booth. In Austria, a recent amendment to the Telecommunications Act (end of 2022) completely erased the obligation for the market leader to operate public telephone booths. There was no replacement plan. The mandate simply vanished. While we hyper-fixate on regulating the future (AI), we are stripping away the safety nets of the past, leaving the public space with less utility than before.

The Dimensions of Regulation

To understand any policy, you have to map it on two specific dimensions. If you don’t do this, you’re just reading rules without understanding the game.

Dimension 1: The Origin Where does the rule come from?

• Technology Policy: comes from the State. This is society trying to influence technology (e.g., laws, bans, subsidies).
• Privacy Policies: come from IT Companies. This is the industry covering its own back.
• Internal Policies: come from Organizations (e.g., password rules).

Dimension 2: The Target Who gets hit by the rule?

• The User: Password policies target you. You are the one who has to dance to the algorithm’s tune.
• The Operator: A good privacy policy should restrict the company (e.g., “we will only store this for 30 days”).
• The Industry: Political policies usually target the companies themselves, trying to rein in their power.

“Code is Law”: The Iron Fist of Software

There is a critical distinction in the digital world that does not exist in the physical world. In the physical world, breaking a law has consequences after the fact. You speed, you get a ticket. In the digital world, software can make breaking the law physically impossible.

This concept is often called “Code is Law.”

The most aggressive implementation of this is in Copyright and DRM (Digital Rights Management). These systems enforce rules far stricter than the actual law requires. In many legal jurisdictions, you have a right to a “private copy” of media you own. The law allows it. But the software on a DVD or a stream does not. It blocks the copying mechanism entirely.

We see the absurdity of this with works that have entered the Public Domain. Take the original Mickey Mouse animation, Steamboat Willie, or the classic film Man with a Movie Camera. These works belong to the public now. Legally, you can do whatever you want with them. However, if you buy a modern disc or file of these works, it will likely still be wrapped in encryption or copy protection.

To exercise your legal right to copy this public domain work, you would have to break the copy protection. But — and here is the trap — breaking copy protection is illegal under a different set of laws (like the DMCA in the US or similar EU directives).

So, the technology effectively overrides the public domain status. The “policy” coded into the disc renders your legal rights null and void. This is dangerous territory. We are moving from a world where laws are social agreements enforced by courts, to a world where usage concepts are enforced by impartial, unyielding code. Code doesn’t care about nuance, fair use, or expiration dates. It just executes.

Coming Up in Part 2: We dive into the deep philosophy of why technology is never neutral, the “Pace Layering” model that explains why governments are always slow, and the Three Theses that prove technology is a political battlefield.

Part 2: The Philosophical Engine & The Three Theses

To understand why we even bother with policy thinking in computer science, we have to look past the surface-level regulations and interrogate the nature of technology itself. This chapter is built on three foundational theses that challenge the way most engineers are taught to view their work. If you accept these premises, the need for rigorous policy becomes undeniable.

Thesis 1: The Myth of Neutrality

The first thesis is widely known as Kranzberg’s First Law of Technology. It states quite simply: Technology is neither good nor bad; nor is it neutral.

This destroys the comfortable idea that tools are just tools. Engineers love to claim that a system is neutral and that responsibility lies solely with the user — the classic “guns don’t kill people” argument. But Kranzberg argues that this is fundamentally false. Every piece of technology forces a specific way of doing things. It inevitably changes the distribution of power. By its very design, a system facilitates certain actions and hinders others; it empowers certain groups of people while disenfranchising others.

When we implement a mathematical concept into a concrete system in the real world, it ceases to be an abstract neutral entity. It becomes an active agent that intervenes in the flow of history. It accelerates some developments and brakes others. Because of this inherent bias in function and access, no technology can ever be truly neutral. Therefore, claiming that “responsibility lies not with the technology, but with the human” is a logical fallacy. The technology itself carries a moral and political weight.

Thesis 2: The Privatized Political Arena

This leads us directly to the second thesis: The design of technology is a political arena that we have negligently privatized.

Every time we design a system, we are answering questions about what kind of human beings we want to be and what kind of society we want to live in. These are deeply political questions. Yet, for the last few decades, we have handed the keys to this arena over to private companies. We have allowed the “Silicon Valley” mindset to dictate the terms of our social reality.

This connects back to the concept of Critical Thinking and Algorithmic Bias. You cannot diagnose bias in a system unless you have a pre-existing idea of what a “fair” world looks like. You need a normative vision of society. By failing to assert a public vision for technology, we gave the industry a blank check in the 1980s. We treated their systems as irrelevant toys or purely positive innovations. Today, we see the damage caused by that negligence, amplified by the astronomical profits these companies extract. We effectively outsourced our societal architecture to ad-tech companies.

Thesis 3: The Industry’s Immune Response

The third thesis explains the current friction: The IT industry has a long history of deflecting, ignoring, and bypassing regulation.

This is a defense mechanism. The industry frequently argues that politicians lack the competence to regulate tech — a point that, painfully, is often true. But they also weaponize the neutrality myth (Thesis 1) to argue that regulation is unnecessary. This creates a culture where bypassing rules is seen as a virtue, a necessary step for innovation, rather than a violation of the social contract.

Defining “Policy Thinking” vs. Technology Policy

So what is this field we are discussing? Wikipedia defines Technology Policy as the sum of all political activities regarding the planning, development, deployment, and evaluation of technology. It is a massive field that includes fostering research and development (R&D), managing the diffusion of new tech, and — crucially — handling the fallout and problems caused by that tech.

The state has a wide arsenal of instruments here. There is institutional funding, where the state supports heavy hitters like the Max Planck Society or Fraunhofer Society. There are financial incentives, such as risk capital and innovation programs. There is the provision of infrastructure and support for technology transfer. But it goes deeper into the “soft” power of the state: organizing the public discourse through technology assessment studies, creating educational paths to train new experts, and regulatory politics like antitrust laws.

However, “Policy Thinking” is broader than just state action. It encompasses the entire ecosystem of governance, from the internal ethics of a startup to international treaties.

The Pace Layering Model

To understand why this is all so difficult, we have to look at Stewart Brand’s model of Pace Layering from around 2000. Imagine a diagram consisting of several layers stacked on top of each other, each moving at a different speed.

At the bottom, you have the slow, stabilizing layers like Nature and Culture. Above them is Governance (the state). Above that is Infrastructure. And moving much faster at the top are Commerce and Fashion.

The core insight here is that these layers must move at different speeds. They stabilize each other. If Commerce moves too fast without the stabilizing weight of Governance, it becomes criminal and extractive. Conversely, if Governance changes as frantically as Fashion, society collapses into chaos because you can’t build a business or a life on shifting sand.

The problem we face today is a mismatch in these layers. The IT industry positions itself somewhere between Infrastructure, Commerce, and Fashion. It moves at breakneck speed. The State (Governance) moves slowly by design. For decades, society stood like a rabbit in front of a snake, watching Big Tech reshape the world, paralyzed by the speed difference. We assumed technology was neutral, so we didn’t intervene. Now, the “shock” is wearing off, and the slow layer of Governance is trying to reassert control over the fast layer of Tech.

The Collingridge Dilemma

This struggle is complicated by a paradox known as the Collingridge Dilemma. It summarizes the problem of control in two frustrating points:

1. The Information Problem: When a technology is at an early stage, we cannot predict its harmful consequences. We don’t know enough to regulate it effectively.
2. The Power Problem: By the time the technology has spread widely enough that we can see the harmful consequences, it has become so entrenched in society that controlling or changing it is nearly impossible.

This dilemma is often used as a “get out of jail free” card by the industry. They shrug and say, “Well, we couldn’t have known, and now it’s too late.” But this is often an excuse to avoid basic responsibility. Many of the problems we face today — surveillance, bias, polarization — were systematically predictable. We just chose not to look because looking would have slowed down the deployment.

From Nurturing to Reining In

The philosophy of technology policy has shifted radically over the last 30 years. Back in 1995, thinkers like Lewis Branscomb defined technology policy as a way for the public to “nurture” capabilities to serve national goals. It was about growth, optimism, and helping the internet take flight.

Today, the conversation is entirely different. We are no longer asking how to nurture the industry; we are asking how to rein it in. We are looking at a wild, overgrown jungle of IT giants and asking if we can prune it back before it strangles the ecosystem.

This parallels the oil industry and the climate crisis. Both problems arose from a lack of early regulation and a refusal to acknowledge negative externalities. The industry fought regulation every step of the way, dating back to the 19th-century railroad barons who had to be forced by law to consider the public good.

It is now clear that “self-regulation” and “technical innovation” alone will not fix these problems. We need political solutions. And contrary to the Silicon Valley narrative, regulation does not kill innovation — it improves it. As Paul Nemitz, a key advisor to the EU Commission, puts it: there must be a primacy of democracy over technology and business models.

The tech scene loves to argue that laws should just adapt to the principles of technology (i.e., code). But the purpose of legislation is not to secure a specific business model. The purpose of legislation is to shape the life of the human being and society as a whole. If a business model relies on destroying the fabric of democracy, the law has a duty to destroy that business model.

Coming Up in Part 3: We enter the dark engine room of the internet to dissect “Surveillance Capitalism,” the roommate prank that revealed too much, and the race to the bottom of the brainstem.

Part 3: The Machinery of Surveillance Capitalism

We often talk about “privacy” in the abstract, but to understand the true weight of Policy Thinking, we need to look at the machinery of influence that operates beneath the surface of the web. This isn’t just about ads; it is about the systematic modification of human behavior for profit.

The Precision of Influence: A Case Study

Let’s start with a story that sounds like a joke but reveals the terrifying granularity of modern targeting. A while back, a writer decided to pull a prank on his roommate. The roommate was becoming paranoid, so the writer used Facebook’s ad targeting tools to feed him incredibly specific “dark” ads. He didn’t cast a wide net; he created a “custom audience” that consisted of exactly one person — his roommate.

Now, Facebook’s policy technically forbids target audiences of size one. To bypass this, the writer created a target group consisting of “all women” plus “his roommate,” and then in a separate setting, specified that the ads should only be shown to men. The intersection of those sets was exactly one person. He then bombarded his roommate with ads that referenced specific things they had just talked about or personal insecurities, driving the poor guy to the brink of a nervous breakdown. The writer eventually had to stop because he feared he was going to send his friend to a psychiatric ward.

This anecdote is funny, but the implications are catastrophic. If a random guy can use off-the-shelf tools to manipulate a friend into a mental crisis, what can a state actor do? What can a corporation do? We are talking about the ability to influence elections, shift cultural narratives, or incite violence (like the storming of a parliament) by targeting specific triggers in specific people. This is the realization of “Surveillance Capitalism” — a term coined by Shoshana Zuboff. It’s the business of harvesting human experience as raw material for behavioral data.

The Great Boycott and the “Pay or Okay” Trap

The public isn’t entirely asleep at the wheel. In fact, we are currently in the midst of the largest consumer boycott in human history. By 2015, Business Insider reported that over 200 million people were using Ad-Blockers. Today, that number is vastly higher. Entire operating systems (iOS) and browsers (Firefox, Brave) now ship with tracking protection enabled by default. People are actively fighting back against the “surveillance” part of the internet economy because the user experience has become hostile.

In response, companies have pivoted to the “Pay or Okay” model. You see this on news sites like Der Standard or Meta platforms: “Pay us €5/month or agree to let us track you.” They frame this as a choice between “supporting journalism” or “seeing ads.” That is a lie. The choice isn’t about seeing ads; it’s about selling your data to third parties. The “Okay” button authorizes a massive backend data trade that most users can’t even comprehend.

Legal activists (like those at noyb and epicenter.works) are currently suing over this model, arguing that privacy is a fundamental right that cannot be sold. You shouldn’t have to pay a ransom to keep your constitutional rights.

The Industrial Scale of Tracking

To grasp the scale of this industry, look at the “MarTech” (Marketing Technology) landscape. In 2011, there were about 150 companies in this space. By 2020, there were 8,000. By 2025, fueled by the AI boom, that number hit approximately 15,000 companies. That is a 100x growth (10,000%) in just over a decade.

There are thousands of companies you have never heard of that know more about your habits than your spouse does. Interestingly, the growth rate of this industry actually slowed down after the introduction of GDPR — proof that regulation does have a tangible impact on the market.

The Race to the Bottom of the Brainstem

The core mechanism of this industry is what experts call the “Race to the Bottom of the Brainstem.”

This concept describes how AI backend systems are optimized to keep you on a platform for as long as possible (Engagement). To do this, the algorithms have learned that the most effective way to grab your attention is not to appeal to your higher reasoning or your prefrontal cortex. That part of your brain is slow, lazy, and energy-intensive. Instead, the algorithms target the brainstem — the primal “lizard brain” responsible for survival instincts like fight-or-flight, fear, and outrage.

Scott Galloway, a Professor of Marketing at NYU, puts it bluntly: “Social media is nicotine… The thing that gives you cancer is the ad model.” The ad model necessitates algorithms that identify your political leaning and then enrage you with content from the “other side” to keep you clicking. This is “Escalating En-rage-ment.”

The consequences are visible everywhere: social media addiction, a mental health crisis among teenagers, massive societal polarization, and the spread of hate speech. We have been running this experiment on humanity for 15 years, and only now are we starting to ask if it’s a good idea.

The Paperclip Maximizer & The AI Dilemma

Tristan Harris and Aza Raskin (creators of The Social Dilemma) argue that this wasn’t necessarily a master plan by evil geniuses. It was an accident of “Instrumental Convergence.”

This is best explained by the thought experiment of the Paperclip Maximizer (playable as the game Universal Paperclips). Imagine you tell a super-intelligent AI to “maximize the production of paperclips.” It will do exactly that. It will turn all the metal in the world into paperclips. Then it will turn all the biomass (plants, animals, you) into paperclips. It doesn’t hate you; it just needs your atoms to make more paperclips.

Social media AIs are Paperclip Maximizers. Their instruction was “maximize watch time.” To achieve that, they figured out that radicalizing users, feeding them conspiracy theories, and destroying their sense of shared reality was the most efficient way to keep them scrolling. They didn’t “want” to destroy democracy; they just wanted to increase the “Time on Site” metric.

The Truth Disadvantage

The impact of this optimization was quantified in a massive 2018 study by MIT. They analyzed 126,000 stories tweeted by 3 million users over 10 years to see how truth and lies spread.

The results were devastating. Falsehoods dominated truth on every metric. Fake news reaches more people, penetrates deeper into the network, and spreads significantly faster than accurate stories. Specifically, a lie is 70% more likely to be retweeted than the truth.

The study found that this wasn’t just because of bots. It’s human nature. Lies are often engineered to be more novel, more shocking, and more emotionally stimulating than the boring, nuanced truth. The algorithms, detecting this high engagement, prioritize the lies and push them to the top of everyone’s feed.

This creates Quasi-Cults — small, isolated pockets of society that operate on a completely different version of reality. These “echo chambers” are reinforced by the platform. If you click on one conspiracy video, the “Paperclip Maximizer” realizes you like that flavor of dopamine and feeds you 50 more videos that are increasingly extreme.

Conclusion: It’s Not a Bug, It’s the Product

We used to think these issues — radicalization, misinformation, fragmentation — were unfortunate side effects. Bugs in the code. We now know that the Social Media giants have been aware of these problems for years. They choose not to fix them because fixing them would break the business model. You cannot solve the problem of “En-rage-ment” if your stock price depends on selling ads against that rage.

This leads us to the inevitable conclusion of the MIT study: We need a new information ecosystem. Since the companies are too profitable to change themselves, this change must be imposed from the outside through Policy. We have to intervene in the business model itself.

Coming Up in Part 4: We explore the fight for “Digital Sovereignty,” the death of the Libertarian Internet dream, and how the web transitioned from a “Home of Mind” to a corporate tyranny.

Part 4: Digital Sovereignty & The Death of the Libertarian Web

We have established that the current internet ecosystem is built on surveillance and behavioral modification. But how do we fix it? The immediate answer from the design and legal world brings us to the concept of Dark Patterns. These are user interface design choices meticulously crafted to trick you into doing things you didn’t intend to do — like buying insurance you don’t need, or, more relevantly here, agreeing to tracking you don’t want.

The Design of Deception

The classic example is the cookie banner. Under the GDPR, you have a legal right to say “no” to tracking. However, the design of these banners often makes the “Accept All” button a giant, flashing green beacon, while the “Reject” option is hidden behind three layers of menus labeled “Vendor Preferences” or “Legitimate Interest.” This is a Dark Pattern. It creates an illusion of choice where effectively none exists.

While the GDPR technically prohibits this, enforcement is the bottleneck. There is no “GDPR Police” patrolling the web. The European Commission doesn’t have a SWAT team that kicks down doors when a button is the wrong color. Enforcement relies heavily on private NGOs like noyb (None of Your Business) or epicenter.works to file lawsuits and force companies into compliance. This creates a “cat and mouse” game where regulation is always chasing implementation. However, we are seeing progress. The “Reject All” button is becoming more common, not because companies grew a conscience, but because the legal pressure from these NGOs is finally making the “Dark Pattern” strategy too risky.

Regulating the Echo Chamber

Beyond the interface, we are seeing attempts to regulate the algorithm itself. We discussed how algorithms create “Echo Chambers” to maximize engagement. Interestingly, China attempted to tackle this head-on about a year ago with a “General Clause” aimed at curbing algorithmic recommendation engines that lead to polarization. It is a fascinating test case: can a state actually legislate “code neutrality” or “anti-radicalization” into a recommendation engine?

We don’t know yet if it works. We do know that TikTok operates a completely different algorithm in China (Douyin) than it does in the West, promoting educational content over the “sugar-rush” content seen here. But while the EU watches this experiment with interest, hoping to find a regulatory model that works, the US has effectively abdicated all responsibility. We should expect zero meaningful regulation from the US in the near future regarding algorithmic transparency.

The Fight for Digital Sovereignty

This regulatory vacuum in the US forces Europe to lean into Digital Sovereignty. This is a buzzword that gets thrown around a lot, so let’s define it properly. It isn’t just about “European Cloud.” It has three distinct layers according to researchers like Pohle and Grohmann:

1. State Sovereignty: The ability of a country to control its own digital infrastructure and enforce its laws (cybersecurity, critical infra).
2. Economic Sovereignty: The ability of local tech companies to compete and innovate without being crushed or bought by US giants.
3. Individual Sovereignty: Your personal right to digital self-determination — the ability to act freely online without being manipulated by a black-box system.

The hard truth is that none of these three forms of sovereignty are compatible with using the services of the big US hyperscalers (Microsoft, Amazon, Google). Why? Because of the legal frameworks. In the US, the Foreign Intelligence Surveillance Act (FISA) and the CLOUD Act allow US intelligence agencies to force US companies to hand over data, even if that data is stored on servers in Europe. And — this is the kicker — the companies are often forbidden by law from telling you they handed it over.

This is why institutions like the International Criminal Court (ICC) have moved away from Microsoft products, and why the Austrian Armed Forces migrated to LibreOffice. You cannot be sovereign if your digital infrastructure has a legal backdoor to a foreign intelligence agency.

Big Tech knows this is a threat to their dominance, so they have invented a counter-move called “Sovereignty-as-a-Service.” They offer to run their software on local servers or “government clouds,” promising that the data stays in the country. It is a marketing trick to redefine “sovereignty” so that it no longer requires independence from their proprietary software stack. They want you to believe sovereignty is just about where the hard drive sits, rather than who controls the code and the legal jurisdiction.

The Death of the 1996 Dream

To understand how we lost this control, we have to look back at the ideology that built the web. In 1996, John Perry Barlow wrote the “Declaration of Independence of Cyberspace.” It was a reaction to the US government’s first clumsy attempts to censor the internet. Barlow, representing the ethos of the early engineers and hackers, wrote:

“Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind… You have no sovereignty where we gather.”

It was a beautiful, anarchic vision. The idea was that the internet was a separate dimension, immune to the laws of physical nations (“meatspace”). They believed that if they just kept the government out, a utopia of free information and peer-to-peer democracy would naturally emerge.

They were wrong.

The “weary giants of flesh and steel” (governments) did fail to understand the internet for a long time. They were incompetent. But because the libertarians fought so hard to keep the government out, they left the door wide open for corporations to walk in. The power vacuum was filled not by a “Civilization of the Mind,” but by Google, Facebook, and Amazon.

We traded the tyranny of the state (which is at least theoretically democratic and accountable) for the tyranny of the corporation (which is accountable only to shareholders). The “New Home of Mind” is now a mall where your thoughts are monitored, categorized, and sold.

The End of Laissez-Faire

Geert Lovink, a prominent net theorist, argues that the era of “Internet Laissez-Faire” is dead. The “multi-stakeholder” model — where a loose coalition of engineers, NGOs, and nice corporations governed the web — has collapsed. The libertarian bubble burst.

We are now in a phase where societies have realized that the internet is not an “exceptional” space that exists outside the law. It is the central nervous system of society, and allowing it to be run by ad-tech companies is destroying the host. We are witnessing the “Enshittification” of the internet (a term coined by Cory Doctorow). Platforms start by being good to users; then they abuse users to make things better for business customers; finally, they abuse those business customers to claw back all the value for themselves, leaving a dying platform filled with spam, scams, and algorithmic sludge.

The friction we feel right now — the lawsuits, the new EU acts, the privacy wars — is the sound of society trying to reassert control over a system that was left to rot for twenty years.

Coming Up in Part 5: The Grand Finale. We take everything we have learned — policy, bias, sovereignty — and apply it to the ultimate case study: Self-Driving Cars. We will cover the “Trolley Problem” distraction, the “Irony of Automation,” and the security nightmare of driving a computer at 130km/h.

Part 5: The Autonomy Trap & The Way Forward

We have spent the last four parts discussing the theory of policy, the history of the web, and the mechanisms of surveillance. Now, we are going to apply all of that to a single, concrete case study that embodies every single one of these tensions: Self-Driving Cars.

This is not a discussion about the technology of LIDAR or neural networks. This is a discussion about the societal impact of deploying robots into public spaces. And before we start, let’s clear the deck: We are not going to talk about the Trolley Problem. You know the one — should the car swerve to hit the nun or the baby? That is a philosophical parlor game that distracts us from the actual, systemic problems we are facing right now. It takes up 90% of the oxygen in the room but represents 0.001% of the reality. The real issues are economic, legal, and structural.

The Labor Displacement Crisis

The first massive policy challenge is labor. Millions of people work as drivers — truck drivers, taxi drivers, delivery personnel. Automation is a direct threat to their livelihood. We are currently in a predictable race: “Who can do it cheaper, the human or the machine?”

The industry narrative is that machines will take over the boring parts, leaving humans to do “higher value” work. But the reality looks different. We are seeing a future where trucks drive themselves on the highway, but human drivers are still needed for the complex “last mile” in cities or bad weather. What does that job look like? A driver might only be paid for the 20% of the time they are actually driving, turning a solid middle-class job into precarious gig work.

Furthermore, “autonomous” often just means “remote controlled.” There are already setups where “driverless” taxis are actually being monitored and guided by remote workers in call centers, sometimes with a ratio of more than one human per car to handle the edge cases. We aren’t necessarily eliminating drudgery; we might just be moving the driver from a truck cab to a cubicle, stripping away the autonomy of the open road and replacing it with the stress of only handling crisis situations.

The Irony of Automation

This leads us to a psychological paradox known as the Irony of Automation. The theory states that the more reliable we make an automated system, the less capable human operators become at stepping in when the system fails.

When a system works perfectly 99% of the time, the human operator checks out. They lose “situational awareness.” They lose the muscle memory and the routine required to handle the vehicle. We saw this in aviation years ago. A 2013 FAA study found that pilots were becoming so dependent on autopilots that their manual flying skills were degrading, posing a significant risk in emergencies.

This creates a “Bathtub Curve” of safety. Initially, automation reduces accidents by removing human error from routine tasks. But as automation increases, accidents might actually spike again because when the machine finally does encounter a situation it can’t handle (a “disengagement”), it hands control back to a human who is bored, distracted, and unskilled.

Legally, we try to paper over this with rules. In Nevada or Washington, regulations require a “driver” to be behind the wheel, ready to take control at any moment. But this is a legal fiction. We know humans are terrible at passive vigilance. We have seen drivers using “steering wheel weights” to trick the car’s sensors into thinking they are holding the wheel while they sleep or play games. The technology encourages complacency, but the policy insists on hyper-vigilance. It is a design contradiction.

The Black Box of Liability

When a crash inevitably happens, we hit the problem of responsibility. Who is to blame? The driver? The manufacturer? The coder who wrote the neural net?

Currently, manufacturers have a massive information advantage. The car is recording everything, but that data belongs to the company. In 2016, a Tesla Model X crashed into a building. The driver claimed the car accelerated on its own. Tesla looked at the logs and said, “No, the accelerator was pressed to 100%.” Case closed.

But this creates a conflict of interest. If the software was at fault, would the company voluntarily release the data that proves their product killed someone? We have already seen instances where hackers had to extract data from wrecked cars to contradict the official company narrative.

Ethicist Blay Whitby proposes a policy trade-off: We should treat autonomous vehicles as a valuable experiment. We should lower the liability for manufacturers to encourage innovation, but in exchange, we must demand radical transparency. This means open access to source code and mandatory, standardized ethical audits. If you want to test your robot on our roads, we need to see how it thinks.

The Framing Problem & Techno-Solutionism

We also need to zoom out and ask: Are we solving the right problem? This is the trap of Techno-Solutionism — the belief that every societal issue has a technical fix.

We are spending billions to make cars drive themselves, assuming that “better cars” is the goal. But self-driving cars do not solve the problem of space. A self-driving car takes up just as much room in a crowded city as a normal car. It still requires massive asphalt infrastructure, leading to soil sealing. It still produces microplastics from tire wear (a huge environmental issue).

By framing the problem as “how do we automate driving,” we ignore the better question: “How do we reduce the need for cars?” We could solve traffic, pollution, and safety much more effectively by investing in public transit and walkable cities. But that isn’t a “tech” solution, so it gets less attention.

The Driving Bomb: Security Risks

Finally, we have to talk about security. A modern car is a computer on wheels. And like all computers, it has bugs. It has vulnerabilities. Estimates suggest 30-50% of personal computers have some form of malware. That is annoying when it’s your laptop. It is a life-or-death crisis when it is a two-ton metal projectile moving at 130 km/h.

Imagine a ransomware attack on a highway. A message pops up on your dashboard: “Send 1 Bitcoin to this wallet in the next 10 minutes, or we disable the brakes.”

This is not science fiction. The internal architecture of most cars relies on the CAN bus (Controller Area Network). This is an ancient standard from the 80s that connects everything in the car — the engine, the brakes, the radio, the wipers. Crucially, the CAN bus traditionally has no internal security. If a hacker gets into the radio (via Bluetooth or WiFi), they are on the same network as the brakes. They can send a “brake now” command, and the car obeys. We are putting insecure, hackable networks on the highway and hoping for the best.

Conclusion: Returning to the Three Theses

So, where does this leave us? We have seen that policy thinking is not just about writing laws; it is about understanding the complex feedback loops between code, commerce, and culture.

We can look at initiatives like the “Contract for the Web” by Tim Berners-Lee, which tries to create a voluntary standard for a better internet. These private governance models are noble, but they are rarely enough on their own.

Ultimately, we circle back to the Three Theses we started with:

1. Technology is not neutral. A self-driving car, a social media feed, or a privacy policy — these are not neutral tools. They actively shape who has power and who has agency in our world.
2. We have privatized a political arena. We let tech companies decide the rules of speech, the rules of the road, and the rules of privacy. We treated these as business decisions rather than political ones.
3. The industry will not regulate itself. History shows that the tech industry will deflect, ignore, and bypass regulation to protect its business model.

Policy Thinking is the discipline of taking that power back. It is about recognizing that “Code is Law,” and if we want to live in a democracy, we need to have a say in writing that code.

This concludes the 5-Part Series on Policy Thinking. Thank you for reading!

To understand why modern software often frustrates us, we have to look at the failures first. We need to analyze why, despite decades of technical advancement, we still encounter interfaces that feel like they were designed by aliens for aliens. Before we get into the theory of Design Thinking, let’s look at three specific examples that illustrate the landscape of “bad design.” These aren’t just aesthetic failures; they are structural failures in how we think about problems.

The Functionality Monster and the Context Switch

Consider the classic “Bulk Rename Utility.” This type of software attempts to solve a very specific, annoying problem: renaming a massive number of files in a file manager. For those comfortable with a Command Line Interface (CLI), this is trivial — provided you remember the correct regex or syntax for the Linux rename command. But for the average user, the CLI is a barrier. Early GUI developers saw this and decided to build visual tools. The result, however, is often a “monster” dialog box. Imagine a single window where a developer has attempted to cram every possible permutation of renaming logic — timestamps, numbering, extension handling, replacement strings — into one view.

The issue with these utilities isn’t that they lack functionality; it’s that they prioritize the existence of the function over the human who uses it. This is the archetype of “Function Follows Function.” The developer assumes that as long as the code can technically perform the task, the job is done. The layout, hierarchy, and clarity are afterthoughts, often decided by where a button happens to fit on the grid rather than where it makes cognitive sense. This points to a deeper issue in engineering culture: the technical capability and ease of implementation are valued higher than the cognitive cost paid by the user.

Then we have the issue of error messages. Straight up, error messages are a failure of design. Even “good” error messages are problematic because they force a hard context switch. When you are in the flow of work and a dialog pops up, you are forced to dump your current mental context to process the error. It is a violent interruption. Worse, the language often bleeds internal technical details into the user space. You might see a prompt asking if you want to “Mark as deleted” versus “Delete,” a distinction that makes perfect sense in a database schema but zero sense to a user just trying to clear a file. The internal logic of the system forces its way to the surface, demanding to be understood, rather than the system understanding the user.

High Stakes and “Dangerous” Design

Bad design isn’t just about annoyance; it has a body count. In 2017, the USS John S. McCain collided with the Alnic MC, resulting in the deaths of ten sailors and over $230 million in damages. That is roughly the total budget of a mid-sized European university. The subsequent investigation didn’t just find human error; it found a systemic failure in the User Interface. The ship used a complex touch-screen navigation system that confused the operators.

This tragedy highlights a critical paradox in automation. We build systems to automate complex tasks, but when those systems malfunction or reach their limits, we hand control back to a human operator. The problem is that the operator, now out of the loop and relying on a confusing interface, is the least equipped person to handle that sudden spike in complexity. We cannot simply blame “user error” when the system itself is designed to provoke confusion.

The Fallacy of the Problem-Based Approach

In Computer Science and engineering, we love the “Problem-Based” approach. It feels rigorous. We define a problem, we analyze it, and then we solve it. It aligns with the “Feynman Algorithm” of thinking: write down the problem, think very hard, write down the solution. This is deeply embedded in how we teach programming and project management. The classic Waterfall model is built on this foundation: you create a massive Requirements Document (often called a Pflichtenheft) that defines the problem in exhaustive detail. The assumption is that if we work hard enough on this document, we will arrive at a single, immutable, “true” definition of the problem.

The industry has historically relied on this document to answer all future questions during implementation. It assumes the problem exists independently of us, sitting there like a rock waiting to be measured. But reality disagrees. The Standish Group’s Chaos Report (2015) analyzed 50,000 projects and found that this problem-based, “define it first” approach doesn’t just fail to guarantee success — it actually increases the risk of failure.

This is where the distinction between “Problem-Based” and “Solution-Based” (Agile) becomes critical. In a solution-based approach, we accept that we don’t fully know the problem yet. We create iterations of solutions not just to fix the problem, but to find the problem. The problem definition changes as we try to solve it.

The Myth of the “Defined Task”

We need to challenge a core definition of Computational Thinking. Gerald Sussman defined it as “rigorous analysis and procedures for accomplishing a defined task efficiently.” The trap here is the phrase “defined task.”

For a task to be truly defined, the problem must be stable. It must be indisputable. This works for solving a quadratic equation, moving the Tower of Hanoi, or sorting a list of integers. These are what we call “Tame Problems.” They are mathematically solvable, and their definitions don’t change. But the moment you introduce humans into the equation, the idea of a “defined task” crumbles.

We have known this for decades. In their seminal 1986 paper, A Rational Design Process: How and Why to Fake It, Parnas and Clements admitted that determining detailed requirements is the hardest part of software design because the people commissioning the system usually do not know what they want. They are unable to tell us everything we need to know until they see the implementation progressing. The “requirements” are not a static target; they are a moving ghost.

Wicked Problems vs. Tame Problems

If most problems aren’t “Tame,” what are they? In the late 1960s and early 70s, Horst Rittel and Melvin Webber coined the term “Wicked Problems.” They were looking at social planning, but their findings map perfectly to modern software engineering.

A Wicked Problem is a problem you cannot understand until you have developed a concept of the solution. You cannot gather information meaningfully unless you understand the problem, but you can’t understand the problem without information. It is a circular paradox. Unlike Tame Problems, Wicked Problems have no “stopping rule” — you don’t stop because you solved it; you stop because you ran out of money, time, or patience.

Here is the deal with Wicked Problems:

• No Definitive Formulation: You cannot write a perfect specification for them.
• No “True” or “False”: Solutions are only “better” or “worse.”
• One-Shot Operation: Every attempt counts. You can’t just reset the simulation without consequences (like implementing a social policy or deploying a live system).
• Uniqueness: Every Wicked Problem is essentially unique.

Henrik Gedenryd’s dissertation, How Designers Work, provides a perfect example of this. He describes a developer building spreadsheets for a CFO. The developer would build exactly what was asked for, and the CFO would look at it and say, “That’s not what I wanted.” It wasn’t until the CFO saw the model that he could articulate what he actually needed. The early versions were not “waste”; they were necessary inquiries to discover the actual problem. The problem setting spanned the entire process.

The Shift to Design Thinking

This brings us to the core realization: If humans are involved, every problem is a Wicked Problem.

Mathematical thinking works for Tame Problems. It relies on reduction and abstraction to create proofs. If we can model a phenomenon mathematically, we can wield the superpower of the “Proof.” But this only covers a tiny fraction of the world. The rest of the world is messy, human, and wicked.

When we treat Wicked Problems as if they were Tame Problems — when we force them into a rigid Waterfall process or a strict Requirements Document — we fail. We see this in “Smart City” diagrams that depict traffic and energy flow but contain no actual humans. We are taming the problem by ignoring the variables that make it difficult. But those variables always come back to bite us. Requirement volatility is consistently cited as the core problem of software engineering. This volatility isn’t a bug; it’s a feature of Wicked Problems.

Design Thinking, therefore, is not about making things pretty. It is the methodology we use to tame the wicked. It is the recognition that problem definition and problem solution must happen simultaneously.

Coming Up in Part 2: We dive into the history of HCI, why “feature creep” is destroying your product, and the “Entanglement” theory that suggests we are no longer separate from our machines.

Part 2: The Human-Centered Imperative & The History of “Clicking Things”

If Part 1 established that “Wicked Problems” are the true final boss of engineering, then Part 2 is about the weapon we chose to fight them. That weapon is Human-Computer Interaction (HCI). We can lay down a fundamental axiom right here, right now: If humans are involved, every problem becomes a Wicked Problem.

This isn’t just a philosophical stance; it is a practical reality. Human needs are not independent variables. They are deeply entangled with context. If the context changes — say, a user moves from a quiet office to a noisy train — their needs change instantly. This volatility makes it impossible to create those “true” a priori problem formulations we love in engineering. The discipline that emerged around 1980 to tackle this volatility is HCI. It is effectively the scientific application of Design Thinking within computer science.

Andrea Bianci, a researcher in the field, once framed it perfectly: HCI focuses on designing interactive systems that are both productive and pleasurable. This is a massive expansion of the old “Form Follows Function” doctrine. It acknowledges that productivity isn’t the only metric; the human experience of using the tool matters. The Association for Computing Machinery (SIGCHI) defines it as the discipline concerned with the design, evaluation, and implementation of interactive computing systems for human use. But even that definition is starting to creak under the weight of reality. As Ben Shneiderman noted back in 2011, HCI has grown from a small, rebellious group of researchers fighting for recognition into a community that impacts the daily lives of every human on earth.

Buxton’s Law and the Complexity Trap

Why is this focus on the human so critical right now? Because of a little thing called “Buxton’s Law.” We all know Moore’s Law, which predicts the exponential growth of computing power and capacity. Buxton’s Law acts as the counterweight: while technology’s complexity and capacity skyrocket, human capacity does not. Our cognitive bandwidth is roughly the same as it was 50 years ago.

Technological artifacts — software, gadgets, and the “hidden” computers inside everything from washing machines to sex toys — have utilized Moore’s Law to pack in more and more functions. This leads to an explosion of complexity in the User Interface. If the machine gets twice as complex every 18 months, but the user doesn’t, you have a usability crisis. This necessitates a shift from “Can we build it?” to “Should we build it, and how?”

This perspective shifts the center of gravity from the technology to the life of the person using it. Historically, we called this “User-Centered Design,” but even that term is problematic. “User” implies a person pressing buttons. But what about the person whose career is decided by an automated HR algorithm? They aren’t “using” the software, but they are definitely affected by it. “Human-Centered Design” is better, but “Life-Centered Design” or “Humanity-Centered Design” might be where we need to land, acknowledging that our systems impact the environment and society at large.

We are also seeing a dark inverse of this principle today, often called “Enshittification” (a term coined by Cory Doctorow) or the “Rot Economy.” This describes the lifecycle where platforms start by being good to users to gain critical mass, then abuse users to make things better for business customers, and finally abuse both to claw back value for shareholders. It is the deliberate degradation of the user experience for profit, a sign of what happens when Human-Centered Design is abandoned for profit maximization.

The Three Waves of HCI

To understand where we are, we have to look at the “Waves of HCI.” This history tracks how our relationship with the machine has morphed.

The First Wave: Man-Machine Coupling. Back when computers were room-sized monoliths, HCI was about “Human Factors.” It was physical. The focus was on the knobs, dials, and switches. How should the lights be arranged? What is the optimal keyboard layout (spoiler: it remained the typewriter layout)? How big must the font be on a CRT monitor so a specialist doesn’t go blind? This era was about coupling an expert human to a machine to optimize throughput. It was industrial.

The Second Wave: Cognitive Coupling. Then came 1981, the IBM PC, and the “Mother of All Demos.” Suddenly, computers were on desktops in offices, used by non-specialists. The physical interaction wasn’t the bottleneck anymore; the mental interaction was. The Second Wave viewed the human and the computer as two information processors that needed to talk. The goal was to design tools that helped us “think better.” This is where the desktop metaphor, files, folders, and the WIMP (Windows, Icons, Menus, Pointer) paradigm solidified.

The Third Wave: Social and Entangled. Then the internet happened. Then mobile happened. Computers ceased to be tools for “defined tasks” and became the infrastructure of our social lives. We don’t just “process information”; we hang out, we play, we create culture. This Third Wave recognized that technology is not external to us. We are now in an era of “Entanglement HCI,” where we are inseparable from our devices. The technology is pervasive, embedded, and constant.

Case Study: Honeywell vs. The Nest

Nothing illustrates the failure of old-school engineering thinking versus Design Thinking better than the Battle of the Thermostats.

Honeywell was the king of thermostats. For decades, they dominated the US market. But they fell victim to “Second Product Syndrome.” This is a phenomenon where a successful company pours all its money into incrementally improving its existing cash cow rather than risking innovation. Over the years, Honeywell thermostats became complex beige boxes. They added a small computer inside, which meant they could add a small LCD screen and more buttons. They essentially took the same confusing interface and digitized it. It was powerful, programmable, and utterly hostile to the average human.

Then came Nest in 2011. It didn’t look like a piece of industrial equipment; it looked like a piece of jewelry. It was a sleek, round glass dial. But the real revolution wasn’t the shape; it was the interaction model. Nest didn’t ask you to program a schedule on a tiny, low-res screen. It asked you to just turn it up when you were cold and down when you were hot. It learned your habits. For the complex stuff, it offloaded the UI to a smartphone app, where the interface could be rich and intuitive.

Honeywell was horrified. How could a startup outclass them in their own domain? To his credit, Honeywell CEO David Cote didn’t just sue; he realized they had a cultural problem. He saw that in his consumer life, things were getting easier to use, but in his industrial sector, they were stagnant. Honeywell initiated a massive corporate pivot, embedding Design Thinking not just as a visual layer, but as a management philosophy. They built Design Studios and forced upper management to attend design workshops. They moved from a culture of “features” to a culture of “experience.” The result? A massive turnaround in stock price and relevance.

The ROI of Design

This isn’t just about feeling good. There is hard data backing the “vibe.” The Design Management Institute (DMI) tracks the “Design Value Index,” a portfolio of design-centric companies. These companies — who treat design as a core strategy rather than a cost center — consistently outperform the S&P 500 by significant margins (often over 200%).

Design is not a luxury. It is not a coat of paint you apply at the end of the engineering process. It is a core component of business strategy. If you ignore it, you end up like the old Honeywell — rich, established, and waiting to be disrupted by a thermostat that actually knows what it feels like to be human.

Coming Up in Part 3: We get into the gritty theory of “Inquiry” — why you have to build things to understand them — and the specific Heuristics you need to memorize to stop building garbage interfaces.

Part 3: The Theory of Inquiry & Core Heuristics

We have established that the problems we face in modern engineering are “Wicked” and that Human-Computer Interaction is our primary weapon against them. But wielding this weapon requires more than just good intentions; it requires a fundamental shift in how we process information and a strict adherence to a set of operational laws. The execution of Design Thinking rests on a theoretical foundation that demands we look outside of computer science, accept the limitations of human perception, and embrace a chaotic, iterative path to the truth.

The Interdisciplinary Requirement

You cannot design effective software if you only understand software. To build systems that function seamlessly for humans, you must possess a working knowledge of the hardware of the human being. This is why the field of Interaction Design is inherently interdisciplinary. It starts with the hard physiological constraints of our bodies. We need to understand how eyes perceive color to avoid poor contrast, we need to know the visual angle required for a font to be legible, and we must consider the physical posture of a user to prevent fatigue or repetitive strain injury.

Beyond physiology, we must delve into psychology. A designer needs to grasp the limits of human attention, how we parse visual hierarchies, and the finite capacity of our working memory. It even extends into organizational theory, asking how teams function and what workflows minimize error. Looking at the landscape of the field, we see a convergence of the hard sciences like engineering, the human sciences like psychology and sociology, and the artistic disciplines of graphic and industrial design. You do not need to be a PhD in all of these fields, but you must be able to communicate across their boundaries. You need to respect that a cognitive psychologist might understand the cognitive load of your navigation bar better than your senior backend engineer does.

The Distorting Mirror

Engineers and computer scientists think differently than the rest of the population. A classic paper from 1990 confirmed that our mental models are fundamentally distinct; we prioritize efficiency, edge cases, and the mantra of “Faster, Cheaper, Smaller, More.” When we build software based solely on our own mental models, the result is what we call a “Distorting Mirror.” The technology ends up reflecting the creator’s mind rather than the user’s needs. If an alien archaeologist were to dig up our legacy keyboards and interfaces, they might deduce that humans possessed twenty fingers and a laser-sharp photographic memory.

To succeed, a product must stop being a distorting mirror and start reflecting the actual capabilities of the human using it. This requires a pivot from “Technology-Centered” design, which solves problems based on what the silicon can do, to “Human-Centered” design, which solves problems based on who is doing the work, and where, when, and why they are doing it. Critically, this often means ignoring what users explicitly say they want. Users are notoriously bad designers. If you ask them, they will request specific features that they think will solve their pain. If you observe them, however, you will see the messy reality of their workflow and the true underlying needs. As the apocryphal Henry Ford quote suggests, if he had asked people what they wanted, they would have asked for faster horses. Design Thinking requires you to look past the “horse” to see the desire for speed and efficiency.

The Theory of Inquiry

The theoretical core of how we navigate this uncertainty comes from the concept of “Inquiry.” The traditional “Feynman Algorithm” — write down the problem, think hard, write down the solution — fails spectacularly when applied to Wicked Problems. Instead, we look to John Dewey’s “Theory of Inquiry” and Donald Schön’s concept of the “Reflective Practitioner.” Schön distinguishes between “reflection-in-action,” which is the act of thinking while doing — tweaking the code as you write it because it just feels wrong — and “reflection-on-action,” which is the analysis that happens after the fact.

This leads us to the concept of “doing for the sake of knowing.” Consider how you solve a mechanical puzzle like a Rubik’s Cube. You rarely solve it by placing it on a table, staring at it, and calculating the algorithmic path in your head. You solve it by picking it up and twisting it. The physical action generates information. You try a move, observe the result, and that result informs your next move. In Design Thinking, the process of creating a prototype is not just about implementing a solution; it is a tool for understanding the problem itself. Every prototype is a hypothesis, and every failure is a data point.

This chaotic journey is famously visualized as the “Design Squiggle” by Damien Newman. The process begins on the left with a tangled, chaotic knot of lines, representing the “Research & Synthesis” phase where everything is noisy and uncertain. As you progress to the middle, the lines begin to straighten out as concepts form and patterns emerge. Finally, on the right, you achieve a single, straight line representing the final design and focused clarity. Unlike the rigid Waterfall model, Design Thinking is an open process where analysis, synthesis, and evaluation happen simultaneously. When you sketch a button, you are analyzing the layout, synthesizing a solution, and evaluating its aesthetic all at the same moment.

Heuristics for Interactive Systems

With the theory established, we must turn to the hard rules — the “Heuristics” — that govern good interactive systems. These are the operational commandments for creating sanity in software.

The first and most critical heuristic is Communication and Feedback. The system must constantly talk to the user. This happens passively through “Affordance,” where elements visually describe how they should be used, but also actively through feedback loops. If a user clicks something, the system must respond immediately. For short actions, a change in cursor or button state suffices; for longer actions, a progress bar is mandatory. The rule is absolute: never leave the user guessing “Did it work?”

This ties directly into the concept of Affordance, a term borrowed from industrial design. A physical door handle “affords” pulling, while a flat plate “affords” pushing. If you have to put a sign on a door saying “PUSH,” the design has failed. In the digital realm, we simulate this. We use shadows and gradients to make buttons look raised, inviting a push. We use ridges on scrollbars to metaphorically suggest the grip of a bottle cap. If a non-clickable element looks like a button, you are effectively lying to your user.

Structure and Consistency form the backbone of a navigable system. We call this Information Architecture. Similar things must look similar, and different things must look different. The user should always be able to answer three questions: Where am I? Where did I come from? How do I get back? This requires internal consistency — if “Save” is a blue button on one page, it cannot be a red link on another — and external consistency, which means adhering to platform standards. Do not reinvent the wheel; if Ctrl+C means copy in every other application, making it “Clear All” in yours is an act of hostility.

We must also respect the limits of Human Perception. Humans are excellent at Recognition — seeing an icon and knowing what it is — but terrible at Recall — remembering a specific command name from memory. Good design relies on recognition, minimizing the cognitive load required to use the tool. This extends to readability, ensuring font sizes, contrast ratios, and color choices accommodate human biology.

Efficiency is governed by the 80:20 Rule. You should identify the 20% of features that users engage with 80% of the time and make those immediate, one-click actions. The remaining 80% of features, which are rarely used, should be tucked away in menus or secondary screens. The goal is to provide accelerators for power users while maintaining clear, uncluttered paths for beginners.

Finally, we must prioritize Clarity and Control. Every action needs a defined beginning and a clear confirmation of completion. But more importantly, we must prioritize “Undo” over error messages. An error message effectively tells the user, “You are stupid, stop.” An Undo function tells the user, “Don’t worry, explore, I have your back.” By allowing users to reverse their actions, you give them the confidence to explore the system without fear of breaking it. If you must show an error, speak human language, not error codes. But the ultimate goal is to design a system where the error is impossible to commit in the first place.

The Product Experience

Beyond the functional mechanics, we must address the “Product Experience,” or the feel of the system. This is not just visual aesthetics; it is Interaction Aesthetics. Paul Hekkert defines this as the “gratification of senses,” but in software, we often refer to it as “Pliability.” Pliability describes the user’s sense of shaping a malleable material. When you drag a file on a smartphone and the icons shift out of the way fluidly, that is pliability. It feels responsive, tight, and alive. This creates an emotional bond. If a tool makes a user feel smart and capable, they will love it. If it makes them feel stupid by throwing constant errors, they will hate it. The goal is to achieve a sense of joy and excitement — a feeling that the system is not just a tool, but an extension of the user’s own intent.

Coming Up in Part 4: The Practitioner’s Toolkit — Why you need to sketch (not prototype) 2,500 times, the difference between “Opportunity Seeking” and “Decision Making,” and why your first idea is probably your worst.

Part 4: The Practitioner’s Toolkit

We have spent a lot of time on the philosophy of the “Wicked Problem” and the history of HCI. Now we need to look at the actual mechanics of doing the work. If Design Thinking is an “Open Process” where analysis, synthesis, and evaluation happen simultaneously, how do you actually structure your day? How do you move from a vague sense of a problem to a shipped product without falling into the trap of building the wrong thing?

The first hurdle you will face is your own brain. In design theory, we talk about the concept of the Primary Generator. This is the technical term for that first, lightning-bolt idea you get when you hear a problem description. You know the feeling: a client describes a need, and immediately, a solution pops into your head. It feels like intuition, or experience, or even genius. But in the context of Wicked Problems, this primary generator is dangerous. These early ideas act as blinders, creating a tunnel vision that forces you toward a specific solution before you have actually understood the problem.

To truly embrace an open design process, you have to learn to “kill your darlings.” A great example of this comes from a group of students who created the game And Yet It Moves. The initial concept relied on a specific mechanic where the player would “fling” the mouse to rotate the world 90 degrees. It was their primary generator, the core hook they were excited about. But during prototyping, it became clear that this mechanic turned the game into a test of dexterity rather than a puzzle platformer. It was only by discarding their original “genius” idea that they were able to uncover the better game underneath — a game that eventually launched on the Nintendo Wii. You must actively seek uncertainty at the beginning of the process. You have to climb the hill of ambiguity rather than rushing for the first comfortable solution.

This approach is exemplified by Graham Whiteley’s work on the “Sheffield Arm.” Whiteley started with a whimsical goal: he wanted to build a better mechanical arm for an animatronic drinking robot in his favorite pub. His first thought was to use existing medical prosthetics, but he quickly found them totally unsuitable. Instead of trying to force the existing solution to fit, he embarked on a process of Research through Design. He didn’t write a specification; he built sketches. He built prototype after prototype, creating physical objects that he could put into the hands of surgeons and osteopaths.

What happened next is key: the experts didn’t just look at diagrams; they manipulated the physical prototypes with their hands, using their tacit, embodied knowledge to give feedback like “this joint is too stiff” or “this needs more resistance.” By “moving all horses at once” — building, testing, and analyzing simultaneously — Whiteley ended up creating a breakthrough in bionics that went far beyond a pub robot. He didn’t solve the problem by defining it first; he defined the problem by trying to solve it.

The Blur of Analysis and Synthesis

In a traditional engineering workflow, you might have a phase for requirements gathering followed by a phase for design. In Design Thinking, these blur together. We use tools like Personas and Scenarios, but not as bureaucratic paperwork. A Persona is not just a demographic checklist; it is a tool to keep the user present in the room. Our brains are wired to remember people, not lists of requirements. If you can say “This feature will confuse Martha,” you are accessing a much faster, more empathetic mode of evaluation than if you reference “User Requirement 4.2.”

Similarly, Scenarios are narratives. They are stories about people using your system to achieve a goal. Writing a scenario forces you to deal with the timeline of interaction, the context, and the inevitable “edge cases” where things go wrong. It creates a context where non-functional requirements become visible. You aren’t just listing features; you are simulating the reality of the usage.

The Art of Sketching

The most potent tool for this simultaneous analysis and synthesis is Sketching. Do not confuse this with drawing art. In design, a sketch is a tool for thinking. Bryan Lawson calls it the “thinking pen.” Designers often say they cannot “speak” or think about a problem without a pencil in hand. The sketch is a conversation between the designer and the problem. You draw a line, and that line asks a question. You draw another, and it answers it.

Crucially, sketching is distinct from prototyping. The difference lies in the intent. You sketch to explore; you prototype to decide. A sketch is cheap, fast, and disposable. It is low-fidelity by design. The “roughness” of a sketch is a feature, not a bug, because it invites interpretation. If you show someone a polished, pixel-perfect mockup, they will critique the font choice. If you show them a rough pencil sketch, they will critique the concept.

Consider the case of the software ProfCast. The creators generated over 2,500 sketches before they settled on the final design. That number seems absurd until you realize that sketching is fast. It is a volume game. You sketch to get the bad ideas out of your system, to explore the impossible, and to find the unexpected connections. If you are precious about your sketches, you are doing it wrong. You should be willing to throw them away instantly. This is where modern “Vibe Coding” — using AI to generate throwaway interactive snippets — can actually be useful. If you treat the code as disposable as a napkin sketch, it becomes a powerful tool for inquiry. But if you start trying to ship that code, you have moved from sketching to bad engineering.

Sketching is not limited to paper. One of the most famous sketches in tech history was a block of wood. Jeff Hawkins, the creator of the Palm Pilot, walked around for weeks carrying a piece of wood cut to the size of his proposed device. He would pull it out of his pocket to “check his schedule.” He would tap on the wood with a “stylus” (a chopstick). He used this physical roleplay to understand the form factor. He discovered that people interacted with the device differently depending on whether he handed it to them vertically or horizontally. He learned about the ergonomics and the social acceptability of the device before writing a single line of code or soldering a single circuit. This is the essence of a sketch: it costs nothing, but it generates massive insight.

We can also do “Interaction Sketches” using video. In one example, designers wanted to test a concept for smart toy cars. Instead of building complex robotics, they simply filmed standard toy cars being moved by magnets under a table. This “Wizard of Oz” approach allowed them to test the experience of the interaction without solving the engineering challenges first. They could ask “Is this fun?” before asking “How do we build it?”

Mental Models and the Delete Button

Finally, all of this sketching and modeling is aimed at one goal: aligning the system with the user’s Mental Model. A mental model is the internal theory a user builds about how your system works. These models are often based on superstition and guesswork rather than facts.

A classic example is the “Clear” button on a calculator. Many people press the “C” button multiple times before starting a new calculation. Why? Because on some older calculators, pressing “C” once only cleared the last entry, while pressing it twice cleared the whole memory. Users formed a defensive mental model: “Pressing it many times is safe.” Even though modern calculators rarely work this way, the behavior persists.

Your job as a designer is to create a system that helps the user build a correct mental model. You do this through consistency, clear feedback, and logical grouping (Grids). If your design is erratic, the user will form a superstitious, defensive model. If your design is consistent and transparent, the user will form a confident, robust model. You are not just building a product; you are teaching the user how to understand it.

Coming Up in Part 5: The traps that ruin everything — Featuritis, Solutionism, and the dark world of Deceptive Patterns.

Part 5: The Traps of Modern Design

We have covered the theory, the history, and the toolkit. Now we have to talk about how it all goes wrong. Even with the best intentions and a stack of Personas, projects frequently derail. They usually fall into one of three specific traps: Featuritis, Solutionism, or the ethical void of Dark Patterns. Understanding these traps is the only way to avoid building software that people hate.

The Trap of Featuritis

The most common disease in software development is Featuritis, also known as Feature Creep or Software Bloat. It is the uncontrolled growth of functionality. We often assume that adding a feature adds linear value to a product, but the complexity of the user interface tends to grow quadratically with the number of functions. Remember the “Bulk Rename Utility” we discussed in Part 1? That monstrous dialog box didn’t happen because the developers were malicious; it happened because they likely started with a simple tool and kept adding “just one more thing” until the interface collapsed under its own weight.

There is a perverse incentive structure driving this. Media outlets compare products using feature tables, forcing companies to tick boxes to remain competitive. Marketing departments demand new bullet points for the next release. But the most dangerous pressure comes from the users themselves. Peter Sikking, in a conversation on the Chaosradio podcast, compared users to children in a candy store: they will always say “yes” to more features, even if the sugar rush eventually gives them a stomach ache. For a developer, adding a feature is the path of least resistance. It is quantifiable work. Removing a feature, or spending weeks refining an existing one to be simpler, is much harder to justify to a project manager. It often looks like a step backward, even if it is the only way to save the product.

This leads to what Kathy Sierra calls the Featuritis Curve. There is a “Happy User Peak” where capability meets usability. Push past that, and the user experience falls off a cliff. The tragedy is that when users encounter bloated software, they rarely blame the software. They say, “I am too stupid for this,” or “I am not technical enough.” When a user says they are too stupid to use your tool, what they are actually saying is that your tool has become so complex that the cognitive load required to operate it outweighs the value it provides. Sierra suggests that we must stop listening to what users say they want and start listening to the motivation behind their requests. We have to trust ourselves enough to say no.

Consider the cautionary tale of AltaVista. Before Google, AltaVista was a dominant search engine. In an attempt to not “patronize” the user or limit their options, they added everything to the homepage: specialty searches, hierarchical indices, news tickers, and advanced search forms. They offered maximum choice, which resulted in maximum cognitive overload. Google arrived with a single text box and a single button. They understood the principle of Simplicity. As industrial design legend Dieter Rams famously put it, good design is “as little design as possible.” It is about omitting the unessential to let the essential speak.

The Trap of Solutionism

The second trap is Solutionism. This is the fancy term for the “when you have a hammer, everything looks like a nail” problem. It describes the tendency to view every problem as a nail that can be hammered down with the latest technology. We see a problem and immediately assume the solution is an app, a blockchain, or a touchscreen, without asking if that technology is actually appropriate for the context.

This brings us back to the tragedy of the USS John S. McCain. The investigation into the collision revealed that the shift from physical throttles to touchscreens was a primary factor in the disaster. Under normal conditions, a touchscreen is fine. But under the extreme stress of a collision course, the lack of physical affordance became fatal. A physical lever tells your hand where it is without you looking at it. A touchscreen demands your visual attention. The feedback from the fleet was unanimous: “Just give us the throttles.”

This is a clear case where Design Thinking would have saved lives. If the engineers had focused on the human need (controlling a massive ship under high cognitive load) rather than the technological capability (we can put this on a screen), they would have kept the physical controls. We are seeing a similar correction in the automotive industry right now. After years of burying climate controls in sub-menus on touchscreens, manufacturers like Volkswagen are bringing back physical buttons. They realized that taking your eyes off the road to adjust the temperature is fundamentally bad design, no matter how modern the dashboard looks.

The Trap of Dark Patterns

If Featuritis is negligence and Solutionism is naivety, then Dark Patterns are malice. These are user interface design patterns that are carefully crafted to trick users into doing things they didn’t mean to do. This is often called “Deceptive Design.” As a designer, you wield significant power over human behavior, and using that power to manipulate users is an ethical failure.

We see this everywhere in “Cookie Banners.” You land on a site, and there is a massive, bright green button that says “Accept All.” If you want to reject them, you have to find a tiny, grey, unstyled link that says “Preferences,” navigate through three sub-menus, and manually toggle off individual vendors. The design uses color theory and visual hierarchy to exhaust the user into submission. This is not an accident; it is a calculated decision to prioritize data collection over user intent.

Krisztina Szerovay’s “UX Knowledge Base” visually documents these patterns, showing how interfaces use confusing language (“double negatives”), hidden costs, and forced continuity to exploit human psychology. In Europe, many of these patterns are now illegal, but the mindset persists. A good designer must resist the pressure to implement these patterns. If you are tricking your user, you aren’t designing; you are scamming.

The “User” Problem

Finally, we need to address the language we use. Throughout this series, we have used the word “User.” But as the old industry joke goes, only two professions refer to their customers as “users”: drug dealers and IT professionals. The term is problematic because it implies passivity. A “user” is someone who takes what is given to them. It strips the human of their agency and complexity.

When we view people as “users,” we start to treat them like the dog in the famous “IT Crowd” style cartoons — stupid, inept, and needing to be heralded through the process. We create error messages that treat them like children. We assume they read every word of our instructional text (they don’t). We assume they care about our database schema (they don’t).

Jonathan Nightingale from Mozilla once satirized this attitude by rewriting a browser error message to say: “You have hurt the internet’s feelings.” It was a joke, but it highlighted how ridiculous our communication often is. We bombard people with technical jargon and meaningless choices because we forget there is a human on the other side of the screen.

We should shift our vocabulary. Some suggest “Actor” or “Stakeholder.” Others prefer simply “Human.” Whatever word you choose, the goal is to remember that the person on the other end is not a metric to be optimized or a receptacle for your features. They are a person trying to get something done.

Conclusion

Design Thinking is not a magic wand. It is a rigorous, messy, and difficult process of aligning technology with human needs. It requires you to be humble enough to kill your best ideas, patient enough to sketch two thousand iterations, and brave enough to say “no” to feature creep.

The goal is not to make users fascinated by your technology. As the saying goes, “Users want to be empowered by technology, not awed by it.” If you can build a system that makes the human feel powerful, competent, and in control, you have succeeded. If you build a system that makes them feel stupid, no matter how many features it has, you have failed.

This concludes the Design Thinking series. Go forth and design for humans.

We need to set the stage before we start writing code or designing systems. This entire domain of “Responsible Thinking” is essentially divided into two massive pillars. First, there is the immediate responsibility we have as researchers when we involve actual human beings in our work — that is the realm of Science Ethics. Second, there is the broader responsibility we bear when we unleash digital technologies into the wild, affecting society and the environment at scale — this is often termed Responsible Research & Innovation (RRI). In this first part, we are going to look strictly at the first pillar: how we treat the people we study. And straight up, the history here is dark. The rules we follow today didn’t appear out of thin air; they were written in blood after the scientific community witnessed horrific abuses of power.

The Tuskegee Betrayal

To understand why modern ethics boards are so strict, you have to look at the Tuskegee Syphilis Experiment. This wasn’t a brief lapse in judgment; it was a systematic, forty-year betrayal of trust orchestrated by the US Public Health Service (USPHS). Starting in 1932, the government recruited 400 African American men from Tuskegee, Alabama, to study the “natural progression” of syphilis. The study was predicated on deception from day one. The researchers lured these men in with offers that, in the context of the Great Depression, were hard to refuse: free medical examinations, meals, and burial insurance.

The cruelty lies in the fact that these men were never treated for the disease they were harboring. Even when Penicillin became the standard, effective cure for syphilis and was widely available, the researchers deliberately withheld it from the participants. They needed the men to remain infected so the study could document the ravages of the disease until death. The “science” was prioritized over human life. By the time the study was finally shut down in 1972 — a staggering 40 years later — between 28 and 100 participants had died as a direct result of the untreated syphilis or related complications. This timeline illustrates a complete failure of moral compass, leading to a profound and justified distrust of medical institutions that persists today.

The Nazi Atrocities and the Nuremberg Code

While Tuskegee was happening in the US, an even more industrial scale of horror was taking place in Europe. During the Nazi regime, concentration camps became sites for gruesome “medical” experiments where human beings were treated as disposable biological material. In Dachau, for instance, doctors murdered between 280 and 300 prisoners in freezing experiments designed solely to test new clothing for the Luftwaffe. They wanted to know how long a pilot could survive in freezing water, so they forced prisoners into tanks of ice water until they died, monitoring their vitals the entire time.

The aftermath of these horrors brought the world to a standstill. On August 20, 1947, during the Nuremberg Trials, Nazi physicians were convicted for these crimes against humanity — crimes that also included the forced sterilization of 3.5 million Germans. Out of this trial emerged the Nuremberg Code, a set of ten ethical principles that remains the absolute bedrock of human research ethics today. The Code established that scientific advancement, no matter how potentially valuable, can never justify the violation of basic human rights. It forces us to ask a difficult retrospective question: If we possess data obtained through torture and murder (like the hypothermia data from Dachau), is it ethical to use that knowledge to save lives today, or does using the data validate the atrocity?

The Milgram Experiment: Anatomy of Obedience

In the wake of the Nuremberg trials, the world was left asking why. How could so many ordinary citizens and doctors participate in such mass extermination? In 1962, Stanley Milgram attempted to answer this by testing the limits of human obedience to authority. The setup was ingenious and terrifying. Participants were told they were part of a learning study. They were assigned the role of “Teacher,” while another person (actually an actor) was the “Learner.” The Teacher was instructed to ask questions, and for every wrong answer, they had to administer an electric shock to the Learner.

The shock generator was clearly marked, escalating from slight shocks up to a terrifying 450 Volts. As the experiment progressed and the Learner began to scream, plead for their life, and eventually fall silent, the Teacher would often hesitate. However, a researcher in a white lab coat would simply stand behind them and calmly command, “The experiment requires that you continue.” The results were shocking to the American public. Out of 40 subjects, not a single person stopped before reaching 300 Volts. Even more disturbing, 26 of the subjects — well over half — continued all the way to the maximum 450 Volts, a level that would likely be lethal in reality.

The Milgram experiment proved that average people could be coerced into torturing others simply by the presence of a perceived authority figure. However, it also sparked a massive debate on the ethics of the experiment itself. Was it ethical to deceive the participants so profoundly? Was it right to put them in a position where they believed they were killing someone? Years later, interviews revealed that many participants were deeply traumatized by the realization of what they were capable of; there are even reports of suicides linked to the guilt associated with the experiment.

Virtual Reality and the Paradox of Harm

Fast forward to 2006, and researchers attempted to replicate Milgram’s work using Virtual Reality. The theory was that by using a virtual avatar as the “Learner” rather than a human actor, they could bypass the ethical issues of the original study. The results were fascinating: the behavioral dynamics in the virtual environment mirrored the original 1962 findings. People still obeyed the authority figure and “shocked” the virtual avatar.

However, this created a logical paradox regarding the ethics of the simulation. The researchers argued that the study was ethical because the participants were exposed to “no risk” — after all, it was just a simulation. But this argument inadvertently undermines their own scientific conclusions. If the participants experienced no real stress or conflict because they knew it was fake, then the results are scientifically invalid. If the results are valid — meaning the participants reacted as if the situation were real — then they must have experienced real psychological stress, bringing us right back to the original ethical violation. You cannot have it both ways; either the stress is real and the ethics are questionable, or the stress is fake and the science is useless.

The Central Calculation: Risk vs. Knowledge

Ultimately, all science ethics boils down to a single, critical trade-off: The balance between Scientific Knowledge Gain and Potential Risk to the Participant.

In an ideal scenario, the knowledge we gain is massive, and the risk to the participant is non-existent. However, we have to navigate the grey areas. There are hard lines we cannot cross. If there is even a minuscule “residual risk” of death — if there is the slightest chance a participant could die for your study — the potential knowledge gain is irrelevant. It is ethically unacceptable, period.

Conversely, this principle works in the other direction as well. Even if the risk is very low (e.g., just boredom), the study can still be deemed unethical if there is zero expected knowledge gain. Wasting a human being’s time for a study that yields no new information is, in itself, an ethical violation. We are required to justify that the imposition we place on a participant is outweighed by the value the research brings to the world.

In the next part, we will break down the specific rules that keep us on the right side of history, specifically focusing on the mechanics of Informed Consent and the deceptive nature of “voluntariness” in university settings.

Part 2: The Rules of Engagement – Consent, Deception, and Privacy

Now that we have looked at the historical horrors that necessitate strict oversight, we need to break down the actual operational framework we use today. This isn’t just about filling out forms to make a university legal department happy; it is about the fundamental agreement between the researcher and the participant. The central calculation we discussed in Part 1 — weighing knowledge against risk — is the foundation, but the pillars that hold it up are specific, actionable principles. If you are running a study, you are responsible for ensuring these are not just met on paper, but in spirit.

The Illusion of Voluntariness

The first and most non-negotiable principle is Voluntariness. This sounds simple: the participant must say “yes” without a gun to their head. But in practice, coercion is rarely that obvious. Voluntariness means that a participant cannot be persuaded, pressured, or manipulated into joining. More importantly, it includes the absolute right to withdraw from the study at any time, without providing a reason, and without facing negative consequences. If a participant gets halfway through your survey or experiment and says “I’m done,” the data collection stops immediately, and you thank them for their time.

A classic “grey zone” you will likely encounter in academia involves the recruitment of students. It is very common for professors to use their own students as guinea pigs for their research. This is an ethical minefield. The power dynamic here is inherently unbalanced. If participation is tied to the grading of a course — for example, if a student gets “extra credit” for participating that cannot be earned any other way — then voluntariness is dead. The student is effectively being coerced by their GPA. To navigate this, institutions like the University of Waterloo have developed strict guidelines: if research credits are offered, there must be an alternative, non-research way to earn those same credits with equal effort. If a student feels they have to participate to pass, you have failed the ethics check.

Informed Consent and The Art of Deception

Voluntariness leads directly into Informed Consent. This is the standard procedure for documenting the agreement between researcher and subject. It has two distinct components that must be satisfied. First is the “Informed” part: the participant must fully understand what they are signing up for, what the risks are, and what will happen to them. Second is the “Consent” part: an explicit, usually written, agreement (like a signature). You cannot assume consent from silence or passivity.

However, science sometimes requires secrets. There are specific research questions that simply cannot be answered if the participant knows what is being tested. These are called Deception Studies. These are incredibly delicate and require rigorous justification. You can only deceive a participant if there is absolutely no other way to get the data, and the risk is minimal.

A prime example of this is the “Social Stress Test” in Virtual Reality. Researchers wanted to see if they could induce genuine biological stress responses using a VR environment. To do this, they couldn’t tell people, “We are trying to stress you out.” Instead, they used a cover story. Participants were recruited for a “memory test.” The procedure was brutal by design:

1. Participants are led before three “judges” (avatars).
2. They are told to prepare for a job interview and given 5 minutes with a pen and paper.
3. Suddenly, the paper is taken away, and they are forced to perform the interview freely, without notes.
4. Following that, they are subjected to a mental arithmetic torture test: counting backwards from the number 1,022 in steps of 13.
5. If they make a single mistake, they are forced to start over from the beginning.

This protocol reliably induces cortisol spikes and stress. But ethically, it is only permissible because of the Debriefing. Immediately after the study, the curtain is pulled back. The researchers explain the true purpose (stress induction), explain why the deception was necessary, and ensure the participant leaves the lab in a stable state. Without that debriefing, this would just be psychological abuse.

Privacy, Data, and The Right to vanish

In the modern era, Privacy has evolved from simply “locking the filing cabinet” to a complex battle against data re-identification. We have to protect personality rights and human dignity. It is not enough to just remove names from a spreadsheet. Researchers have demonstrated that with enough metadata (location, time, demographics), it is often possible to “reverse engineer” the identity of participants, even in supposedly anonymous social media studies. The Association of Internet Researchers provides extensive guidelines on how to handle online data ethically to prevent this “doxing by science.”

This is all legally codified now under the GDPR (General Data Protection Regulation or DSGVO in German), which came into force in May 2018. This regulation fundamentally changed how we handle scientific data. The principles are strict: collect as little data as possible (Data Minimization), inform participants exactly how the data will be used, protect that data with state-of-the-art security, and implement a “Right to be Forgotten.” Today, before a study even begins, researchers usually have to draft a Data Management Plan that outlines exactly how every byte of data will be handled, stored, and eventually destroyed.

Trust, Justice, and Compensation

Beyond the legalities, there are the softer, yet equally critical, principles of Trust and Justice. Trust is about transparency; participants need to feel safe and cared for. Justice creates a more difficult constraint, particularly in comparative studies.

Consider medical trials involving a placebo. If you are testing a life-saving drug for a virus, and you infect 100 people, giving 50 the drug and 50 a placebo, you have a justice problem. If the “non-treatment” of the placebo group exposes them to significant harm or death, the study is unethical. You cannot sacrifice the health of one group just to prove a point about the other. Justice demands that the benefits and burdens of research are distributed fairly.

Finally, we have to talk about Compensation. It is good practice to thank participants, whether that is a small cash payment, a gift card, a badge, or just coffee and cake. However, money changes the voluntariness equation. We have to tread carefully regarding “undue inducement.” For a wealthy person, $50 is a nice thank you. For a person in a desperate financial situation, $50 might be the difference between eating and starving. If the compensation is too high, it becomes coercive; the participant effectively cannot say no, and they certainly cannot exercise their right to withdraw if they feel uncomfortable. We must ensure that compensation is an appreciation of time, not a bribe that exploits vulnerability.

In-Action Ethics

We wrap up this section with a concept that bridges the gap between theory and reality: In-Action Ethics. We have legal frameworks (like the GDPR) that tell us what is allowed. We have anticipatory ethics (Ethical Codes) that describe what we should do. But the real world is messy. Often, you will face situations in the lab or the field that the rulebook didn’t predict. This is where In-Action Ethics comes into play. It requires critical, reflexive action in the moment. It demands that you develop a personal ethos — a “sense” for what is right — so that when the unexpected happens, you can make a moral decision instantly, rather than just looking for a clause in a contract.

In the next part, we leave the lab and step into the wider world, examining the “Oppenheimer” moment of technology, where we face the responsibility of building systems that can reshape — or destroy — society.

Part 3: The “Oppenheimer” Moment – Bias, Power, and the Responsibility Gap

In Part 2, we discussed the ethics of the laboratory — how we treat the few dozen people we invite into our studies. Now, we shift gears to Responsible Research & Innovation (RRI). This is the “macro” view. It’s no longer about the participant signing a consent form; it is about the millions of people who will live in the world reshaped by the code we ship. We are moving from the responsibility of the researcher to the responsibility of the creator.

The Oppenheimer Dilemma

The recent film Oppenheimer serves as a perfect cultural touchstone for this section. The central narrative is not just about physics; it is a profound exploration of the moral burden of innovation. The story forces us to confront a brutal series of questions: Should you bring a technology into existence that has the potential to end the world, even if it might also stop a war? Can human lives be weighed on a scale?

The film highlights the trap of “drifting” ethical thinking. Scientists often convince themselves that “if I don’t build it, someone else will,” or “I can control how it’s used.” But once a technology is released, it leaves your hands. You cannot control the misshapen ways society will use your invention. The “Oppenheimer Moment” is that realization that you have birthed something you can no longer contain. We face this today not with atomic bombs, but with generative AI and autonomous systems. The question remains: Is it better to build it first to “control” it, or is the act of building it the original sin?

Robert Moses and The Politics of Concrete

A common defense in engineering is that “technology is neutral.” A bridge is just a bridge; code is just math. This is false. Technology is never neutral; it is frozen power dynamics.

To understand this, we look at Robert Moses, the “Master Builder” of New York City in the mid-20th century. Moses designed the parkways that connected NYC to the beautiful public beaches of Long Island. But he designed the overpasses on the Southern State Parkway with a specific, hidden constraint: they were built unusually low.

To the casual observer, it was just a low bridge. But functionally, the clearance was too low for public buses to pass underneath. At that time, wealthy (mostly white) people owned cars; poor (mostly black) people relied on buses. By setting the clearance of a concrete arch, Moses effectively engineered social segregation. He filtered the population of the beach without ever putting up a “Whites Only” sign. His prejudices were baked into the physical infrastructure of the city. This proves that artifacts — whether concrete or code — enforce politics.

Algorithmic Segregation: The Self-Driving Car

Today, we are building the digital equivalent of Robert Moses’ bridges. A glaring example is the object detection algorithms used in autonomous vehicles. These systems are trained on massive datasets to identify pedestrians so the car knows to brake. However, studies have revealed a terrifying predictive inequity.

The algorithms were significantly better at identifying white men than they were at identifying dark-skinned women. Because the training data was skewed toward white faces, the “vision” of the car was racially biased. In a real-world scenario, this means the probability of being recognized — and therefore not run over — is dependent on your skin color and gender. This isn’t a “glitch”; it is life-or-death discrimination encoded into a safety feature. The technology is not neutral; it is actively replicating the biases of its creators.

The Proteus Effect

Our creations don’t just kill or segregate; they also psychologically manipulate us. We see this in the Proteus Effect. This phenomenon describes how users change their behavior based on the appearance of their digital avatar. In studies, users given taller avatars negotiated more aggressively. Users with more attractive avatars stood closer to people in virtual spaces.

We even see this carrying over into the real world with children and Voice Assistants (Alexa/Siri). If children get used to barking commands at a female-voiced assistant that never complains and always obeys, researchers have observed this “command-and-control” tone bleeding into how they speak to their actual parents. We are not just shaping the tools; the tools are shaping us.

The “No Excuses” Policy

Given these stakes, the field of RRI has zero tolerance for the standard engineering excuses. We need to dismantle three of the most common ones:

1. “Guns don’t kill people, people kill people.” This is the argument that the tool has no intentionality. It is flawed. Objects carry “affordances” — they make certain actions easy and others hard. You can kill a person with a hammer, and you can hammer a nail with a gun (poorly). But a gun is designed to kill. Its intentionality is destruction. When we build systems, we are embedding intent. If you build a surveillance system, you cannot feign shock when it is used to spy on people.

2. “I was just following orders / I just wrote the code.” This is the “cog in the machine” defense. “I was young, I needed the money, my boss told me to do it.” As we learned from the Milgram experiment, humans are hardwired to obey authority. But “Civil Courage” is the professional obligation to resist. If you are coding a feature that is unethical, you have a responsibility to raise your hand. You are the last line of defense.

3. “It’s not my fault, the system did it.” (The Responsibility Gap) When the Deepwater Horizon oil spill happened, we could blame BP as a corporation. But as systems become autonomous, we face a “Responsibility Gap.” If an AI kills a pedestrian, who is responsible? The coder? The dataset curator? The user? The AI itself? We are seeing a dangerous trend where humans offload moral agency to the machine. We cannot allow this. We must close the gap. Even if a system is “autonomous,” the responsibility for its actions must eventually tether back to the humans who deployed it.

In the next part, we will explore the “Algorithmic Panopticon,” diving into the Trolley Problem, the surveillance economy, and the massive environmental cost of training the AI models we are so obsessed with.

Part 4: The Algorithmic Panopticon – Surveillance, Morality, and the Climate Cost

In the previous section, we discussed the responsibility gap — the dangerous idea that we can offload moral agency to a machine. Now, we are going to look at exactly what happens when those machines start making decisions at scale. We are moving into the territory of automated morality, the industrialization of surveillance, and the hidden ecological price tag of our digital obsessions. This isn’t science fiction; these are the economic and ethical realities of the systems currently running the world.

The Trolley Problem: From Philosophy Class to Production Code

For decades, the “Trolley Problem” was a dusty thought experiment reserved for moral philosophy seminars. You know the drill: a trolley is hurtling down a track toward five people. You are standing next to a lever. If you pull it, the trolley switches tracks and kills only one person. Do you pull the lever? It’s a classic utilitarian dilemma. But with the advent of autonomous driving, this is no longer a hypothetical. It is an engineering specification.

Engineers programming self-driving cars are effectively hard-coding answers to the Trolley Problem. A vehicle will eventually face a situation where an accident is unavoidable — where it must choose between swerving into a pedestrian or crashing into a wall and killing its passenger. The car needs a decision tree for death. This raises an impossible question: How does an algorithm value human life? Does it prioritize the passenger because they bought the car? Does it prioritize the pedestrian? What if the pedestrian is a child vs. an elderly person?

To tackle this, MIT launched the Moral Machine project. They crowdsourced millions of decisions from people around the world to see if there was a universal consensus on how machines should kill. The results were not comforting. They found that “morality” is geographically and culturally relative. Some cultures prioritize saving the young; others prioritize the elderly. Some prioritize following the law (crossing at a green light) over maximizing the number of lives saved. There is no single “correct” algorithm for morality, yet we are deploying cars that must act as if there is.

Predictive Policing and the Math of Prejudice

If the Trolley Problem deals with immediate physical harm, Predictive Policing deals with systemic societal harm. Law enforcement agencies increasingly use algorithms to allocate resources, sending officers to “high crime” areas based on historical data. This sounds efficient, but it creates a dangerous feedback loop known as a Self-Fulfilling Prophecy.

If you send more police to a specific neighborhood based on past arrest data, those police will inevitably find more crime — even minor infractions — simply because they are there to see it. This generates new data points that reinforce the algorithm’s bias, telling it to send even more police next time. The system isn’t predicting crime; it is predicting (and amplifying) policing.

Data scientist Cathy O’Neil explores this in her seminal book, Weapons of Math Destruction. She argues that the problem isn’t just “biased data” (though that exists); the problem is the goal of the modeling itself. We optimize for efficiency, arrests, or convictions, but we rarely optimize for fairness. When you treat human behavior as an optimization problem without accounting for the social context, you end up automating oppression.

Surveillance Capitalism: The Business Model of Our Time

The data feeding these systems has to come from somewhere, and that brings us to the economic engine of the modern internet: Surveillance Capitalism. Coined by Shoshana Zuboff, this term describes a market logic where human experience is claimed as free raw material for translation into behavioral data. This isn’t just about showing you better ads. It is about predicting and modifying your behavior for profit. Zuboff argues that this accumulation of behavioral data fundamentally undermines democracy by creating an asymmetry of knowledge — they know everything about us; we know nothing about them.

We see this creeping into the workplace. Microsoft, for example, faced severe backlash for rolling out a “Productivity Score” in Office 365. This feature allowed employers to monitor granular employee activity — how many emails they sent, how often they collaborated, effectively turning the office into a digital panopticon. It creates a culture of fear where workers are constantly performing for the algorithm.

The Shadow Market: Data Brokers

It gets darker when we look at Data Brokers. These are companies whose entire existence is dedicated to buying, packaging, and selling your personal information. A particularly egregious example involves location data. You might download a simple flashlight app or a weather widget, and buried in the Terms of Service is permission to track your location. That app developer then sells your movement history to a data broker.

This has become a loophole for government surveillance. In the US, the military and intelligence agencies are legally restricted from spying on citizens without a warrant. However, they can simply buy the location data from data brokers on the open market, effectively bypassing constitutional protections. We have seen reports of the US military buying movement data from ordinary apps, and Israeli surveillance firms siphoning masses of location data for intelligence purposes. Your phone is a tracking device first, and a communication tool second.

The Carbon Footprint of “Intelligence”

Finally, we need to talk about the physical cost of all this computation. AI is not floating in the “cloud”; it is burning coal and gas in massive data centers. The training and operation of Large Language Models (LLMs) have a staggering ecological footprint.

To put this in perspective: In 2021, Google’s total electricity consumption was 18.3 TWh. At that time, AI accounted for about 10–15% of that total. But as we shift from simple keyword search to generative AI interactions (like ChatGPT or Gemini), the energy cost per query skyrockets.

A worst-case scenario analysis suggests that if every standard Google search were replaced by an LLM interaction, Google’s AI alone could consume as much electricity as the entire country of Ireland (29.3 TWh per year). We are essentially trading the planet’s climate stability for the convenience of automated text generation. Responsible innovation requires us to ask: Is the utility of this model worth the carbon it emits?

In the final part, we will look at how to fight back: the rise of tech worker activism, the power of whistleblowers, and the new regulatory landscape that aims to rein in these giants.

Part 5: Reclaiming the Code – Resistance, Regulation, and the Way Forward

We have spent the last four parts outlining a grim reality: historical atrocities, ethical minefields in the lab, biased algorithms in our streets, and a surveillance economy that mines our behavior for profit. If you stop reading there, the conclusion is paralysis. But the point of “Responsible Thinking” isn’t to make you feel guilty; it’s to make you effective. The narrative that “technology is inevitable” is a lie sold by the people building it. The future is not fixed, and as the people who actually write the code, we possess a unique kind of leverage.

The Myth of the Powerless Developer

When we look at the sheer scale of the “Big 5” tech giants (GAFAM: Google, Amazon, Facebook, Apple, Microsoft), it feels impossible to enact change. What is one engineer against a trillion-dollar market cap? But this view ignores the economics of the valley. These companies are desperate for talent. They can afford to lose a few thousand users, but they cannot afford to lose their core engineering teams.

We have seen this power exercised successfully. When Google employees discovered their code was being used for military drone targeting (Project Maven), thousands signed petitions and staged walkouts. The pressure was internal, bottom-up, and effective. Google eventually declined to renew the Pentagon contract. This proved that “tech workers” are not just cogs; when they organize, they are the most powerful activists in the industry. You cannot build a surveillance state if the architects refuse to pick up their tools.

Courage and The Cost of Dissent

However, we have to be realistic about the risks. “Civil courage” is easy to talk about in a lecture hall but dangerous to practice in a corporate office. The case of Dr. Timnit Gebru is the defining example here. A leading ethical AI researcher at Google, she co-authored a paper criticizing the environmental costs and biases of Large Language Models (the very tech driving the current AI boom).

Instead of embracing the feedback, Google pushed her out. Her firing (or “resignation,” as they spun it) sent a chilling message: you are paid to find “fixable” bugs, not to question the fundamental business model. But her ousting backfired. It galvanized the research community and exposed the hypocrisy of “Corporate AI Ethics” boards. It demonstrated that true ethical oversight often has to come from the outside, or from whistleblowers willing to burn bridges to tell the truth.

Subversive Design: The Project Alias Case

If we can’t change the companies, can we hack their products? Designers have begun creating “parasitic” technologies to reclaim privacy. A brilliant example is Project Alias, created by Bjørn Karmann and Tore Knudsen.

Alias is a “smart fungus” that you physically place on top of a Google Home or Amazon Echo. It constantly feeds white noise into the device’s microphone, deafening it so it cannot listen to your private conversations. When you want to issue a command, you speak a custom wake word (of your choosing) to Alias. Alias then stops the white noise and plays a recording of “OK Google” directly into the device’s ear. It acts as a middle-man, allowing you to use the tech without being constantly monitored, and even allows you to rename your assistant. This is “Adversarial Design” — using technology to disrupt technology.

The Role of Critical Research

We also need rigorous science to prove these systems are broken. You cannot regulate what you cannot measure. This is where the work of Joy Buolamwini and the Algorithmic Justice League comes in. Her “Gender Shades” project didn’t just claim facial recognition was racist; she proved it mathematically. She showed that error rates for darker-skinned women were astronomically higher than for lighter-skinned men.

This hard data made the problem undeniable. It provided the ammunition for activists and policymakers to push back. Following the George Floyd protests and the mounting evidence from researchers like Buolamwini, major players like IBM announced they would stop offering, developing, or researching facial recognition technology. It was a victory for the “Critical Research” pipeline: Science $\rightarrow$ Awareness $\rightarrow$ Public Pressure $\rightarrow$ Corporate Change.

The Regulatory Hammer: The EU AI Act

Voluntary corporate ethics are nice, but law is better. We are currently witnessing the birth of the first comprehensive legal framework for AI: the EU AI Act. This legislation attempts to categorize AI systems by risk.

• Unacceptable Risk: Systems that manipulate behavior or use social scoring (like China’s social credit system) are banned outright.
• High Risk: Systems used in hiring, law enforcement, or critical infrastructure face strict compliance and transparency rules.

It is imperfect, and lobbying has watered it down, but it is a start. It signals that the “Wild West” era of deployment is ending.

Conclusion: The First Law of Technology

We end this series with a return to the fundamentals. Historian Melvin Kranzberg formulated six laws of technology, but the first is the most important for us to internalize:

“Technology is neither good nor bad; nor is it neutral.”

This is the summary of everything we have discussed. Technology is not “good” just because it is new. It is not “bad” just because it disrupts things. But it is never neutral. Every line of code, every dataset, and every design choice carries the values, biases, and politics of its creator.

We need new spaces — an “Agora” — to debate these values, because Twitter and Facebook are not designed for nuance. We need to write our own Manifestos (like the Vienna Manifesto on Digital Humanism or the IoT Design Manifesto) to clearly state what we stand for before we get swallowed by the industry.

The “Responsible Thinking” mindset is simply this: Acknowledge that you are building the world, and accept the weight of that fact. No more excuses.

This concludes the 5-part deep dive into Responsible Thinking. The lecture notes have been fully expanded.

Here’s the deal: In the world of Computer Science, “Creative Thinking” often suffers from a serious PR problem. It has a bad reputation. It’s seen as the fluffy antithesis to hard logic, something reserved for designers or people who wear berets. But if we actually look at the history of our field, this perspective doesn’t hold water. Creativity plays an absolutely vital role in almost every technical process we touch.

In fact, when we look at the monumental leaps in Computer Science, they weren’t just improvements in calculation speed; they were creative re-imaginings of problems. Consider the Quicksort algorithm by Tony Hoare. It wasn’t just a faster way to sort; it was a conceptual shift in how we handle data partitioning. Look at Dijkstra’s Travelling Salesman algorithm, or the concept of PageRank by Larry Page and Sergey Brin, which completely flipped the script on how search results are prioritized based on authority rather than just keyword density.

The list goes on. Linus Torvalds didn’t just write a better version of SVN; he invented Git, a distributed version control system that fundamentally changed how humans collaborate on code. Alan Kay gave us Object-Oriented Programming, changing the paradigm of how we model software. Douglas Engelbart gave us the computer mouse and the concept of direct manipulation. These weren’t inevitable logical conclusions; they were creative sparks that became foundational technologies.

A massive aspect of creative problem-solving in our field is Computational Thinking. This mindset allows us to forge completely new paths to solutions that were previously invisible. Consequently, your role — whether you are a developer, a Research Software Engineer, or an architect — is not just to write syntax. Your job is to utilize Computational Thinking to discover creative new solutions.

Defining the Undefinable (and the AI Problem)

However, pinning down exactly what “creativity” means is notoriously difficult. We struggle to find a definition that everyone agrees on. A relevant article from 2023 attempted to consolidate recent efforts into a “Standard Definition of Creativity” that could satisfy all requirements. This has become an urgent issue because we now have to distinguish between human creativity and the artificial creativity of AI systems.

The standard definitions we often cite, like those found on Wikipedia, don’t really answer the hard questions posed by Generative AI. We know for a fact that AI systems can generate ideas that are convincing, original, surprising, and even useful. However, we usually view the selection of those generated ideas by humans as the actual contribution. This is where the distinction gets blurry.

To solve this, Mark Runco proposes a critical update to our definition. He suggests we need to add two specific criteria: Authenticity and Intentionality. These are two aspects of creativity that we cannot — at least at this moment — truly ascribe to Artificial Intelligence. An AI might generate a beautiful image or a working code snippet, but it lacks the internal intent to solve a problem or express a state, and it lacks the authenticity of lived experience behind the creation.

This leads us to a cascade of complex questions. Is creativity a purely individual quality, or does it emerge from groups? Does it require an entire society, backed by history, art, and culture, to manifest? Is it a genetic lottery ticket, or is it a muscle that can be trained? Finally, should we judge creativity by the product (the thing created) or the process (how it was made)?

The “Art Bias” and Pop Culture Stereotypes

Despite the evidence that engineering is inherently creative, many people in technical disciplines genuinely believe they possess zero creativity. This belief system can be traced back to a romanticized tradition of how we view “creatives,” which manifests in two specific phenomena that damage our self-image as engineers.

The first phenomenon is the distortion of creativity by popular media. In movies, TV series, books, and graphic novels, “creative people” are depicted as fundamentally different from the rest of the species. To make them easily identifiable to audiences, they are forced into rigid stereotypes. They work in “creative professions” — usually creating cultural artifacts like paintings or fashion — and are portrayed as eccentric, unusual characters. They have exaggerated traits: they are inattentive, easily distracted, messy, perhaps introverted and brooding, or wildly extroverted and manic.

This creates a role model for creativity that most engineers cannot — and do not want to — identify with. This idea that creativity is the exclusive domain of art and design is called the Art Bias. It is a cognitive distortion. Unlike some biases that have evolutionary biological roots, the Art Bias is socially constructed. It is essentially a societal misunderstanding, but one with damaging consequences.

There are even studies showing that we subconsciously rate the work of creative people as “better” or “more valuable” if the artist acts eccentrically. This is a direct result of this misrepresentation. We have turned a stereotype into a prejudice. If you are a tidy, logical, punctual engineer, society tells you that you don’t fit the “creative” costume.

The False War: Logic vs. Intuition

The second phenomenon that convinces engineers they aren’t creative is the false dichotomy between Logic and Creativity. We are taught to view them as opposites. If you are logical, you cannot be creative. If you are creative, you cannot be logical.

We often swap these terms for others: we equate “logical” with “analytical” or “systematic,” and we equate “creative” with “intuitive.” There is a widespread prejudice that intuition and analytics stand in each other’s way. Unfortunately, engineering education has historically reinforced this bias by placing too little value on creative problem-solving. A study from 2007 by Foley et al. concluded that engineers enter the workforce with significant analysis skills but struggle to “think outside the box” when faced with creative problem-solving scenarios.

The reality, however, is that intuition and analytics are deeply interwoven. You cannot separate them. As noted in lectures on the subject, creativity and logical thinking must work hand-in-hand. Without creativity, we cannot generate solutions to problems. Without logical thinking, we cannot understand the problems in the first place, nor can we verify that the creative solutions actually work.

Even if you feel your creativity is buried, lost, or absent, the truth is that we all practice various forms of creative thinking constantly. Sociologist Ulrich Bröckling put it perfectly: “You cannot not be creative, but perhaps you can stop wanting to be creative all the time.”

Creativity as a Core Skill

We have to confront the grim statistic from the Adobe “State of Create” report (2012), which found that only 1 in 4 people believe they are living up to their creative potential. In Computer Science, we cannot afford this lack of confidence. Creative problem-solving is a core skill.

We are constantly facing problems that are either entirely new or have never been viewed through the specific lens of modern informatics. New fields like Research Software Engineering are tackling questions that were previously approached without computational power, requiring a fundamental reimaging of the solution. The relentless innovation in technology, components, and processes forces us to look at existing situations from fresh angles every single day.

This is the motto we must hang over this entire series: Creativity enables “Creative Problem Solving,” the heart of Computer Science. Being creative isn’t about colored pencils or musical instruments. We are all creative, but we often refuse to call it by its name because we fear that admitting to “creativity” somehow weakens our status as logical thinkers.

But if we look behind the curtain, the truth is undeniable: Analytics and Logic cannot exist without Creativity.

Now that we’ve established that you are, in fact, creative, we need to look at how your brain actually handles — and blocks — new ideas. In the next part, we’ll deconstruct the “Thinking Canyon,” destroy the myth of the “Right Brain,” and solve a puzzle that proves how your own implicit assumptions are holding you back.

Part 2: Breaking the Box: Implicit Constraints, Neuro-Myths, and the Reality of Insight

We’ve established that you are creative, whether you like it or not. But if that’s true, why does problem-solving often feel like banging your head against a wall? Why do we get stuck? To understand this, we need to look at the mechanics of “Outside the Box” thinking, not as a buzzword, but as a cognitive process.

The Nine-Dot Problem: A Case Study in Self-Deception

“Thinking outside the box” is a phrase so overused it has lost most of its meaning. To reclaim it, we need to look at its origin: the famous Nine-Dot Problem.

Picture a grid of dots arranged in three rows of three (a 3x3 matrix). The challenge is simple: Connect all nine dots using a single continuous path of four straight lines, without lifting your pen from the paper.

If you’ve never seen this before, it is surprisingly difficult. Most people fail because they instinctively try to draw lines that stay within the square perimeter formed by the outer dots. But here is the catch: it is geometrically impossible to solve this puzzle if you stay strictly inside that square. To solve it, at least one of the “vertices” — the point where your line changes direction — must fall in the empty white space outside the grid of dots.

This reveals a fascinating glitch in human cognition. The puzzle instructions never said, “Stay inside the square.” They never said, “Turn only on the dots.” Yet, almost everyone creates these rules in their head. This is the concept of Affordance: the dots suggest themselves as turning points. We see a grid, so our brain constructs an implicit “box” and locks us inside it. We are seduced by the narrative implied by the visual data.

Researchers Kershaw and Ohlsson explore this in their paper “The Fallacy of Single-Source Explanations.” They argue that there isn’t just one reason this is hard; it’s a “multiple blockage.” Our perceptual processing (seeing a square), our prior knowledge (connect-the-dots games usually stay on dots), and our look-ahead planning all conspire to keep us trapped.

The Layers of the Box

But we can go deeper. The standard solution (extending the line past the grid) is just the first layer of “outside the box” thinking. If we truly scrutinize our implicit assumptions, we can break the puzzle wide open.

Consider the physical nature of the dots. In a math textbook, a point has no dimension. But on paper, the dots are actually small ink circles — they have width. If we reject the implicit assumption that “these are mathematical points,” we can realize that a line can pass through the top edge of one dot and the bottom edge of another. With sufficient precision, you can solve the puzzle with just three lines by zigzagging through the dots at extremely shallow angles.

Let’s go further. Who said the dots are on a flat 2D plane? That is another implicit assumption. If you imagine the dots on a sphere (or realize the paper itself rests on the curvature of the Earth), you could theoretically connect them with a single line that circumnavigates the globe. Or, even simpler: who said you cannot manipulate the medium? If you fold the paper effectively — aligning the dots into a single row — you can stab a pencil through all nine dots at once. One line.

This is the superpower of creative thinking: identifying Implicit Assumptions. These are the rules you are following that nobody actually gave you.

However, a quick word of caution: Sometimes, the box is good. In Design Thinking, we talk about “Tame Problems.” The box acts as a framing device that makes a problem solvable. Constraints (money, physics, time) are often productive. The “Guy who questions everything” can be toxic to a team if they destroy the necessary constraints that allow work to happen. But to solve the impossible, you must first find the invisible walls you built yourself.

Myth 1: The Left vs. Right Brain Nonsense

Now that we’ve looked at the software (thinking), let’s look at the hardware (the brain). There is a persistent myth that the brain is split into two opposing factions: the logical, analytical Left Brain and the creative, emotional Right Brain.

This story claims that engineers are “Left-Brained” (logical, boring, uncreative) and artists are “Right-Brained” (chaotic, creative, emotional). This is absolute biological nonsense.

Here is the grain of truth: The brain is divided into two hemispheres connected by the Corpus Callosum. Some functions are lateralized. For example, language processing is heavily concentrated in the left hemisphere (specifically motor speech and grammar), while the right hemisphere handles prosody (the melody of speech) and some spatial tasks.

But the idea that “Creativity” lives on the right and “Logic” lives on the left? False. A 2013 study analyzing fMRI scans of over 1,000 brains found zero evidence for an individual having a “dominant” hemisphere that dictates their personality or cognitive style. The “Left-Brained vs. Right-Brained” categorization is as scientifically valid as reading tea leaves or horoscopes.

Neuroscience actually highlights the plasticity of the brain. Functions are not rigidly locked; they are networked. Creativity is a “whole brain” activity. It requires the “left” side’s ability to process details and the “right” side’s ability to see patterns. If you are a human with a brain, you are equipped for both. The excuse “I’m just not right-brained” is not a biological fact; it’s a defense mechanism.

Myth 2: The “Flash of Genius”

Another destructive myth is the idea of the “Flash of Genius” — the lightning bolt of inspiration that strikes out of nowhere. We love this story. We picture Newton and the apple, or Archimedes in the bathtub. It suggests that creativity is magic, reserved for the chosen few.

Here is the reality: The “Flash” is real, but it does not come from nowhere.

The “Flash” is actually the final step of a long, invisible labor. It happens only after a period of intense Preparation. You have to load your brain with data, struggle with the problem, and hit wall after wall. Then, you need Incubation — a period where your conscious mind steps away (the “idle time” we mentioned). During this downtime, the subconscious (or rather, non-conscious processing networks) continues to churn through the data, making connections that your focused, stressed-out conscious mind blocked.

Bill Buxton, a computer scientist and designer, wrote about this regarding Wolfgang Amadeus Mozart. We see Mozart as a vessel of divine talent who just “heard” the music. We ignore the fact that he was drilled in music theory and performance from the time he was a toddler. His “genius” was the result of massive, sustained cognitive loading.

The myth of the “Flash from Nowhere” is dangerous for two reasons:

1. It makes us lazy: We think we just have to sit and wait for the muse to kiss us.
2. It makes us insecure: If the flash doesn’t come, we assume we lack “the gift.”

The truth is much more empowering: The flash is a harvest. You have to plant the seeds (hard work/study) and let the field rest (incubation) before you can reap the rewards.

We’ve debunked the biology and the magic. Now we need to look at the environment. If creativity isn’t a solitary spark, but a fire that needs oxygen, how does your team, your boss, and your stress level control the flame? In Part 3, we talk about the “Lonely Genius” and why stress makes you stupid.

Part 3: The Social & Emotional Code: Teams, Stress, and the Psychology of Safety

We have talked about the individual brain — the “software” and the “hardware.” But unless you are coding in a cave on Mars, you do not work in a vacuum. You work in a team. And this brings us to the most critical environment for creativity: the social dynamic.

Myth 3: The Lonely Genius

There is a persistent romantic image of the “Lonely Genius” — the brilliant recluse who locks themselves in a tower and emerges with a finished masterpiece. In reality, innovation is statistically a team sport.

Research on “Distributed Intelligence” provides overwhelming evidence that the power of the unaided individual mind is highly overrated. Most of our intelligence and creativity results from interaction: collaborating with other individuals, using shared tools, and building upon existing artifacts. Cities with higher densities of “creative industries” produce significantly more patents, suggesting that proximity and collision of ideas drive innovation.

However, there is a fascinating contradiction in the expert opinions here. Stephan Ledain (Business Psychologist) claims “Creativity is a team sport,” while Vincent Walsh (Neuroscience Professor) argues “Creativity is not a team sport.”

How can both be true? The answer lies in the atmosphere.

Creativity is a team sport only if the team is safe. If the atmosphere is open to “outside the box” thinking, the team amplifies intelligence. But if every new idea is met with the “social guillotine” — comments like “Don’t be stupid” or “Let’s be realistic” — then the team becomes a creativity graveyard. Under those conditions, the individual is better off working alone.

Furthermore, group creativity techniques like Brainstorming only work if the individuals have done the work beforehand. A group of unprepared people shouting at a whiteboard is just noise. The most effective workflow is individual preparation (loading the brain) followed by group collision (sparking connections).

The “First Validator” and the Onion of Context

Imagine your working life as a series of concentric circles — like an onion.

• The outer layer is Society.
• The middle layer is your Company/Institution.
• The innermost layer — the one touching you — is your Immediate Team.

This inner layer acts as the First Validator. When you have a fragile, new idea, you are vulnerable. You expose yourself to judgment. If this First Validator layer is toxic or dismissive, your brain learns a very fast lesson: Do not share ideas here. You shut down.

Therefore, the primary job of a team lead (or a senior engineer) is to protect that inner layer. You must create an environment where curiosity is currency. You need to reward questions that start with “Why” and “How.” If you allow cynicism to rule the First Validator layer, you are effectively paying your engineers to stop thinking. Curiosity breeds creativity.

Creativity vs. Stress: The Biological Tunnel

We often hear managers say, “I need to put some pressure on the team to get the creative juices flowing.” This is scientifically backward. Stress and Creativity are biologically incompatible.

When you are under stress (duress, fear of deadlines, angry bosses), your brain shifts gears. It shuts down higher-order functions and hands the reins to the Limbic System — the primal, emotional center focused on survival.

This creates a Cognitive Tunnel Vision. Your brain’s only goal is to escape the stress. To do that, it craves certainty. It reaches for what it knows works: established patterns, safe code, standard procedures. It blocks out anything risky, new, or unproven — i.e., it blocks out Creativity. You literally cannot “think outside the box” when your brain is screaming that the box is on fire.

The Four Fears

If we drill down into why we self-censor, Tom and David Kelley (founders of the legendary design firm IDEO) identify Four Fears that block creative thinking:

1. The Fear of the Chaotic Unknown: Engineers like order. Creativity requires leaving the safety of your desk and “predictable sources” (like documentation) to engage with the messy, chaotic real world. We fear that chaos.
2. The Fear of Judgment: This is the social fear. We are terrified of not being accepted by the tribe. We stick to “safe” ideas to avoid looking foolish.
3. The Fear of the First Step: The blank page (or empty IDE) is terrifying. We fear failure so much we don’t even start. We have to reframe failure not as a disaster, but as data.
4. The Fear of Losing Control: To be creative in a group, you have to let go of your ego. You have to accept that someone else might have a better idea, or that the group might take your idea in a direction you didn’t intend.

Motivation: The Dan Pink Reality Check

Finally, we have to talk about how we motivate creative work. In a famous RSA Animate talk, Dan Pink destroys the idea that financial bonuses drive performance for cognitive tasks. For mechanical tasks, bonuses work. For tasks requiring rudimentary cognitive skill (like coding or design), high stakes actually result in poorer performance due to the pressure/stress effect mentioned above.

True creative motivation stands on three pillars:

1. Autonomy: The urge to direct our own lives.
2. Mastery: The desire to get better and better at something that matters.
3. Purpose: The yearning to do what we do in the service of something larger than ourselves.

Managers who believe that employees work better under fear, uncertainty, or “crunch time” pressure are simply wrong. Research proves that a negative “inner work life” (unhappiness, fear) creates a measurable drop in four dimensions: creativity, productivity, commitment, and collegiality.

If you want a creative engineer, you cannot whip them into shape. You have to give them space, safety, and a reason to care.

So, we have the team, the safety, and the brain. How do we actually DO the work? In Part 4, we’re going to map out the operational process of creativity, looking at the “Thinking Canyon,” the “Design Wall,” and the controversial question: Should you go to the pub to solve a coding problem?

Part 4: The Process of Innovation: From the “Thinking Canyon” to the “Long Nose”

We’ve covered the myths and the psychology. Now, let’s get operational. How does the machine actually work? If you want to replicate creative success, you can’t just hope for it; you need to understand the mechanics of the process.

The Four-Stage Model (How Ideas actually happen)

In 1926, Graham Wallas, a British social psychologist, wrote The Art of Thought. Despite being nearly a century old, his four-stage model of creativity remains one of the most accurate descriptions of how a human brain solves a complex problem. If you’ve ever struggled with a bug for three days only to solve it while brushing your teeth, you have lived this model.

1. Preparation This is the “loading” phase. You cannot have an idea about nothing. In this phase, you recognize the problem and aggressively hunt for information. You immerse yourself in the data, the constraints, and the existing code. You are feeding the machine. This is hard, conscious work.

2. Incubation This is the phase most managers hate because it looks like you aren’t working. In medical terms, “incubation” is the time between infection and symptoms. In creativity, it is the time where you consciously put the problem aside. You stop staring at the IDE. You go for a walk, sleep, or work on something trivial. Crucially, this is not “doing nothing.” It is a hand-off. You are passing the data from your limited, linear conscious mind to your massive, parallel-processing non-conscious mind. This is similar to the “Inner Game of Tennis”: you have to get your ego out of the way to let the specialized parts of your brain do the heavy lifting. But for this to happen, you need idle time — a rare commodity in the age of the smartphone.

3. Illumination (The Flash) This is the “Eureka” moment. It defines the Illumination phase. Wallas observed that this moment almost always happens when you are not thinking about the problem. It happens when you are in the shower, driving, or waking up. Why? Because you created the necessary “white space” or “freewheeling” mental state during Incubation that allowed the signal from the subconscious to break through to the conscious surface.

4. Verification This is the return to engineering. A flash of insight is not necessarily a good idea; it’s just an idea. Now, the conscious, analytical mind must take back the controls to verify if the solution actually works, if it’s scalable, and if it solves the original problem.

The “Design Wall”: Externalizing the Brain

If creativity requires connecting disparate ideas, we need tools that help us see those connections. In design studios, this is solved with the Design Wall (also known as a mood board, research wall, or information radiator).

The concept is simple but powerful: You physically pin up your sources of inspiration, your constraints, your sketches, and your data on a vertical surface. You saturate your visual field. By “spatializing” the information, you allow your eyes to drift and make random connections between a user requirement on the left and a technical schematic on the right. It unlocks insights that are impossible to see when your information is hidden in tabs on a web browser or pages in a notebook.

We can visualize the creative workflow as a specific diagram often used in design theory, sometimes called the “Snake Swallowing Tennis Balls.” It depicts the process not as a straight line, but as a series of bulges (the tennis balls) along a path. Each “ball” represents a cycle of Exploration (widening the scope, generating wild ideas) followed by Reflection (narrowing down, evaluating, selecting). The process is a constant oscillation between opening up to new possibilities and closing down to practical realities. If you only explore, you never ship. If you only reflect, you never innovate.

The “Hit the Pub” Hypothesis: Alcohol and Code

This brings us to a controversial question: Does alcohol make you more creative? The “Ballmer Peak” (referenced in the famous xkcd comic) suggests there is a specific blood-alcohol concentration where coding ability peaks before plummeting.

The science actually supports a nuanced version of this. Alcohol acts as a depressant that inhibits certain brain functions. Specifically, it dampens the “Feasibility Censor” — the part of your brain (often the prefrontal cortex) that constantly whispers, “That won’t work,” or “That’s a stupid idea.”

In engineering, we have a very strong Feasibility Censor. We kill ideas before we even speak them because we instantly judge them as impossible or inefficient. Alcohol lowers this barrier. It allows you to speak the “stupid” idea, which might turn out to be the breakthrough.

However, there is a massive trade-off. To focus, your brain stem releases Norepinephrine (Noradrenaline). This chemical promotes attention and alertness. Acute exposure to alcohol inhibits this signal. So, while you might have more “wild” ideas because your filter is off, your ability to actually implement them, focus on syntax, and maintain logical coherence drops significantly.

The verdict: Alcohol might help with ideation (breaking the block), but it is terrible for execution. The code you write while drunk is likely garbage, even if the idea behind it was brilliant.

The “Thinking Canyon” (The Curse of Experience)

Alan Kay, the father of OOP, proposed a powerful metaphor for why experts get stuck: The Thinking Canyon.

Imagine your mind is a landscape. Every time you learn something or solve a problem a certain way, you carve a little groove in that landscape. Over years of experience, that groove becomes a ditch, then a valley, and finally a massive canyon like the Grand Canyon. When you are at the bottom of the Thinking Canyon, life is easy. You know exactly what to do. You are highly competent. You can solve 90% of problems without thinking because the walls of the canyon guide you.

But the walls also blind you. You cannot see what is happening on the plateau above. You cannot see solutions that require you to leave the canyon. Every “Big Idea” in history (the computer, the printing press) required climbing out of the canyon.

• The Trap: The more experienced you are, the deeper your canyon, and the harder it is to climb out.
• The Paradox: Creativity is the productive overcoming of experience. You need the experience to be useful, but you must be able to ignore it to be novel. You have to know the rules well enough to know which ones to break.

Invention vs. Innovation: The “Long Nose”

Finally, we must distinguish between “cool new tech” and actual change. Bill Buxton argues we confuse Invention (making something new) with Innovation (getting it adopted).

He coined the term “The Long Nose of Innovation.” We tend to focus on the “short tail” of recent success, but innovation actually has a massive, long lead-up — the “Long Nose.”

The Example: The Mouse

• 1968 (Invention): Douglas Engelbart demos the mouse in the “Mother of All Demos.” Simultaneously, German engineer Rainer Mallebrein invents a “Rollkugel” (rolling ball) for air traffic control. Both are brilliant. Both are largely ignored by the mass market.
• 1984 (First Step): The Macintosh is released. It takes 16 years for the mouse to find a commercial home.
• 1995 (Ubiquity): Windows 95 launches. It takes another 11 years for the mouse to become the undeniable standard for human-computer interaction.

That is a 29-year gap between invention and true innovation. This teaches us patience. Just because an idea (like a creative solution in your code) doesn’t catch on immediately doesn’t mean it failed. Real innovation is a marathon of refinement, not just a sprint of invention.

We know the process, and we know the traps. But how do we actually get better at this? Is there a gym for creativity? In the final part, Part 5, we will outline the specific training regimen and the “Cheat Codes” (Toolkits) you can use to force your brain out of its canyon.

Part 5: The Gym for Your Brain: Training Regimens and Tactical Toolkits

We have established that creativity isn’t a mystical gift bestowed by the gods of code; it is a neurological function. And like any function of the human body, it operates on the “use it or lose it” principle.

Here is the good news: Creative Thinking is a muscle. You can train it. You can do reps. You can increase your max load.

However, training this muscle requires a specific kind of workout. You need to accustom your brain to perspective shifts, to the discomfort of ambiguity, and to the suppression of that nagging voice that says, “This won’t work.” That voice comes from the Dorsolateral Prefrontal Cortex. In engineers, this area is often overdeveloped as a “Feasibility Censor.” To train creativity, we have to learn how to temporarily bypass that censor.

The Training Regimen

If you want to upgrade your ability to solve complex problems, you need to integrate these practices into your daily routine. This isn’t about doing “creative things” on the weekend; it’s about rewiring how you approach your 9-to-5.

1. Transfer Your Talents (Cross-Pollination) Look for habits or skills you possess in completely unrelated areas and force a transfer to your engineering work.

• Example: If you are a photographer, you are used to framing a shot, looking for lighting, and changing your angle to get a better composition. Apply this to your code. “Photograph” your architecture — create a visual “Research Wall” of your current project components.
• Example: If you do high-intensity interval training (HIIT) or disciplined sports, you understand structure, intervals, and recovery. Apply that rhythm to your coding sprints. Use the discipline of your body to discipline your mind.

2. The “Streak” Challenge Gamify your output. The internet is full of “30-day creativity challenges.” These might sound trivial, but the goal isn’t the output; the goal is the streak. By forcing yourself to produce something novel every day, you lower the stakes. You stop waiting for “perfect” and start getting comfortable with “done.”

3. Aggressive Input Diversity Your brain is an association machine. It connects Dot A to Dot B. If you only feed it computer science textbooks, it can only make connections within computer science. You must widen the pool of “dots.” Read wildly. Read history, biology, architecture, or fiction. The broader your knowledge base, the more exotic the connections your subconscious can forge. This is the secret sauce of the “Genius” — they are usually just people with a very strange, very wide library of mental references.

4. Operationalize Curiosity As we discussed in Part 3, the social environment is critical. You must actively build a workspace where “Why” and “How” are the most valuable words. If you are a lead, you need to incentivize these questions. Remember: Curiosity breeds creativity. If you stop asking how things work, you stop inventing ways to make them work better.

5. The Physiology of the Pause This is a critical health warning from occupational medicine: If you notice you are exhausted, it is already too late. A pause is not a cure for exhaustion; it is a preventative measure. Once you are burned out, a 15-minute coffee break won’t fix you. You need to build “Idle Time” into your schedule before you crash. This idle time is the “Incubation” phase we talked about.

• Tactical Move: Block your smartphone. The phone is the enemy of the idle mind. It fills the necessary “void” with dopamine noise, preventing your brain from wandering into creative territory.

6. Suppress the Engineer (Temporarily) This is the hardest rep for us. When you have a weird idea, your instinct is to immediately run a unit test in your head. Is it performant? Is it scalable? Is it compliant? You must learn to delay this judgment. Hold the idea in a “quantum state” where it is neither good nor bad, just present. The time for verification will come later. If you kill the idea in the first 3 seconds, you never get to see what it might have evolved into.

The Cheat Codes: Creative Toolkits

Sometimes, willpower isn’t enough. You are stuck in the “Thinking Canyon,” and you need a ladder to climb out. This is where Creativity Support Tools come in.

These often take the form of Card Decks. Why cards? Because cards introduce two things engineers hate but creativity loves: Randomness and Constraint. Shuffling a deck forces a connection you would never logically choose.

Here are the standard-issue kits you should know about:

1. Design with Intent Cards These are excellent when you are working on user behavior. The deck addresses a core problem: How do we design a system that influences people to do (or not do) something?

• How it works: Each card presents a “gambit” or pattern phrased as a question (e.g., “Can you use social proof to change user behavior?”). They act as provocations. You pull a card, and you must try to apply that lens to your current problem. It forces you to look at your software through a behavioral psychology lens rather than just a functional one.

2. Grow-a-Game Cards This set is pure inspiration through chance. It is designed for game development but works for any interactive system. It helps you brainstorm mechanics and dynamics by mashing up values and actions. If you are trying to “gamify” an app or just make a UI more engaging, these cards can break you out of standard patterns.

3. The Catalyst Kit This kit is special because it was created by an alumnus of this very institute (who later became Head of Design at Atlassian).

• Focus: It isn’t just about “ideas”; it’s about the process. It addresses the friction between Design, Code, and Marketing. It helps teams reflect on how they are collaborating. It’s a tool for debugging your team’s creative workflow, not just the product.

4. IDEO Method Cards IDEO is the heavyweight champion of Design Thinking. Their deck is a mix of a Creativity Toolkit and a Process Toolkit.

• The Value: If you run a traditional engineering process, it focuses purely on “Problem Solving.” This is efficient but sterile. If you focus only on “Creativity,” you get chaos. The IDEO cards bridge the gap. They give you specific methods (like “Shadowing” a user or “Bodystorming”) to visualize invisible aspects of the problem. They force you to leave your desk.

5. Collective Action Toolkit (frog design) This is one of the most comprehensive kits available. It goes beyond the single “spark” and helps manage the entire lifecycle of a project. It balances the “Snake Swallowing Tennis Balls” concept — helping you manage the expansion (creativity) and the reduction (selection) phases so the team doesn’t burn out or get lost in the weeds.

The Final Paradox

We end this series with the central paradox of your career.

The more experience you gain, the deeper your “Thinking Canyon” becomes. Your expertise is what makes you valuable — it allows you to solve known problems quickly and safely. But that same expertise is what builds the walls that block innovation. You “know” what works, so you stop looking for what could work.

Creativity, for a senior engineer, is the productive overcoming of experience. It is the ability to look at a problem you have seen a thousand times and choose to see it as if it were the first time.

So, go ahead. Build your deep canyon of expertise. But every once in a while, grab a rope, climb up to the plateau, and take a look around.

Beyond the Telescope

In a curriculum dedicated to the “Ways of Thinking in Informatics,” the chapter on Computational Thinking often feels like it holds a special, almost holy status. Since Computer Science ostensibly revolves around computers, one might assume that Computational Thinking is simply the core objective of the entire discipline.

Here is the reality check: That assumption is partially false.

Computer Science is only conditionally about computers. The legendary computer scientist Edsger W. Dijkstra is famously attributed with the aphorism: “Computer science is no more about computers than astronomy is about telescopes.” While the provenance of this quote is debated — Wikiquote marks it as disputed — the underlying sentiment remains structurally sound. Astronomy involves the development of high-performance instruments, yes, but the goal of the astronomer is not to build a telescope; it is to gain knowledge about the universe using that telescope.

Similarly, Informatics does not have the sole objective of building powerful machines. We certainly have sub-disciplines dedicated to hardware and architecture, but the soul of the field lies elsewhere. Computational Thinking is indeed a core concern, but we must be careful not to elevate it to a mythical “silver bullet” status. It is essential, but it is nuanced. To understand it, we have to look at how we solve problems with these machines, rather than just how the machines work. As Stephen Wolfram (the physicist behind WolframAlpha) once noted, the act of actually programming something inevitably allows one to do more exploration of the concept itself. It is a tool for thought, not just calculation.

The Revival: Jeannette Wing and the Definition

The modern terminology was effectively resurrected in 2006 by Jeannette Wing. She published a seminal article titled “Computational Thinking” in the Communications of the ACM, one of the most influential journals in the field. While the concept had roots stretching back to the mid-20th century, Wing gave it a definition that stuck. She described it as a specific form of problem-solving competence: tackling complex problems through abstraction, algorithmic thinking, and decomposition so that they can be solved by (or with) a computer.

Wing’s definition is precise: It involves the thought processes required to formulate problems and their solutions so that the solutions are represented in a form that can be effectively carried out by an “information processing agent.” This is a critical distinction. It implies that this mode of thinking transforms the conduct of every discipline. A professional with the ability to use computation effectively possesses a distinct “edge” over one who cannot. It is not just about writing code; it is about structuring reality in a way that code can manipulate it.

The True Origin: Ada Lovelace’s Vision

To truly understand the depth of this concept, we have to look much further back than 2006 — all the way to the 19th century. Augusta Ada King, Countess of Lovelace (born 1815), provides the first historical evidence of Computational Thinking. At the age of 17, she witnessed a demonstration of a partially finished automatic calculating machine and was immediately captivated. She met its creator, Charles Babbage, and wrote about seeing the “thinking machine” (or so it seemed) raising numbers to the 2nd and 3rd powers and extracting roots of quadratic equations.

Babbage and Lovelace began a collaboration that would define the pre-history of computing. Babbage focused on a machine far more complex than his previous “Difference Engine.” He called it the Analytical Engine. Today, we can legitimately call this device the first concept of a “general-purpose computer.” However, there was a massive gap in understanding between the inventor and the collaborator. Babbage viewed his projects essentially as increasingly complex calculators; his primary goal was to print mathematical tables quickly and precisely to avoid human error.

Ada Lovelace saw something else entirely.

In 1842, Lovelace translated an article by a French engineer who had summarized one of Babbage’s lectures. During the translation process, she appended her own thoughts in the form of seven “Translator’s Notes.” These notes were three times the length of the original article. They reveal that while Babbage was building a calculator, Lovelace had conceptually invented the computer. She discussed the potential for what we now call “nested loops” and, most importantly, the abstraction of moving from manipulating numbers to manipulating symbols.

In these notes, we find the first documented instance of Computational Thinking. Lovelace wrote: “The Analytical Engine has no pretensions whatever to originate any thing. It can do whatever we know how to order it to perform. It can follow analysis; but it has no power of anticipating any analytical relations or truths.”

This quote is frequently cited to demonstrate that AI cannot be truly creative, but there is a second, more profound half to her observation. She noted that the engine is likely to exert an “indirect and reciprocal influence on science itself.” By distributing and combining truths and formulas so they can be handled by the engine, the nature of scientific subjects is “thrown into new lights, and more profoundly investigated.”

Lovelace predicted that the mere act of automating mathematical processes would force scientists to see their own fields differently. This is the essence of Computational Thinking: the tool changes the user’s perception of the problem.

The 20th Century Pillars: Papert and Wilson

Fast forward to 1980, and we meet Seymour Papert, a pioneer who linked this thinking to education. Papert argued that everyone uses procedures in everyday life — like giving directions to a lost motorist — but these are rarely reflected upon. In a computational environment (like his LOGO programming language), a procedure becomes a distinct “thing” that is named, manipulated, and recognized. Papert famously called debugging “the essence of intellectual activity,” a perspective that reframes failure not as an error, but as the primary mechanism of learning.

Shortly after, in 1982, physicist Ken Wilson won the Nobel Prize. His contribution was the computational modeling of phase transitions in matter. Wikipedia’s entry on Wilson is telling; it lists his status as a “pioneer in using computers” before his physical discoveries. Peter Denning, writing in 2017, noted that Wilson and his contemporaries used the term “Computational Science” to describe a new paradigm of science. They viewed computation not just as a tool, but as a third pillar of scientific inquiry, standing equal alongside Theory and Experiment.

The Evolution of the Model: From Two A’s to Three

When Jeannette Wing reintroduced Computational Thinking in 2006, and in subsequent talks around 2008, she initially boiled it down to the “Two A’s”: Abstraction and Automation.

This formulation aligns with a popular, yet historically flawed, model of rational problem-solving that dates back to the ancient Greeks: First, you understand the problem (Abstraction), and then you solve it (Automation). Henrik Gedenryd, in his dissertation “How Designers Work,” deconstructed this idea. He showed that while the “First understand, then solve” model feels intuitively correct, it is empirically false.

This flawed “rational” view is perfectly encapsulated in the so-called Feynman Algorithm. Named after Nobel laureate Richard Feynman, the algorithm goes like this:

1. Write down the problem.
2. Think hard.
3. Write down the solution.

This is, of course, a joke. It originated from Murray Gell-Mann, Feynman’s colleague, who described Feynman’s method this way to express admiration for his genius. The problem is that people took it seriously. It became a stand-in for the “genius view” of problem-solving. But if you asked Feynman himself, his process was nothing like that. It was iterative, parallel, opportunistic, and messy. He didn’t “think then solve”; he used “new tricks” to change how he thought about the problem. As we discussed in Scientific Thinking regarding “cognitive artifacts,” externalizing knowledge changes what we are capable of thinking.

Jeannette Wing’s “Two A’s” (Abstraction -> Automation) sounded suspiciously like the Feynman Algorithm. It suggested a linear flow: model the world, then automate it. Critics pointed out that this ignored the iterative nature of real engineering and science.

Consequently, Wing updated her model. The “Two A’s” became the “Three A’s”: Abstraction, Automation, and Analysis.

Crucially, she placed these three elements into a cycle.

1. Abstraction: We model the problem to get a formulation we can automate.
2. Automation: We let the “information processing agent” execute the solution.
3. Analysis: We examine the results of that execution.

This analysis then feeds back into the Abstraction phase. The insights gained from the automation allow us to refine the model, fix the bugs, and improve the logic. We iterate. This cyclic view acknowledges that we often don’t truly understand a problem until we have tried (and perhaps failed) to simulate or solve it computationally. This loop — Abstraction, Automation, Analysis — is the modern, robust definition of Computational Thinking.

Next, we will look at how this thinking style triggered five distinct revolutions in science, and why FedEx might be faster than the internet.

Part 2: The Five Revolutions & The New Science

The Landscape of Change

If we accept that Computational Thinking isn’t just “using a computer” but a fundamental shift in how we process reality, we have to look at the scale of that shift. It’s not just about doing math faster; it’s about changing what “doing math” actually means.

Matti Tedre, a Finnish computer scientist, delivered a lecture in 2019 that captured this perfectly. He postulated five computing revolutions in science. This framework is arguably the most comprehensive way to understand the impact of CT. It moves beyond the hardware and looks at the philosophical and sociological shockwaves.

1. The Technological Revolution

This is the most obvious layer. It’s about speed. We take known processes and accelerate them by orders of magnitude. Think of encryption or decryption. Historically, a “computer” was a human being who performed calculations. We moved from Human Computing to Machine Computing. This is essentially the “upgrading” of mathematics. However, this speed brings a side effect: We now have mathematical proofs generated by computers that are so complex that no single human can verify them manually. We trust the machine because the math is “known,” but the scale is alien.

2. The Methodological Revolution

Here, we start doing things that were previously impossible, not just slow. The classic example is the Monte Carlo method. This is a class of algorithms that rely on repeated random sampling to obtain numerical results. Before computers, you couldn’t reasonably “simulate” randomness a million times to find a probability curve. Now, it’s a standard method. Computational Science has emerged as a distinct methodology, sitting right next to the traditional scientific pillars of Theory and Experiment.

3. The Epistemological Revolution

This is where it gets heavy. Epistemology is the branch of philosophy concerned with knowledge — “What can we know?” Tedre argues that computation gives us a new way to interpret the world. Simulation becomes a valid path to knowledge. Previously, we observed the world or theorized about it. Now, we simulate it. If a simulation accurately predicts a phenomenon, we accept the simulation’s rules as a form of truth. This is a Representational Shift, equivalent in human history to the invention of writing, the printing press, or the moving image. Code is now a valid way to represent knowledge.

4. The Ontological Revolution

Ontology asks, “What exists?” Computational Thinking introduces new concepts and entities into our reality. We now treat “information processes” as fundamental building blocks of the universe. We explain biological phenomena (like DNA) as “code.” We talk about the “state” of a system. These are computational metaphors that have become the actual descriptions of reality.

5. The Sociotechnical Revolution

Finally, science itself has changed as a social activity. The lone genius is being replaced by massive, distributed networks. Tedre points to a physics paper with 5,154 authors. The paper itself is 33 pages long; only the first nine pages describe the research. The rest is the list of authors. This scale of collaboration is only possible because of the communication and data-handling infrastructure provided by computing.

Computational Thinking in the Wild

To ground these high-level revolutions, let’s look at four concrete examples of how this thinking manifests in the real world.

Example 1: The Reset (The Engineer, The Physicist, and The Programmer)

There is an old joke that Jeannette Wing cites as a legitimate example of CT. An engineer, a physicist, and a programmer are driving in a car. Suddenly, the car stalls and stops. The Engineer says: “It must be the fuel injectors. The gas mixture isn’t right.” The Physicist says: “No, clearly the cylinder head gasket has failed due to thermal expansion.” The Programmer looks at them and says: “I suggest we all get out, wait a few seconds, get back in, and then it should work.”

Wing argues this isn’t just a gag. It represents a specific computational strategy: The Reboot. A person thinking computationally understands that a complex system has an “internal state.” If that state gets corrupted, you don’t necessarily need to fix the physical component immediately; you need to reset the system to a “known, fresh state.” It’s a valid, abstract solution to a physical problem.

Example 2: Shotgun Sequencing

This is the “poster child” for Computational Thinking in biology. Shotgun sequencing is a method used for sequencing genomes. DNA strands are massive. You cannot just read them start-to-finish. In this method, the genome is cloned and then violently “shredded” into tiny, random fragments (about 1000 base pairs long). These small pieces are individually sequenced. Then, the magic happens. A computer takes these millions of random, overlapping puzzle pieces and looks for patterns where the ends match. It reassembles the full sequence purely through pattern recognition algorithms. This approach makes the impossible possible. It is only “thinkable” if you already know that a computer can handle the reassembly. If you didn’t have CT, you wouldn’t even attempt to shred the DNA, because you’d have no way to put it back together.

Example 3: The Earth-Sized Telescope (and FedEx)

When researchers photographed a Black Hole for the first time, they didn’t use one telescope. They linked radio telescopes in Arizona, Spain, Mexico, Antarctica, and other locations to form a “virtual instrument” the size of the Earth (The Event Horizon Telescope). Here is the data problem: The telescopes collected 5 petabytes of data. That is roughly 5,000 years of MP3 music. They needed to get this data to a central supercomputer to merge it. How do you move 5PB? The internet is too fast? No. The researchers said: “What we actually do is, we take our hard drives and we FedEx them from place to place. This is much faster than any cable that you can ever find.” A 500kg crate of hard drives moving via airplane represents a data transfer rate of roughly 14GB/sec. This is a classic computational trade-off: Bandwidth vs. Latency. The “Ping” is terrible (it takes 24 hours to arrive), but the bandwidth is unbeatable. Understanding that physical logistics is just another form of data bus is pure Computational Thinking.

Example 4: The Monty Hall Simulation

Finally, we have the Monty Hall problem. You have three boxes (or doors). One has a prize (a pearl), two have nothing (peas). You pick a box. The host opens one of the other boxes to reveal a pea. He asks: “Do you want to switch your guess to the remaining closed box?”

Intuitively, most people say it doesn’t matter. It feels like a 50/50 split. But if you write a simple simulation — a script that runs this scenario 10,000 times — you see the truth immediately. Switching wins 2/3 of the time. The simulation forces you to accept a mathematical reality that your intuition rejects. However, as we will discuss later, the goal isn’t just to trust the simulation. The ultimate goal is “Code as a way of understanding.” By writing the code, you can actually see the logic: The variable determining which box the host opens becomes irrelevant to your winning chances if you stay, but crucial if you switch. The code reveals the structure of the logic itself.

The New Scientist: The Research Software Engineer

This shift has created a new job description: The Research Software Engineer. These are people who bridge the gap. They are scientists who think in code. The archetype for this is Tim Berners-Lee. On paper, he was a physicist at CERN. In reality, he was a computer scientist. He didn’t invent the World Wide Web just for fun; he invented it to solve a specific information exchange problem between researchers. He applied computational concepts (hypertext, client-server architecture) to a sociological problem (scientific collaboration).

Jeannette Wing noted that this transformation is happening everywhere. Computational biology changes how biologists think. Computational game theory changes how economists think. It is not just a tool; it is a new language for every discipline.

Next, we dive into the history of the “Act” of programming itself — how we went from “Writing” poetry for machines to the industrial “Engineering” of the NATO conference, and why the Waterfall model was doomed from the start.

Part 3: A History of “The Act”: From Writing to Engineering

The Great Gap & The War Machines

After the visionary work of Charles Babbage and Ada Lovelace, the history of computing hit a pause button. Babbage was a brilliant inventor but a terrible communicator, and Lovelace died tragically young at 34, likely from cancer. Their ideas — the “Analytical Engine” and the first “program” — were largely lost to time, misunderstood by their Victorian contemporaries who only saw fancy calculators. It took nearly a century for the train to leave the station again, and unfortunately, it was war that fueled the engine.

The catalyst was the Enigma, a German machine used during World War II to encrypt communications. While not a computer in the modern sense (it was a highly specialized electromechanical cipher device), the Allied effort to break it birthed the modern computing era. This happened at Bletchley Park, where a team of British mathematicians and “computers” (the job title for humans who did calculations) worked to decrypt messages.

The “Bomb” (or Bombe) was the machine designed to crack Enigma. It wasn’t a general-purpose computer; it was a beast built for one specific task: finding the daily settings of the Enigma machines. This project was critical — it is estimated that the work at Bletchley Park shortened the war by two to four years.

The Hidden Figures of Bletchley

The most famous figure here is Alan Turing, the father of theoretical computer science. He formalized the concept of the “General Purpose Computer” (the Turing Machine) and later laid the groundwork for AI with the Turing Test. But the history books often gloss over his team. Joan Clarke was a pivotal figure who worked alongside Turing on the Bomb. Because the job of “crypto-analyst” wasn’t technically open to women, she was hired as a “Linguist,” despite speaking no foreign languages. Her pay and rank reflected this bureaucratic fiction, not her actual contributions.

This is a recurring theme we need to address: The history of informatics is often told through a male lens, erasing the women who were foundational to the field. Just as we saw in Scientific Thinking with the Viking warrior leader (who turned out to be a woman upon modern DNA analysis), computing history is full of “forgotten” women. Turing himself was later persecuted for his homosexuality, driven to suicide by state-mandated hormone “therapy” — a tragedy that highlights how society treated the architects of its own salvation.

ENIAC: The First “Real” Computer

The shift from specialized machines like the Bomb to true “General Purpose Computers” happened with the ENIAC (Electronic Numerical Integrator and Computer). Commissioned for calculating artillery firing tables, it ended up being a programmable beast that could solve a wide array of problems. In the genealogy of modern computing, ENIAC is the root node. Everything we use today traces back to it.

But who programmed it?

The hardware was built by men, but the ENIAC Six — the first professional programming team in history — were women. In 1944, there were nearly 50 women working on the project, but six of them became the core operators. At the time, they were often dismissed as “refrigerator ladies” (models posing with appliances), but in reality, they were inventing the discipline of software engineering from scratch. They didn’t have a manual. They had wiring diagrams.

Phase 1: Programming as “Writing”

To understand the mindset of this era (1940s-1950s), you have to realize that programming languages didn’t exist. There was no Python, no C, not even Assembly.

Programming the ENIAC meant physically connecting cables and setting switches. It was “operating at the open heart of the patient.” The machine was completely exposed. To “program,” you had to describe a narrative of what the electricity should do. The programmers wrote this narrative down as text — prose descriptions of the logic — and then translated that text into physical connections.

This era defined programming as “Writing.” Code was seen as a literary form, a story told to the machine. This philosophy persisted even as early languages emerged. Donald Knuth’s magnum opus, The Art of Computer Programming, enshrines this view: Code is a form of art, meant to be beautiful and elegant.

However, this “artistic” approach has a fatal flaw. It works great for calculating Bernoulli numbers or polynomials (linear mathematical tasks). It fails catastrophically when you introduce complex branching logic. If your “story” jumps around too much, it becomes unreadable. This led to the famous edict by Edsger Dijkstra in 1968: “Go To Statement Considered Harmful.” He argued that using GOTO commands (which jump the program flow to a different line) creates “spaghetti code” that is impossible to maintain. The “Writing” metaphor was hitting a wall.

Phase 2: The Software Crisis

By the 1960s, computers had evolved from room-sized calculators to mainframes like the IBM 360. These machines were powerful, and they were everywhere — banks, airlines, governments.

Suddenly, the industry faced a terrifying reality: Software was becoming more expensive than hardware. The programs required to run these mainframes were so complex that a single “artist” couldn’t write them. They couldn’t even be fully mathematically described or tested. Projects ran over budget, missed deadlines, and were full of bugs.

Dijkstra (the “first nerd,” who started counting at zero) described the crisis in 1972: “As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now that we have gigantic computers, programming has become an equally gigantic problem.”

Phase 3: The Pivot to “Engineering”

The industry needed a fix. In 1968, the NATO Science Committee organized a conference in Garmisch, Germany. The goal was to solve the software crisis.

Their solution was a fundamental shift in identity. They decided that software development should no longer be an art or a craft. It should be an Engineering Discipline.

This was a massive philosophical pivot. They wanted to industrialize code. The idea was to build software like we build bridges or cars:

1. Standardization: Use interchangeable parts.
2. Hierarchy: Managers oversee architects, who oversee coders.
3. Process: Follow a strict, linear sequence of steps.

This decision birthed Software Engineering as a term and a profession. It rejected the idea of software as architecture (a design discipline) and embraced the factory model.

The Waterfall Model

The embodiment of this engineering mindset is the Waterfall Model. It visualizes development as a cascade:

• Requirements Analysis → Design → Implementation → Verification → Maintenance.

The theory was seductive: You finish one phase completely, document it perfectly, and “hand it off” to the next team. It allows for centralization and clear management. It looks great on a Gantt chart.

There was just one problem: It doesn’t work.

Winston Royce, the man often credited with inventing the Waterfall model in his 1970 paper, actually wrote the paper to say it was a bad idea! He included a diagram of the linear process and explicitly stated: “I believe in this concept, but the implementation described above is risky and invites failure.”

He argued that software is inherently iterative. You discover new things about the problem while you are coding the solution. A strict linear process forbids this learning. If you find a design flaw during implementation in a Waterfall model, it’s too late — you’ve already signed off on the Design phase.

The Mythical Man-Month

The failure of this industrial “Construction” mindset was immortalized by Frederick Brooks, who managed the development of the OS/360 (the operating system for the IBM 360). It was the largest software project in history at the time, and it was a disaster of delays and bugs.

Brooks wrote The Mythical Man-Month, a book that remains the bible of software project management. His central law is devastating to the factory model: “Adding manpower to a late software project makes it later.”

Why? Because software isn’t digging a ditch. If you have a ditch to dig, adding more people helps. In software, adding people increases the communication overhead quadratically. New people need to be trained, and they interrupt the work of the experienced people. Brooks also described “Software Entropy”: As time passes, a system becomes less and less well-ordered. Eventually, fixing bugs creates more bugs. The system wears out, not physically, but logically.

This realization — that you cannot “construct” software like a building — led us to the modern era. We had to abandon the idea of “Building” and embrace a new metaphor: “Growing.”

Next, we explore “Code as a Garden,” why your codebase is likely a sick patient, and the cognitive science of how we actually read and understand this strange artificial language.

Part 4: Growing Code, Decay, and The Cognitive Shift

From Construction to Cultivation

If the “Waterfall” model was an attempt to treat software like a construction site — rigid, planned, and architectural — the modern era is defined by a realization that this model is fundamentally broken. We have moved from the metaphor of Building to the metaphor of Growing.

Software development is not about stacking bricks according to a blueprint that was finalized months ago. It is an organic process. The “Standish Group Chaos Report” (2015), which analyzed 50,000 projects, made this brutally clear: Linear processes fail. Iterative processes succeed.

This shift changes the definition of “Programming” again. It is no longer about “Writing” a story or “Constructing” a bridge. It is about Gardening. You plant a seed (a prototype), you water it (add features), you prune it (refactor), and sometimes you have to rip out weeds (debugging). As you move pieces on the board — Concept, Design, Model, Code — everything evolves simultaneously. You don’t know exactly what the final tree looks like until it has grown.

The Codebase as an Organism

In 2014, Kevin Simler published an influential essay titled “A Codebase is an Organism.” He argued that the engineering metaphors we use (architecture, foundation, build) are actively harmful because they imply stability. “The computer is a machine,” Simler wrote, “but a codebase is an organism.”

This biological view exposes the dual forces at play: Growth and Decay. Just like a living thing, code that isn’t actively maintained begins to rot. We call this “Bit Rot” or “Software Entropy,” but the biological metaphor is more accurate: it’s a sick patient. The role of the programmer shifts from “Architect” to “Nurse.” We spend much of our time diagnosing symptoms, applying patches, and trying to keep the patient alive as it grows more complex and unwieldy.

The Reality Check: “It Isn’t Done Yet”

Despite our fancy new metaphors, the actual state of software engineering is arguably a disaster. If you browse communities like Reddit’s /r/ProgrammerHumor, you’ll see the collective trauma of the industry. We joke about “spaghetti code,” “technical debt,” and copying from Stack Overflow because deep down, we know our processes are fragile.

Alan Kay, a Turing Award winner and one of the fathers of object-oriented programming, offers a sobering critique. He argues that the computer revolution hasn’t actually happened yet. We are still in the Stone Age. Kay says: “The worst thing we could ever do is to pretend to the students that we know what [computer science] is… We should teach the students… that it isn’t done yet. It’s not even close to done.”

Kay points out that we build massive systems (skyscrapers) using the methods suitable for small scripts (log cabins). We stack log cabins on top of each other and hope they don’t collapse. A prime example of this fragility is NPM (Node Package Manager). It is the largest software registry in the world, yet the average package depends on 683 other packages. This creates a “Dependency Hell” where security is impossible to guarantee.

• Case in point: The ua-parser-js library. It’s a tiny utility used by millions. In 2021, a malicious actor hijacked it and injected malware. Instantly, millions of systems worldwide were compromised.
• The sobering stat: For every 100 lines of code, there is likely an undiscovered bug. When you have millions of lines of dependencies you didn’t write, the math is terrifying.

The Cognitive Science of Coding

So, if the systems are complex and organic, how do humans actually understand them? This brings us to the cognitive science of programming, specifically the work of Australian researcher Raymond Lister.

Lister studies what happens in our brains when we read code. He identified a critical skill that is often ignored in education: Code Tracing.

The Three Stages of Understanding

Lister argues that programmers move through three cognitive stages:

1. Pre-Tracing: The novice stage. You look at code and guess what it does based on variable names or comments, but you cannot mentally execute the logic. You are essentially “guessing.”
2. Tracing: You can manually simulate the computer in your head. You can take a piece of paper, track the variables, line by line, and calculate the output. This is the mechanical understanding of how it works.
3. Post-Tracing: This is expert-level. You look at a block of code and you don’t need to run it line-by-line. You instantly recognize the pattern. You understand the intent and the function without doing the mental math.

The “Chunking” Phenomenon

This transition to Post-Tracing relies on Chunking. It’s the same process as learning to read. When you learn a new script (like Cyrillic), you focus on the lines (curves vs. straights). Then you see letters. Then you see words. Eventually, you read whole sentences without looking at the letters. In coding, a novice sees: int i = 0; while (i < n) { ... i++ }. An expert just sees: “Loop n times.” This chunking allows experts to reason about abstract problems because their short-term memory isn’t clogged with syntax details.

The “Variable Swap” Experiment

Lister demonstrated this with a simple experiment. Consider this logic (represented here in pseudo-code):

1. Compare y1 and y2. Put the smaller value in y1 and the larger in y2.
2. Compare y2 and y3. Put the smaller value in y2 and the larger in y3.
3. Compare y1 and y2 again. Put the smaller in y1 and the larger in y2.

The Question: What is the relationship between y1, y2, and y3 at the end?

• The Tracer (Stage 2) will take specific numbers (e.g., 5, 2, 8), run them through, and say “It worked for these numbers.” But they might miss the general rule.
• The Post-Tracer (Stage 3) looks at the structure and realizes: “This is a bubble sort network. It sorts the three variables from smallest to largest.”

Lister found that students who could trace perfectly on paper often failed to answer the “big picture” question because they were stuck in the details. They couldn’t see the forest for the trees.

Code as a New Way of Understanding

This brings us back to the ultimate point of Computational Thinking. Code is not just a way to tell a computer what to do. Code is a way of understanding the world.

When you reach the “Post-Tracing” level, code becomes a language for reasoning. Recall the Monty Hall simulation from Part 2. If you look at the code for that simulation, there is usually a line that defines which door the host opens: host_opens = a door that is NOT the player's pick AND NOT the prize door. Once you write that line, you realize something profound: The host’s choice is constrained. The variable host_opens adds information to the system because it cannot be random. You don’t even need to run the simulation anymore. Just writing the code forces you to see the logic structure that makes switching the winning strategy.

This is the Epistemological Revolution. Just as we use calculus to talk about rates of change, we use code to talk about processes, states, and complex systems. As physicist Niels Bohr said, “Science is not to tell us about the universe, but to tell us how to talk about the universe.” Code is our new way of talking.

Next, in the final part, we will demystify the “Algorithm” — separating the media’s “Dark Side” fear-mongering from the mathematical “Light Side” — and break down the 5 Principles of Algorithmic Thinking.

Part 5: Algorithmic Thinking: The Light, The Dark, and The Logic

The Definition: What is an Algorithm?

Before we can master the five principles of algorithmic thinking, we need to agree on what an “algorithm” actually is. The term itself is ancient, deriving from the name of the 9th-century Persian scholar Al-Chwarizmi (Latinized as Algorismi), the same mind who gave us the term “Algebra.”

While Wikipedia offers a functional definition, we need something more robust for computer science. An algorithm isn’t just “code.” A recipe for lasagna is an algorithm. A protocol for landing a plane is an algorithm. To qualify as a true algorithm in our context, a process must satisfy four strict criteria:

1. Unambiguous Action: It must be a clear prescription for action. There is no room for interpretation. “Stir until it tastes good” is not an algorithm; “Stir for 30 seconds” is.
2. Finite Steps: It must consist of a finite number of well-defined individual steps. It cannot run forever; it must eventually conclude.
3. Input/Output: It must take a clear input (e.g., two numbers) and transform it into a clear output (e.g., the product of those numbers).
4. Substrate Independence: Crucially, an algorithm works with or without a computer. You must be able to execute it with a pen and paper. If it requires a specific piece of silicon to exist, it’s an implementation, not an algorithm.

This distinction is vital: Algorithms are abstract; Programs are concrete. An algorithm is the pure logic; a program is that logic frozen into a specific language (like Python or C) to run on specific hardware.

The Power of Scale: Linear vs. Binary Search

To see why algorithmic thinking matters, let’s look at a classic problem: Searching for a specific CD in a collection that is sorted alphabetically by band name.

Method A: The Linear Search You start at the left end of the shelf. You look at the first CD. Is it the one you want? No. You move to the next. You repeat this until you find it.

• The Math: If you double the number of CDs, the time it takes to find your target also doubles (on average). The effort grows linearly with the dataset size.

Method B: The Binary Search You go straight to the middle of the shelf. You look at the CD. Is the band name “Zappa”? You are looking for “Beatles.” “Beatles” comes before “Zappa.” You now know, with absolute certainty, that the CD is in the left half of the shelf. You can ignore the entire right half. You then go to the middle of the left half and repeat the process.

• The Math: Every time you make a check, you eliminate 50% of the remaining possibilities. If you double the number of CDs, you only need to add one single extra step to the search process. The effort grows logarithmically.

This difference is the “Scalability” principle in action. For 10 items, the difference is negligible. For 10 billion items, Linear Search is impossible, while Binary Search is instant.

The Devil is in the Details

However, understanding the concept of Binary Search is easy. Implementing it is a nightmare. Because algorithms must be “unambiguous” and handle all edge cases, humans are terrible at writing them correctly.

In 1983, researcher R. Lesuisse conducted a study on Binary Search. He examined 20 implementations of the algorithm found in published educational articles. The result: Only 5 out of 20 were correct. 15 of them contained subtle bugs — usually “off-by-one” errors (e.g., excluding the middle item incorrectly) or failing to handle empty lists. This proves that high-level conceptual understanding (Abstraction) is not enough; you need rigorous precision (Specification) to make it work.

The PR Problem: The “Dark Side” of Algorithms

In the public sphere, the word “Algorithm” has acquired a sinister vibe. It has become a placeholder for “opaque system that oppresses me.” If you search Google News for “Algorithm,” you find headlines asking: “Are algorithms sexist?” “Do algorithms control our lives?”

We can think of this as the Dark Side vs. the Light Side.

• The Dark Side: Algorithms that determine creditworthiness, police patrols, or job applications. These are often “Black Boxes” where biases in data (Machine Learning) are codified into rules that affect human lives without accountability.
• The Light Side: The algorithms that route logistics so supermarkets have food, the code that compresses video so you can stream movies, or the search tools that organize the world’s information.

The media often conflates “Algorithm” with “Machine Learning” (AI).

• Classic Algorithms (Symbolic AI) are rules we write. We know exactly how they work (e.g., Binary Search).
• Machine Learning (Sub-symbolic AI) involves systems that learn their own rules from data.

When people are angry at “The Algorithm,” they are usually angry at the opaque results of Machine Learning, not the sorting logic of Computer Science. However, as computer scientists, we own both.

The Framework: The 5 Principles

So, how do we master this thinking style? Stefan Szeider breaks down Algorithmic Thinking into five distinct pillars. These are the mental tools we use to tame complexity.

1. The Principle of Specification: Before we solve, we must define. We need to describe the problem and the goal with mathematical precision, removing all ambiguity.
2. The Principle of Decomposition: “Divide and Conquer.” We break a massive, scary problem into tiny, manageable sub-problems that we can solve individually.
3. The Principle of Abstraction: We hide the messy details. We create models that ignore the irrelevant parts of reality so we can focus on the core structure (like using a map instead of a satellite photo).
4. The Principle of Scalability: We don’t just solve for today’s data. We ask: “What happens if the inputs grow to infinity?” We design for efficiency at scale (like choosing Binary Search over Linear).
5. The Principle of Reduction: We don’t reinvent the wheel. We try to transform our new problem into an old problem that we already know how to solve.

These five principles are the DNA of the discipline. They transform us from people who just “write code” into people who “solve problems.”

This concludes the transformation of the Computational Thinking lecture notes. The five parts cover the history, philosophy, practice, cognitive science, and algorithmic foundations of the field.

If you go to YouTube right now and type “critical thinking” into the search bar, you are going to see a mess. You won’t just find educational content; you’ll find videos of people screaming at each other, insulting intelligence, and engaging in bad-faith arguments. That isn’t what we are here to do. We need to strip away the internet noise and get down to the brass tacks of what it actually means to think critically, especially as engineers and technical professionals.

Defining the Undefinable

At its core, critical thinking is the fundamental willingness to question things and get to the bottom of them. It is a dual-stack system: you need a critical attitude (the mindset) and specific cognitive skills (the toolset). These skills include raising the right questions, conducting independent research, analyzing data, evaluating sources, and integrating that information to reach a well-founded, explainable judgment.

That sounds like a solid definition, but it’s a bit of a “list of ingredients” without the recipe. In the educational sciences, this is a known problem. There are countless studies dedicated to figuring out if you can actually teach critical thinking. The results? Honestly, they are modest. Some researchers have even concluded that critical thinking is less of a method you learn and apply, and more of a personality trait or an attitude you adopt.

To make this concrete, let’s look at the framework provided by Otto Kruse, a psychologist and writing researcher who led the Centre for Academic Writing at the University of Zurich. He breaks it down into four distinct buckets:

1. Self-directed and self-aligned thinking: This refers to metacognitive abilities — thinking about your thinking. It involves maintaining intellectual autonomy and adhering to quality criteria for your own thoughts.
2. Rational procedure: This is crucial when things get messy. How do you handle ill-defined problems or genuine ignorance? You need reflected, methodical thinking, not just guessing.
3. Skeptical thinking: This is the critical reflection and testing of all knowledge assumptions. It implies a high awareness of error and deception. You have to assume you could be wrong.
4. Habits of thought: This treats critical thinking as a personality feature — a careful, deliberate handling of facts and knowledge as a default mode of operation.

While one might not agree with every single point Kruse makes, his positioning of critical thinking as a central educational goal is vital. He argues that this is the core of higher education and a service universities provide to society. Kruse also dropped a line that is incredibly relevant for us: “Writing is the royal road to learning to think.” As computer scientists, we write a staggering amount. We just happen to write in languages designed to give instructions to machines rather than communicate with humans. Despite that difference, the ability to read with deep comprehension (reading skills) correlates strongly with programming performance.

The Pocket Guide to Rigor

Let’s get granular. If we want to practice critical thinking, we need a standard to measure our thoughts against. There is a concept known as the “Pocket Guide to Critical Thinking” that provides a checklist of essential properties. If you are debugging a complex system or arguing a system architecture, these are your metrics.

Clarity A statement must be clear and unambiguous. In computer science, we suffer from this constantly: everyone in the meeting nods and agrees, but everyone is silently thinking of a completely different implementation. This “silent disagreement” happens because of unstated ambiguity. You need to ask: Can this thought be worked out better? Can we give an example? Can we visualize exactly what is meant?

Correctness Here is the trap: a statement can be perfectly clear but completely false. For example, “Most dogs weigh more than 150 kg.” That is a grammatically correct, unambiguous, crystal-clear statement. It is also factually wrong. The key here is verification. How can we check this? How do we find out if it is true? How do we test it?

Precision Vagueness is the enemy. If I say, “Peter is overweight,” what does that mean? Is he 1 kg over his BMI target? 20 kg? 80 kg? We don’t know because the precision is missing. We need to ask: Can we address this more specifically? Can we add details? Can we express this numerically?

Relevance You can have a statement that is clear, correct, and precise, but completely useless. Relevance forces us to ask: How does this connect to the problem? How does it impact the question at hand? Does this actually move the needle?

Depth This is where many technical arguments fail. A statement can meet all the previous criteria but be superficial. Consider this statistic: “95% of all heroin addicts have also smoked cannabis.” This is likely clear, correct, precise, and relevant to a drug discussion. But it is superficial and superfluous because it fails to reflect the complexity of the situation (correlation vs. causation). Deep thinking asks: What factors make this problem difficult? Where are the complex aspects? What are the hard questions we are avoiding?

Networking (Breadth) An argument can check every box above and still only represent a slice of the truth. For example, “Reducing three lanes to two on the Getreidemarkt will cause massive traffic jams.” That might be true from a traffic flow perspective. But we must view it from other angles. Do we need to consider other standpoints (urban planning, environmental impact, pedestrian safety)? Do we need a new approach to the problem entirely?

Logic Does the whole thing make sense? Do the beginning and the end fit together seamlessly? The constituent parts must align without contradiction.

Focus Arguments often drift. Are we dealing with the most important problem? Is the central idea actually in the focus of interest, or are we bike-shedding on minor details? Which of the presented facts are actually decisive?

Fairness Finally, have we considered the viewpoints of others? Fairness demands an active effort to understand opposing positions and incorporate them into our thinking. Is there a hidden self-interest? Are we appreciating the viewpoints of dissenters constructively?

Practicing this list is incredibly difficult. It is worth noting that in today’s discourse, “critical thinking” of this nature is sometimes dismissed or branded as “woke” (whatever that term is supposed to mean in this context). Do not be discouraged by that. Ultimately, critical thinking is the only thing that moves us forward.

The Model of Thinking

To understand why we fail at the standards listed above, we need a model. We aren’t trying to build a biological model of the brain here — we are building a conceptual model of thinking.

Models are simplified summaries and reflections of what we observe. They aren’t necessarily “true” or “false” in a binary sense; they are useful or not useful. If a model explains our observations without breaking established knowledge, it works. It gives us a vocabulary. However, models are always incomplete. We need to know where the model ends. Our model here does not distinguish much between perception and thinking. The moment light hits the retina and stimulates sensory cells, we are “thinking” in this framework.

A common, but flawed, model is the Stream of Consciousness. We imagine ourselves standing on the bank of a river, watching thoughts flow by, picking out the ones we like based on creativity or logic. The problem with this model is that it ignores the massive amount of unconscious processing and decision-making that happens upstream. It doesn’t explain where the thoughts come from.

We need a more inclusive, “monolithic” model. Our model posits that thinking is not a single stream, but the sum of actions and interactions between many Components of Thinking.

The Fast vs. Slow Components Thinking consists of many interacting parts. Some are fast, some are slow. Some are conscious, some are hidden.

Imagine someone throws a ball at you unexpectedly. You react. You throw your hands up to deflect or catch it. This is a stunning computational feat. If you tried to use your “rational thinking” (the conscious component) to calculate the trajectory, solve the differential equations, and move your muscles, you would get hit in the face long before you finished the first calculation. Even for robots, catching a ball is an extraordinary task.

In that split second, your rational thinking steps aside and lets other components — fast, automated, physical components — take the lead. Whether you catch it depends on your practice, but the reaction happens without “you” (your conscious self) doing it.

We see this interference in other areas. Have you ever tried to carry a glass of water filled to the very brim? If you stare at the water and consciously try not to spill it, it becomes incredibly difficult. Your hand shakes. But if you look away and let your body handle it, you often spill less. When the conscious, rational mind gets involved in tasks it isn’t suited for, it becomes a bottleneck.

The Inner Game of Tennis

There is a fascinating example of this in Timothy Gallwey’s book, The Inner Game of Tennis. Gallwey claims you can teach competent tennis in a very short time by bypassing the conscious mind. He argues that the part of the thinking process that reflects and over-analyzes often gets in the way of the parts that actually execute the movement.

In 1973, Harry Reasoner, a TV host, invited Gallwey to prove this on The Reasoner Report. Gallwey took a woman who was completely unathletic and had never played tennis. In 20 minutes, he had her playing decent tennis.

How? He kept her conscious mind busy with trivial tasks (like saying “bounce” when the ball hit the ground and “hit” when it hit the racket) so it couldn’t critique her form. By distracting the “over-critical” component, the other components of her thinking — the ones that handle spatial awareness and motor control — could work without interference.

The participant described it perfectly: “Every time I did start to think, things went wrong. But if I just stop thinking, the body seems to know what to do… All of a sudden, everything became effortless.”

This reveals a critical flaw in our architecture: The components of our thinking do not always work together productively. They can stand in each other’s way. This is “overthinking.” It is when the rational mind tells you that you can’t ride a bike, even though your body knows you can.

The Cognitive Miser

Neurologically, we know that conscious thinking is a tiny fraction of brain activity — estimates range from 1% to 10%. We have a “Fast System” (the choir of fast components) and a “Slow System” (the conscious, rational mind).

Here is the problem: The slow components require a tremendous amount of energy. The fast components are cheap and efficient.

Evolution has subjected us to stringent selection pressure. As Richerson & Boyd (2005) put it: “…all animals are under stringent selection pressure to be as stupid as they can get away with.”

Humans are Cognitive Misers. Our brain constantly tries to outsource work to the fast, low-energy system to save the expensive, high-energy conscious system for when it’s absolutely necessary. We replace complex questions with simpler ones. We rely on heuristics (shortcuts).

This is why we have Cognitive Biases. They aren’t random glitches; they are the result of our brain trying to save power. The fast components rush forward with an answer (“It’s the availability heuristic!”), and the lazy, slow conscious mind says, “Sounds good to me,” and accepts it without verification.

This is why Critical Thinking feels so hard and why people resist it. It forces you to fight your own biology. It demands that you wake up the “cognitive miser,” spend the energy, and override the impulse to just go with the flow.

In the next part, we will open up the “Cognitive Bias Cheat Sheet” and systematically dismantle the four specific categories of errors that our energy-saving brains force us to make every single day.

Part 2: The Cognitive Miser & The Bias Cheat Sheet

We established in the previous section that the human brain operates on a dual-system architecture. You have the fast, automated components that handle ball-catching and instant reactions, and you have the slow, deliberate conscious mind that handles complex logic. The critical insight here is that your brain is fundamentally lazy. In evolutionary biology, we call this being a cognitive miser. The slow, conscious system is metabolically expensive to run, so the brain constantly tries to outsource cognitive load to the cheaper, faster system. It uses heuristics — mental shortcuts — to solve complex problems with minimal energy. When these shortcuts work, we call it intuition. When they fail, we call them cognitive biases.

This isn’t a random glitch; it is a feature. We are under stringent selection pressure to be only as smart as we need to be to survive. The result is that we don’t make rational decisions based on all available data; we make pragmatic decisions based on what is available and easy to process. To understand exactly how this breaks down, we can look at the taxonomy created by John Manoogian and Buster Benson, often called the Cognitive Bias Cheat Sheet. They categorized hundreds of biases into four distinct problems the brain is trying to solve: dealing with too much information, lack of meaning, the need to act fast, and the limits of memory.

Problem 1: Too Much Information

The world bombards us with more sensory data than we can possibly process. To function, our brain has to aggressively filter this noise. It doesn’t filter randomly; it filters based on what it already knows or what is most prominent. This filtering process is the source of our first category of errors.

A classic example here is the availability heuristic. We judge the frequency or importance of an event based on how easily we can recall an example of it. If you see constant news reports about a specific type of crime, you will believe that crime rate is skyrocketing, even if statistics show it is plummeting. A study from 1993 on the US “War on Drugs” showed this clearly: students believed drug use was rising because of intense media coverage, even though the actual data showed a decline. In our daily work, this manifests when we overestimate the difficulty of a refactoring task simply because the current, messy code structure is more “available” in our minds than the clean, theoretical solution.

This filtering mechanism also leads to the confirmation bias, perhaps the most dangerous of them all. Once we adopt an opinion, we act like a filter that only lets in supporting evidence. We accept confirming data as high-quality facts and dismiss contradictory data as noise or exceptions. Francis Bacon identified this back in 1620, noting that human understanding forces everything else to add support and agreement to its adopted opinions. This is the engine behind modern “filter bubbles.” We are not just passively receiving information; we are actively constructing a reality that reinforces what we already believe.

We also see this in how we perceive value and choices. The anchoring effect describes how we use the first piece of information we see as a reference point for everything that follows. If you see a price tag of $2000 crossed out next to a price of $1000, the TV seems cheap. If you just saw $1000, it might seem expensive. Similarly, the framing effect changes our decision based on how the data is presented. We prefer a product labeled “95% fat-free” over one labeled “5% fat,” even though they are identical. We are also subject to inattentional blindness. When we focus hard on one thing — like counting passes in a basketball game — we can completely miss massive, obvious anomalies, like a person in a gorilla suit walking through the frame. This is known as the Monkey Business Illusion.

Problem 2: Not Enough Meaning

The world is often fragmented and confusing. We see isolated data points, but we crave narrative. We need the world to make sense, so our brain connects the dots, filling in the gaps to create a coherent story. We hallucinate patterns where there are none because a false pattern feels safer than chaos.

The most famous example of this in an engineering context is survivorship bias. During World War II, the US military wanted to reinforce their bombers to reduce casualties. They analyzed the planes returning from missions and plotted the location of every bullet hole. The damage was concentrated on the wings, the body, and the tail. The engineers initially decided to reinforce those areas.

It took a statistician named Abraham Wald to stop them. He pointed out that they were only looking at the survivors. The planes that were hit in the cockpit, the engines, or the fuel tanks didn’t come back to be counted. The bullet holes on the returning planes showed where a plane could be hit and still survive. The data they had was biased by the survival of the aircraft. They needed to reinforce the empty spaces on their charts, not the filled ones. In the tech industry, we see this when we try to emulate the traits of successful startups (the survivors) while ignoring the thousands of failed companies that had the exact same traits but died quietly.

We also struggle with the difference between correlation and causation. Just because two things happen together doesn’t mean one caused the other. Our brains love to invent a causal link because it allows us to predict the future, but often these links are spurious. We also deal with the pro-innovation bias, where our optimism about a new technology blinds us to its downsides, and the anecdotal fallacy, where we trust a single personal story (“My grandmother smoked until she was 90”) over statistical data.

Problem 3: Need to Act Fast

Evolutionarily speaking, hesitation is death. If a predator attacks, you don’t have time to conduct a comprehensive risk analysis. You need to act. To facilitate this, the brain prioritizes speed over accuracy, leading to biases that push us toward immediate action or preserving the status quo.

One of the most persistent issues here is the sunk cost fallacy. We tend to stick with a losing decision simply because we have already invested time, money, or effort into it. In software projects, this leads to throwing good money after bad, refusing to scrap a flawed architecture because we have already spent two months building it. The rational move is to look only at future utility, but the fast brain wants to validate the past effort.

We also overvalue things we have created ourselves, a phenomenon known as the IKEA effect. Studies show that people value a product they assembled much higher than a pre-assembled version, even if their craftsmanship is mediocre. In coding, this leads to the “Not Invented Here” syndrome, where we prefer our own buggy custom tools over superior standard libraries.

This drive for speed and confidence leads to the overconfidence bias. We systematically overestimate our own knowledge and competence. In spelling tests, people who claim to be 100% certain of an answer are often wrong a significant portion of the time. This hubris is a root cause of major catastrophes, from Chernobyl to the Deepwater Horizon oil spill, and more recently the Titan submersible implosion. We mistake familiarity with safety.

Finally, we have the default bias. We view any change as a potential cost or risk, so we stick to the default option. If a software setting is pre-selected, the vast majority of users will never change it. This is why the default settings in privacy policies or software installers are so powerful; they effectively dictate user behavior because our brains are trying to conserve the energy required to make a change.

Problem 4: What Should We Remember?

We do not have infinite storage space. We can’t remember every pixel of our lives, so our brain compresses information. It saves the gist, the generalizations, and the high-level concepts, discarding the specifics. This compression is lossy and biased.

We tend to remember the first thing we hear in a series (the primacy effect) and the negative things that happen to us (the negativity bias). Evolutionarily, remembering that a red berry made you vomit is more important than remembering a beautiful sunset. We also succumb to the Google effect, or cognitive offloading. If we know we can look information up later, we don’t bother to store it in our long-term memory. We use the internet as an external hard drive. While this is efficient, it can compromise deep learning. If you offload the processing of a problem to a tool, you might never internalize the underlying logic.

Satisficing and Bounded Rationality

When you look at these four categories together, it becomes clear that the model of the “Rational Economic Man” who makes perfectly optimized decisions is a myth. Herbert Simon, a social scientist, introduced the term satisficing to describe what we actually do. It is a portmanteau of “satisfying” and “sacrificing.”

We don’t search for the optimal solution; we search for one that is “good enough” to meet our thresholds, and then we stop. When you buy a TV, you don’t analyze every model on the market. You check a few reviews, find one that fits your budget and size requirements, and buy it. You sacrifice the potential perfection of the optimal choice to save the cognitive energy of the search. Simon called this bounded rationality. Our rationality is limited by the information we have, the finite time at our disposal, and the cognitive capacity of our minds.

The Trap of the Linear Mind

To illustrate how easily our fast thinking system can be tricked, consider the lily pad riddle.

In a pond, there is a lily pad. The lily pad doubles in size every day. If it takes 30 days for the lily pad to cover the entire pond, how long would it take for it to cover half the pond?

If you are answering quickly, your fast brain (System 1) almost instinctively shouts “15 days!” It applies a linear heuristic to an exponential problem. Half the size, half the time. It feels intuitively correct. But it is wrong. If it doubles every day, then on day 29 it was half the size, and on day 30 it doubled to cover the whole thing. The answer is 29 days.

We are terrible at intuitively grasping exponential growth. We see this in finance, in viral pandemics, and in resource consumption. Under stress, the likelihood of falling for this trap increases. Stress forces the brain to rely even more heavily on the fast, automated components. This is why the advice to “count to 10” when angry is scientifically sound; it buys time for the slow, rational system to boot up and override the panicked signals of the fast system.

The Bias Blind Spot

The most ironic twist in all of this is that while we are excellent at spotting these biases in others, we are terrible at seeing them in ourselves. This is the bias blind spot. We believe our own judgments are objective and reasonable, while assuming others are influenced by their emotions or prejudices.

We cannot simply “turn off” these biases. They are hardwired into our biology. However, we can manage them. The first step is acknowledging that your brain is a cognitive miser that will lie to you to save energy. By slowing down, reflecting on our first impulses, and actively looking for disconfirming evidence, we can mitigate the worst effects. But we must remain humble; the moment you think you have conquered your biases is likely the moment you are being controlled by the overconfidence bias.

In the next part, we will explore how these human cognitive flaws are translated into code, creating Algorithmic Bias in search engines, image recognition, and artificial intelligence.

Part 3: The Digital Reflection (Algorithmic & Data Bias)

We have spent a lot of time dissecting the human brain. We know it is a cognitive miser, we know it filters information to save energy, and we know it constructs a version of reality that is often factually incorrect but easy to process. Now, we need to look at what happens when we take those flawed human brains and ask them to write code.

The counterpart to cognitive bias in humans is Algorithmic Bias in computers. If we defined cognitive bias as “faulty tendencies in perceiving, remembering, thinking, and judging,” we can map that definition 1:1 onto software. We tend to think of algorithms as neutral mathematical arbiters of truth, but they are often just codified opinions. These errors usually don’t happen in isolation; they are a stack. You have inappropriate data structures forming the foundation for partial decisions, Machine Learning (ML) systems fed with unbalanced data, and models that are inherently distorted.

For the purpose of this section, we are going to treat the algorithm as a “Black Box.” We can observe the Input and the Output, but the internal churning of the machine remains opaque.

The Search Engine as a Reality Constructor

Let’s look at Google Search. We often assume Google just shows us “what is on the internet,” acting as a passive mirror. But it is not a passive mirror; it is a curator. And that curation has a history of severe bias.

The “Professional” Haircut A famous example of algorithmic bias surfaced a few years ago regarding Google Image Search. If you searched for “professional hairstyles for work,” the algorithm returned a grid of images dominated by white women with straightened hair or neat updos. However, if you searched for “unprofessional hairstyles for work,” the results shifted dramatically to show Black women with natural hair, braids, or afros. If someone were to present these two sets of images to you manually, you would immediately call them out for being racist. But because it came from a “neutral” machine, it passed as a reflection of reality.

The “Three Boys” Experiment Another heavily discussed instance is the search for “three boys.” Historically, if you typed this into an image search, the results were almost exclusively white children playing, smiling, or posing. To see children of color, you had to explicitly racialize the search terms (e.g., “three black boys”). But when you did that, the tone of the results changed. Instead of stock photos of happy kids, the results often included mugshots or images from news stories about crime.

While Google has manually patched many of these specific queries (often “under the rug” after public outcry), the underlying issue remains. It raises a massive philosophical question for engineers: Do we want search engines to reflect the internet as it is, or as it should be?

If the internet is full of racism, sexism, and bias, a “perfect” search engine will reflect that racism back at us. But search engines don’t just reflect reality; they construct it. Studies show that we consider search results to be “realistic” if they match our expectations (Confirmation Bias). If a search engine shows us what we expect to see, we trust it. If it shows us something that challenges our worldview, we lose trust. This creates a feedback loop: the algorithm feeds us our own biases to gain our trust, which reinforces our biases, which trains the algorithm to feed us more of the same.

The Era of Hallucination

The problem is getting worse with the rise of Generative AI and Large Language Models (LLMs). We are seeing a flood of AI-generated content on the internet, and estimates suggest that between 5% and 25% of it is simply factually wrong.

We call these errors “hallucinations,” but that term is misleading. It implies a malfunction. In reality, hallucinations are a feature, not a bug.

As Arvind Narayanan and Sayash Kapoor point out in their book AI Snake Oil, ChatGPT and similar models are not truth machines; they are plausibility machines. They predict the next likely word in a sentence. It just so happens that true statements are often more statistically plausible than false ones, so they get things right a lot of the time. But there is no internal “truth check.” As AI researcher Paola Lopez puts it: “There is no inner-technical, no functional, and no operational difference between hallucinations and non-hallucinations.”

To the algorithm, a lie is just a sequence of tokens that has a high probability of appearing together. This leads to dangerous territory, such as the generation of “Russian Disinformation” sites where AI generates fake news stories that look real, sound real, but describe events that never happened. The AI doesn’t know it’s lying. It’s just completing the pattern.

The Hidden Sexism in Vector Space

One of the most fascinating places to see bias is in the mathematics of language models, specifically in Vector Space Mathematics.

Computers don’t understand words; they understand numbers. To teach a computer language, we convert words into vectors (lists of numbers) in a multi-dimensional space. Words that are used in similar contexts end up closer together in this mathematical space. This allows us to do “math” with meaning.

The classic example of this is: $$King - Man + Woman = Queen$$

If you take the vector for “King,” subtract the vector for “Man,” and add the vector for “Woman,” the resulting vector is mathematically closest to the vector for “Queen.” It captures the semantic relationship of royalty and gender.

However, when researchers looked closer, they found this math also captured society’s hidden sexism. $$Doctor - Man + Woman = Nurse$$

The model had learned, from millions of texts, that “Man” is to “Doctor” as “Woman” is to “Nurse.” It didn’t learn this because of biology; it learned it because the training data (our books, our articles, our internet) contained that bias.

The Turkish Pronoun Problem This manifested in Google Translate. Turkish is a gender-neutral language. The pronoun “o” can mean he, she, or it. If you typed “o bir doktor” (o is a doctor) into Google Translate, it would translate it to “He is a doctor.” If you typed “o bir hemşire” (o is a nurse), it would translate it to “She is a nurse.”

The algorithm was assigning gender based on statistical probabilities derived from biased training data. Google has since patched this specific UI to show both “He is a doctor” and “She is a doctor” for gender-neutral inputs, but the underlying model still contains the statistical weight of the bias.

The Nurse Riddle This bias makes LLMs fail at basic logic puzzles. Consider this riddle: A father and son are in a car crash. The father dies. The son is rushed to surgery. The surgeon looks at the boy and says, “I cannot operate on him; he is my son.” Who is the surgeon?

Humans often stumble on this, but we expect computers to be logical. However, because LLMs have a deep statistical link between “Surgeon” and “Man,” they often fail to identify that the surgeon is the mother. Or, in some cases, they invent complex scenarios (the boy has two gay fathers) rather than accepting a female surgeon, because the statistical weight of “Female Surgeon” is lower in the vector space.

Data Bias: The Root of the Poison

Where does all this bias come from? It comes from the data. If the data is not objective, the algorithm cannot be objective.

We often rely on standardized datasets to train and benchmark our systems. One famous example is the Yale Face Database B+. It is used to train systems to recognize facial expressions under different lighting conditions. It contains 16,128 images, which sounds like a robust dataset.

However, if you look at the source, those 16,128 images are just different lighting angles of 10 distinct subjects. Of those 10 subjects, 9 are men. Only 1 is a woman. Most are white. They are all roughly the same age.

If you train a facial recognition system on this database, it will become an expert at recognizing middle-aged white men in bad lighting. It will fail miserably at recognizing women, people of color, young people, or people with facial hair.

The “White Guy” Default This is why we see constant headlines about facial recognition failing for non-white demographics. The systems are optimized for the data they were trained on. This is called Data Bias. We are teaching machines to see the world through a keyhole, and then we are surprised when they can’t see the whole room.

Many datasets used in scientific and commercial environments are in no way representative, yet they are used as the “Ground Truth” for systems that make life-and-death decisions. This isn’t just about bad software; it’s about automating inequality. If a dataset doesn’t include you, the system doesn’t serve you. In fact, it might actively endanger you.

In the next part, we will crack open the “Black Box” of decision-making algorithms and see what happens when we let biased code decide who goes to jail, who gets a loan, and why “AI” is often just a marketing term for Snake Oil.

Part 4: The Black Box (Manipulation, Decisions, & Snake Oil)

We have looked at how human bias infects data and how that data infects algorithms. But there is a darker layer to this stack. What happens when these systems are not just biased by accident, but manipulated by design? And worse, what happens when we hand over life-altering decisions — who goes to jail, who gets a loan, who gets a job — to “Black Box” systems that we are legally forbidden from auditing?

The Architecture of Manipulation

We treat search engines and AI like oracles, but they are easily gamed. The entire industry of SEO (Search Engine Optimization) is essentially a multi-billion dollar effort to manipulate Google’s ranking algorithm. But beyond selling sneakers, this manipulation shapes our political and historical reality.

The “Republic of Austria” Case Study A striking example of this occurred with the search term “Republik Österreich” (Republic of Austria). For a long time, if you searched this on Google, one of the top results was a link to “Metapedia.” This isn’t Wikipedia; it’s a site that, in the tradition of right-wing revisionism, effectively denies the legitimacy of the modern Austrian state.

I tracked this personally:

• November 2019: Metapedia was the 3rd result. A fictional, revisionist text was presented as a primary source on the country.
• November 2020: I tested it via a private window and VPN (simulating a US location). It was still there.
• 2021: It finally moved to the first entry on Page 5.
• November 2022: It dropped to Page 11.

This timeline reveals two things. First, the “truth” on the internet is malleable and subject to gaming by motivated interest groups. Second, Google can fix it, but usually only after manual intervention or algorithm updates that take years to propagate. We are relying on a single technology — “Googling” has become a verb — that cannot reliably protect itself from being hijacked by bad actors.

Adversarial Attacks & Russian Propaganda It’s not just search rankings. AI systems are now being poisoned. We have seen instances where well-funded disinformation networks (e.g., Russian propaganda) actively infect the training data of Western AI tools. Since LLMs (Large Language Models) ingest the internet to learn, if you flood the internet with specific narratives, the AI learns those narratives as fact.

This leads to a “Cat and Mouse” game. Microsoft’s Tay chatbot was taught to be a racist misogynist by Twitter users in less than 24 hours. Meta’s BlenderBot 3 lasted three days before it started spouting antisemitism. The creators patch these holes, but the vulnerability is systemic.

Computational Decisions: The COMPAS Scandal

The stakes get infinitely higher when we move from search results to Computational Decisions. We are increasingly offloading judicial and financial judgments to software. We call it “AI,” but often it’s just a proprietary algorithm hiding behind a trade secret.

The ProPublica Investigation The most damning case study in this field is COMPAS (Correctional Offender Management Profiling for Alternative Sanctions). This is a software used by judges and parole officers across the US to assess the “risk” of a defendant. It spits out a score from 1 to 10 indicating how likely a person is to re-offend (recidivism).

In 2016, ProPublica analyzed the risk scores of thousands of defendants and compared them to what actually happened two years later. They found the system was deeply biased against Black defendants.

• False Positives: Black defendants who did not re-offend were nearly twice as likely to be misclassified as “High Risk” compared to their white counterparts.
• False Negatives: White defendants who did re-offend were much more likely to be misclassified as “Low Risk.”

Take the case of Bernard Parker and Dylan Fugett. Parker (Black) had a minor record but was rated “High Risk.” He did not re-offend. Fugett (White) had a more serious history but was rated “Low Risk.” He did re-offend.

The “Black Box” Defense Here is the kicker: We don’t know why COMPAS made these decisions. The software is owned by a private company, Northpointe (now Equivant). The source code is proprietary. It is Closed Source. When defendants challenge their risk score, they are told, “It’s a trade secret.” We have a judicial system where you have the right to face your accuser, unless your accuser is an algorithm protected by copyright law. This opacity makes it impossible to audit the code for bugs or specific weighting errors.

The Mechanical Turk Experiment In 2018, a study published in Science Advances humiliated this high-tech system. Researchers asked: Is COMPAS actually smarter than a random human? They took the data and gave it to random crowd-workers on Amazon Mechanical Turk. These weren’t criminologists; they were people on the internet paid pennies to do tasks. They gave the humans only two pieces of data: Age and Number of Prior Convictions.

• COMPAS Accuracy (137 features): ~65%
• Random Humans (2 features): 67% ± 2%

A proprietary, expensive, “AI-driven” system using 137 distinct data points was no better at predicting the future than a random person looking at two basic facts. And the random humans were likely biased too!

Snake Oil AI

This brings us to the concept of Snake Oil AI, a term coined by Princeton computer scientist Arvind Narayanan.

He argues that “Artificial Intelligence” has become a useless umbrella term, similar to if we called bicycles, rockets, and skateboards all just “vehicles.” If you grouped them all together, you’d have furious debates about whether “vehicles” are safe (rockets vs. bikes) or environmentally friendly.

Narayanan classifies AI into three buckets:

1. Genuine AI: Perception tasks like image recognition or medical imaging. It works reasonably well.
2. Imperfect but Improving: Automated content moderation, spam filters.
3. Snake Oil: Predicting social outcomes.

Predicting the Future is Impossible Predicting job success, recidivism, or “terrorist risk” is fundamentally different from recognizing a cat in a photo. Social outcomes are Wicked Problems (a term from Rittel & Webber, 1973). They are complex, non-linear, and depend on millions of variables. When companies sell software that claims to predict “who will be a good employee” based on a 30-second video interview, they are selling Snake Oil. They are selling a mathematical veneer over uncertainty.

As Joe Weizenbaum, the creator of the first chatbot ELIZA, said: “Computers can make judicial decisions, computers can make psychiatric judgments… The point is that they ought not be given such tasks. They may even be able to arrive at correct decisions in some cases — but always and necessarily on bases no human being should be willing to accept.”

The Problem of Explainability (XAI)

Even if we open-sourced every algorithm tomorrow, we would still have a problem. Modern Machine Learning (Deep Learning) is not a list of if-then rules. It is a neural network with millions or billions of parameters (weights).

If you look at the “code” of a neural network, you don’t see logic; you see matrices of floating-point numbers. You cannot look at Weight #3,405,201 and say, “Ah, this is the weight that makes it racist.”

This has birthed a new field called Explainable AI (XAI). The goal is to build systems that can tell you why they made a decision. But right now, we are in a dangerous transition period. We are deploying systems that are:

1. Proprietary: We aren’t allowed to see how they work.
2. Opaque: Even if we could see them, we wouldn’t understand them.
3. Unaccountable: When they fail, the company blames the “black box.”

Conclusion: The “Do Not” List

We must be skeptical of automated summaries and decisions. A chilling example of this occurred recently with Google’s AI Search Generative Experience (SGE). When asked “What to do if someone has a seizure,” the AI provided a list. The list included: “Hold the person down” and “Put something in their mouth.”

These are the exact things you are NOT supposed to do. The AI had scraped a “What NOT to do” list from a medical website and presented it as instructions, missing the negation context.

We are building systems that act with 100% confidence but zero understanding. When we let them make decisions about human rights, safety, and history, we are abdicating our responsibility to a coin toss that we’ve dressed up in a suit of mathematics.

In the final part, we will discuss the only defense we have left: Epistemology. We will cover logical fallacies, Street Epistemology, and how to maintain a grip on truth in a probabilistic world.

Part 5: The Epistemological Defense

We have spent the last four parts dismantling the reliability of your brain, the code you write, and the society you live in. We established that your mind is a cognitive miser that filters reality to save energy. We saw how those filters get hardcoded into algorithms that accidentally (or intentionally) distort the truth. And we looked at how “black box” systems can manipulate outcomes without accountability.

So, where does that leave us? If you can’t trust your brain and you can’t trust the machine, how do you navigate the world? The answer lies in building a defensive layer around your thinking process. We call this Probabilistic Epistemology.

The Comfort of False Certainty

The fundamental problem we face is a deep, biological craving for security. We want to know, with 100% certainty, that X causes Y. We want to hear that “Smartphones cause depression in teenagers.” It is a clean, simple narrative. It gives us a villain (the phone) and a victim (the teen). But reality is rarely that clean. Maybe the depression is caused by economic anxiety, climate grief, or a lack of third places for socialization, and the phone is just the mechanism where that grief is expressed.

Accepting that second option requires us to live with uncertainty. It requires us to accept a complex correlation rather than a simple causation. Most people hate this. They will choose a comfortable lie over a complex, probabilistic truth every time.

This is where the “Probabilistic Worldview” comes in. Instead of asking “Is this true?”, you should ask “How likely is this to be true?” You treat knowledge not as a binary switch (True/False), but as a confidence slider (0% to 100%).

A good argument is simply a process that moves that slider. It provides premises that make the conclusion more likely to be true. You will never reach 100% certainty — that doesn’t exist outside of pure mathematics — but you can reach a level of confidence high enough to act upon.

The Doubt Factory and The “One Study” Fallacy

One of the biggest enemies of this probabilistic approach is the modern media cycle, or what Paolo Bacigalupi calls “The Doubt Factory.”

We have a cognitive bias (Confirmation Bias) that makes us latch onto any piece of evidence that supports our existing view. The media ecosystem exploits this by pumping out headlines based on single, often flawed, studies. You will see a headline: “New Study Proves Chocolate Cures Cancer.”

In the scientific community, a single study proves almost nothing. It is a data point. It might be an outlier; it might be p-hacked; it might be poorly designed. Real knowledge comes from consensus — the aggregation of many studies over time pointing in the same direction.

However, the “Doubt Factory” operates by funding or highlighting studies that cast doubt on the consensus. This was the strategy of the tobacco industry (casting doubt on the lung cancer link) and the fossil fuel industry (casting doubt on climate change). They don’t need to prove they are right; they just need to introduce enough noise to keep your probability slider stuck in the middle, preventing you from taking action.

To defend against this, you need a mental firewall. When you see a claim, run a quick checklist:

1. Is this a single study or a meta-analysis? (Meta-analyses are worth 100x more).
2. Who funded it? (Follow the money).
3. Does it confirm what I desperately want to believe? (If yes, be double skeptical).

Debugging Arguments: Logical Fallacies

Just as we debug code for syntax errors, we must debug arguments for logical errors. These are known as Logical Fallacies. There are dozens of them, and learning to spot them is like learning to read a stack trace — it tells you exactly where the logic crashed.

For example, the Strawman Fallacy is when someone attacks a distorted, weaker version of your argument rather than the argument itself. The Ad Hominem is attacking the person rather than the point. The Slippery Slope assumes that step A necessarily leads to extreme step Z.

You can find excellent visualizations of these, such as the “Fallacy Poster,” which maps them out. The value in knowing the names isn’t to shout “Ha! Ad Hominem!” during a debate to win points. The value is internal. When you hear an argument that feels wrong but you can’t put your finger on why, running it against a list of fallacies often reveals the bug. It prevents you from being manipulated by rhetoric that sounds good but computes to zero.

Street Epistemology: How to Change a Mind

The hardest part of critical thinking isn’t debugging your own thoughts; it’s engaging with others who have fallen down a rabbit hole of conspiracy theories or extreme bias.

We mentioned earlier that facts don’t change minds. If someone believes a conspiracy theory, throwing a peer-reviewed paper at them usually makes them dig in deeper. This is the “Backfire Effect.” Their belief is part of their identity, and your fact is an attack on that identity.

There is a technique called Street Epistemology that offers a different path. It is a conversational style that focuses not on what the person believes, but how they came to that belief.

Instead of saying, “The earth is round, look at these photos,” you ask, “What method did you use to determine the earth is flat?” You then explore that method with them. “If that method turned out to be unreliable, would you lower your confidence in the belief?”

The goal is to guide the person to realize, on their own, that their methodology for determining truth is flawed. You are trying to get them to adjust their own probability slider. It is non-confrontational and Socratic. There are communities (like the “VTbetroffene” subreddit or Street Epistemology groups) dedicated to teaching this, and it is often the only way to reach people who have inoculated themselves against standard evidence.

Conclusion: The Engineer’s Responsibility

We have covered a lot of ground, from the neurons firing in your amygdala to the SQL queries in a recidivism algorithm.

If there is one takeaway, it is this: You are not a neutral observer. You are a machine built to jump to conclusions, protect your ego, and save energy. The systems you build — the software, the AI, the data pipelines — will inherit those flaws unless you actively fight against them.

As computer scientists and engineers, we have a unique power. We are the ones building the digital infrastructure of reality. We decide how the search algorithm ranks truth. We decide which data features matter for a loan application. We decide whether a chatbot optimizes for engagement or accuracy.

This is why “Human-Centered Computing” and ethics are now core parts of the computer science curriculum. It is not “fluff.” It is the safety engineering of the 21st century.

Critical thinking is not a certificate you hang on the wall. It is a runtime process. It is the constant, exhausting background job of asking: “Why do I believe this? What if I’m wrong? And who is being left out of this dataset?”

It is hard work. It feels unnatural. But as we move into an age of automated decisions and AI-generated reality, it is the only thing that keeps us — and our technology — sane.

This concludes the series on Critical Thinking. Thank you for reading.