If I had encountered the Lindy Effect earlier, I would have mapped out my IT career and professional growth differently. I wouldn’t have picked a different path, but I would have navigated it with much more intent.

Who or What Exactly is This Lindy?

Like any good story, this one starts in a compelling place - and who doesn’t love a great deli? Lindy comes from the name of a New York City hotspot (Lindy’s Cheesecake Deli), where comedians and movie producers used to hang out. Over coffee and cheesecake, they noticed a pattern: the bigger a performer’s initial hype, the shorter their career tended to be. It was as if they burned through their fuel and peak potential almost instantly. Based on this observation, writer and biographer Albert Goldman formulated the Lindy Effect.

Benoît Mandelbrot, doing what mathematicians do, transformed this rule of thumb into a rigorous mathematical model based on power-law distributions. As a reminder, this is the kind of curve showing that as value increases, fewer subjects meet it - much like in society, where many people work hard, but only a few amass true wealth. Since few people read math textbooks and tables before bed, Nassim Taleb, the economist-philosopher, popularized and accessibly explained Mandelbrot’s proven thesis in his book Antifragile.

For Goldman, the Lindy Effect was a tool to show that popularity is a finite resource that can run dry. The biographies he penned were meant to demonstrate this across the biggest musical icons of the era. Taleb, however, evolved this rule by flipping its logic. He argued that the longer something has already survived, the longer it is likely to keep surviving. For instance, a book that has been read for 50 years has a much higher chance of being read for another 50 years than a brand-new bestseller. These theories don’t contradict each other; they just approach similar conclusions from different angles. Goldman focused on the human being who burns out and gets bored, while Taleb focused on things or ideas that don’t suffer from biological aging but simply withstand the test of time.

An Counterintuitive Rule

At first glance, you might think that if something has been around long enough, its time must eventually come. Yet, looking at basic tools like a hammer, a fork, or a shovel, it is hard to imagine anyone inventing a disruptive replacement. Their functionality is explicit and perfectly sufficient, leaving no room for optimization - unless you paint them red, because as we all know, red tools dig faster and hammer harder.

For another example, look at physical knobs and buttons in cars. Right after 2020, when I was shopping for a new car, I was shocked to find that several popular brands had stripped them away in favor of controlling the AC and volume through software. Modernity - touchscreens everywhere you look. Except there is a fundamental flaw with this design: you can’t use a screen without looking at it, because you can’t feel the buttons before pressing them. So I asked the salesman: does this mean every time I want to adjust something, I have to take my eyes off the road and look at a screen? To my disappointment, he confirmed it (and he didn’t look particularly sold on the idea either). By 2025, several carmakers pivoted back to antifragile, physical controls we are all so accustomed to. This approach proved to be Lindy Proof - battle-tested, intuitive, and safer, because tactile buttons are easier to muscle-memory on bumpy roads, keeping your eyes locked on traffic. What’s more, this setup has been in cars long enough that, according to the rule, it will likely survive another 100 years!

The Lindy Effect operates on the assumption of a breakthrough that fundamentally shifts how an action is performed or makes it possible in the first place. If the internal combustion engine hadn’t been invented, we’d be choosing saddle leather instead of upholstery today, checking our steed’s pedigree to ensure it is nimble enough and won’t “rust” out too quickly. If mobile networks hadn’t evolved, we would still be crossing our fingers dialing numbers, hoping the recipient was currently sitting next to their landline. Walking down the street with a stack of cash for a major purchase used to be risky and clunky. In the era of globalization, paying with physical fiat currency for online purchases shipped from across the globe would be painfully inconvenient. A digital ledger for transactions and currency had to become standard sooner or later for the system to run smoothly and securely.

Often, it is the birth of a disruptive technology that topples antifragile solutions by rewriting the very foundation of how things work. It’s an innovation that solves the exact same problem, but with better convenience, economics, or speed. After all, who in 1880 would have guessed that horse-drawn transport, practiced for at least 4,000 years, wouldn’t survive the next millennium? Similarly, I doubt most owners of the Encyclopædia Britannica decades ago could have envisioned the instantaneous, universal access to knowledge the Internet provides today. All of these, much like the sextant - now mostly relegated to crosswords and museums - become less convenient, hobbyist, or backup methods. Yes, some solutions are strictly more Lindy - less failure-prone, battle-tested, and independent of external variables like electricity or cellular coverage - but their market share crumbled to modernity or a shift in the underlying paradigm.

Lindy Proof in IT

It is tough to compare IT itself to concepts that have survived for dozens of generations. Let’s arbitrarily set 1945 as the baseline for IT-Lindy, marking the creation of ENIAC, the first widely recognized, fully electronic general-purpose computer. That is a brief window, not even a single century. Luckily, as Mandelbrot demonstrated, the Lindy Effect scales via power laws, meaning you can expect the exact same insights at any scale of reference, even much shorter ones.

Skipping past “ancient” computer history, let’s jump to the 1970s. That was when Dennis Ritchie set the trajectory for developers for decades to come by creating one of the most IT-Lindy-Proof entities in existence: the C programming language. Hand in hand with SQL (in all its flavors and dialects), it survived the PC boom, GUI adoption, the mobile revolution, Cloud Computing, and steadily marched into the next era shaped by AI. After more than 50 years, C remains the bedrock of the modern digital world - powering the Linux kernel, the very core operating system running nearly every server on the web. Everyone has interacted with it, unless they commute by horse carriage, avoid smartphones, and live 100% off-grid.

Every developer knows at least one language from the “C dynasty” or its object-oriented successor, C++, because they form the foundation of most modern software. For some languages, C serves as the runtime environment or interpreter; for others, it was the scaffolding during inception; and some merely married into the family, adoption C syntax as their blueprint. For decades, no other tool offered such a balance between raw performance and cross-architecture portability. The very first thing implemented on most new chips is C compatibility. It is the literal lingua franca for bare-metal communication. While Rust is the current contender for the throne, C enjoys a 50-year market head start and will likely outlive it. Even the rise of Quantum Processing Units (QPUs) doesn’t seem to threaten its dominance; despite being disruptive, they don’t alter the core logical paradigms required to run a system. QPUs are projected to operate alongside classic CPUs as compute accelerators - so it is easy to guess what will likely handle the communication between these units.

Thanks to its ubiquitous availability, speed, and versatility, C embodies the exact durability traits that the IT world craves. It isn’t the flashiest or the most talked-about language. It just works, delivers on its promises, and is utterly boring in doing so. It has nothing to prove and nowhere to rush, because time acts in its favor - cementing it further with each passing year.

What is Lindy Proof in a Developer’s Daily Work?

This might shatter a common myth, but a developer’s job isn’t just an infinite loop of eat, sleep, code, repeat. Before a single line of logic is written, requirements gathering and scoping swallow up to 25% of the clock. Code reviews, testing, debugging, bug fixing, and documentation take another 30%. Add roughly 10% for demos, syncs, and sprint planning. When the dust settles, a developer usually spends no more than 40% of their time actually typing code. These numbers don’t instantly add up to a clean 100% because they represent statistical ceilings for these activities, and the ratios shift depending on project lifecycle, team maturity, application age, and other variables. Still, looking at these metrics paints a clear picture of where the hours actually go.

Within these time blocks, work happens using specific tools and frameworks - some are fleeting trends, while others stand the test of time, entering the canonical toolkit across companies and stacks. It is like comparing a cheesy summer radio hit to an immortal holiday classic that everyone hums, regardless of their daily playlist. While the tech stack and tooling evolve, the core job remains the same, and skipping steps comes at a steep price. Skip scoping, and you fly blind; cut corners on testing, and you spend your weeks firefighting bugs; neglect documentation, and you are left with “tribal knowledge” that evaporates over time, leading to missed edge cases and botched project estimates during planning.

Hardware and software are incredibly volatile. Between 2000 and 2026, we saw 9 major versions of Windows, 11 of Ubuntu, and 22 of macOS. The dominant Integrated Development Environments (IDEs) swap places every few years. Every few months - sometimes weeks - new libraries pop up that developers use as building blocks for larger systems. Fail to stay current, and you quickly become obsolete. Yet, the underlying CPU doesn’t care whether it is executing code written in Notepad on Windows or inside a $100-a-year IDE on a Space Gray M4 Mac.

Ultimately, the most Lindy Proof asset in a developer’s toolkit isn’t hard tool proficiency, but adaptability, risk mitigation, and estimation skills. Core design patterns, system architecture, software testing methodologies, and writing clean, readable code for humans are what endure. You could skim job postings and cite “working in a fast-paced environment” or “time management,” but these aren’t unique to IT (nor does anyone take them seriously).

An Example of a Fleeting Trend in Tech Management

My personal favorite here is Scrum. On the IT-Lindy scale, it has traveled a long road: from its initial conceptual article in the Harvard Business Review (1986), to its first formal framework draft (1995), the signing of the Agile Manifesto (2001), and finally the release of the Scrum Guide and its massive enterprise adoption around 2010. The sheer volume of hype and marketing surrounding agile methodologies back then was suffocating. It was repackaged into endless, slightly tweaked framework variants and marketed as a silver bullet for team and project management. According to some, you just had to unbox it to magically fix your delivery. In practice, it was neither easy nor agile.

Scrum surged in popularity at breakneck speed. It solved plenty of bottlenecks with one hand while introducing more questions than answers with the other. Since agile methodologies inherently rely on self-interpretation, newly minted evangelists smoothly bent the Scrum Guide and Agile Manifesto to fit their personal narratives. This set up a clash between two contenders: a barely vetted newcomer versus a towering, legacy corporate hierarchy. One was trying to be IT-Lindy-Proof, while the other was simply Lindy-Proof on a timeline dating back centuries.

Engineering teams eventually warmed up to agile principles because Scrum’s emphasis on self-organization, shared ownership, and iterative delivery actually worked. In more orthodox setups, teams didn’t even have a traditional manager assigning tasks; instead, the engineers collectively decided who would tackle what to ship high-quality work on time. Everyone had a voice, while Scrum Masters facilitated meetings and protected the process. The wheels kept turning. You could argue it successfully band-aided the pain points of rigid legacy management.

Top Management, however, remained mostly immune to the “agile” charm, continuing to answer to shareholders with 4-year strategic plans and quarterly earnings calls. Many execs reviewing their performance wouldn’t list resistance to change as a flaw - in their minds, the old way worked, period. Some of the “guild masters” - the veteran Tech Leads and Architects - were also lukewarm on the shift. From their perspective, the junior developer should listen, learn, and avoid making waves. Every skeptic already had a battle-tested workflow honed by years of delivery. Because not everyone was ready to pivot, the common ground fractured, leaving middle management caught right in the friction zone.

Every company’s implementation of Scrum evolved differently, giving rise to the running joke: ScrumBut (“We do Scrum, but…”). Some claimed they were cherry-picking the best of both worlds, while others saw it as a blatant attempt to have your cake and eat it too - but as long as it was labeled “agile” and the annual plan was hit, nobody complained.

What is Lindy Proof here? Now that the initial decade-long Scrum hype has settled, it has left behind a few battle-tested methodologies. When properly implemented, they serve as highly valuable tools for engineering teams. Examples include regular retrospectives aimed at continuous process improvement, methods for flagging uncertainty before grooming, and effective cross-team synchronization. The most impactful, habit-shifting aspect was breaking massive initiatives into smaller, fixed iterations. This enables systematic course correction before the final product hits production. It’s highly efficient because, in a fast-moving market, you end up shipping what is needed right now, rather than what was requested months ago at kickoff.

Years later, larger organizations saw a return to hierarchical structures and Team Leads. Not for micro-management, but to streamline reporting lines, unblock technical hurdles, and directly support career growth. The “Servant Leader” philosophy is now partially baked into the tech lead role, rather than being sequestered into the increasingly rare Scrum Master position. Paradoxically, ruthlessly keeping only what works - all the “buts” in ScrumBut - better aligned with the very first value of the Agile Manifesto: “Individuals and interactions over processes and tools.” Guided by the Lindy Effect, we can expect younger, hyped frameworks to fade away, while the 25-year-old Agile Manifesto will likely endure for another quarter-century.

Is AI the Internal Combustion Engine of the Horse-and-Buggy Era?

AI isn’t the existential threat it’s made out to be - it’s a technological leap like any other, just more ambitious and highly publicized because its impact stretches far beyond the engineering bubble. No dedicated software engineer should fear it any more than a new framework or automation tools that boost throughput. The current shifts are faster, highly impactful, and have the potential to severely disrupt daily workflows. However, an engineer with 10–15 years of experience has survived enough “revolutions” that panicking now would just mean losing hair faster than a toddler playing with clippers.

The underlying anxiety is largely a hangover from a multi-year tech hiring bubble. That bubble led to an influx of people who barely understood programming fundamentals, often working entirely by rote. Those skills might have been enough to land an IT job during the pandemic lockdowns - a short bootcamp and a few resumes were all it took. Today, junior talent faces rigorous screening. Tech leaders are auditing what progress engineers have made over recent years and whether their current skill level matches the industry’s evolution. This is a true litmus test for core engineering traits: first-principles thinking, cognitive flexibility, sheer persistence, and the grit to handle broken code and shifting requirements.

A massive part of engineering isn’t just solving immediate problems or tuning algorithms; it’s writing code that is highly maintainable and readable for the next person. The well-known S.O.L.I.D. acronym outlines five core principles for object-oriented, clean, and flexible architecture. Is that obsolete now? Do developers no longer need to care? Quite the opposite! Since AI tools allow us to generate statistically 55% more code in the same timeframe, order and readability matter more than ever. Generating unreadable code faster is just a recipe for disaster. Developers and the LLMs assisting them must understand how the system fits together if they hope to maintain and scale it. AI doesn’t alter the core objective of software engineering: translating business intent into a functional application.

Developers are transitioning from manually typing explicit commands to instructing non-deterministic language models acting as Coding Agents. They are shifting focus from “how to write efficient code” to “how to write an efficient prompt that generates the code.” Engineers still solve legacy problems every day, but now they also manage the compute costs and data volume consumed by AI. It is not a free utility, and maximizing its efficiency requires a specific, modern skill set. The volume of data exchanged with AI is measured in tokens - the fundamental billing unit used by LLM providers. Naturally, fewer tokens mean a lower compute bill. Yet, this doesn’t fundamentally alter a good developer’s habits; carrying bloated, poorly optimized code has always been bad practice. Someone always had to spend valuable time reading and refactoring it - today, that liability is just billed differently.

Since the start of the IT-Lindy timeline, developers have climbed to higher layers of abstraction multiple times. They started with register-by-register programming directly in RAM, moved to high-level compiled languages that streamlined development, and have now reached the point of building “algorithms that write algorithms.” The paradigm remains unchanged: someone has to cost-effectively translate human requirements into a working product. Tech visionaries might claim anyone can build an app today using AI. But back during the dawn of the dot-com boom, anyone could technically spin up a website and host it - yet very few actually did. Software engineers were vital then, and they will be vital now, if only to audit AI-generated code, architect better AI models, or design more cost-effective workflows around existing AI tooling.

What’s Next? Where to Invest in the New Era?

Regardless of the shifts shaking up IT, a first-principles grasp of programming paradigms guarantees industry antifragility for an engineer. The most IT-Lindy-Proof assets for years to come will remain core computer science fundamentals, logic, and algorithmic design. Mastery of at least one C-family language remains non-negotiable. Code generation tools will continue to mature, growing more ubiquitous and accessible. Because this space is young and hyped, certain tools will peak in popularity only to disappear - expect significant market consolidation. Given the volatility of individual tools, we must quickly standardize universal principles for working alongside them. Mastery of these shared mechanics will insulate tech professionals against the ongoing evolution of artificial intelligence.

In the near term, AI providers will likely hunt for highly specialized niche experts to anchor the exponential growth of LLMs with deep domain knowledge. Conversely, among companies implementing these technologies, generalist skill sets will become highly sought-after, enabling engineers to operate across every layer of the software delivery pipeline. As the demand for systems thinking and cross-disciplinary synthesis grows, the rigid boundaries that carved engineering departments into silos over the last decade will blur once again.

Within engineering organizations, I anticipate a return to pragmatism, built around professionals who offer deep fundamentals and experience. Aligning with classic, profitable and safe investment portfolio (60% stable assets and 40% high-upside, volatile ones), the smartest move is to double down on IT-Lindy-Proof skills while consistently but selectively implementing modern tooling. The tech trends will keep you competitive, but those antifragile competencies are the stairs you rely on to carry the couch to the third floor when the elevator breaks down.

---

Paweł Nejczew