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 [music]

design, spent decades as an IBM fellow,

and has witnessed every major

transformation this industry has

undergone since [music] the 1970s. In

today's conversation, we discuss the

three golden ages of software

engineering and what history [music]

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 [music] ethical forces are not going

anywhere. Grady's direct response to

Dario's prediction that software [music]

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,

[music] 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

[laughter] 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.

[clears throat]

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