Building on Sand: Why Vol. 2 of the Fuckup Almanac is Built on Rot, Piles, and Pure Exhaustion

When I finally clicked “Send” on the manuscript for Volume 1 of the Fuckup Almanac, you’d think I would have taken whatever modest royalties I scraped together, bought a one-way ticket to a beach with zero cell service, and never looked at an incident report again.

But apparently, my thirst for digital disaster hasn’t been quenched. If anything, writing about tech catastrophes is like opening a bag of salty chips: you know it’s bad for your blood pressure, but you just can’t stop. Besides, even if I wanted to quit, I’m bound—I did promise a four-volume series, and I’m not about to let a little thing like my sanity get in the way of a good print run.

So, here we are. Volume 2: Stuff We Built on Top is coming, and it’s a completely different beast.

But before we talk about software, let me take you on a quick detour to the Netherlands.

Why the Netherlands? Well, for one, Volume 2 features a few absolutely massive, jaw-dropping disaster stories directly tied to this country. But more importantly, it perfectly illustrates the fundamental difference between Volume 1 and Volume 2.

The 11 Million Poles of Amsterdam

If you’ve ever walked through the narrow, leaning, postcard-perfect streets of Amsterdam, you were probably thinking about stroopwafels, broodje haring – that raw herring sandwich the Dutch are inexplicably proud of (which most tourists find deeply traumatizing), canals, or perhaps some of the city’s more… bohemian attractions.

What you almost certainly weren’t thinking about is what’s directly beneath your shoes.

And why would you? When we look at great architecture, we evaluate the facade, the history, the windows. We don’t think about the mud.

But here’s the reality: Amsterdam is built entirely on a swampy, unstable layer of peat and clay. If you tried to build a heavy brick house directly on that ground, it would sink faster than a junior developer’s self-esteem on their first day of on-call.

To prevent the entire city from sliding into the North Sea, historically, builders had to drive millions of wooden logs (and nowadays, massive concrete piles) 15 to 20 meters deep into the earth until they hit a stable, solid layer of sand.

How many logs are we talking about?

• The famous Royal Palace at Dam Square rests on exactly 13,659 wooden piles.
• The Central Station sits on nearly 9,000.
• Across the entire city, it’s estimated there are over 11 million piles keeping Amsterdam dry and upright.

Without this massive, hidden forest driven into the mud, the capital of the Netherlands would be an underwater archaeological site.

And yet, 99% of tourists don’t know this, and frankly, they don’t care. They just care that the coffee shops are open and the ground isn’t shaking.

This is exactly how the general public views IT. Nobody cares about the data centers, the fiber-optic cables running along the ocean floor, or the routing protocols keeping the internet together. Does the app open? Yes? Then why dig deeper?

This is exactly where Volume 2 comes in. We are finally leaving the basement to look at the superstructure: the Software.

Because this is the layer that everyone actually sees and interacts with, you could argue that Volume 2 might be a far more interesting read, and perhaps even a better entry point for most people. But since I am clearly a very weird individual (I mean, who actually researches the structural engineering of Amsterdam for fun?), I absolutely had to start with the foundations first for Volume 1 (pun fully intended).

The Silent Rot vs. The Big Boom

Climbing up the architectural ladder to write Volume 2 was supposed to be easier. Spoiler alert: it wasn’t. It introduced a fresh set of challenges that did unspeakable things to my nervous system.

First of all, companies are extremely good at hiding software failures.

When a physical data center catches fire or a pensioner slices a fiber-optic cable with a shovel (check Volume 1 if you don’t recall that gem), you can’t hide it. It’s a physical, undeniable reality. But when a software bug messes up a database, corporations will deploy every PR shield, legal loophole, and obfuscation tactic available to keep it quiet. I didn’t have a stream of neat, public post-mortems to translate into human English. I had to play digital detective—cross-referencing obscure forums, connecting random dots, and digging through archives.

To give you an idea of the scale of this investigation: the bibliography for Volume 2 is twice as long as the first book, packing in well over 1,000 source documents.

Secondly, we have to talk about how things collapse.

Coming from a family of builders who have worked on some genuinely massive construction projects, I’ve learned a thing or two about structural integrity. Buildings don’t usually collapse overnight. If a foundation fails, yes—walls crack, pillars buckle, and you get a sudden, spectacular “boom.”

In IT, that’s your infrastructure going down. Half the internet goes dark, everyone panics, and it’s on the front page of the news.

But if a builder fails to properly waterproof an exterior wall, the building doesn’t fall down tomorrow. Instead, water slowly seeps in, rots the drywall, and quietly eats away at the structure over a decade. Of course, if you point out the resulting cracks to the contractor, you’ll get a masterclass in defensive deflection. It’s the classic, deeply-ingrained logic of cowboy builders worldwide: “Well, chief, the universe is expanding, so of course the walls are cracking!”

This is exactly how software fails, just with fewer hard hats and worse posture.

When a software system is structurally compromised, the company doesn’t implode overnight. Instead, they patch it. They obscure the bugs with clever UI workarounds, and the marketing team assures everyone that these aren’t system-wide failures, but rather “unplanned retro-features.” It is a slow, quiet, invisible rot—a massive accumulation of technical debt that quietly erodes the system while everyone pretends everything is perfectly fine.

Cutting the Fat

The final challenge was simply coping with the sheer, unfathomable scale of human error.

Our capacity to write complex software is only rivaled by our infinite creativity in finding new ways to break it. When I sat down to map out the chapters, I realized I had a massive volume problem. I wanted to tell every story, but unless I wanted to ship the book with a free forklift to help readers carry it, I had to make some brutal editorial cuts.

I ended up completely deleting an entire section of the book (don’t worry, it will resurface in some form in Volume 4), and I drastically shifted the balance between case studies and technical explainers to keep things punchy.

And just to be absolutely clear: this aggressive pruning wasn’t due to a sudden lack of digital disasters. Trust me, our industry generates monumental, catastrophic screw-ups faster than any human can document them. It was purely a battle against physical volume limits and the constraints of the printing press.

Despite all this aggressive liposuction, Volume 2 is still roughly 15% longer than Volume 1 in terms of word count. (Though thanks to some formatting wizardry, we managed to compress the physical page count increase down to just about 10%). You’re welcome.

Because software is so abstract, explaining why these disasters happened also forced me to step away from the standard “here is what broke on Tuesday” case studies. In some chapters, I had to adopt a slightly more essayistic, analytical tone. I couldn’t avoid injecting a few deeply subjective (but heavily researched) opinions on where our industry is heading—especially when examining the precarious house of cards that is our software supply chain, open-source dependencies, and maintenance issues.

And don’t worry, AI and Machine Learning still take up a massive, deeply terrifying portion of the book. But simply pointing at an AI disaster and laughing wasn’t enough. To understand why these systems collapse in such spectacularly weird ways, I first had to explain how they are actually trained and built—because you can’t fully appreciate an automated dumpster fire without knowing what garbage fueled it in the first place.

Does it Actually Work?

Writing this book felt like trying to waterproof a basement while the tide was coming in. But now that the dust has settled and the first physical proofs are sitting on my desk, the big question remains: Is it actually any good?

Well, according to the early readers’ opinions and reviews from places like the Independent Book Review and Kirkus, the answer is a surprising, resounding yes.

In fact, I’ll stick my neck out and say it might actually be a better, tighter, and more entertaining read than the first volume.

Volume 2 officially drops on July 21st. If you want to read about the digital equivalent of wet rot, corporate cover-ups, and the precarious Jenga tower we call modern software, you can secure your copy right here: