Grady Booch on the Third Golden Age of Software Engineering
The Pragmatic Engineer
AI tools now write surprisingly good code, and many developers fear this means the end of software engineering. Grady Booch, co-creator of UML, a pioneer of object-oriented design, and a longtime IBM figure, argues the opposite. In this conversation on The Pragmatic Engineer, Booch walks through the history of the field as a series of rising levels of abstraction. He describes two earlier "golden ages" and a third that, in his view, began around the turn of the millennium. He places today's AI coding agents inside that third age: developers have faced this kind of existential crisis before, the tools are changing but the problems are not, and Dario Amodei's prediction that software engineering will soon be automated is, in Booch's words, profoundly wrong.
What makes software "engineering"
Booch starts with the name itself. He credits Margaret Hamilton as probably the first to use "software engineer." She had just left the Manned Orbiting Laboratory project and was working on Apollo, one of very few software developers among mostly male hardware and structural engineers, and she wanted a term that set her work apart. The NATO conference on software engineering came a few years later. Booch notes that its organizers chose the name as a somewhat controversial one, much as "artificial intelligence" was controversially named for its first conference.
For Booch, what the name captures is that software people, like structural, electrical, or chemical engineers, build reasonably optimal solutions that balance static and dynamic forces. Perfect solutions are not available. Software is an extraordinarily fungible, elastic, fluid medium, but the same kinds of forces still act on it. He lists several:
- Physics: information cannot travel faster than light, and hardware limits how large systems can grow.
- Algorithms: sometimes a solution is known in theory long before anyone can implement it. His examples are the Viterbi algorithm, essential to cellular phones, and the Fourier transform, which could not advance progress until it became something computational.
- People: Can you find enough people and organize them into teams? Booch jokes that the ideal team size is zero, the next best is one, and it grows from there. Some systems are so large, and so economically and socially important, that no individual could build them, and the software has to outlive the people who wrote it.
- Law: digital rights management is one example.
- Ethics: this is the force he considers most overarching. We know how to build certain things, but should we?
Balancing these forces, in a medium he calls wonderful, is why Booch says software developers are engineers. This definition matters for his later argument, because it is the basis of his claim that automating code does not automate software engineering.
Before software, and the first golden age
In the earliest days there was no software as such. Programming the ENIAC meant putting plugs into a plugboard, and hardware and software could not be told apart. Only in the late 1940s and early 1950s did the two begin to separate. Booch points out how recent this is: "digital" was coined in the late 1940s and "software" in the 1950s. If software were placed on Carl Sagan's cosmic calendar, he says, it would occupy the last few nanoseconds.
The early software was all bespoke and tied to a particular machine, mostly written in assembly language. But organizations were investing heavily in software and wanted faster machines without throwing that investment away. Booch credits people like Grace Hopper with seeing that software could be treated as a business and an industry in its own right. The turning point he names is IBM's move in the 1960s to a whole architecture of machines sharing a common instruction set. Hardware could now improve without discarding software. Booch describes this as an engineering, business, and economic decision at once, and says it opened the floodgates. That began the first golden age, which he dates roughly from the late 1940s to the late 1970s.
The central problem of the age was complexity. By today's standards the systems were almost laughably simple, the equivalent of "hello world," but they were hard problems at the time. Because software was still closely coupled to machines built mainly for mathematics, the dominant abstraction was algorithmic: think Fortran, "formula translation." The world was decomposed into processes and functions rather than data. Booch names Ed Yourdon, Tom DeMarco, and Larry Constantine as the era's defining figures and mentions the rise of entity-relationship ideas on the data side. Flowcharts were invented as aids to thinking. Labor divided into analysts, programmers, keypunch operators, and computer operators. Booch attributes this division to economics: machines cost far more than people, so work was organized to make the best use of rare machines.
Most software of the era automated existing business processes and numerical work. Companies had entire floors of people doing accounting and payroll, and that was the low-hanging fruit: automation made those processes both faster and more precise. To a programmer at the time, the center of gravity looked like IBM, insurance companies, and banks.
Innovation at the fringe: defense, SAGE, and the "loom of sorrow"
Booch stresses that the real innovation of the first golden age happened at the edges, especially in defense. Software was moving into aircraft, missiles, weather forecasting, and medical devices. Because Russia was, as he puts it, the clear and present threat, there was demand for distributed, real-time systems, while most business systems were not real-time.
His main example is the lineage from the experimental Whirlwind machine to SAGE, the Semi-Automatic Ground Environment, built in the 1950s and 1960s. Booch says the last installation was decommissioned around the 1990s. Before missiles, the fear was a fleet of Soviet bombers crossing the Arctic. The DEW line, a distant early warning system across Canada, fed data into SAGE. By some reports Booch cites, SAGE used 20 to 30 percent of all software developers in the United States. He adds that there were perhaps only a few tens of thousands of developers then, but it was still the largest project around. Graphical CRT interfaces, the ancestors of today's user interfaces, have their roots in Whirlwind and SAGE. He also mentions the "Mother of All Demos" as experimentation with human interfaces that sat outside the mainstream.
On the academic side, researchers such as David Parnas, C.A.R. Hoare, and Dijkstra were studying the formal properties of systems and treating software development as a formal mathematical activity.
Booch sums up the pattern with a phrase from the documentary on computing he is making: two great forces run through the history of computing, commerce and warfare. So "much of modern computing is really woven upon the loom of sorrow," an allusion to Jacquard's loom. The internet and microminiaturization both came out of government funding, and "we owe a lot to the Cold War." The broader lesson he draws is that software tends to grow: once we know how to build something and have patterns for it, we find economically interesting ways to apply it elsewhere.
The software crisis
Booch says cracks in the first golden age became visible in the late 1970s and early 1980s, and he describes the NATO conference as one of the first big public acknowledgments. NATO realized it had a software problem: insatiable demand, and no way to produce quality software at speed. That was the "software crisis." Asked what exactly the crisis was, Booch lists four parts. Software was expensive, slow to produce, and of poor quality, and demand kept growing. He notes this is a different kind of crisis from today's worries about surveillance or system crashes. The nature of the problems changes in every golden age.
Microminiaturization fed into this. Booch traces Silicon Valley's growth to the transistor and notes that Fairchild's first customer was the Air Force, mainly for the Minuteman missile. Most early Silicon Valley transistors went to Cold War programs, which built the economic base that led to integrated circuits and then personal computers.
By the late 1970s the US government saw a "problem of Babel." By its count, at least 14,000 programming languages were in use across military systems. Jovial was a popular one. ALGOL, not a military language, together with the formal work of Hoare, Dijkstra, and Wirth, led to applying mathematical rigor to languages. The government's answer was the project that produced Ada, which aimed to reduce the many languages to "one language that ruled them all." Booch says Ada absorbed the research of the time: abstract data types, Parnas's information hiding, separation of concerns, and Knuth's literate programming, which he relates to what we now call clean code. No other organization had the weight or economic power to push such ideas at that scale.
Objects versus processes, and the road not taken
Alongside this, Bell Labs had produced C and Unix. Booch describes Bjarne Stroustrup as a "crazy researcher" who wanted to bring ideas from Simula, which Booch calls the first object-oriented language, into C to address C's problems. The broader realization in academia and at the fringes was that algorithmic abstraction was not enough and object abstractions were needed too.
Booch finds this split in Plato: a dialogue in which one participant argues for seeing the world through processes and flows, and another through things. He connects the latter view to the Greek origin of the word "atom." Parnas and the designers of Simula, he says, applied this old philosophical dichotomy to software.
He also describes a third path. After Fortran, its inventor John Backus, who became an IBM Fellow, turned to functional programming, which views the world through stateless mathematical functions. Booch interviewed Backus a few months before his death and asked why functional programming never became mainstream. Booch reports the answer: functional programming makes it easy to do hard things but "astonishingly impossible to do easy things." Booch believes that is why functional programming still has a real but niche role today.
The second golden age: objects, PCs, and counterculture
Booch identifies three forces that pushed the field into its second golden age: growing complexity, the difficulty of building software big enough and fast enough, and the value of distributed systems that defense work had shown. The fruits of microminiaturization produced the personal computer. Asked whether this was the first time hobbyists could really get their hands on computing, Booch says yes, at least at scale. There had been earlier hobbyists; he mentions Pascal building a calculating machine to spare his father tedious accounting. But post-war disposable income in the US, plus the availability of military-driven transistors and chips from electronics shops in Silicon Valley, made hobby computing widespread. "Play is an important part in the history of software," he says.
He recommends the book What the Dormouse Said, which argues that the rise of the personal computer was tied to the hippie counterculture: "power to the people," Stewart Brand, the Merry Pranksters, and The WELL, which Booch calls the very first social network, a bulletin-board system. He speaks warmly of Brand, who has just released Maintenance: Part One, a book on the problems of maintaining systems, including software. The host notes that Stripe Press is publishing it.
Booch entered the field at this time, working at Vandenberg Air Force Base on missile and space systems, including an envisioned military space shuttle. He shares a few anecdotes: launches about twice a week, evacuating his building for Titan launches because an explosion on the nearby pad would have destroyed it, and secret spy-satellite launches that were never really secret, because local hotels filled with contractors and the highway filled with spectators.
By the late 1980s, he says, the world was ready for object-oriented programming and design. The key difference from the first age was the level of abstraction. Instead of a raw "lake" of data and separate algorithms to manipulate it, data and processes were brought together in one place. His favorite example is the source code for MacWrite and MacPaint, written in Object Pascal and viewable through the Computer History Museum, which he calls one of the most beautiful pieces of software he has seen. He says many of its design decisions still persist in systems like Photoshop, a story about how long software lives. The 1980s and 1990s were vibrant, with the "three amigos" (Booch, Ivar Jacobson, and Jim Rumbaugh) plus Peter Coad, and Constantine and Yourdon back on the scene. Booch acknowledges mistakes: the field overemphasized inheritance, which "was kind of wrong," though the core idea of classes and objects endured.
Open source, platforms, and moats
Booch describes reuse as a recurring economic pattern. In the first golden age, people kept rebuilding the same things: drum and disk handling, teletype output, screen output, sorting. These were codified and packaged. IBM SHARE, a user group whose members literally shared software, was in Booch's account the earliest open-source software. It was customer-driven, with IBM supporting it. At the time manufacturers essentially gave software away; IBM only began charging separately for software in the late 1960s and 1970s. In the second golden age the same thing happened at a higher level of abstraction, for example libraries for writing to "newfangled CRTs" that gave no competitive advantage to the owner but let everyone build more.
Growing libraries and distributed systems led to service-oriented architectures. Booch recounts how the web grew beyond passing links: Netscape added images to HTML, and people wanted to pass messages over HTTP, so the internet became a higher-level medium for moving information and processes. SOAP and service-oriented protocols followed, which he sees as the predecessors of today's platform era: islands surrounded by APIs. Asked to define a platform, he points to AWS and Salesforce: "economically interesting castles defended by the moat around them," with access across the moat sold for a fee that is "not even a slight fee." Such businesses exist because building the capability yourself is so costly and complex.
Booch recalls getting his first email address in 1987 on the ARPANET, when a roughly hundred-page book listed the email address of everyone in the world. As email and similar things became commodities in the second age, software moved into "the interstitial spaces of civilization." The first age's problems were largely solved and became part of the atmosphere. "The best technology evaporates and disappears and becomes part of the air that we breathe."
Y2K, the dot-com crash, and AI's parallel history
Around 2000 came the dot-com crash, as many internet businesses did not make economic sense, and Y2K. Booch pushes back on the retrospective view that Y2K was a non-event: from inside, he says, there was a lot of heroic work, and without it many problems would have occurred. He calls it a good example of the best technology being invisible: money and effort prevented a problem that never showed up. The host remembers the stress of that New Year and how people came away distrusting such predictions.
Booch then fills in a parallel history of AI with its own ages. The first, in the 1940s and 1950s with Herbert Simon, Allen Newell, and Marvin Minsky, focused on symbolic methods. Neural networks were tried too: the SNARC used about five vacuum tubes per artificial neuron. A UK report concluded that the money was not producing results, and the age ended with the belief that neural networks were a dead end. Booch attributes this to missing computational power and missing algorithmic abstractions. The second AI age, in the 1980s, centered on rules and inference engines, alongside a lively period in hardware such as the Lisp machine and Thinking Machines. It too ended in an AI winter, according to Booch because it did not scale beyond a few hundred if-then statements.
The third golden age began around 2000
Booch's somewhat controversial claim is that the third golden age did not start with today's AI but around the turn of the millennium. Its sign was another rise in abstraction: from individual components to whole libraries, packages, and platform services. Need messaging? Use a library. Need to manage a large body of data? Use something like Hadoop, which he notes was not yet around then but whose seeds were growing. Methodologies and languages followed.
He sees AI coding assistants as a reaction to that growth. So many libraries exist that not enough people know how to use them, and tools like Cursor and ChatGPT speed up their use. In his framing they continue forces that already produced the third age.
The problems of this age differ from earlier ones. First, there is so much software that managing it is itself a problem. Second, safety and security: it is easy to inject something into the software supply chain, and he cites Stuxnet as an example of espionage through software. Human issues that software was once insulated from are now front and center. Third, economics: companies such as Microsoft and Google are too big to fail, and if they sneeze, part of the world catches a cold. Fourth, ethics: it is possible to track where someone is at every moment of the day, but should we?
"This is not the first existential crisis"
The host describes a sense of existential dread among engineers that grew over the recent winter break, when new models went from decent autocomplete to generating code good enough that the host began to trust it. Because coding has been so closely tied to the profession, many developers are asking what comes next.
Booch's answer is that developers have faced the same crisis in the first and second ages, and "this too will pass." His advice to worried people is to focus on fundamentals, because those skills will not go away. He recalls meeting Grace Hopper, whom he describes as a "fireplug" of a person, and recommends her appearance on David Letterman's show. Her recognition that software could be separated from hardware threatened early machine builders, who argued that nothing efficient could be built without being tied closely to the machine and wrote that it would destroy their work. The same fears arose with Fortran, when assembly experts insisted they could write tighter code than any compiler; Booch says moving to higher-level languages proved them wrong. Those people saw that their skills would be replaced by the very thing they had helped create. The difference now, Booch says, is scale: then it was a few thousand people, now millions are legitimately asking what this means for them.
When young developers ask whether they chose the wrong field, he tells them it is an exciting time, because the field is again moving up a level of abstraction: from machine language to assembly, to higher-order languages, to libraries, and now this. He finds it freeing to be relieved of the tedium while the fundamentals remain. The fundamentals matter when building software meant to endure. For throwaway software, "do what you want," and he sees many people using agents to automate things that were never affordable before, especially for a single user. He compares this to the hobbyist side of early personal computing: good ideas and skills will come from it, even if much of it will not last.
The host gives an example: a neighbor who is an accountant had ChatGPT build Apps Script tools for their accounting team, personal throwaway software from someone outside the field. Booch celebrates this. He recalls that artists and gamers were drawn to early PCs and the Amiga as a new medium of expression. Much of the current lamenting, he argues, comes from people narrowly focused on their own part of the industry who miss that the industry is expanding, with more software written by non-professionals.
Booch's response to Dario Amodei
The host brings up Anthropic CEO Dario Amodei. According to the host, Amodei predicted about a year earlier that around 90 percent of code would be AI-generated, which people dismissed but which the host considers to have come true. Amodei now says software engineering will be automatable in 12 months. The host points out that coding is only a subset of software engineering.
Booch first says he uses Claude and calls it his go-to system. He has used it with JavaScript, Swift, PHP ("of all things"), and Python, mostly to learn unfamiliar libraries, since in his words Google search and the documentation are both poor. But he stresses that he brings decades of experience with the fundamentals, and that in every engineering discipline the fundamentals remain while tools change.
He then puts Amodei's statement in context: Amodei leads a company that must make money and must speak to its stakeholders, so outrageous statements get made; Booch believes this one was made at Davos. Booch calls it "utter" nonsense, trailing off before the final word and calling it the "technical term," and says Amodei is profoundly wrong. He accepts that AI will accelerate some things but denies that it will eliminate software engineering, because in his view Amodei misunderstands what software engineering is. Engineers balance the forces Booch described at the start, and code is only one mechanism. None of what Amodei or his colleagues describe addresses those decision problems; their work automates the lowest levels, which Booch likens to what compilers did. "Your tools are changing, but your problems are not."
His second objection concerns scope. Tools like Cursor are trained mostly on problems solved over and over again, such as a UI over CRUD or web-centric systems, just as libraries grew up around the recurring problems of the first age. Paraphrasing Shakespeare, he says there are more things in computing than are dreamt of in Amodei's philosophy: computing is much larger than web-centric systems at scale, and a great deal remains unautomated. Third, he describes these agents as good at generating patterns, which he sees as a new abstraction: societies of objects and algorithms that work together, describable in English.
English as a programming language, and the D3 example
Booch addresses the obvious objection that English is imprecise, ambiguous, and full of nuance. His reply is that engineers already work this way: they tell someone "I want the system to do this, it looks kind of like this," give examples, and someone else turns it into code.
His concrete example involves the D3 JavaScript library, which he had never used. He found a site called Victorian Engineering Connections, built for a museum by a man named Andrew, where you can enter a name such as George Boole and explore that person's social network interactively. Booch wanted something similar. The creator gave him the code, which used D3. Booch asked Cursor to build the simplest possible version, with about five nodes, so he could study the code, then asked it to change the nodes' appearance by type. He was expressing needs in English as he would to a person, and the tool shortened the distance between what he wanted and a working result. He calls this a breakthrough, with the caveat he raised against Amodei: it works where the task has been done hundreds of times before. He acknowledges Feynman's view that doing it yourself is the only way to understand, but says there is too much in the world he is curious about to learn it all.
He closes the point with a definition: a language precise and expressive enough to build executable artifacts is a programming language. English is good enough, much like COBOL was, in well-structured domains, producing good-enough solutions that people who know the fundamentals can nudge and clean up. That, he says, is why fundamentals matter.
What becomes obsolete, and what matters more
The host notes that every jump in abstraction made some skills obsolete, such as hand-optimizing for a particular instruction set, and asks what will happen this time. Booch points first to the software delivery pipeline, which he says is far more complex than it should be. Getting something running is hard without a pipeline, and companies like Google or Stripe have huge custom infrastructure. He treats infrastructure as software and sees it as low-hanging fruit for agents, where automation brings clear economic value and security value. He expects job losses there and a need for people to reskill. He also expects losses among those who build simple applications, such as a straightforward iOS app, since people can now prompt their way there. He calls this fine, because it hands a new generation what professionals used to do, as happened with PCs.
His advice to those affected is to move up a level of abstraction, from programs and apps to systems. People who can manage complexity at scale and balance the many forces, human as well as technical, will not lose their jobs. If anything, he expects greater demand, because those human skills are rare and delicate.
Foundations: systems theory, brains, and multi-agent architecture
Asked which foundations people should study, Booch says his "happy place" when facing a hard problem is systems theory. He recommends Simon and Newell's work, particularly The Sciences of the Artificial, and the Santa Fe Institute's work on complexity and systems.
He illustrates with his work on NASA's Mars missions, thinking about long crewed missions and robots on the Martian surface. He realized NASA essentially wanted to build HAL, and he keeps a HAL replica behind him as his "sword of Damocles," a reminder to stay humble. He jokes that NASA did not want the "kill all the astronauts" use case. He framed the problem as systems engineering, because the intelligence had to be embodied in the spacecraft, whereas most AI today, Cursor, Copilot and the like, is disembodied with no connection to the physical world. His work focused on embodied cognition. Around the same time he studied with neuroscientists to understand the brain's architecture, and began to see structures from systems engineering that apply to very large systems.
For today's agent programming, which he thinks people are only beginning to understand, Booch points to earlier work on multiple agents: Minsky's Society of Mind; global workspace ideas associated with Baars and the blackboard architectures in early AI systems such as Hearsay; and Rodney Brooks's biologically inspired subsumption architecture. He observes that a cockroach has no central brain yet does magnificent things, and that the entire neural network of a common worm has been mapped without producing "evil worms running around the world." Something more is happening, and biological systems have architecture. Looking at architecture through biology, neurology, and real-world systems, as Simon and Newell did, is what guides his thinking about the next generation of systems. "There is nothing new under the sun in many ways."
How to thrive at the start of a new age
The host observes that agents are spreading everywhere, citing reports that they will be part of Windows 11, and asks what people who thrived at the start of earlier golden ages did. Booch returns to imagination. Software begins with imagination, which is almost unlimited, and is constrained by physics, algorithms, ethics, and cost. Now some of that friction and cost is disappearing, so people can focus on imagination and build things that were impossible before, because they could not have raised a team, afforded it, or had the reach. There will be losses for those with a vested economic interest in the old ways, he says, but he considers it a net gain.
He admits it is frightening as well as exciting, and says that is how it should be. On the cusp of something wonderful, you look into the abyss and either decide you will fall in or decide to leap. "This is the time to soar."
Some people worry that AI writing surprisingly good code could mean the end of software engineering. But Grady Booch disagrees and says that we are entering the third golden age of software engineering. Grady Booch is one of the founding figures of software engineering as we know it. He co-created UML, pioneered object-oriented design, spent decades as an IBM fellow, and has witnessed every major transformation this industry has undergone since the 1970s. In today's conversation, we discuss the three golden ages of software engineering and what history teaches us about surviving and thriving through major technology shifts. Why coding has always been just one part of software engineering and why the human skills of balancing technical, economic, and ethical forces are not going anywhere. Grady's direct response to Dario's prediction that software engineering will be automated in 12 months. Spoiler, he does not hold back. And many more. If you want to understand that the massive change that AI is bringing has in fact happened before and not just once, this episode is for you.
This episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsors.
So, Grady, it's great to have you back on the podcast again. Thanks for having me. Aloha.
So touching a little bit on the history of software engineering, you've said many times before that the entire history of software engineering is one of rising levels of abstraction. Can you walk us through the key inflection points that help us understand this and then of course tie it into how AI is all tying into this?
Well, the very term software engineering did not come to be until Margaret Hamilton was probably the first to anoint it. She at the time had just left the Manned Orbiting Laboratory project. She was working on the Apollo program and she was one of the very few people who were software developers in a sea of mostly men who were the hardware structural engineers, and she wanted to come up with a phrase that distinguished herself from the others. So she began using the term software engineer, and I think we can rightfully give her the claim to the first one that coined that.
There were others that followed, most notably people talk about the NATO conference on software engineering, and when the organizers established that, which was actually a few years after Margaret's work, they did so as kind of a controversial name, not unlike how the term artificial intelligence was named controversially for its first conference on the west coast. So there were others that followed and after a period of time it kind of stuck, and I think what it meant, the essence of what Margaret and others were doing, is to say there's something engineering-ish about it in the sense that ours is a field that tries to build reasonably optimal solutions. You can't have perfect solutions that balances the static and dynamic forces around them, much like what structural, electrical, chemical engineers do. In the software world, of course, we deal with the medium that is extraordinarily fungible and elastic and fluid, and yet we still have the same kinds of forces upon us.
Here we've got the forces of the laws of physics. You can't pass information faster than the speed of light, which is kind of annoying in some cases, but hey, we'll have to live with it. There are issues about how large we could build things, largely constrained by our hardware below us. There are constraints we have on the algorithmic side of things. We may know theoretically how to do something, such as the Viterbi algorithm, which was essential to the creation of cellular phones. For the longest time, we didn't know how to implement it, but there was indeed a calculable solution. Similar stories with regards to fast Fourier transform. We knew the theory, but until Fourier transforms could be turned into something computational, we couldn't progress.
And there are also other constraints upon us, not just these scientific ones and the computer sciency ones, but constraints such as the human ones. Can I get enough people to do what I need to do? Can I organize teams doing what I want to do? Ideally the largest team size you want for software is zero. Well, that's not very practical. The next best one is one, and then it kind of grows from there. And there are projects that simply are of a certain scale that you cannot conceive of them being done by a small group of people. I mean, why do any of the large projects we have have a cadre of folks in them? It's because the footprint of these systems and their enduring economic and social importance is so great. You can't rely upon just an individual. That software must endure beyond them.
And increasingly as software moves into the interstitial spaces of the world, we have the legal issues, such as we see with digital rights management, but I think more importantly and overarching, the ethical issues. We know how to build certain things, but should we build them? Is it the right thing for us to do in our humanity? So these are the collection of things that are in a way, well, not in a way, but absolutely are the static and dynamic forces that weigh upon a software engineer, and that's why I can say we are engineers, because much like the other kinds of engineers, we build systems that balance those forces, and we do so in a medium that is absolutely wonderful. So that's software engineering.
Now I mentioned in our last call there are certain ages of software engineering, and I think as we look from the lens of looking backward, there are at least two identifiable major epochs in software engineering. In the earliest days there was no software because what we did was simply managing our machines, and the difference between the hardware and the software was completely indistinguishable. Putting plugs in a plugboard, as happened with the ENIAC. Is that programming? Well, yes, but there's not really software there. It's something else. And it wasn't until our machines came to the point in the late 40s, early 50s that we began to find a difference for them. Most of this software written at that time was bespoke. Well, really all of it was. And virtually all that software was tied to a particular machine. But the economics of software were such that we love these machines. We'd like them to be faster, but gosh, we put a lot of investment in the software itself. Is there a way to decouple these kinds of things?
We talk about the recent history of our world. The term digital was not coined until the late 40s. The term software was not done until the 50s. And so even the acknowledgement that software was an entity unto itself was just about in my lifetime, which is frightening to think about.
Yeah. Like 70, 80 years ago. Wow.
Yeah. Exactly. So we're an astonishingly young industry. If you were to take Carl Sagan's cosmic calendar and put software in it, we would be in the last few nanoseconds of that cosmic calendar. It would be less than a blink of an eye.
But anyway, as software began to be decoupled from hardware itself, then folks such as Grace Hopper and others were beginning to realize that this is a thing that we could treat as a business and an industry, as an institution unto itself. So the earliest software of course was, as it was, software itself was assembly language, which was very much tied to the machine. And jumping ahead a little bit, as IBM came along in the '60s recognizing that there was a way to establish a whole architecture of machines with a common instruction language, then it was possible to preserve software investments and yet decouple it from hardware in a way that I could improve my hardware without throwing away the software. Once that realization happened, which was both an engineering decision, a business decision and overall an economic decision, then the floodgates opened up and all of a sudden we had a lot more software that could be and needed to be written.
This was the first golden age of software engineering, in which we had software was an industry unto itself. And so the essential problems that world faced were problems of complexity. Complexity in that we were building things that were difficult to understand, that were trying to manipulate our machines in some cunning ways, but it was complexity that by today's standards was laughably simple. This is the equivalent of hello world, but they were problems that were hard unto themselves. And so because we were so coupled to the machines, the primary abstraction used in the first golden age of software engineering was that of algorithmic abstraction, because that's what our machines did. Most of our machines were meant for mathematical kinds of operations, and so as was done in Fortran, it was a matter of building our software that could do formula translation. So that was the realm and the problems faced by the first generation.
And this first generation, like in timeline, where would you put it roughly?
Timewise I'd put it in the late 40s to the late 70s or thereabouts, and that's what dominated that time frame. So the figures you would see would be Ed Yourdon, Tom DeMarco, Larry Constantine. This is when ERP, sorry, not, entity relationship ideas came about. And so these ideas of that kind of abstraction poured over not just into software but also into the data side of things as well. This was an extraordinarily vibrant period of time in software engineering in which we had the invention of flowcharts, for example, which were an aid to thinking about how to construct these kinds of systems. You saw a division of labor where you had people who would analyze the system, people who would then program it, people who would keypunch the solutions, people who would operate the computers. And again this was largely driven by economic reasons, because the cost of machines were far greater than the cost of the humans involved in them. So a lot of what was happening was done to optimize the use of the machines, which were very, very rare resources.
The lesson in this, as we'll see coming back in the next generations, is that these forces, much like with software engineering itself, have shaped the very industry of software, and economics and the whole social context also influences them. So in the first generation it was largely focused upon mathematical needs and the automation of existing business processes. So what you had happen is that you would have businesses that have literal floors of offices with people doing accounting and payroll and the like. And this was the low-hanging fruit, because now all of a sudden we could accelerate those processes and actually improve their precision by pulling the human out of it and automating it. So the vast amount of software written during that time was business and mathematical and numerical kinds of things.
Now this is an important thing, because while this was the focus, this was not the only kind of thing, because you saw in the periphery, or shall I say, from the point of view of a person who was a programmer in that time, it looked to them as the dominant places was in the IBMs, the insurance companies, the banks and the like. There's a lot of work going on outside that world in the defense industry as well. We saw people moving software and hardware into our machines of destruction, into our aircraft, into our missiles. We saw it moving into weather forecasting. We saw it moving into medical devices itself. So while the concentration was the things that the general public would see, a lot of stuff was happening around the edges as well.
I would say in the first golden age of software engineering there was this central push of algorithmic abstractions into business and numerical things, but the real innovation was happening in that fringe. In particular it wasn't in business cases but it was in defense cases, because Russia was the clear and present threat for us at the time, in which there was a need to build distributed systems of real-time nature. Most of the systems I've talked about were not real time. And so we saw the rise of experimental machines such as Whirlwind. We saw the work in the mother of all demos, which was experimentation of various human interface kinds of things, which was not the center of gravity of software development at the time, with the things on the fringes. We saw researchers such as David Parnas who were coming on the scene, C.A.R. Hoare, Dijkstra and others were beginning to look at the formalisms of these systems and looking at treating software development as actually a formal mathematical activity.
Grady just mentioned formal methods and formal mathematics and software engineering. Being able to verify that software does what it should has been a problem since the early days of software engineering. And this leads us nicely to our seasonal sponsor, Sonar. As we're living through what Grady might call the third golden age of software engineering, AI coding assistants generate code faster than we ever thought was possible. This rapid code generation has already created a massive new bottleneck at code review. We're all feeling it. All that new AI-generated code must be checked for security, reliability, and maintainability. A question that is tricky to answer, though: how do we get the speed of AI without inheriting a mountain of risk?
Sonar, the makers of SonarQube, has a really clear way of framing this: vibe, then verify. The vibe part is about giving your teams the freedom to use these AI tools to innovate and build quickly. The verify part is the essential automated guardrail. It's the independent verification that checks all code, human and AI-generated, against your quality and security standards. Helping developers and organizational leaders get the most out of AI while still keeping quality, security, and maintainability high is one of the main themes of the upcoming Sonar Summit. It's not just a user conference. It's where devs, platform engineers, and engineering leaders are coming together to share practical strategies for this new era. I'm excited to share that I'll be speaking there as well. If you're trying to figure out how to adopt AI without sacrificing code quality, come join us at the Sonar Summit. To see the agenda and register for the event on March 3rd, head to sonarsource.com/pragmatic/sonarsummit.
With this, let's get back to Grady and treating software development as a form of mathematical activity.
And you saw the rise of, as I said, distributed and real-time systems, primarily in the defense world. So from Whirlwind it begat a system called SAGE, the semi-automatic ground environment, which came about during the 50s and 60s, and indeed the last one was decommissioned I think in the 1990s. This was based upon the threat of Russia. This is pre-missiles; Russia would send a fleet of bombers over the Arctic and invade the United States. So thus was born the DEW line, the distant early warning system across Canada. And all that data was then fed into a series of systems called SAGE, the semi-automatic ground environment. This system was so large it consumed, according to some reports, easily 20 to 30% of every number of software developers in the United States at the time.
Wow.
That's a lot of folks. But remember, back in the time there were maybe only a few tens of thousands of software developers, but this was the biggest project.
Basically the military was the biggest spender in research and moving the industry forward, right? Because they had...
Absolutely, absolutely correct. They had to, because it was a clear and present threat, and so a lot of the innovation was happening in the defense world. As I think I passed this phrase on to you, in the documentary I'm working on in computing I use the phrase that there are two major influences in the history of computing. One is commerce. We've talked about the economics already. And the second is warfare. And thus I claim, and I think there's much defense for it, much of modern computing is really woven upon the loom of sorrow. Referring back
to Jacquard's loom. So yeah, a lot of the things we take for granted today like the internet, like microminiaturization, this all came from government funding in these cases. So we owe a lot to the Cold War.
This phase, was this still the first golden age?
We passed the first golden age. These are the things happening in the first golden age. But what I'm pointing out is there was sort of a center of mass to it, but lots of things happening on the edge that were driving software out from its primary roots.
So let's recap here. In the first golden age, you had the focus primarily upon mathematical and business kinds of applications. And the primary means of decomposition was an algorithmic abstraction. We looked at the world through processes and functions, not so much through data. But on the fringe, we had organizations, use cases that were pushing us beyond that simple place. Use cases that demanded distribution, use cases that demanded the coupling of multiple machines and also use cases that demanded real-time processing and use cases that demanded human user interfaces.
The interfaces we deal with today, they had their roots in Whirlwind and the roots in SAGE. This is the first UI interface that was graphic tube, a CRT. And so these kinds of things were born from that. So that was the point and I think the lesson from this is that software is a wonderfully dynamic, fluid, fungible domain. But it's also one that tends to grow because once we built something and we know how to build it and we have patterns for doing so, all of a sudden we discover there economically interesting ways we can apply it elsewhere.
So this was the first generation, the first golden age of software engineering. But you could begin to see cracks in the facade in the late 70s, early 80s. The NATO conference on software engineering was one of the first to do this in a big public way. And for them NATO was realizing we, NATO, have a software problem. We have an insatiable demand for software and yet our ability to produce it of quality at speed, we just don't know how to do it. And so this was the so-called software crisis and people didn't know what to do about it.
Can you help us understand or take us back, what was the crisis about? What were people kind of like saying, oh my gosh, this is the problem?
Yeah, the problem was, to recap, software was clearly useful. There were economic incentives to use it and yet the industry could not generate quality software of scale fast enough.
I see. I see. So it was both expensive, slow and not good.
There's a fourth one which was the demand was so great that, I guess you could call it the slow, the demand was so great. It's like wow, we want more of this stuff. Give us more software. So those four things together put us in the sense of crisis. Notice subtly it's not the same kind of crisis we have today where we worry about surveillance, we worry about crashes, that kind of thing. So the nature of the problems have changed and they do in every golden age.
It's fascinating that this thing existed, living in our current reality.
Yes. Yes. It's a very different world itself. But the clear and present danger at the time was that, and it was an exciting, vibrant time because there was so much that could be done and software being such a fungible, elastic, fluid medium meant that we were primarily limited just by our imagination. You add to this then microminiaturization. Why did integrated circuits come about? Why did Fairchild come about and establish Silicon Valley, be the basis for it? It's because of the transistor. Who was the first customer of Fairchild? It was the Air Force, primarily for their Minuteman missile. In fact, most of the transistors being made in Silicon Valley in the earliest days went to our Cold War programs. But that was great because that established then the economic basis for the whole infrastructure for doing it, where it was possible to start doing these things at scale, and of course we knew that begat integrated circuits, that begat personal computers and so on.
So here we are now in the late '70s and the software crisis was quite clear. The US government in particular, to focus on one story, recognized that they had the problem of Babel and that there were so many programming languages in place. By their count, there were at least 14,000 different programming languages used through military systems.
Oh wow. Back then when software was so much smaller than today. Wow.
Absolutely. It's incredible. And languages like JOVIAL was a very popular one, JOVIAL kind of a play on words for COBOL and the like. We had the rise of ALGOL, which was not a military language, but the formal forces of Hoare and Dijkstra and Wirth led to this discipline of applying mathematical rigor to our languages and so the idea of formal language research was born. You had this wonderful confluence of resources. It said by the late '70s, the government recognizing that we have a problem, that's when they funded the Ada project, which at the time was called the joint program working group, something like that, which was an attempt to remove the number of languages that exist and try to reduce it to one language that ruled them all.
Now what was interesting is that you saw at this time there was a lot of interesting research that was feeding into it. The work of abstract data types from Galan and the ideas of information hiding from Dave Parnas, separation of concerns, the ideas today we would call clean programming, clean coding, but it's the ideas of literate programming from Knuth. So these kinds of things were bubbling away in the late 70s and early 80s, and Ada was a little bit of a push to make that happen on a big scale. No other industry or company could really do it because they didn't have the exposure or weight or gravitas or economic powerhouse as the US military at the time did.
At the same time, you had some interesting work going on in laboratories like at Bell, which had begat C and Unix and the like, which was becoming incredibly important. But there was this crazy researcher at the time by the name of Bjarne Stroustrup who was saying, wow, this is kind of cool, but hey, let's take some of these ideas from Simula, I should mention Simula, which was the first object-oriented language, and let's see if we can apply them to C, because C's got problems with it, let's see if we can move about. So what was happening in the background in academia and in these fringes was the realization that we needed new kinds of abstractions and it wasn't just algorithmic abstractions, but it was object abstractions.
Turns out there's an interesting history behind that dichotomy. There is a discourse in Plato about that very kind of split, in which he has a dialogue between two people who are talking about how I look at the world, and one of them says we should look at the world in terms of its processes.
This is the ancient Greek philosopher from like before Christ, that guy, that Plato, he brought up some parallel ideas.
He brought up the ideas of the dichotomy of looking at the world through two lenses. The very Plato whose work has now been banned in certain US universities because he was so radical. Right? But in one of these dialogues he observed that one of the writers said, oh, we have to look at the world through the processes, how things flow. And the other one said no, no, no, we have to look at them through things. And this is where the idea of atoms came about. The very term atom came from Greek terms and that terminology. So the idea of looking at the world and looking at the world are basically abstractions is not a new one. But people like Parnas and others and the designers of Simula said, "Wait a minute, we can apply these ideas to software itself and we can look at the world not just through algorithmic abstractions, but we can look at them through object abstractions."
Now there's another factor that came into the place and this is where the inventor of Fortran came into be. After Fortran he went off, and he did this at IBM of course, he was made a fellow, and he went off and said this was fun but I want to do something else, and he said let's look at a different way of programming, and it was the idea of functional programming, which was looking at the world through mathematical functions, stateless kinds of things. So there was work here, we are talking what, in the 70s now, in which the ideas of functional programming came to be. I had a chance to interview him a few months before he passed away and I asked him, why did functional programming never make the big time? And his answer was because functional programming makes it easy to do hard things, but it makes it astonishingly impossible to do easy things.
Easy things.
Yeah. So functional programming has a role. There's no doubt. And I think its foundations were laid at the time by John. But even today, it has a role. It has a niche, but it hasn't become dominant because of that very same edict. So at any rate, here we are at the sort of end of the first golden age of software engineering and moving into the second. What were the forces that led us into that? First off, it was growing complexity.
Grady just mentioned how growing complexity was a force pushing the industry into a new golden age of software engineering. Fast forward to today and software complexity keeps growing, growing and growing, in part thanks to AI generating a lot more code a lot faster. And this brings us nicely to our season sponsor WorkOS. WorkOS provides the primitives that make it easy to make your app enterprise ready. But under the hood, there's so much complexity that happens. I know this because I recently took part in an engineering planning meeting at WorkOS called the Hilltop review, an engineer walking through their proposed implementation. In this review, we discussed how to implement authentication for customers when their users authenticate across several platforms using WorkOS. For example, what should happen if a user logs out on the mobile version? Should they stay logged in in the web version? What about the other way around? We covered 10-plus similar questions. The answer, as I learned, goes down to: it depends what the customer using WorkOS wants.
The WorkOS team walks through edge cases I had no idea existed and then turns those decisions into configurable behavior in the admin panel, so customers choose the right trade-offs for their product and their users without having to build and maintain all of this logic themselves. But this is not always enough. And when customers have unique needs, the WorkOS engineering team often works with them directly to figure out how to solve their very specific problem. They then generalize these solutions so they become part of the platform for everyone. After this planning session, I have a newfound appreciation for just how much complexity WorkOS absorbs so product and engineering teams don't have to. The same planning goes into all WorkOS products and customers get all the benefit. Learn more at workos.com.
And with this, let's get back to Grady and how the second golden age of software engineering came about.
As I mentioned, growing complexity, difficulty of building software fast enough and building big enough software, and I would add to this the things that came about in the defense world, which were the desire and an obvious value in building systems in a distributed kind of way. Now come on to the scene, because what was happening around that same time is the fruits of microminiaturization came to be and it led us to the personal computer.
This was because of transistors, right? And the breakthroughs in like electronics and
Precisely, and this too was a vibrant time because you had hobbyists who could put these things together and build them from scratch, and there were no personal computers at the time.
Was this the first time that hobbyists could actually meaningfully get their hands on it in the history of computing? Really?
I think at scale, yes. You had hobbyists such as Pascal back in his day, who decided that his father was so tediously working over his accounting that Pascal built a little machine for him. So there was hobbyist work at that time, no doubt about it. But in terms of scale, and also remember post World War II, you had the addition, especially in the United States, of more disposable income, which made it possible for hobbyists to actually do these kinds of things. And then lastly, you had the military who was producing integrated circuits and transistors. And all of a sudden, especially in Silicon Valley, you could go down to Fry's or the Fry's equivalent, this is before Fry's, and buy these things. They were just there, and so it enabled people to play, and play is an important part in the history of software.
So you had this wonderful thing happening, and I'd say the late 70s and early 80s was a vibrant time of experimentation. There's a delightful book called What the Dormouse Said, which posits that the rise of the personal computer was also tied together with the rise of the hippie counterculture. And so this drive toward power to the people and, make love not war, these kinds of things. This is the era of Stewart Brand, the era of the Merry Pranksters and the like, and that led to things like the WELL, which was the very first social network, which today we call bulletin boards, which grew up in Silicon Valley. Quick aside, Stewart, just a lovely fellow. He was actually mentioned as one of the Merry Pranksters in the book about them. He's still on the scene and he's just released a wonderful book called Maintenance: Part One, which looks at the problems of systems, software is one of them, and the problems of maintenance associated with them. Anyway, here we are, late 70s, early 80s, also a very vibrant time because there's a lot of cool stuff that could be done.
Yeah. And Stripe Press is publishing this actually. So I'll leave a link in the show notes below. It looks like a really nice book and Stripe Press is known to produce excellent quality. So I'm actually excited to look into this.
Yeah, it's a great book. So the realization was that we now had the beginnings of theories of looking at the world not through processes, but through objects and classes. We had the demand pull of distributed systems, the demand pull from trying to build more and more complex systems. And so there was also this perfect storm that really launched that second golden age.
And that's frankly where I came onto the scene. I was just in a lucky place at a lucky time. I was at the time working at Vandenberg Air Force Base on missile systems and space systems. There was an envisioned military space shuttle and I was part of that program as well. It was great. It was a fun place to be because we'd have launches like twice a week. It was pretty cool. You'd run up and say, "Wow, look at that." It was pretty wild. At the building in which I worked, I had to evacuate whenever there was a launch, because if it was a Titan launch, the Titan launch pad was really close to us, and if it had blown up on the launch pad, it would have blown up our building, which would have been really annoying.
So, yeah. Good stuff.
And one other quick story, you could always tell when it was the secret launches going off, the secret spy satellites, because there were two main clear indications. The first is all the hotels would fill up because you'd have the contractors come in. And second, the day of the launch, the highway nearby where you could see the launch would fill up with people to watch it. So there were no secrets in that world.
So here we are, late 80s. The world was poised for a new way of looking at the world, and that was object-oriented programming and object-oriented design.
So how does that differ from the first
generation? It differs in the sense that we approach the world at a different layer of abstraction. Rather than just looking at the data which was this raw lake out here and the algorithms we have to manipulate them, we bring them together into one place. We combined the objects and the processes together and it worked. My gosh, it'll enable us to do things we could not do before. It was the foundation for a lot of systems.
Go out to the Computer History Museum and go look at the software for MacWrite and MacPaint. It was written in Object Pascal, one of the early object-oriented programming languages. One of the most beautiful pieces of software I've seen. It's well structured. It's well organized. And in fact, much of the design decisions made in it, you still see persist in systems such as Photoshop today. They still exist, which is an interesting story unto itself about the lifetime of software.
So looking at software through the lens of objects proved to be very effective because it allowed us to attack the software complexity problem in a new and novel way. And so much like the first golden age, this was also a very vibrant time in, I would say, the 80s and 90s, where you had people such as the three amigos, me, Ivar Jacobson and Jim Rumbaugh, you had Pete Coad, you had Larry Constantine was back on the scene, Ed Yourdon was back on the scene, a lot of folks who were saying, "Let's look at software not from processes but from objects and think about it."
Now, this was great. We made some mistakes. There was an overemphasis upon the ideas of inheritance. We thought this would, you know, be the greatest thing. That was kind of wrong. But the idea of looking at the world from classes and objects, it was kind of built in.
And so what began to happen, this was also an economic thing. As people started building these things, all of a sudden we saw the rise of platforms. Now there was precedence for this because in the first golden age of software people started, you know, building the same kinds of things over and over again. The idea of collecting processes, collecting algorithms that were commonly used, like, you know, how do I manipulate a hard drive or a drum? How do I write things to a teletype? How do I, you know, put things on a screen? How do I sort? These kinds of algorithms could be codified and so the first ideas of, if you will, packaging them up into reusable things came into being. This is when, at least in the world of business systems, IBM SHARE came to be. SHARE was a customer-organized group that literally shared software among one another. Totally.
And this was in the first golden age, right?
This is the first golden age, right?
So this was kind of like a primitive, or like, I mean, looking back, a more primitive way of just packaging stuff into related, may that be sorting algorithms, or, as you said, IBM was distributing just like functions and things like that.
IBM wasn't doing it. It was perfect. It was completely public driven. IBM supported it but was done for it.
Yeah. So the point is this was the earliest open-source software. So the ideas of open source existed, and remember too in the economics of software and hardware back in the time, software was pretty much given away free by the main manufacturers. IBM did not charge for software until later, in the later 60s, 70s, they realized, my gosh, we can make money, and they decoupled software and hardware and started charging you for it. But in the earliest days, there was this vibrant community of people who could say, you know, gosh, I've written this thing. Go ahead and use it. That's fine. No problem. So, open source was late at that time.
And the same thing began to happen in the second golden age, in which we saw, much like the rise of operating systems, the rise of open-source software, the same phenomena applied in the second golden age, but now it was a new layer of abstraction. Oh, I want to have now a new library for, you know, writing to these newfangled CRTs. Here it is. No competitive value in me having it, but by gosh, it enables me to build some really cool things. You can have it, too. So, open source laid its roots, took its ideas from the first golden age, applied itself in the second golden age, but in a different kind of abstraction.
Lurking in the background, speaking of economics, was the rise of platforms, because now all of a sudden these libraries are becoming bigger and bigger. And as we moved to distributed systems, there was the rise of, back then we called it, service-oriented architectures. There was this need of, you know, we had HTML and the like. We could, you know, pass links back and forth, but there were some crazy folks that said, wouldn't it be cool if we could do things like, you know, share images? And that was one of the things that Netscape allowed, which was they produced this addition to HTML that allowed you to put images. Wouldn't it be cool if we could pass messages back and forth via HTML? So all of a sudden the internet, via HTML protocols, HTTP protocols, became a medium at a higher level of abstraction for passing information and processes around. But there was a need to package it up. So thus was born service-oriented architectures, SOAP, the service-oriented architecture, service-oriented protocols, all that, the predecessors to what we have today.
And this was laying the foundations in the second golden age for the beginnings of the platform era, which is, you know, what Bezos and others have really brought us to, where, jumping ahead in our current age, you have these islands which are sort of formed by all sorts of APIs around them. But it was in the second golden age that they were being born.
And when you say platforms, what do you mean when you say the rise of platforms? How do you think of a platform?
AWS would be a good one. Salesforce would be another one, in which I have these economically interesting castles defended by the moat around them, and those organizations like Salesforce give you access across the moat for, you know, a slight fee. Well, not even a slight fee.
Yes. Not a slight fee.
Yeah. Under the assumption that we as, like, a Salesforce, the cost of you doing it yourself is so high it makes sense for you to buy from us. So during the second golden age we saw the rise of those kinds of businesses, because the cost of certain kinds of software was sufficiently high and the complexity was certainly high, it allowed the business and the industry of these kinds of SaaS companies.
So, let's look at the late '90s, early 2000s. Also a vibrant time, much like the first golden age. We had the growth of the internet. When did you get your first email address?
My first email address I got sometime in maybe 2005, 2006. It was still very fresh when Gmail launched. But when did you get your first email address?
1987, when it was the ARPANET. And in fact, at that time, yes, we had a little book. It was probably a hundred pages long that listed the email address of everybody in the world. It was pretty cool. You can find them online and you can see my email there. Doesn't work anymore because it doesn't have the same, you know, top-level domain kind of things. So, I've been on email before email was cool.
And so as you saw these kinds of structures like email becoming a commodity thing in the second golden age of software, this is when software began to filter into the interstitial spaces of civilization, and it became not just this one thing fueling businesses or certain domains. It became something that became part of the very fabric of civilization. This was important. And so now the things we worried about in the first golden age, we'd solved them for the most part. They were part of the very atmosphere. We didn't think about algorithms much because, you know, gosh, everybody kind of knows about them. And this is as technology should be. The best technology evaporates and disappears and becomes part of the air that we breathe. And that's what's happening now. But it was in the second golden age. The foundations of where we are today are here.
So what happened around 2000 or so? Well, by that time the internet was big, lots of businesses being built, but there was the crash around that time because economically it just didn't make sense. So there was this great pullback. Also happening was the whole Y2K situation, where a lot of effort was put into, you know, solving that problem. You know, people in retrospect say, well gosh, we didn't need to worry about that. But being in the middle of it, you realize, oh no, there was a lot of heroic work. And if that hadn't been done, then lots of problems would have happened. So this is a good example of how the best technology you simply don't see. A lot of effort and a lot of money was spent to subvert a problem that simply did not manifest itself. That's a great thing.
Grady just mentioned how the best technology is one that you simply do not see. This is an underrated observation and it's true for most mission-critical software. When it works, it's invisible. It's only when it breaks that users notice that it's there. There is, however, a problem with building reliable invisible software. There's often a tension between moving fast with few guardrails that can make things break, or putting in more guardrails for stability but then slowing down in shipping speed.
Well, there's a third way, which leads us nicely to our presenting sponsor, Statsig. Statsig built a unified platform that enables the best of both cultures: continuous shipping and experimentation. Feature flags let you ship continuously with confidence. Roll out to 10% of users. Catch issues early. Roll back instantly if needed. Built-in experimentation means every rollout automatically becomes a learning opportunity, with proper statistical analysis showing you exactly how features impact your metrics. And because it's all in one platform with the same product data, analytics that should replace everything, teams across your organization can collaborate and make data-driven decisions.
Companies like Notion went from single-digit experiments per quarter to over 300 experiments with Statsig. They ship over 600 features behind feature flags, moving fast while protecting against metric regression. Microsoft, Atlassian, and Brex use Statsig for the same reason. It's the infrastructure that enables both speed and reliability at scale. They have a generous free tier to get started, and pro pricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com/pragmatic. And with this, let's get back to the Y2K event that Grady was talking about.
Yeah, I remember how stressful that time was leading up to year 2000. I think some movies even came out predicting, you know, how the world would collapse, but there was this fear of, like, will all these systems crash, and it started to become pretty intense in the few months leading up. So I was, you know, like a kid at that time. But when the year 2000 came, that was probably the most stressful new year, because you weren't kind of sure. You were hoping, you know, and then nothing happened and you're like, okay, it was just a hoax. So anyone who went through there kind of learned to not trust these predictions. But you're right, knowing what we know, there was so much work to make sure that that overflow did not hit at the wrong place.
Yeah. So here we are. Mentally put yourself in the first decade of the 2000s. It's a fun place because, well, yeah, there was the crash, but still so much fun stuff to do, so much great software to be written. We were still only limited largely by our imagination.
Now I'm going to pause for a moment and backfill with some history that I hadn't mentioned. We've been talking about software in general. There was a parallel history going on in AI, in which we saw also some generations. The first golden age of AI was in the 40s and 50s, where you had people such as Herbert Simon and Newell and Minsky in particular. The focus there was upon, gosh, we could build intelligence artificially using symbolic methods. So this was the first golden age, first great age of AI, and the ideas of neural networks were tried. The thing they built was the SNARC, which was the first vacuum tube artificial neuron. It took like five vacuum tubes to make a single neuron. And there was a report coming out of the UK at the time that said we're spending a lot of money here, but by gosh, it doesn't work. And so the first golden age ended when they realized you can't really build anything interesting. And furthermore, neural networks are a dead end. Largely a dead end because we didn't have the computational power to do them. We didn't have the algorithmic concepts, the abstractions, to know what to do with them once we had them at scale.
The second golden age of AI was really in the 80s, when you had people like Falcon come along and say, hey, there's another way of looking at it, and it's looking at it through rules. Thus was born the idea of machine learning. Things like MYCIN and the like came upon the scene, but there too we saw the AI winter come about. By the way, there was an interesting rise in hardware at the time. The Lisp machine, the Thinking Machine were all built during this time. Vibrant periods of time of computer architectures. So you see these kind of feeding into one another, but ultimately it failed because they didn't scale up. Once you got beyond a few hundred if-then statements, we simply didn't have a means of building inference engines that could do anything with them.
So here we are in exciting times again, the first decade of the 2000s. AI was kind of, you know, back in the back rooms. We still had a lot of cool things to do, and more and more distributed kinds of systems, plus fueling that also was the fact that software was now in the hands of individuals through personal computers. So the demand for software was even greater.
I would claim, and this may be a little controversial, we are in the third golden age of software engineering, but it actually started around the turn of the millennium. It's not now, but it's then. And the first indication of the rise of it is we saw a new rise in levels of abstraction, from individual components of our software programs to whole libraries and packages that were part of our platform. Oh, I need to do messaging. Well, I'm not going to do that on my own machine. I can go out to this library which does messaging. I need to manage this whole chunk of data. Let's, you know, use Hadoop or something like that. It wasn't around at the time, but the seeds were growing. So we again saw a growth in levels of abstraction from just simple programs to now subcomponents of systems, and that was the next great shift that happened, and our methodologies and our languages and all that began to follow. So the third golden age we've been in for several years already.
And not to get ahead of ourselves, what's happening with AI assistants and the like in the coding space is in many ways a reaction to the growth of those kinds of things, because we want to accelerate their use. We have so many of those kinds of libraries out there and not enough people know about them. We want to accelerate the use of them by having aids that help us do so. So that's the context in which I put AI agents such as Cursor and ChatGPT, in that they are in a way a follow-on to the forces that have already led us to this third golden age.
So we are now in a very vibrant time, but the problems are different from the first and second generations. What are the problems now? First, it's problems of: we have so much software. How do we manage it? And we have to deal with issues of safety and security. Can somebody sneak in something that I can't trust? How do I defend myself against that? It is so easy to inject something in the software supply chain. How do I prevent the bad guys from putting stuff inside there? How do I defend against it? The whole history behind Stuxnet and the like is a good one to show, you know, espionage and software. And so
all of a sudden the human issues that we had for much of the history of software we were insulated about because it was so much part of civilization, these human issues became front and center, clear and present for our world. And the other element is to the economic issues of it. We had now companies that were too big to fail. What would happen if a Microsoft were to go under? What would happen if a Google were to go under? They're so economically important to the world that the things they do, they sneeze and some part of the world catches a cold. And so the problems we have now in this third golden age of software are different than they were than the first and second generations, but equally as exciting.
And then last, we have the ethical issues. Because I can do this kind of software, it is possible for me to track where you are in every moment of the day. I can do that. Should I do that? Some will say yes, I should because, you know, it's a good thing for humanity. Others will say not so sure about that.
So, I like how you laid it on. It's very interesting, especially through both your experience and also sharing the history that I think a lot of us don't really reflect on, which is how it all started and just honestly how young it is. I mean, you know, like 70 or 80 years can be long depending on how old you are, but it's not even a generation, or barely a generation.
It's a couple of generations. Yeah.
But one thing that I'm seeing across the industry right now, which feels very like this setup makes sense, but one thing that kind of feels it contradicts it for a lot of software engineers today, is there seems to be an existential dread that is especially accelerating, especially over the winter break. What happened over the winter break is before the winter break, these AI LLMs were pretty good for autocomplete. Sometimes they could generate this or that. And over the winter break, I'm not sure if you played with some of, I have, with the new models, they actually generate really good code to the point that I'm starting to trust them. And
Yes.
As far as the history of software has been, my understanding is that software developers have written code and it's a hard thing to do. And a lot of us, you know, it takes years for us to learn, and to be excellent at it even longer. And so a lot of us are starting to have this really existential crisis of, okay, well, the machine can write really, really good software code. First of all, like WTF, and how did this happen over the last few months? And then the question is what next? It feels that it could shake the profession because I feel coding has been so tightly coupled to software engineering, and now it might not be. You know, looking at, I guess, you know, like taking a breath out first and looking through both the history and your, what is your take on what's happening right now?
Well, let me say that this is not the first existential crisis the developers have faced.
Tell us more.
They have faced the same kind of existential crisis in the first and the second generation. So that's why I look at this and say, you know, this too will pass when I talk to people who are concerned about it. Don't worry, focus upon the fundamentals because those skills are never going to go away. I had a chance to meet Grace Hopper. She was just delightful, you know, fireplug of a woman. Just amazing, amazing thing. For your readers, go Google Grace Hopper and David Letterman. She appeared on the David Letterman show and you'll get a sense of her personality.
Well, we're going to link in the show notes below.
She of course is the one who recognized that it was possible, here we are in the 50s, that it was possible to separate our software from our hardware. This was threatening to those who were building the early machines because they said, you know, gosh, you could never build anything efficient because you have to be tied so closely to the machines. And many in that field, and they wrote about it, expressed concerns that, you know, this is going to destroy what we do, and it should have. So we had here the beginnings of the first compilers. The same thing happened with the invention of Fortran, where people were saying, gosh, you know, we can write tight assembly language better than anybody else, better than any machine can kind of do. But that was proved wrong when we moved up a level of abstraction from the assembly language to the higher order programming languages. And so you had a set of people who were similarly concerned and distressed by the changes in levels of abstraction because they recognized that the skills they had in that time were going to go away and they were going to be replaced by the very thing they themselves created.
Now you didn't see as much of a crisis because there weren't that many of us back in that time frame. We're talking, you know, a few thousands of people. Now we're talking millions of people who ask, quite legitimately, the question, what does it mean for me?
So, I've had, as I'm sure you have had, a number of, you know, especially young developers come up to me and say, Grady, what should I do? Am I choosing the wrong field? Should I, you know, do something different? And I assure them that this is actually an exciting time to be in software because of the following reasons. We are moving up a level of abstraction, much like what happened in the rise from machine language to assembly language, from assembly language to higher order programming languages, from higher order programming languages to libraries. The same kind of thing happened, and we're seeing the same change in levels of abstraction, and now I as a software developer, I don't have to worry about those details. So I view it as something that is extraordinarily freeing from the tedium of which I had to do, but the fundamentals still remain.
As long as I am choosing to build software that endures, meaning that I'm not going to build it and I throw it away. If you're going to throw it away, do what you want. That's great. And I see a lot of people using these agents for that very purpose. That's wonderful. You're going to go off and automate things you could not have afforded to do today. And if you're a single user for it, then more power to you. This is the hobbyist era and the hobbyist side of software, if you will, much like we saw in the earliest days of personal computers where people will build these things. Great stuff. Great ideas will come from it.
I like the comparison. Yes.
Yeah. Great ideas will come from it. You know, people will build skills. We'll do things we could not have done before. We'll automate things that were economically not possible, but they're not going to endure necessarily, but still we will have made a valuable impact.
And I guess just like in the first era where personal people could buy it, you will have people come into the industry who have honestly nothing to do with it, and they might bring amazing ideas, right? Like back then, you know, a school teacher might have bought a personal computer. Today I just talked to my neighbor upstairs, an accountant. She has instructed ChatGPT to build some Apps Script to help their accounting team's process a bit better because she knows how that thing works. Nothing to do with software, but now creating their own personal throwaway software, by the way.
Yes, absolutely. The same parallels, and I celebrate that. I encourage it. I think it's the most wonderful thing, which is why we are in this vibrant period. In the early days of the personal computer, the very same thing happened. You found artists drawn to especially the PC and the Amiga at the time. You found gamers who realized I've got a new medium for expression that I did not have before, and that's why it was a very vibrant time. The same thing is happening. And so much of the lamenting of, oh gosh, we have an existential crisis, are those who are narrowly focused upon their industry, not realizing that what's happening here is actually expanding the industry. We're going to see more software written by people who are not professionals. And I think that's the greatest thing around because now we have software much like in the counterculture era of the personal computer. The same thing is happening today as well.
I like what you're saying. However, one, however [laughter], however one thing that I also pay attention to, one person I pay attention to is Dario Amodei, the CEO of Anthropic. And the reason I pay attention to him is I tend not to pay attention to CEOs, but he actually said about a year ago, he said something interesting. He says he thinks most code will be generated by AI, about 90% of it, maybe in a year, and then more. And we thought that's silly, and then he was right, and code was generated. And now he said another thing, interesting, that sounded interesting, but the next one sounds scary. He said, I quote, software engineering will be automatable in 12 months. Now this sounds a lot scarier for reasons we know: coding is a subset of software engineering, but he said this. What is your take on this? And you've had a strong response already. So,
I have one or two things to say about it. So, first off, I use Claude. I use Anthropic's work. I think it's my go-to system. I've been using it for problems with JavaScript, with Swift, with PHP of all things, and Python. So, I use it and it's been a great thing for me, primarily because, you know, there are certain libraries I want to use. Google search sucks. Documentation for these things sucks. And so I can use these agents to accelerate my understanding of them.
But remember also I have a foundation of at least one or two years of experience in these spaces, okay, a few decades, where I sort of understand the fundamentals. And that's why I said earlier that the fundamentals are not going to go away, and this is true in every engineering discipline. The fundamentals are not going to disappear. The tools we apply will change.
So Dario, man, I respect what you're saying, but recognize also that Dario has a different point of view than I do. He's leading a company who needs to make money, and it's a company who, he needs to speak to his stakeholders. So outrageous statements will be said like that. I think he said these kind of things at Davos, if I'm not mistaken.
It was very, yes.
And I'd say politely, well, I'll use a scientific term in terms of how I would characterize what Dario said and put it in context. It's utter... that's the technical term, because I think he's profoundly wrong, and I think he's wrong for a number of reasons.
First, I accept his point of view that it's going to accelerate some things. Is it going to eliminate software engineering? No. I think he has a fundamental misunderstanding as to what software engineering is. Go back to what I said at the beginning. Software engineers are the engineers who balance these forces. So we use code as one of our mechanisms, but it's not the only thing that drives us. None of the things that he or any of his colleagues are talking about attend to any of those decision problems that a software engineer has to deal with. None of those we see within the realm of automation. His work is primarily focused upon the automation at the lowest levels, which I would put akin to what was happening with compilers in these days. That's why I say it's another level of abstraction. Fear not, O developers. Your tools are changing, but your problems are not.
There's another reason why I push back on what he's saying. And that is if you look at things like Cursor and the like, they have mostly been trained upon a set of problems that we have seen served over and over again. And that's okay. Much like I said in the first generation, first golden age, we had a certain set of problems, and so libraries are built around them. The same thing is happening here. If I need to build a UI on top of CRUD, it's sub winter or some web-centric kind of thing, I can do it. And much like your friend, more power to them. They can do it themselves because the power is there to do so. They're going to, you know, probably not build a business around it. Some small percent of them might do so. But it's enabled them to do things they could not do before because they're now at a higher level of abstraction.
What Dario neglects, and I used a bit of a paraphrase from Shakespeare: there are more things in computing, Dario, than are dreamt of in your philosophy. The world of computing is far larger than web-centric systems of scale. So we see many of the things applied today on these web-centric systems, and I think that's great and wonderful, but it means that there's still a lot of stuff out there that hasn't yet been automated. So we keep pushing these fringes away. So I told you those stories at the beginning because history is repeating itself, or some will say history is rhyming again. The same kinds of phenomena are applying today, just at a different level of abstraction.
So that's the first one. The world of software is bigger than what he's looking at. It's bigger than just software-intensive systems. And then second, you know, if you look at the kinds of systems that most of these agents deal with, they are in effect automating patterns that we see over and over again for which they have been trained upon. Patterns themselves are new abstractions that are in effect not just single algorithms or single objects, but they represent societies of objects and algorithms that work together. These agents are great at automating generations of patterns. I want to do, you know, this kind of thing, and I can tell you in English because that's how I describe the pattern. So anyway, that's why I think he's wrong. More power to him. But, you know, I think this is an exciting time more than things to worry about existentially.
Let me offer another story with regards to how we see a shift in levels of abstraction. English is a very imprecise language, full of ambiguity and nuance and the like. So one would wonder, how could I ever make that, you know, a useful language? And the answer is we already do this as software engineers. I go to somebody and say, hey, I want my system to do this. It kind of looks like this, and I give them some examples. I do that already. And then somebody goes and turns that into code. We've moved up a level of abstraction to say, I'd like it to do this.
I'll give you a concrete example. I'm working with a library I'd never touched before. It's the JavaScript D3 library, which allows me to do some really fascinating visualizations. I go off and search for a site called Victorian Engineering Connections. It's just this lovely little site where the gentleman did this for a museum, Andrew, and you can, you know, put in a name like George Boole and you see his name, you find things about him, and you find his social network around him, and you can go touch it and explore. It's very, very cool. And I said, "I want that kind of thing, but my gosh, I don't know how to do that. So, what can I do?" He gave me his code. I realized it uses the D3 library. I knew nothing about the D3 library. So, I said to Cursor, "Go build me the simplest one possible. Go do it out of, you know, five nodes and show me." So I could then study the code. And then I could say, "Well, what I really wanted to do is this. Go make the nodes look like this, depending upon their kind."
So, just like I would do with a human, I was expressing my needs in an English language that now all of a sudden I didn't need to labor to turn that into reality. I could simply have a conversation with my tool to help me do that. So, it reduced the distance between what I wanted and what it could do. And I think that's great. That's a breakthrough.
But remember, as I said to Dario, this only works in those circumstances where I'm doing something that people have done hundreds and hundreds of times before. I could have learned it on my own. As Feynman would have said, you know, go do it yourself because then that's the only way you're going to understand. And my reaction is that's great, but there's so much in
...the world I'm curious about. I can't understand it all. Let's decide what I want to do. So go do it for me. So that's why I say these kinds of tools are another shift in the levels of abstraction, because they're reducing the distance from what I'm saying, my English language, to the programming language.
Last thing I'll say is that, what do we call a language that is precise and expressive enough to be able to build executable artifacts? We call them programming languages. And it just so happens that English is a good enough programming language, much like COBOL was, in that if I give it those phrases in a domain that is well enough structured, it allows me to have good enough solutions that I, who know those fundamentals, can begin nudging and cleaning out the pieces. That's why the fundamentals are so important.
And speaking of history rhyming, one thing that happened in both the first age and the second golden age, or as we jumped abstractions, or every time we had an abstraction, is some skills became obsolete and then there was a demand for new skills. For example, when we went from assembly level, the skill of knowing the instruction set of a certain board and knowing how to optimize it, that became obsolete in favor of thinking at a higher level. In this jump right now, where I think it's safe to say we're going to: we do not need to write any more code, and the computer will do it pretty well, and we'll check it and tweak it. What do you think will become obsolete and what will become more important as software professionals?
Great question. The software delivery pipeline is far more complex than it should be. My gosh, just getting something running is hard if you have no pipeline. If you're within a company such as a Google or a Stripe or whatever, you have...
You have a huge infrastructure around them.
A custom one.
Yes.
Yeah. A custom one. Yes. And so there is low-hanging fruit for the automation of those. I mean, I don't need a human that fills in the edges of those kinds of things. By the way, I'm talking about, in effect, infrastructure as software. It's not just raw lines of code. So this is low-hanging fruit where we could begin seeing these agents, where I say, "Hey, I want you to go, gosh, I don't know, spin up something for this part of the world. I don't want to write the code for that stuff because it's complex and messy. I'd rather use an agent that helps me do it." So there's a case where I think you're going to have the loss of jobs in those places where it's messy and complex, because the automation has clear economic and, frankly, value in terms of security.
That's a place where people are going to need to reskill. In the building of simple applications and the like, well, I think people who had skills in saying, "I want to build this thing for iOS or whatever," they're going to lose some jobs, because frankly people could do it just by prompting it. That's great. That's fine, because we've enabled a whole other generation of folks to do things that professionals did in the past, exactly what happened in the era of PCs themselves.
What should these people do? Move up a level of abstraction. Start worrying about systems. So the shift now, I think, is less so from dealing with programs and apps to dealing with systems themselves, and that's where the new skill set should come in. If you have the skills of knowing how to manage complexity at scale, if you know as a software engineer how to deal with all of these multiple forces, which are human as well as technical, your job's not going to go away. If anything, there will be even greater demand for what you're doing, because those human skills are so rare and delicate.
So you mentioned the importance of having strong foundations, and you've previously said, I'm actually quoting you, "The field is moving at an incomprehensible pace for people without deep foundations and a strong model of understanding." What foundations would you recommend people look at? Both students, people who are at university studying or looking for their first job, and also software professionals who now actually want to go back and strengthen those foundations, that will be helpful.
I find my happy place, if you will, my sweet space that I retreat back to when I'm faced with a difficult problem, is back in systems theory. Go read the work of Simon and Newell in The Sciences of the Artificial. There's a whole set of work that's come out on complexity and systems from the Santa Fe Institute. It's those kinds of fundamentals of systems theory that ground me in the next set of things which I want to build.
I think I mentioned to you in one of our previous discussions, I was doing some really interesting work on NASA's mission to Mars. We were faced with an issue of saying, "Hey, we want to have people go off on these long missions. We want to put robots on the surface of Mars." And so I was commissioned to go off and think about that for a while. And in effect, I realized NASA wanted to build a HAL. And you'll notice I've got a HAL above me here.
Yes.
I'm a great one for history. This is my sword of Damocles that passes behind me. If you know the history behind the sword of Damocles, the king Damocles, he was always kept humble because at his throne there was a sword right above him on a thread. So he felt constantly uneasy. And this is why I have HAL behind me as well. For some reason, NASA didn't want the kill-all-the-astronauts use case. Don't understand why, but we threw that one kind of out.
But if you look at the problems there, this is a systems engineering problem, because you needed something that was embodied in the spacecraft. Much of the kind of software we have today in AI is disembodied. The Cursor, the Copilot and the like, they have no connection to the physical world. So our work was primarily in embodied cognition.
Around the same time, I was studying under a number of neuroscientists, trying to better understand the architecture of the brain. And here's where the fundamentals of that came together for me, because I began to realize there are certain structures we see in systems engineering that I can apply to the structure of these really large systems. Taking ideas of Marvin Minsky's Society of Mind, which is a way of systems architecting multiple agents. We're in agent programming now, which I think people are just beginning to tap upon, how those things apply. They need to go look at systems theory, because that problem has been looked at with multiple agents already. Go read Minsky's Society of Mind. You'll see some ideas that will guide you there in dealing with multiple agents.
The ideas from Baars, which were manifest in early AI systems such as HEARSAY. The ideas of global workspaces, blackboards and the like, another architectural element. The ideas of subsumption architectures from Rodney Brooks. His was influenced by biological things. If you look at a cockroach, a cockroach is not a very intelligent thing. But we know there's not a central brain in it, and yet it does some magnificent things. We have been able to map the entire neural network of the common worm. We're not flush with evil worms running around the world. There's something else going on there.
But biological systems have an architecture to them. So to go back to your question, by looking at architecture from a systems point of view, from biology, from neurology, from systems in the real world, as Herbert Simon and Newell did, this is what's guiding me to the next generation of systems. And so I would urge people looking at systems now to go back to those fundamentals. There is nothing new under the sun in many ways. We've just applied them in different ways. Those fundamentals in engineering, they're still there.
And then as closing, you gave some really good recommendations to read, to ponder, to educate yourself, and get ideas that will probably be useful in this new world, especially as we're going to have a lot more agents. For example, I just heard that agents will be part of Windows 11, the operating system. So they will be everywhere. But looking back at the previous rises of abstractions and also the previous golden ages, the people who did great at the start of a new golden age or at the start of a new abstraction, even if they were not amazing at the previous one, what have you seen those people do? Based on this historical lesson, what would you recommend if we were just to kind of copy successful things that people did? Because I feel this is an opportunity as well, right? We have this rise of abstraction. A lot of people will be paralyzed, but there will be new superstars being born who will be basically riding the wave, and they will be the experts of agents, of AI, of building these new and a lot more complex systems than we could have done before.
So, as I alluded to earlier, the main thing that constrains us in software is our imagination. Well, actually, that's where we begin. We're actually not constrained by imagination. We can dream up amazing things, and yet we are constrained by the laws of physics, by how we build algorithms and the like, ethical issues and the like. So what's happening now is that you are actually being freed, because some of the friction, some of the constraints, some of the costs of development are actually disappearing for you. Which means now I can put my attention upon my imagination to build things that simply were not possible before. I could not have done them because I couldn't have raised a team to do them. I couldn't have afforded that. I could not have done it because I couldn't have had the reach in the world as I do now.
So think of it as an opportunity. It's not a loss. It'll be a loss for some who have a vested interest in the economics of this, but it's a net gain, because now all of a sudden these things unleash my imagination to allow me to do things that were simply not possible before in the real world.
This is an exciting time to be in the industry. It's frightening at the same time, but that's as it should be. When there's an opportunity where you're on the cusp of something wonderful, you should look at the abyss, and you can either take a look and say, "Crap, I'm going to fall into it." Or you can say, "No, I'm going to leap and I'm going to soar. This is the time to soar."
Grady, thank you so much for giving us the overview, the outlook, and a little bit of perspective. I personally really appreciate this.
And I hope I offered some hope as well.
I think you definitely did. This was a really inspiring episode. Thank you, Grady.
One thing that really stuck with me was when Grady pointed out that developers have faced this exact existential crisis before, multiple times, in fact. When compilers came along, assembly programmers thought their careers were over. When high-level languages emerged, the same fear ripped through the industry. And each time, the people who understood what actually was happening, that it was just a new level of abstraction, came out ahead. This historical lens is something that I think we often miss when some of us are caught up in the day-to-day anxiety of new AI capabilities. I don't think we're at the end of software engineering, and neither does Grady. We're at the beginning of another chapter, and if history is any guide, it's going to be a pretty exciting one.
If you found this episode interesting, please do subscribe in your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks, and see you in the next one.
Article published