The third golden age of software engineering – thanks to AI, with Grady Booch

Some people worry that AI writing surprisingly good code could mean the end of software engineering. But Grady Boosh 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 Aymodai'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 seasoned sponsors. Great.

0:00

It's great to have you back on the podcast again.

1:05

Thanks for having me. Aloha.

1:07

So touching.

1:09

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?

1:10

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. But 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 Virtalbri 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 sciencey 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. 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. 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.

1:29

And.

5:44

And the difference between the hardware and the software was completely indistinguishable. You know, putting plugs in a plug board, as was 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 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. 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.

5:45

Yeah, like 70, 80 years ago.

6:48

Wow.

6:49

Yeah. Yeah, exactly. So this is this. We're an astonishingly young, young industry. If you were to take Carl Sagan's cosmic calendar and. 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, in 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 and that we were building things that were, you know, difficult to understand, that we're trying to manipulate our machines in some cunning ways. But it was complexity that by today's standards was, you know, laughably simple. We could, you know, 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, 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.

6:50

And then this first generation, like in timeline, where would you put it?

9:11

Roughly?

9:15

Timeline, 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 Yorden, 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 to 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 key punch the solutions, people would operate the computers. And again, this was largely driven by economic reason 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, you know, floors of offices with people doing accounting and payroll and like that. And this was the low hanging fruit, because now all of a sudden we could accelerate those processes and, 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 was 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 as the concentration was the things that the general public would see a lot of stuff 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 thus far 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, we saw researchers such as David Parnas who were coming on the scene, ca, Ahar Dykstra and others for beginning to look at the formalisms of these systems and looking at treating software development as actually a formal mathematical activity.

9:16

Grady just mentioned formal methods and formal mathematics in 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 seasoned 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 is high on 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.

13:09

Strategies for this new era.

14:22

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.compragmatic sonarsummit with this, let's get back to Grady and treating software development as a form of mathematical activity.

14:24

And you saw the rise of, I said distributed in real time systems, primarily in the defense world. So from whirlwind it began a system called SAGE, the semiautomatic ground environment which came about during the six during the 50s and six in 60s and indeed the last one was decommissioned I think in the 1990s. This was based upon the threat of Russia. This is, you know, pre, pre missiles Russia would send a fleet of bombers over the Arctic and and invaded the United States. So thus was born the DEW line, the distance early warning system across Canada. And all that data was then fed into a series of systems called sage, the semiautomatic 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.

14:44

Basically the military was the biggest spender in soft and research and moving the industry forward. Right. Because they have to.

15:42

Absolutely. Correct. They had to because it was a clear and present threat. And so a lot of the innovation was happening to the defense world. As I think I passed this phrase on to you in the documentary I'm working on a 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 micro miniaturization, this all came from government funding in these cases. So we owe a lot to the Cold War.

15:48

This phase was this still the first golden age? We passed the first golden age.

16:32

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 and 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 are 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 you know, people didn't know what to do about it.

16:35

Can you help us understand or take us back what, what was the crisis about? What were people like, kind of like saying, oh my gosh, this is the problem?

18:40

Yeah, the problem was, to recap was software was clearly useful, there were economic incentives to use it, and yet the industry could not generate quality software of scale Fast enough.

18:47

I see, I see. So it was both expensive slow and not good.

19:01

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, this is. 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, you know, crashes, that kind of thing. So the nature of the problems have changed, and they do in every. Every golden age.

19:06

It's fascinating that this thing existed, you know, living in our current reality.

19:33

Yes, yes. It's a very different world itself, but it was. 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 in software. Being such a fungible elastic fluid medium meant that we were primarily limited just by our imagination. You add to this then micrometerization. Why did integrated circuits come about? Why did Fairchild come about and establish Silicon Valley be the basis for it? It's because the transistor who was the first customer of the Fairchild, it was the Air Force, primarily for their man 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. The economic basis for the whole infrastructure. We're doing it where it was possible to start doing these things at scale. 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.

19:37

Back then when software was so much smaller than today.

21:05

Wow.

21:08

Absolutely. It's incredible. In languages like languages like Jovial was a very popular one, a 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 CA are horror and Dykstra and Verth led to this discipline of applying mathematical rigor to our languages. And so the idea of, you know, 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, something like that, which was an attempt to remove the number of language 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 Gaugin and the ideas of information hiding from Day Parnas. Separation of concerns. The ideas. Today we would call it 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. 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 begotten C and Unix and the like, which was becoming incredibly important. But there was this crazy researcher at the time by the name of Jarnest Stroustrup who was saying, wow, you know, 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, you know, C's got problems with it. Let's see if we can move about. So it was happening in the background in academia and in, 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. He has a dialogue between two people who are, you know, talking about how I look at the world. And. And one of them says we should look at the world in terms of its processes.

21:08

This is the ancient Greek philosopher from.

23:49

Like before Christ, that guy, that Plato.

23:52

Wow. So he brought up some parallel ideas.

23:55

He brought up the ideas of the dichotomy of looking at the world for 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, 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 Adam came from Greek terms and that terminology. So the idea of looking at the world and looking at. 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. 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. 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, you know, 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, easy things. Yeah, so. 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 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.

23:58

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 AI Generating a lot more code a lot faster. And this brings us nicely to our seasoned 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 discuss how to implement authentication for customers when their users authenticate across several platforms using work os. 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 work OS wants. The work OS 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 work OS 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 engineered teams don't have to the same planning goes into all workos products and customers get all the benefit. Learn more@workaras.com and with this, let's get back to Grady and how the second golden age of software engineering came about.

26:16

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 from a distributed kind of way, now come onto the scene. Because what was happening around that same time is the fruits of micro miniaturization came to be. And it led us to the personal computer.

27:56

This was because transistors, right, and the breakthroughs in like electronics and, and precisely.

28:22

And you know, this too was a vibrant time because you had, you know, you had hobbyists who could put these things together and, and build them from scratch. And there were no personal computers at the time.

28:28

Was this the first time that hobbyists like meaningfully get their hands on it in the history of computing? Really?

28:39

I think at scale, yes. You had, you had hobbyists such as Pascal back at 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 of, especially in the United States, you had 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 equivalent, this is before Fry's, and buy these things. They were just, they were 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, which 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, this drive toward, you know, power to the people and you know, let's, you know, love, like make love, not war, these kinds of things. This is the era of Stuart Brand, the era of, of the Murray Pranksters and the like. And that led to things like the. Well, which was the very first social network which was. Today we call them bulletin boards, which grew up in, in Silicon Valley. Quick aside. Stewart, just a lovely fellow. He was actually mentioned as one of the merry Pranksters in, in the book about, 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.

28:46

Yeah, and Astronaut Press is publishing this actually, so I'll leave a link in the show notes below. It looks like a really nice book and Stride Press is known to produce excellent quality. So I'm actually excited to look into this.

30:51

Yeah, it's a great, 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, 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 envisioned military space shuttle and I was part of that program as well.

31:03

It was great.

31:47

It was a fun place to be because we'd have launches like twice a week. Was pretty cool. You'd run up and say, wow, look at that. It was pretty wild. At the building in which I work, I had to evacuate whenever there was a building ever a launch because it was a Titan launch. The Titan launch pad was really close to us. And if it had blown up on the light launch pad, it would have. It would have blown up our building, which would been really Annoying. So, yeah, good. And one other, one other quick story you could always tell when it was the secret launches going off the secret small 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 combine the objects and the processes together. And it worked. My gosh, it'll label 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 persistent 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 object proved to be very effective because it allowed us to attack software, the software complexity problem, in a new and new and novel way. And so much like the first Golden Age, this was also a very vibrant time in, I would say, the. The 80s and 90s where you had people such as the Three Amigos, me, Ivar Galkason, he and Jim Rumbaugh. You had Pete Code, you had Larry Constantine was back on the scene, Ed Yordan 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 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, is it's. 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? These kinds, 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, the, the world of business systems, IBM Share came to be. Schare was a customer organized group that literally shared software among what others. Totally.

31:47

And this was in the first golden age, right?

35:42

This first golden age, right.

35:43

So this was kind of like a primitive or like, I mean looking back, a more primitive way of just like packaging stuff into like, yeah, related may that be sorting algorithms or as you said, IBM. IBM was also distributing just like functions and things like that.

35:45

IBM wasn't doing it. It was perfect. It was completely public driven. IBM supported it, but it was, they facilitated 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, was laid 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 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 move 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 was 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, they produced this addition to HTML that allow 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 became via HTML protocols. HTTP protocols became a medium at a higher level of abstraction for passing information and, 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, the beginnings of the platform era, which is, you know, what Bezos and, and others have really brought us to, where jumping ahead in our current age where you have these islands which are sort of formed by all sorts of APIs around them. But it was the second golden age is they were being born.

35:58

And when you say platforms, what do you mean? When you say the rise of platforms, what, how do you think of a.

38:50

Platform 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.

38:55

Yes, not a slight fee.

39:15

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?

39:17

My first email address I got sometime in maybe 2005, 6. It was still very fresh when Gmail launched. But when did you get your first email address?

39:56

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, 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, we had, by that time 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.

40:06

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, when 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 representing sponsor statsig. Statsig built a unified platform that enables the best of both cultures. Continuous shipping and experimentation. Feature flags yet you ship continuously with confidence, roll out to 10% of users, catch issues early rollback 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 session, 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 shipped over 600 features behind feature flags, moving fast while protecting against metric regression. Microsoft, Atlassian and Brex use static 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 statsic.compragmatic and with this, let's get back to the Y2K event that Grady was talking about.

42:08

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 like a kid at that time. But when the year 2000, like that was probably the most stressful new year because you weren't kind of sure, you were hoping and then nothing happened and you're like, okay, it was just a hoax. So anyone who went through there like kind of learned to like not trust these prediction. But you're right, like knowing what. No, there was so much work. Right. To make sure, to make sure that that overflow did not like hit at the wrong place.

43:41

Yeah. So here we are. Mentally put yourself in the first, first decade of the 2000s is a fun place because. Well, yeah, the, 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 is the first golden age, first great age of AI and the ideas of neural networks were tried. The thing they built was the snark, 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, 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 Falgenbaum 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 a, 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, an exciting time again. 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 kind 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, 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 the time, but the seeds where it was 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 assistance 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 want to. We have so many of those kinds of libraries out there and not enough people who 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, 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 stuck necks and the like is a good one to show, you know, espionage in 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 in. 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, 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 it's, you know, it's a good thing for humanity. Others will say, not so sure about that.

44:22

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. If, I mean, you know, like 70 or 80 years can be long, depending on how old you are. But it is. It's not even a generation or a barely generation.

50:26

It's a couple of generations. Yeah.

50:46

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. I have, with the new models, they actually generate really good code to the point that I'm starting to trust them. And 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 looking at, I guess, taking a breath out first and looking through both the history and. What is your take on what's happening right now?

50:48

Well, let me say that this is not the first existential crisis the developers have faced.

52:08

Tell us more.

52:14

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 a delightful, you know, fire plug of a woman. Just amazing, amazing thing for your readers, go Google Grace Hopper and David Letterman. And there's this. She appeared on the David Letterman show and you'll get a sense of her personality.

52:15

We're going to link it in the show notes below.

52:46

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 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 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 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, rarer and the hobbyist side of software, if you will. Much like we saw in the earliest days of personal computers where people would build these things. Great stuff. Great ideas will come from it.

52:48

I like the comparison. Yes.

55:40

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.

55:42

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, school, 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 teams 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.

55:56

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 in 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.

56:26

I like what you're saying. However, one thing that I also pay attention to, one person I pay attention to is Dario Amodei, the CEO of Antropic. 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.

57:23

Yes.

57:50

And now he said some. 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 more scarier for reasons we know, coding is a subset of software engineering. But he said this. What is your take on, on this? And you've had, you've had a strong response already.

57:51

So.

58:11

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, it's my, it's my go to system. I've been using it for problems with JavaScript, with Swift, with PHP, of all things, in Python. So I use it and it's, 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 suck. 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.

58:13

I'm not mistaken. It was very. Yes.

59:29

And I'd say politely, well, I'll use a scientific term in terms of how I'd characterize what Dario said and put it in context. It's utter bullshit. 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, within the realm of automation. His work is primarily focused upon the automation at the lowest levels, which is 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 subwinter 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 percentage 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 have. 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. Software is bigger than this 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, as 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 distraction 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. 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 Boolean, 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, they wanted. What 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 I, 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 go, you know, 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, you know, 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 up the pieces. That's why the fundamentals are so important.

59:32

And speaking of history rhyming, one thing that happened in both the first stage 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 from, we do not need to write any more code and the computer will do it pretty good and we'll check it and tweak it. What do you think will become obsolete and what will become more important as software professionals?

1:06:11

Great question. The software delivery pipeline is far more complex than it should be. That, 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 about, around them.

1:06:51

A custom one. Yes.

1:07:12

Yeah, 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 kind of things. By the way, I'm talking about, in effect, infrastructure is software.

1:07:14

Y.

1:07:26

It's not just, you know, not just raw lines of code. So this is low hanging fruit where we could begin seeing these agents that say, hey, you know, I want you to go, you know, gosh, I don't know, you 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, you know, 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, you know, people who had, who had skills in saying, I want to build this, you know, thing for iOS or whatever, they're going to lose, you know, they're going to lose some jobs because frankly, people could do it just by, you know, prompting it. That's great, that's fine. Because we've enabled a whole nother 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.

1:07:27

So you mentioned the importance of having strong foundations and you 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 to 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.

1:09:07

I find my happy place, if you will, my sweet space that I retreat back to when I'm faced with a difficult problem. Back into 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 system theory that ground me in the next set of things in 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, you know, we want to, you know, 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, this is, 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, you know, constantly, you know, unease. 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, 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 co pilots and the like. They have no connection to the physical world, though 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 some certain structures we see in systems engineering that I can apply to the structure of these really large systems. Taking ideas of Marvin Minsky, Society of Mind, which is a way of, 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 Society of Mine. You'll see some ideas that will guide you there in dealing with multiple agents. The ideas from Bears of which was 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, from Rodney Brooks. His was influenced by, by biological things. If you look at a cockroach, a cockroach is not a very intelligent thing, but we know there's, there's, 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, you know, evil worms. Running around the world. So 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 or Newell did, this is what's guiding me to the next generation of systems. And so I would urge people looking at systems now 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.

1:09:34

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, just heard that agents will be part of Windows 11 and 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? And based on this historical lesson, what would you recommend? If we were just trying to, to kind of copy successful, you know, things that people did? Because I feel this is an opportunity as well.

1:13:27

Right.

1:14:13

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 complex, a lot more complex systems that we could have done before.

1:14:13

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 did before. So think of it as an opportunity. So 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 say. 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. And this is the time to soar.

1:14:28

Grady, thank you so much for giving us the overview, the outlook, and for a little bit of perspective. I personally really appreciate this and I.

1:16:00

Hope I offered some hope as well.

1:16:08

I think you definitely did. This was a really inspiring episode.

1:16:10

Thank you Grady. One thing that really struck with me was when Grady pointed out that developers have faced this exact existential crisis before. Multiple times in fact.

1:16:14

Fact.

1:16:23

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, they 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 has any guide, it's going to be a pretty exciting one. If you found this episode interesting, please do subscribe on 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.

1:16:24