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

Some people worry that AI writing is surprisingly good quality. But Grady Busch disagrees and says that we are entering the third golden age of software engineering. Grady Boosch 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 survival.

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 Aymodae's. Prediction that software engineering will be automated in 12 months, spoiler, he does not hold back. And many more.

If you want to understand that the massive change that AI is bringing has in fact happened before and not just once, this episode is for you. This episode is presented by Statsig, the Unified Platform for Flags, Analytics Experiments, and more. Check out the show notes to learn more about them and our other season sponsors.

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 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 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. 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 engineering-ish about it. In the sense that ours is a field. that tries to build reasonably optimal solutions, you can't have perfect solutions.

that balances the static and dynamic forces around them, much like what structural, electrical, chemical engineers do. In the software world, of course, we deal with the medium that is extraordinarily fungible and elastic and fluid, and yet we still have the same kinds of forces upon us. 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 Vertabri 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 per se pro progress. And there are also other constraints upon us, not just these scientific ones and and the computer sciencey 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 generic. 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 th from the lens of looking backward, they're 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 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 forties, early fifties 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 forties. The term software was not done until the fifties. 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 seventy eighty years ago. Wow. Yeah, yeah, exactly. So this is this we're an astonishingly young uh young industry. If you were to take Carl Sagan's cosmic calendar

and uh and put software in it, we would be in the last few nanoseconds of that cosmic calendar. It would be uh less than a blink of an eye. But anyway, as software be can 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 sixties 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 Fortran, it was a matter of building our software that could do formula translation. So that was the realm and the problems faced by the first generation.

And another generation, like in timeline, where would you put it roughly? Timeline I put it in the late forties to the late seventies or thereabouts. Yeah. And that's what dominated that time frame. So the figures you would see would be uh Ed Jordan, Tom DiMarco, 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 who would operate the computers.

And again, this was largely driffen 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 resource. 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 with 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 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 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 um 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 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 Parnas who were coming on the scene, C. A. Ahora, Dijkstra and others.

for beginning to look at the formalisms of these systems and looking at treating software development as actually a formal mathematical activity. Grady just mentioned formal methods and formal mathematics and software engineering.

being able to verify that software does what it should has been a problem since the early days of software engineering. And this leads us nicely to our 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 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 quick. 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 stats.

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 slash pragmatic slash sonar summit. With this, let's get back to Grady and treating software development as a formal 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 fifties and six in sixties. And indeed the last one was decommissioned, I think, in the nineteen nineties. 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 invade 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 semi-automatic ground environment. This system was so large it consumed, according to some reports, easily twenty to thirty percent 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. Solve and and research on moving the industry forward, right? Because they 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 on 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 uh 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 Descartes' loom. So yeah, a lot of the things we take for granted today, like the internet.

uh like uh microminization, 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 or 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 the interfaces we deal with today, they had their roots in Whirlwind and the U roots in Sage. This is the first UI interface that was graphic tube, a C R T.

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 build 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 seventies, early eighties. 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. It 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 it 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 c the clearing present danger at the time was that.

And it was an exciting, vibrant time because there was so much that could be done and software being such a fungible, elastic, fluid medium meant that we were primarily limited just by our imagination. You add to this then micro-miniaturization. Why did integrated circuits come about? Why did uh 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 uh muddy men missile. In fact, most of the transistors being made in Silicon Valley in the earliest days went to our Cold War program. But that was great because that established then the the economic basis for the whole infrastructure for doing it where where it was possible to start doing these things at scale. Of course we knew that begat uh integrated circuits, that begat uh personal computers and so on. So here we are now in the late seventies.

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 Fourteen thousand different programming languages used through military systems. Oh wow. Back then when software was so much smaller than today. Wow. 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 and the like. We had the rise of Algal, which was not a military language, but the formal forces of C A Hor and Dijkstra and Wirth. led to this discipline of applying mathematical rigor to our languages. And so the idea of, you know, formal language research was born. So you had this wonderful confluence of resources, it said, by the late seventies.

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 j j something like that. Which was an attempt to remove the number of language that exists. 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 type.

uh from Galgen and the ideas of information hiding from Dave Parnas, uh separation of concerns, uh the ideas uh today we would call it clean programming, uh clean coding, but it's the ideas of literate programming from Canute. So these kinds of things were bubbling away in the late seventies and early eighties. And Ada was a little bit of a a a push to make that happen on a big scale. No other

industry or company could really do it'cause 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 reinstating work going on in laboratories like at Bell, which had begot C and Unix and the like, which was becoming incredibly important. But there was this crazy researcher at the time by the name of

Bjarnus Stroustrip who was saying, Wow, you know, this is kinda cool, but hey, let's take some of these ideas from Simula. I should mention simula, which was the first object oriented language And uh 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 playthrough. So he he he he brought up some parallel ideas. 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 uh US universities because he was so radical, right? But but in one of these dialogues he observed that

What 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 Parness 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 um

uh 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 the seventies 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 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 So any rate, so here we are at the sort of end of the first golden age of software engineering and moving into the second, what were the forces that led us into that?

First off, it was growing complexity. Grady just mentioned how growing complexity was a force pushing the industry into a new golden age of software engineering. Fast forward to today, and software complexity keeps growing, growing, and growing, in part thanks to AI generating a lot more code, a lot faster. And this brings us nicely to our seasoned sponsor, WorkOS. Work OS 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. and 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 WorkAway. 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 a customer using WordQuest wants. The WorkOS team walks through edge cases I had no idea existed and then turns those decisions into configurable behavior in the admin panel so customers choose the right trade-offs for their product and their users. without having to build and maintain all of this logic themselves.

But this is not always enough. And when customers have unique needs, the WorkOS engineering team often works with them directly to figure out how to solve their very specific problem. They then generalize these solutions so they become part of the platform for everyone. After this planning session, I have a newfound appreciation for just how much complexity WorkOS absorbs

So, product and engineering teams don't have to. The same planning goes into all WorkWise products and customers get all the benefit. Learn more at workerwise.com. And with this, let's get back to Grady and how the second golden age of software engineering came about.

It was 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 d 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. This was because transistors, right? And and the breakthroughs in in uh like electronics and and precise And you know, this too was a vibrant time because you had, you know

Uh 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 it Scale, yes. You you had you had hobbyists such as uh 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 Two, 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 fries 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 in 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, uh power to the people and, you know, let's, you know, love, m like make love, not war, these kinds of things. This is the era of Stuart Brand, the era of of uh 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 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 maintenance associated with them. Anyway, here we are. Um late 70s, early eighties. Uh uh also a very vibrant time because there's a lot of cool stuff that could be done. Yeah, and and it's a Stride 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 Stripress 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 uh envisioned uh 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 li launch pad it would have it would have blown up our building, which would have been really annoying. So

Yeah. Good story. And 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 eighties, uh i 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 combine the the objects and the a and the uh 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. Uh go out to the Computer History Museum and go

look at the software for for Mac Write and Mac 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. 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 and I would say the the eighties and nineties where you had people such as the three amigos, me, Eve Argokason, uh, Eve uh and uh Jim Rumbaugh, 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 g you know be the greatest thing. Uh that was kinda 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, collect 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 so 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 uh business systems, IBM Share came to be. Share was a customer. uh organized group that literally shared

software among one another is totally. And this was in the first golden age, right? This first golden age, right. 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 literally 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 it was

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. So IBM did not charge for software until later, in the later sixties, seventies, 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 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 uh Netscape allowed, uh, which was the 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 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 architectures, service oriented protocols, all that, the predecessors to what we have today. And this was laying the foundations in the second golden age. or the the beginnings of the platform era, which is, you know, what Bezos and and others have really brought us to, we're 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 that they were being born. And when you say platforms, what do you mean when you say the rise of platforms? What How how how do you think of a platform? A AWS would be a good one. Uh Salesforce would be another one. in which I have these economically interesting m 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, n not a slight fee. Yeah. Under the assumption that We as like a sales force, 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, uh it allowed the business and the industry of these kinds of SaaS companies. So l let's look at the the the late nineties, early two thousands, 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 two thousand five, six. It was still very fresh when Gmail launched, but when did you get your first email address? Nineteen eighty seven. Yeah. 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'cause 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 solve 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.

uh around that time because economically it just didn't make sense. So there was this great pullback. Also happening was the whole Y two K 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 w 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 card drills that can make things break, Or putting in more guardrails for stability, but then slowing down in shipping speed. Well, there's a third way, which leads us nicely to our presenting sponsor, Staff. Statsik built a unified platform that enables the best of bold cultures.

continuous shipping and experimentation. Feature flies gets you ship continuously with confidence, rollout to 10% of users, catch issues early, roll back instantly if needed. Built-in experimentation means every rollout automatically becomes a learning opportunity. with proper statistical analysis, showing you exactly how features impact your method.

And because it's all in one platform with the same product data, analytics session replays 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 projecting against metric regression. Microsoft, Atlashian, and Brex use Statsik 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 statsec.com/slash pragmatic. And with this, let's get back to the Y2K event that Grady was talking about.

Yeah, I I I r I remember how stressful that time was leading up to the year 2000. I think some movies even came out uh predicting, you know, how how the world would collapse. But there was this fear of like will all these systems crash? Uh and it it it started to become pretty intense in in the few months leading up. So it I I I was, you know, like a a kid at that time, but when

the year two thousand 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 A anyone who who went through their uh like kind of learned to like not trust these predictions. But you're right, like knowing what you know, there was so much work, right?

So to make sure 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 uh first decade of the two thousands is a fun place because well yeah the Th there was the crash, but still so much fun stuff to redo, so much great software to be written. We were still only limited largely by our imagination.

Now I'm gonna 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 forties and fifties.

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, uh 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 a 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, uh, 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 eighties. when you had people like Falgenbeim 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 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. Uh the list machine, the thinking machine uh 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 two thousands. AI was kind of, you know, back in the in the back rooms. Uh 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, d 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 to know about them. We want to accelerate the use of them by having aides 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 stucknecks and the like is a good one, uh, to show uh 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 too the economic issues of it. We had now companies that were too big to fail.

Uh what would happen if a Microsoft were to go under? What would happen if a Google were to go under? They're so economically important to the world that the things they do, they sneeze and some part of the world catches a cold. And so the problems we have now in this third golden age of software are different than they were than the first and second generations, but equally as exciting. And then last we have the 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. 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 seventy or eighty years can be long depending on how old you are, but it is it's it's not even a generation or it's barely a generation.

It's 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 dreadful? 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 m but yeah, 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? This it feels that it 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 I guess, you know, like taking a breathe out first and looking through the both the history and and your your d what 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. Mm. 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 gonna 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 for your readers. Go Google Grace Hopper and David Letterman and there's this

She appeared on the David Letterman show and sh you'll get a sense of her personality. We'll we're gonna link it in the show notes below. She of course is the one who recognized that it was possible, here we are in the fifties, that it was possible to separate our software from our hardware. This was threatening to those who were building the early machines because they said, you know, gosh.

You could never build anything efficient because you have to be tied so closely to the machines. And many in that field, and they wrote about it, expressed concerns that. you know, this is going to destroy what we do. And it should have. So we had here the beginnings of the first compilers.

The same thing happened with the invention of Fortran, where people were saying, Gosh, you know, we can write tight assembly language better than anybody else, better than any machine can kind of do, but that was proved wrong when we moved up a level of abstraction. From the assembly language to the higher order programming language.

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 high order programming languages, from high order programming languages to libraries. The same kind of thing happened and we're seeing the same

change and 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 gonna build it and I throw it away. If you're gonna 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 gonna 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 er rara and the hobbyist side of software, if you will, much like we saw in the earliest days of

uh personal computers where people would 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'll have made a valuable impact.

And I guess just like in the first era where personal com people could buy it, you will have people come into the industry who have honestly nothing to do with it and they might bring amazing ideas, right? Like back then, you know, a school school teacher might have bought a personal computer today. I I just talk to my neighbor upstairs, an accountant. She has instructed Chat GPT to build some app script 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, a absolutely s 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 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 gonna 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 uh 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 Amadei, the CEO of Anthropic, and the reason I pay attention to him is Yes. I I try I tend Nazi Pay's engine CEOs, but he actually said uh about a year ago, he said something interesting. He says he thinks most code will be generated by AI, about ninety percent of it, maybe in a year.

and then more and we thought that's silly and then he was right and code was generated. Yes. 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 s a strong response already, so Uh I have one or two things to say about it. So first off, uh 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 Dario, man, I I respect what you're saying, but recognize also that Dario has a different point of view than I do. He's leading a company who needs to make money.

And it's a company who he needs to speak to his stakeholders. So outrageous statements will be said like that. I think he said these kind of things at Davos, if I'm not mistaken. Yes. And and I'd say politely, well, I'll use a scientific term in terms of how I would characterize what what Dario said and to put it in context, it's utter bullshit. Uh that's the technical term. Because uh I think he's profoundly wrong and and he I think he's wrong for a number of reasons.

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, oh 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 Cursure 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 gonna, 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 abstraction. What Dario neglects and I used a

Uh, a bit of a paraphrase from from Shakespeare. Uh, 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 as 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 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 extent existentially. Let me offer another

story with regards to how we see a 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 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. Uh go off and search for uh a site called Victorian Engineering Connections. It's this this lovely little site where the gentleman did this for a museum. Andrew, and you can, you know, put in a name like uh George Bule.

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 Uh, what can I do? He gave me his code. Uh I realize it uses the D three library. I knew nothing about the D three 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, really 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 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 we're gonna 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 in 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 COBOL was, in that if I give it those phrases in a domain that is well enough structured, it allows me to have good enough solutions that I, who know those fundamentals, can begin nudging and cleaning out the pieces. That's why the fundamentals are so important.

And speaking of history rhyming, one thing that happened in both the first age and the g the sec second golden age or as 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 were 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 uh Do you have a huge infrastructure about around them? 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, uh I'm talking about

in effect, infrastructure is software. It's not just, you know, not just raw lines of code. So this is low hanging fruit. where we could s 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'cause 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 gonna 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 gonna need to reskill.

in the building of simple applications and the like, well, I think, you know, people who had uh who had skills and saying, I wanna build this, you know, thing for IOS or whatever, they're gonna lose, you know, they're gonna lose some jobs'cause 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 tentacle

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 the foundations of 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 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 wanna, you know, have people go off on these long missions. We wanna 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 Uh NASA wanted to build a HAL. And you'll notice I've got a HAL above me here. Yes. Uh this is I I'm a great one for history. This is my Sword of Domacles that passes behind me. If you know the history behind the Sword of Domacles.

uh the king Domacles, 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, uh 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 copilots and the like, they have no connection to the physical world. So our work was primarily in embodied cognition. Around the same time I was studying under a number of neuroscientists. trying to better understand the architecture of the brain.

And here's where the fundamentals of that came together for me, because I began to realize there are 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's 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's Society of Mind, 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, uh blackboards and the like, another architectural element, the ideas of subsumption architectures from uh from Rodney Brooks.

Uh his it 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, but we're not a 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 uh neurology, from systems in in the real world, as uh Herbert or Herbert Simon or Newell 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 be useful in this new world, especially as as we're gonna have a lot more agents. For example, like I I now just heard that agents will be part of Windows eleven and operating systems. So they 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. 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 of to kind of copy

successful, you know, things that that that people did. Cause 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 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 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 team 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 uh an a 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 at it 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. Great E. 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 me was when Grady pointed out that developers have faced

this exact exist before, multiple times in fact. When compilers came along, assembly programmers thought their careers were over. When high level languages emerged, the same fear ripped through the industry. And each time the people who understood what actually was happening, that it was just a new level of abstraction, 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 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.