Jonathan Blow - Preventing the Collapse of Civilization (English only)

Summary

Jonathan Blow argues that technological progress is not automatic. Skills, systems, and engineering knowledge can be lost—even by advanced societies—and today’s software industry may be experiencing a gradual decline masked by increasingly powerful hardware. He urges programmers to simplify the systems they build and depend on, both to improve their work now and to make technical knowledge more resilient over time.

Technology can regress

Blow uses several historical examples to challenge the assumption that technology always advances:

• The space program: The United States rapidly built up its space capabilities after the Soviet Union’s early achievements, culminating in the Apollo 11 Moon landing. But after the Space Shuttle era, American human spaceflight capability declined to the point where the country relied on Russian Soyuz spacecraft to reach orbit.
• Lost Roman and Byzantine technologies: The Roman-era Lycurgus Cup used sophisticated glassmaking techniques that were not understood again until much later. The Byzantine Empire’s powerful incendiary weapon, often described as a form of “Greek fire,” was also lost.
• The Antikythera mechanism: This ancient Greek geared device could track dates, lunar phases, planetary positions, and the timing of the Olympic Games. Blow argues that such a complex device implies a broader body of technical knowledge that has not survived.
• The Bronze Age collapse: A network of interconnected civilizations depended on trade to obtain materials such as copper and tin. Environmental stresses and conflict may have disrupted those networks, contributing to the collapse of multiple societies and the loss of languages and knowledge.

These examples illustrate his central point: knowledge must be actively preserved and passed on. Otherwise, it can disappear through societal disruption or a breakdown in the transfer of expertise between generations.

Why Blow thinks software is declining

Blow’s claim is not that nothing in software improves. He acknowledges advances such as machine learning, but argues that these are relatively small areas of progress compared with the complexity and fragility of much everyday software.

• Hardware improvements can disguise software stagnation. Programs may appear more capable because they run on dramatically faster hardware, rather than because software engineering itself has become more effective.
• Everyday reliability has fallen. Blow shares examples of bugs and failures in tools he uses, including programming software, email, game stores, games, websites, and a hotel’s heating controls. He says users have become accustomed to treating broken behavior as normal.
• Quality standards have weakened. He notes that terms such as “five nines”—a system being available 99.999% of the time—are used less often, suggesting that expectations of reliability have declined.
• Engineering knowledge may not be passed on. Blow cites an interview with Bob Colwell about chip manufacturers whose newer designers failed to account for electrical effects that experienced engineers understood. The lesson, in Blow’s view, is that expertise can be lost when experienced practitioners leave and their knowledge is not transmitted.
• The software industry’s incentives may not prioritize software quality. Blow argues that many companies called “tech companies” are focused primarily on finding and exploiting market opportunities, rather than advancing the underlying technology.

He also challenges the claim that programmers are more productive because they use higher-level languages and tools. As an illustration, he compares the limited year-to-year changes in major social media products with the very large engineering teams behind them. He contrasts this with Ken Thompson’s account of building an early operating system in a few weeks, suggesting that modern development involves a great deal of overhead.

Complexity and abstraction

Blow argues that software has accumulated layers of complexity that make both development and maintenance harder.

• Higher abstraction is not necessarily simplification. It can reduce the amount a programmer must think about directly while adding complexity underneath and weakening the programmer’s understanding of the machine.
• Convenience can come with lost capabilities. Programmers may become less familiar with assembly, memory layout, pointers, or what the CPU is actually doing.
• Operating systems and platforms can add barriers. Blow gives examples such as installers, platform-specific shader languages, code-signing requirements, and other steps that prevent programs from being moved, built, or run as simply as he believes they could be.
• Tools can turn straightforward tasks into large systems. He criticizes Microsoft’s vswhere utility for taking thousands of lines of code to locate development libraries, and the Language Server Protocol for turning editor features into communicating services that introduce distributed-system complexity.
• Complexity crowds out useful work. More complicated systems demand more knowledge from developers, fragment understanding across teams, and encourage people to rely on narrow workarounds or temporary fixes rather than deeper principles.

Blow distinguishes intrinsic complexity—the difficulty inherent in the problem being solved—from incidental complexity introduced by tools, platforms, and existing software systems. The goal, he says, should be to reduce the latter and get closer to the simplest system that can solve the problem.

Risks to the future

Blow warns that a complex technical system may be less resilient to shocks. If too few people understand how its components work, a disruption could make it difficult to repair or maintain. He mentions possible shocks such as climate-related problems, major cyberattacks that fragment internet access, or restrictions on access to computer hardware.

He also raises concerns about the game industry’s dependence on engines such as Unity and Unreal. Using an engine can shorten development time, but if nearly everyone relies on existing engines, fewer developers may learn how to build or maintain them. The industry could eventually lack the expertise needed to sustain its own foundational tools.

Practical lessons and recommendations

• Track the failures you encounter. Blow recommends making a daily list or taking screenshots whenever software exhibits an obvious bug, confusing behavior, or failure. He says this can reveal how frequent such problems have become.
• Simplify systems at every level where you can. He calls for reducing unnecessary complexity in:
  • Hardware and operating systems
  • Libraries and application code
  • Networking and communication systems
  • Software building, debugging, and distribution
  • The ways people interact with software
• Prefer tools that are not needlessly complicated. Blow does not prescribe a single set of tools for independent developers. Instead, he recommends developing an eye for tools that avoid unnecessary layers and choosing them over more cumbersome alternatives.
• Do not assume a flawed system is worth enduring until a deadline. Blow argues that projects often take much longer than planned, so continuing to work around a seriously buggy system for a supposed short period can cost more than addressing it.
• Preserve low-level understanding. Using higher-level tools may be useful, but teams should avoid losing all knowledge of what happens beneath those tools.
• Build institutional knowledge through simpler work. Fixing local problems by simplifying code can also help teams retain practical knowledge about how to build and maintain software.

Audience Q&A

• On the technological singularity: Blow says he does not believe in the singularity in the way many people describe it. He adds that when change accelerates, systems may also become easier to break.
• On using AI to manage complexity: He says AI might eventually understand very complicated software, but questions whether it would be desirable for humans to lose the ability to understand the software they depend on.
• On tools shaping creative thought: Blow agrees that tools influence how people think. Bugs and unnecessary complications can interrupt creative flow; he says his own language project aims to remove such complications, while acknowledging that his ideas about simplicity may themselves be shaped by the tools he has used.
• On tools for independent game developers: Blow does not name a particular recommended toolset. He advises looking for tools that are not an unnecessarily complicated mess.
• On whether programming is inherently too difficult: Blow distinguishes the complexity inherent in a problem from the additional complexity imposed by existing systems. Simplification may not make every problem easy, but it can bring software closer to the problem’s “ideal” complexity.
• On abstraction and simpler languages: Blow argues that higher-level abstraction is often mistaken for simplification, even though it can add complexity underneath. He describes languages such as Smalltalk and Logo as attempts to simplify programming, while noting that he sees practical shortcomings in them.

Speakers and sources featured or referenced

• Jonathan Blow — Main speaker and responder during the Q&A.
• Elon Musk — Featured in a video excerpt discussing the non-inevitability of becoming a spacefaring civilization and the possibility of technological decline.
• Bob Colwell — Quoted in an interview about chip-design problems and the loss of engineering knowledge between generations.
• Ken Thompson — Featured in an interview discussing how quickly early Unix was built.
• Eric Cline — Source of the lecture 1177 BC: The Year Civilization Collapsed, excerpts from which Blow uses.
• Apollo 11 documentary / NASA archival footage — A documentary excerpt is introduced to illustrate the scale of the Apollo mission; the subtitles do not identify the documentary’s speaker.
• Audience members, not identified by name — Ask questions during the Q&A. One references Edsger Dijkstra; Dijkstra is mentioned by the audience member, not featured as a speaker.
• Other recommended references: Casey Muratori’s The 30 Million Line Problem and a video by Samo Burja about civilizations, institutions, knowledge, and the future.