Reinventing the Circle

We’re doing things a bit differently this week. Actually, who am I kidding? We are talking about our obsessive focus on technicalities again.

But consider this a gentle warning: we are skipping the polite corporate filter today. Things are about to get a bit sharper—and perhaps a bit more painful—than usual. If you’re easily offended by tech-industry heresy, now is your chance to close the tab.

Still here? Good.

The Unpatchable Wetware

There is a widespread, almost religious belief in the IT sector that technology is a magical entity. We genuinely act as if writing code somehow suspends the laws of human nature, physics, and basic economics. Got a cultural problem? Throw a new tool at it. Process bottleneck? Introduce a KPI. If that fails, we can always rely on the board to issue a PDF directive instructing everyone to “be more productive.” Problem solved.

Except it isn’t.

Tools are built for humans. And humans, much to the annoyance of engineers, come pre-installed with unpatchable software: cognitive biases, physical limits, and predictable behaviors. The reason I constantly write about cognitive economics and psychological paradoxes isn’t because I’ve lost interest in tech. It’s because these are the hard limits of our system.

As engineers, we are forced to operate within these human constraints. Yet, the longer I spend in this industry, watching dumpster fires of varying scales, the more I realize our entire education took a very strange detour.

We spend years mastering complex frameworks, abstract mathematics, protocols, and obscure programming languages. But we spend exactly zero seconds trying to understand the wetware that will actually use our creations. If anything, we channel massive reservoirs of our creativity—and that smug irony unique to otherwise highly intelligent people—into mocking those very limitations. Because, obviously: haha, stupid users.

Meanwhile, other high-stakes industries—medicine, aviation, structural engineering, urban planning—have already paid for these lessons in blood, sweat, and massive lawsuits. They are a goldmine of “what not to do” case studies. Yet, the moment a new framework or technology drops, we collectively decide to throw decades of hard-won human knowledge out the window and “do it better.”

The Multi-Billion-Dollar Circle

It’s cute when a junior developer decides to write their own CMS from scratch. We’ve all been there. It is significantly less cute when a multi-billion-dollar enterprise decides that the circle is a fundamentally flawed design and tasks fifty engineers with inventing a better shape.

And no, I’m not just talking about the current AI frenzy—though that is indeed a massive, buzzing flytrap for this kind of hubris. This pathology runs much deeper.

I recently stumbled upon a startup that had an entire, dedicated engineering team responsible for maintaining an in-house microservice to generate unique UUIDs. Three highly paid human beings spent their working days solving a problem that was solved, standardized, and dusted three decades ago. I’m sure it looked absolutely spectacular on a PowerPoint slide during a VC funding round. In reality? Not so much.

Our industry’s response to everyday failure is almost poetic in its stupidity:

• System throwing too many errors? Let’s add more alerts! Never mind that the medical industry spent decades proving that “alert fatigue” literally kills patients because humans naturally tune out constant noise.

• A deployment taking too long? Let’s automate it and add a checklist telling developers to “make sure to double-check everything.” Who cares about cognitive load and human error?

• Our service is running slow? Throw an autoscaler at it. Don’t worry about “induced demand”_—an urban planning concept known since the mid-20th century which proves that adding lanes to a highway only creates more traffic.

Welcome to the Post-Mortem Theatre

And on those rare occasions when a solid concept actually manages to scale this interdisciplinary Great Wall and slip into our territory, we immediately set to work turning it into a complete parody. Take the post-mortem. It’s a process that owes its name to 18th-century medicine and was perfected to near-flawlessness in aviation and aerospace. Yet, when imported into IT, it quickly degenerates into a theatrical exercise of ticking checkboxes and feeding corporate metrics.

We obsess over TTD, MTTR, and SLAs, only to file away “lessons learned” that read like: “We didn’t write tests because tests are hard.” (An actual, real-world conclusion I have seen in production environments far more often than I care to admit). As for Root Cause Analysis? We don’t have time for actual, rigorous engineering inquiry because the RCA report must be submitted within 72 hours. After all, you can’t visualize the depth of an intellectual conclusion on a KPI dashboard, but a shiny compliance checkmark looks fantastic.

We believe we can code our way out of reality. But reality refuses to cooperate, and the frequency of spectacular failures keeps rising. I wonder why.

So, here is my heartfelt invitation for your next self-improvement session: skip the next RFC. Put down the tutorial. Ignore the hot new framework documentation. Instead, grab a book from literally any other industry. Read it, and then honestly ask yourself: How does this apply to my backyard?

I promise you, the overlap is bigger than your IDE can handle.

P.S. On a more constructive note: to see how a post-mortem should actually work, check out Chapter 0 of my Fuckup Almanac series: The Anatomy of a Post-Mortem. It’s available completely for free.