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 Buch disagrees and says that we are entering the third golden age of software engineering. Grady Buch 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 Unifi 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 the history of 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 is all tying into this? >> Well, the very term software engineering did not come to be until Margaret Hamilton was probably the first to uh anoint it. uh she at the time had just left the man 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 uh 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. Um, 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 engineeringish 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 funible and elastic and fluid and yet we still have the same kinds of forces upon us. Uh 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 vertalry 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 forier transform. We knew the theory but until Forier transforms could be turned into something computational we couldn't pro progress. And there are also other constraints upon us not just these scientific ones and and the computer sciency ones but constraints such as the human ones. Uh 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 uh such as we see with you know 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 from the lens of looking backward there are at least two identifiable major epics 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. you know, putting plugs in a plugboard 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 sh 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. >> Yeah. Like 70 80 years ago. Wow. >> Yeah. Yeah. Exactly. So this is this were an astonishingly young young industry. If you were to take Carl Sean's cosmic calendar and uh and put software in it, we would be in the last few nanoconds of that cosmic calendar. It would be less than a blink of an eye. But anyway, as software began 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. uh complexity in that we were building things that were, you know, difficult to understand, that were 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 forran 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 and this first generation like in timeline where would you put it roughly >> timewise I'd put it in the late 40s to the late7s or thereabouts >> and that's what dominated that time frame. So the figures you would see would be uh Ed Jordan, Tom DeMarco, Larry Constantine. This is when uh ERP uh 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. You people who would then program it, people who would key punch the solutions, people would operate the computers. And again this was largely driven 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. Um 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 lowhanging 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 and mathematical and 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 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 this were were not real time. And so we saw the rise of 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 of software development at the time with the things on the fringes. We saw we saw researchers such as David Parnes who were coming on the scene CAR Dyster and others were forbidding to look at the formalisms of these systems and looking at treating software development is 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 Sonar Cube, 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 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/sonarssummit. With this, let's get back to Grady and treating software development as a form of mathematical activity. And you saw the rise of 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 six during the 50s and60s 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 premissiles Russia would send a fleet of bombers over the Arctic and invade the United States. So thus was born the D line, the distance 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 uh in soft 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 to 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 Jakard's loom. So yeah, a lot of the things we take for granted today like the internet uh like uh micro miniaturaturization, 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. Yeah, >> 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, fungeible 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 uh software engineering uh 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. 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? >> 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. >> I see. I see. So it it was both expensive, slow and 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 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. >> It's fascinating that this thing existed, you know, living in our our current reality. >> Yes. Yes. It's a very different world itself. But it was a 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 funible elastic fluid medium meant that we were primarily limited just by our imagination. You add to this then micro miniaturaturization. Why did integrated circuits come about? Why did Fairchild uh come about and and establish Silicon Valley be the basis for it? It's because of the transistor. Who was the first customer of the Fairchild? It was the Air Force primarily for their men 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 for doing it where it was possible to start doing these things at scale and of of course we knew that begat integrated circuits that begat personal computers and so on. So here we are now in the late '7s 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 languages like Jovial was a very popular one. a jovial kind of a play on words for cobalt and and the like. We had the rise of algal which was not a military language but the formal forces of caor and dystra 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 '7s 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 uh abstract data types uh from Galan and the ideas of information hiding from Dave Parnes uh separation of concerns uh the ideas today we would call it clean programming clean coding but it's the ideas of literate programming from canuth 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 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 Bjarn Struestrip 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 what 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 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 he 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 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 atom came from Greek terms and 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 Parnis and and others and the 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 uh the inventor of Forran came into be. After forran 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 the 70s now in which uh the ideas of functional programming came to be I had a chance to interview him a few a few months before he passed away and I asked 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 things. >> 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. 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 season sponsor work OS. Work 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 work 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 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 works absorbs so product and engineering teams don't have to. The same planning goes into all work products and customers get all the benefit. Learn more at workowwise.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 building big enough software and I would add to this the things that came about in in the defense world which were the desire and an obvious value in building systems from a distributed kind of way. Now come on to the scene because what was happening around that same time is the fruits of micro miniaturaturization came to be and it led us to the personal computer. This was because transistors, right? And and the breakthroughs in in like electronics and and >> precisely 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. Was this the first time that hobbyists could actually like meaningfully get their hands on it in in the history of computing? Really? I think at scale, yes, you you had 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 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 or the Fry equivalent. This is before Fries 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 doormouse 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 make love not war these kinds of things. This is the era of Steuart 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, Stuart just a lovely fellow. He was actually mentioned as one of the merry pranksters in uh in the book about uh 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 maint associated with them. Anyway, here we are um late 70s early 80s uh also a very vibrant time because there's a lot of cool stuff that could be done. >> Yeah. And and it's Strike Press is publishing this actually. So, uh, I'll 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. >> 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. Um I was at the time working at Vandenberg Air Force Base on uh missile systems and space systems. Uh there was 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 it was pretty wild. At the building in which I work, I had to evacuate whenever there was a building, ever 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 it would have blown up our building, which would have been really annoying. So, yeah. Good stuff. >> And one other 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. uh the 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 the objects and the and the uh 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. Uh go out to the computer history museum and go look at the software for for Mac Write and Mech Paint. 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 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. Uh 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 Gakasen, uh and Jim Rumba, you had Pete Code, you had Larry Constantine was back on the scene, uh Ed Jordan was back on the scene, uh 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. Uh 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 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? uh these kind 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 be. This is when at least in the the the world of of business systems IBM share came to be. Share was a customer uh organized group that literally shared software among one anothers. Totally. >> And this was in the first golden age, right? >> This is the first golden age, right? >> So 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 or as you said IBM 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 60s7s 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 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 uh library for, you know, writing to these new fangled 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 serviceoriented 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 uh 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 uh the internet became via HTML protocols, HTTP protocols became a medium at a higher level abstraction for passing information and and processes around. But there was a need to package it up. So thus was born serviceoriented architectures, SOAP, the serviceoriented architecture, serviceoriented 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 sort of APIs around them. But it was in the second golden age is they were being born. And when you say platforms what do you mean when you say the rise of platforms? What how do you think of a platform? AWS would be a good one. Uh 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 uh 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 SAS companies. So, let's look at the the late '9s, early 2000s. Also a vibrant time, much like the first golden age. We had the growth of the internet. Uh, when did you get your first email address? >> My first email address I got sometime in maybe 2005 six. 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 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. 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 guard rails that can make things break or putting in more guard rails for stability but then slowing down in shipping speed. Well, there's a third way which leads us nicely to our presenting sponsor stats. Static 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 roll out 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 datadriven decisions. Companies like Notion went from single digit experiments per quarter to over 300 experiments with stats. They ship over 600 features behind feature flags, moving fast while protecting against metric regression. Microsoft, Atlashian, 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 pricricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to stats.com/pragmatic. And with this, let's get back to the Y2K event that Grady was talking about. Yeah, I I I I remember how stressful that time was leading up to year 2000. I think some movies even came out uh predicting, you know, h how the world would collapse, but there was this fear of like will all these systems crash and it it it started to become pretty intense in in the few months leading up. So I I I was, you know, like a 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, you know, and then nothing happened and you're like, okay, it was just a hoax. So anyone who who went through there uh like kind of learned to like not trust these predictions. But you're right like knowing what know there was so much work right to make to make sure that that overflow did not like hit at the wrong place. Yeah. So here we are mentally put yourself in the 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 was the first golden age first great age of AI and the ideas of neural networks were tried. The 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 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 to know what to do with them once we had them at scale. The second golden age of 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 uh things like m 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 list 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 in exciting time again two first decade of the 2000s. AI was kind of you know back in in the back rooms. we still had a lot of cool things to do and uh 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 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 chat tpt in and 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 uh 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 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, 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. If if I mean you know like 70 or 80 years can be long depending on how old you are but it is it's it's not even a generation or barely 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 ex existential dread that is especially accelerating especially over the winter break. What happened over the winter break is before the winter break, these AI uh LLMs were 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 Yeah, 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? this it feels that it could shake the profession because I feel coding has been so tightly coupled to software engineering and and now it might not be you know looking at I guess you know like taking a breathe out first and looking through the both the history and and your 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 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. >> 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 a 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 forran 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 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 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 ly 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 and 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, school school teacher might have bought a personal computer. Today I I just talked to my neighbor upstairs, an accountant. She has instructed Chad GBT to build some appcript to uh 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. >> 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 of the personal computer, the very same thing happened. You found artists drawn to especially the PC and the amigga 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 in the counterculture era of of the personal computer. The same thing is happening today as well. I like what you're saying. However, one however however one one thing that I also pay attention to uh one person I pay attention to is is Dario Amod the CEO of Antropic. And the reason I pay attention to him is I I try 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 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. So, >> u I have one or two things to say about it. So, first off, I use Claude. I use Anthropics 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, uh with PHP of all things and 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 Daario man I I respect what you're saying but recognize also that Daario 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 it was very Yes. >> And and I'd say politely well I'll use a scientific term in terms of how I would characterize what Daario said and put it in context. It's utter uh that's the technical term because I think he's profoundly wrong and and he 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 abstraction. Fear not, O developers. Your tools are changing, but your problems are not. There's another reason why I 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 ccentric 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 abstraction. what Daario neglects and I used a a bit of a paraphrase from from Shakespeare. There are more things in computing Daario that 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 webric 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 where 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 exist 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. Though 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 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 Bool 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 they wanted would 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 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 Daario, 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 Fineman 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 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 Cobalt 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 the sec 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 for new skills. For example, when we from assembly level the the skill of like knowing how 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? >> Great question. The software delivery pipeline is far more complex than it should be. Uh 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. >> A custom one. >> Yes. >> Yeah. A custom one. Yes. And so there is lowhanging 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. >> It's not just, you know, not just raw lines of code. So, this is lowhanging 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 uh 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 cuz frankly people could do it just by you know prompting it that's great that's fine because we've enabled a whole another 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 of having strong foundations and and you've previously said, I'm actually quoting you, the field is moving at an incomp 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 you know now actually want to go back and strengthen those foundations that that will be helpful. I find my my uh 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 of Simon and Newell in the the sciences of the artificial. Uh 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 in one of our 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 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 howl. And you'll notice I've got a how above me here. >> Yes. >> Uh this is I I'm a great one for history. This is my sword of Dicles that passes behind me. If you know the history behind the sword of Dacles, the king Damacles, 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 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. Uh the cursor, the copilot and 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 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 uh which was manifest in early AI systems such as hearsay. The ideas of of global workspaces, blackboards and the like. Another architectural element. the ideas of subumption architectures from uh from Rodney Brooks. Uh 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. 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 uh neurology from systems in in the real world as Herbert Herbert Simon and New did this is what's guiding me to the next generation of systems and so I would urge you know people looking at systems now go back to those fundamentals. There is nothing new under the sun in many ways. We've just, you know, applied them in different ways. Those fundamentals in engineering, they're still there. And then as closing, uh, you gave some really good recommendations to read, to ponder, to educate yourself, and and get ideas that will probably useful in this new world, especially as as we're going to have a lot more agents. For example, like I now just heard that agents will be part of Windows 11 and operating system. So, they will be everywhere. But looking back at the the previous rises of abstractions and also the previous golden ages, the people who 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? Like what and and based on this historical lesson, what would you recommend if if we were just kind to kind of copy successful, you know, things that that 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 uh agents of of AI of building these new and complex a lot more complex systems that we could have done before. >> So I 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 could 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 teen to do them. I couldn't have afforded that. I could not have uh 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 an 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 gonna 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 the overview, the outlook, and and for and for a little bit of perspective. I 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 struck 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 highle 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 traction, 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 a 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 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.