The history of software engineering is characterized by rising levels of abstraction, and the current advancements in AI are not an existential threat but rather the next evolution in this ongoing progression, ushering in a third golden age.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
Some people worry that AI writing
surprisingly good code could mean the
end of software engineering. But Grady
Buch disagrees and says that we are
entering the third golden age of
software engineering. Grady Buch is one
of the founding figures of software
engineering as we know it. He co-created
UML, pioneered object-oriented design,
spent decades as an IBM fellow, and has
witnessed every major transformation
this industry has undergone since the
1970s. In today's conversation, we
discuss the three golden ages of
software engineering and what history
teaches us about surviving and thriving
through major technology shifts. Why
coding has always been just one part of
software engineering and why the human
skills of balancing technical, economic,
and ethical forces are not going
anywhere. Grady's direct response to
Dario's prediction that software
engineering will be automated in 12
months. Spoiler, he does not hold back.
And many more. If you want to understand
that the massive change that AI is
bringing has in fact happened before and
not just once, this episode is for you.
This episode is presented by Statsig,
the Unifi platform for flags, analytics,
experiments, and more. Check out the
show notes to learn more about them and
our other season sponsors. So, Grady,
it's great to have you back on the
podcast again. Thanks for having me.
Aloha. So touching a little bit on the
the history of of software engineering,
you've said many times before that the
entire history of software engineering
is one of rising levels of abstraction.
Can you walk us through the key
inflection points that help us
understand this and then of course tie
it into how AI is is all tying into this?
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.
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
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.
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?
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.
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,
>> 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,
endures,
meaning that I'm not going to build it
and I throw it away. If you're going to
throw it away, do what you want. That's
great. And I see a lot of people using
these agents for that very purpose.
That's wonderful. You're going to go off
and automate things you could not have
afforded to do today. And if you're a
single user for it, then more power to
you. This is the hobbyist rarer and the
hobbyist side of software if you will
much like we saw in the earliest days of
personal and computers where people will
build these things. Great stuff. Great
ideas will come from it.
>> I like the comparison. Yes.
>> Yeah. Great ideas will come from it. You
know, people will build skills. We'll do
things we could not have done before.
We'll automate things that were
economically not possible, but they're
not going to endure necessarily, but
still we will have made a valuable
impact. And I guess just like in the
first era where personal people could
buy it, you will have people come into
the industry who have honestly nothing
to do with it and they might bring
amazing ideas, right? Like back then,
you know, school school teacher might
have bought a personal computer. Today I
I just talked to my neighbor upstairs,
an accountant. She has instructed Chad
GBT to build some appcript to uh help
their accounting teams process a bit
better because she knows how that thing
works. Nothing to do with software, but
now creating their own personal
throwaway software. by the way.
>> Yes, absolutely. The same parallels and
I celebrate that. I encourage it. I
think it's the most wonderful thing
which is why we are in this vibrant
period. In the early days of of the
personal computer, the very same thing
happened. You found artists drawn to
especially the PC and the amigga at the
time. You found gamers who realized I've
got a new medium for expression that I
did not have before and that's why it
was a very vibrant time. the same thing
is happening. And so much of the
lamenting of oh gosh, we have an
existential crisis are those who are
narrowly focused upon their industry not
realizing that what's happening here is
actually expanding in the industry.
We're going to see more software written
by people who are not professionals. And
I think that's the greatest thing around
because now we have software much like
in the in the counterculture era of of
the personal computer. The same thing is
happening today as well. I like what
you're saying. However, one however
however one one thing that I also pay
attention to uh one person I pay
attention to is is Dario Amod the CEO of
Antropic. And the reason I pay attention
to him is I I try I tend not to pay
attention to CEOs but he actually said
about a year ago he said something
interesting. He says he thinks most code
will be generated by AI about 90% of it
maybe in a year and then more and we
thought that's silly and then he was
right and code was generated and now he
said some another thing interesting that
sounded interesting but the next one
sounds scary he said I quote software
engineering will be automatable in 12
months now this sounds a lot more
scarier for reasons we know coding is a
subset of software engineering but he
said this what is your take on on this
and you've had you've had a strong
response already. So,
>> u I have one or two things to say about
it. So, first off, I use Claude. I use
Anthropics work. I think it's it's my
it's my go-to system. I've been using it
for problems with JavaScript, with
Swift, uh with PHP of all things and
Python. So, I use it and it's it's been
a great thing for me primarily because,
you know, there are certain libraries I
want to use. Google search sucks.
documentation for these things suck and
so I can use these agents to accelerate
my understanding of them. But remember
also I have a foundation of at least one
or two years of experience in these
spaces okay a few decades where I sort
of understand the fundamentals and
that's why I said earlier that the
fundamentals are not going to go away
and this is true in every engineering
discipline the fundamentals are not
going to disappear the tools we apply
will change so Daario man I I respect
what you're saying but recognize also
that Daario has a different point of
view than I do. He's leading a company
who needs to make money and it's a
company who he needs to speak to his
stakeholders. So outrageous statements
will be said like that. I think he said
these kind of things at Davos if I'm not mistaken.
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
what I said at the beginning. Software engineers are the engineers who balance
engineers are the engineers who balance these forces. So we use code as one of
these forces. So we use code as one of our mechanisms, but it's not the only
our mechanisms, but it's not the only thing that drives us. None of the things
thing that drives us. None of the things that he or any of his colleagues are
that he or any of his colleagues are talking about attend to any of those
talking about attend to any of those decision problems that a software
decision problems that a software engineer has to deal with. None of those
engineer has to deal with. None of those we see within the within the realm of
we see within the within the realm of automation. His work is primarily
automation. His work is primarily focused upon the automation at the
focused upon the automation at the lowest levels which is I would put akin
lowest levels which is I would put akin to what was happening with compilers in
to what was happening with compilers in these days. That's why I say it's
these days. That's why I say it's another level abstraction. Fear not, O
another level abstraction. Fear not, O developers. Your tools are changing, but
developers. Your tools are changing, but your problems are not. There's another
your problems are not. There's another reason why I I push back on what he's
reason why I I push back on what he's saying. And that is if you look at
saying. And that is if you look at things like cursor and the like, they
things like cursor and the like, they have mostly been trained upon a set of
have mostly been trained upon a set of problems that we have seen served over
problems that we have seen served over and over again. And that's okay. Much
and over again. And that's okay. Much like I said in the first generation,
like I said in the first generation, first golden age, we had a certain set
first golden age, we had a certain set of problems. And so libraries are built
of problems. And so libraries are built around them. The same thing is happening
around them. The same thing is happening here. If I need to build a UI on top of
here. If I need to build a UI on top of CRUD, it's sub winter or some web
CRUD, it's sub winter or some web ccentric kind of thing. I can do it. And
ccentric kind of thing. I can do it. And much like your friend, more power to
much like your friend, more power to them. They can do it themselves because
them. They can do it themselves because the power is there to do so. They're
the power is there to do so. They're going to, you know, probably not build a
going to, you know, probably not build a business around it. Some small percent
business around it. Some small percent of them might do so. But it's enabled
of them might do so. But it's enabled them to do things they could not do
them to do things they could not do before because they're now at a higher
before because they're now at a higher level abstraction. what Daario neglects
level abstraction. what Daario neglects and I used a a bit of a paraphrase from
and I used a a bit of a paraphrase from from Shakespeare. There are more things
from Shakespeare. There are more things in computing Daario that are dreamt of
in computing Daario that are dreamt of in your philosophy. The world of
in your philosophy. The world of computing is far larger than web centric
computing is far larger than web centric systems of scale. So we see many of the
systems of scale. So we see many of the things applied today on these webric
things applied today on these webric systems and I think that's great and
systems and I think that's great and wonderful but it means that there's
wonderful but it means that there's still a lot of stuff out there that
still a lot of stuff out there that hasn't yet been automated. So we have we
hasn't yet been automated. So we have we keep pushing these fringes away. So I
keep pushing these fringes away. So I told you those stories at the beginning
told you those stories at the beginning because history is repeating itself
because history is repeating itself where some will say history is rhyming
where some will say history is rhyming again. The same kinds of phenomena are
again. The same kinds of phenomena are applying today just at a different level
applying today just at a different level of abstraction. So that's the first one.
of abstraction. So that's the first one. Software is bigger than this world of
Software is bigger than this world of software is bigger than what he's
software is bigger than what he's looking at. It's bigger than just
looking at. It's bigger than just software intensive systems. And then
software intensive systems. And then second, you know, if you look at the
second, you know, if you look at the kinds of systems that most of these
kinds of systems that most of these agents deal with, they are in effect
agents deal with, they are in effect automating patterns that we see over and
automating patterns that we see over and over again for which they have been
over again for which they have been trained upon. Patterns themselves are
trained upon. Patterns themselves are new abstractions that are in effect not
new abstractions that are in effect not just single algorithms or single
just single algorithms or single objects, but they represent societies of
objects, but they represent societies of objects and algorithms that work
objects and algorithms that work together. These agents are great at
together. These agents are great at automating generations of patterns. I
automating generations of patterns. I want to do, you know, this kind of thing
want to do, you know, this kind of thing and I can tell you in English because
and I can tell you in English because that's how I describe the pattern. So
that's how I describe the pattern. So anyway, that's why I think he's wrong.
anyway, that's why I think he's wrong. More power to him. But, you know, I
More power to him. But, you know, I think this is an exciting time more than
think this is an exciting time more than things to worry about exist
things to worry about exist existentially. Let me offer another
existentially. Let me offer another story with regards to how we see a shift
story with regards to how we see a shift in levels of abstraction. English is a
in levels of abstraction. English is a very imprecise language full of
very imprecise language full of ambiguity and nuance and the like.
ambiguity and nuance and the like. Though one would wonder how could I ever
Though one would wonder how could I ever make that you know as a useful language
make that you know as a useful language and the answer is we already do this as
and the answer is we already do this as software engineers. I go to somebody and
software engineers. I go to somebody and say hey I want my system to do this. It
say hey I want my system to do this. It kind of looks like this and I give them
kind of looks like this and I give them some examples. I do that already. And
some examples. I do that already. And then somebody goes and turns that into
then somebody goes and turns that into code. We've moved up a level of
code. We've moved up a level of abstraction to say I'd like it to do
abstraction to say I'd like it to do this. I'll give you a concrete example.
this. I'll give you a concrete example. I'm working with a library I'd never
I'm working with a library I'd never touched before. It's the JavaScript D3
touched before. It's the JavaScript D3 library which allows me to do some
library which allows me to do some really fascinating visualizations. I go
really fascinating visualizations. I go off and search for a site called
off and search for a site called Victorian Engineering Connections. It's
Victorian Engineering Connections. It's just this lovely little site where the
just this lovely little site where the gentleman did this for a museum Andrew
gentleman did this for a museum Andrew and you can, you know, put in a name
and you can, you know, put in a name like George Bool and you see his name,
like George Bool and you see his name, you find things about him and you find
you find things about him and you find his social network around him and you
his social network around him and you can go touch it and explore. It's very,
can go touch it and explore. It's very, very cool. And I said,"I want that kind
very cool. And I said,"I want that kind of thing, but my gosh, I don't know how
of thing, but my gosh, I don't know how to do that. So, what can I do?" He gave
to do that. So, what can I do?" He gave me his code. I realized it uses the D3
me his code. I realized it uses the D3 library. I knew nothing about the D3
library. I knew nothing about the D3 library. So, I said to Cursor, "Go build
library. So, I said to Cursor, "Go build me the simplest one possible. Go do it
me the simplest one possible. Go do it out of, you know, five nodes and show
out of, you know, five nodes and show me." So, I could then study the code.
me." So, I could then study the code. And then I could say, "Well, what they
And then I could say, "Well, what they wanted would really wanted to do is
wanted would really wanted to do is this. Go make the nodes look like this,
this. Go make the nodes look like this, depending upon their kind." So, just
depending upon their kind." So, just like I would do with a human, I was
like I would do with a human, I was expressing my needs in an English
expressing my needs in an English language that now all of a sudden I
language that now all of a sudden I didn't need to labor to turn that into
didn't need to labor to turn that into reality. I could simply have a
reality. I could simply have a conversation with my tool to help me do
conversation with my tool to help me do that. So, it it reduced the distance
that. So, it it reduced the distance between what I wanted and what it could
between what I wanted and what it could do. And I think that's great. That's a
do. And I think that's great. That's a breakthrough. But remember, as I said to
breakthrough. But remember, as I said to Daario, this only works in those
Daario, this only works in those circumstances where I'm doing something
circumstances where I'm doing something that people have done hundreds and
that people have done hundreds and hundreds of times before. I could have
hundreds of times before. I could have learned it on my own. As Fineman would
learned it on my own. As Fineman would have said, you know, go do it yourself
have said, you know, go do it yourself because then that's the only way you're
because then that's the only way you're going to understand. And I my reaction
going to understand. And I my reaction is that's great, but there's so much in
is that's great, but there's so much in the world I'm curious about. I can't
the world I'm curious about. I can't understand it all. Let's go, you know,
understand it all. Let's go, you know, let's decide what I want to do. So go do
let's decide what I want to do. So go do it for me. So that's why I say these
it for me. So that's why I say these kinds of tools are another shift in the
kinds of tools are another shift in the levels of abstraction because they're
levels of abstraction because they're reducing the distance from what I'm
reducing the distance from what I'm saying my English language to the the
saying my English language to the the programming language. Last thing I'll
programming language. Last thing I'll say is that you know what do we call a
say is that you know what do we call a language that is precise and expressive
language that is precise and expressive enough to be able to build executable
enough to be able to build executable artifacts? We call them programming
artifacts? We call them programming languages. And it just so happens that
languages. And it just so happens that English is a good enough programming
English is a good enough programming language much like Cobalt was in that if
language much like Cobalt was in that if I give it those phrases in a domain that
I give it those phrases in a domain that is well enough structured, it allows me
is well enough structured, it allows me to have good enough solutions that I who
to have good enough solutions that I who know those fundamentals can begin
know those fundamentals can begin nudging and cleaning out the pieces.
nudging and cleaning out the pieces. That's why the fundamentals are so
That's why the fundamentals are so important. And speaking of history
important. And speaking of history rhyming, one thing that happened in both
rhyming, one thing that happened in both the first age and the the sec second
the first age and the the sec second golden age or as we jumped abstractions
golden age or as we jumped abstractions or every time we had an abstraction is
or every time we had an abstraction is some skills became obsolete and then
some skills became obsolete and then there was a demand for for new skills.
there was a demand for for new skills. For example, when we from assembly level
For example, when we from assembly level the the skill of like knowing how the
the the skill of like knowing how the instruction set of a certain board and
instruction set of a certain board and knowing how to optimize it, that became
knowing how to optimize it, that became obsolete in favor of thinking at a
obsolete in favor of thinking at a higher level. In this jump right now
higher level. In this jump right now where I think it's safe to say we're
where I think it's safe to say we're going from we do not need to write any
going from we do not need to write any more code and the computer will do it
more code and the computer will do it pretty good and we'll check it and tweak
pretty good and we'll check it and tweak it. What do you think will become
it. What do you think will become obsolete and what will become more
obsolete and what will become more important as software professionals?
important as software professionals? >> Great question. The software delivery
>> Great question. The software delivery pipeline is far more complex than it
pipeline is far more complex than it should be. Uh that my gosh just getting
should be. Uh that my gosh just getting something running is hard if you have no
something running is hard if you have no pipeline. If you're within a company
pipeline. If you're within a company such as a Google or a Stripe or
such as a Google or a Stripe or whatever, you have
whatever, you have >> you have a huge infrastructure about
>> you have a huge infrastructure about around them.
around them. >> A custom one.
>> A custom one. >> Yes.
>> Yes. >> Yeah. A custom one. Yes. And so there is
>> Yeah. A custom one. Yes. And so there is lowhanging fruit for the automation of
lowhanging fruit for the automation of those. I mean I don't need a human that
those. I mean I don't need a human that fills in the edges of those kind of
fills in the edges of those kind of things. By the way, I'm talking about in
things. By the way, I'm talking about in effect infrastructure is software.
effect infrastructure is software. >> It's not just, you know, not just raw
>> It's not just, you know, not just raw lines of code. So, this is lowhanging
lines of code. So, this is lowhanging fruit where we could begin seeing these
fruit where we could begin seeing these agents that say, "Hey, you know, I want
agents that say, "Hey, you know, I want you to go, you know, gosh, I don't know,
you to go, you know, gosh, I don't know, you know, spin up something for this
you know, spin up something for this part of the world. I don't want to write
part of the world. I don't want to write the code for that stuff because it's
the code for that stuff because it's complex and messy. I'd rather use an
complex and messy. I'd rather use an agent that helps me do it." So there's a
agent that helps me do it." So there's a case where I think you're going to have
case where I think you're going to have the loss of jobs in those places where
the loss of jobs in those places where it's messy and complex because the
it's messy and complex because the automation has clear economic and you
automation has clear economic and you know frankly value in terms of security.
know frankly value in terms of security. That's a place where people are going to
That's a place where people are going to need to reskill in the building of
need to reskill in the building of simple applications and the like. Well,
simple applications and the like. Well, I think you know people who had uh who
I think you know people who had uh who had skills in saying I want to build
had skills in saying I want to build this you know thing for iOS or whatever
this you know thing for iOS or whatever they're going to lose you know they're
they're going to lose you know they're going to lose some jobs cuz frankly
going to lose some jobs cuz frankly people could do it just by you know
people could do it just by you know prompting it that's great that's fine
prompting it that's great that's fine because we've enabled a whole another
because we've enabled a whole another generation of folks to do things that
generation of folks to do things that professionals did in the past exactly
professionals did in the past exactly what happened in the era of PCs
what happened in the era of PCs themselves what should these people do
themselves what should these people do move up a level of abstraction start
move up a level of abstraction start worrying about systems so the shift now
worrying about systems so the shift now I think is less so from dealing with
I think is less so from dealing with programs and apps to dealing with
programs and apps to dealing with systems themselves and that's where the
systems themselves and that's where the new skill set should come in. If you
new skill set should come in. If you have the skills of knowing how to manage
have the skills of knowing how to manage complexity at scale if you know as a
complexity at scale if you know as a software engineer how to deal with all
software engineer how to deal with all of these multiple forces which are human
of these multiple forces which are human as well as technical your job's not
as well as technical your job's not going to go away. If anything, there
going to go away. If anything, there will be even greater demand for what
will be even greater demand for what you're doing because those human skills
you're doing because those human skills are so rare and delicate.
are so rare and delicate. >> So, you mentioned the importance of of
>> So, you mentioned the importance of of having strong foundations and and you've
having strong foundations and and you've previously said, I'm actually quoting
previously said, I'm actually quoting you, the field is moving at an incomp
you, the field is moving at an incomp incomprehensible pace for people without
incomprehensible pace for people without deep foundations and a strong model of
deep foundations and a strong model of understanding. What foundations would
understanding. What foundations would you recommend people to look at? both
you recommend people to look at? both students, people who are at university
students, people who are at university studying or looking for their first job
studying or looking for their first job and also software professionals who you
and also software professionals who you know now actually want to go back and
know now actually want to go back and strengthen those foundations that that
strengthen those foundations that that will be helpful. I find
will be helpful. I find my my uh my happy place if you will, my
my my uh my happy place if you will, my sweet space that I retreat back to when
sweet space that I retreat back to when I'm faced with a difficult problem back
I'm faced with a difficult problem back into systems theory. go read the work of
into systems theory. go read the work of of Simon and Newell in the the sciences
of Simon and Newell in the the sciences of the artificial. Uh there's a whole
of the artificial. Uh there's a whole set of work that's come out on
set of work that's come out on complexity and systems from the Santa Fe
complexity and systems from the Santa Fe Institute. It's those kinds of
Institute. It's those kinds of fundamentals of system theory that
fundamentals of system theory that ground me in the next set of things in
ground me in the next set of things in which I want to build. I think I
which I want to build. I think I mentioned to you in in one of our our
mentioned to you in in one of our our previous discussions, I was doing some
previous discussions, I was doing some really interesting work on NASA's
really interesting work on NASA's mission to Mars. we were faced with an
mission to Mars. we were faced with an issue of saying, "Hey, you know, we we
issue of saying, "Hey, you know, we we want to, you know, have people go off on
want to, you know, have people go off on these long missions. We want to put
these long missions. We want to put robots on the surface of Mars." And so I
robots on the surface of Mars." And so I was commissioned to go off and think
was commissioned to go off and think about that for a while. And in effect, I
about that for a while. And in effect, I realized NASA wanted to build a howl.
realized NASA wanted to build a howl. And you'll notice I've got a how above
And you'll notice I've got a how above me here.
me here. >> Yes.
>> Yes. >> Uh this is I I'm a great one for
>> Uh this is I I'm a great one for history. This is my sword of Dicles that
history. This is my sword of Dicles that passes behind me. If you know the
passes behind me. If you know the history behind the sword of Dacles, the
history behind the sword of Dacles, the king Damacles, he was always kept humble
king Damacles, he was always kept humble because at his throne there was a sword
because at his throne there was a sword right above him on a thread. So he felt,
right above him on a thread. So he felt, you know, constantly, you know, unease.
you know, constantly, you know, unease. And this is why I have Hal behind me as
And this is why I have Hal behind me as well. For for some reason, NASA didn't
well. For for some reason, NASA didn't want the kill all the astronauts use
want the kill all the astronauts use case. Don't understand why, but we we
case. Don't understand why, but we we threw that one kind of out. But if you
threw that one kind of out. But if you look at the problems there, this is a
look at the problems there, this is a systems engineering problem because you
systems engineering problem because you needed something that was embodied in
needed something that was embodied in the spacecraft.
the spacecraft. Much of the kind of software we have
Much of the kind of software we have today in AI is disembodied. Uh the
today in AI is disembodied. Uh the cursor, the copilot and like they have
cursor, the copilot and like they have no connection to the physical world. So
no connection to the physical world. So our work was primarily in embodied
our work was primarily in embodied cognition. Around the same time, I was
cognition. Around the same time, I was studying under a number of
studying under a number of neuroscientists trying to better
neuroscientists trying to better understand the architecture of the
understand the architecture of the brain. And here's where the fundamentals
brain. And here's where the fundamentals of that came together for me because I
of that came together for me because I began to realize there are some certain
began to realize there are some certain structures we see in systems engineering
structures we see in systems engineering that I can apply to the structure of
that I can apply to the structure of these really large systems. Taking ideas
these really large systems. Taking ideas of Marvin Minsky society of mind which
of Marvin Minsky society of mind which is a way of of systems architecting
is a way of of systems architecting multiple agents. We're in agent
multiple agents. We're in agent programming now which I think people are
programming now which I think people are just beginning to tap upon how those
just beginning to tap upon how those things apply. they need to go look at
things apply. they need to go look at systems theory because that problem has
systems theory because that problem has been looked at with multiple agents
been looked at with multiple agents already. Go read Minsky society of mine.
already. Go read Minsky society of mine. You'll see some ideas that will guide
You'll see some ideas that will guide you there in dealing with multiple
you there in dealing with multiple agents. The ideas from bears of uh which
agents. The ideas from bears of uh which was manifest in early AI systems such as
was manifest in early AI systems such as hearsay. The ideas of of global
hearsay. The ideas of of global workspaces, blackboards and the like.
workspaces, blackboards and the like. Another architectural element. the ideas
Another architectural element. the ideas of subumption architectures from uh from
of subumption architectures from uh from Rodney Brooks. Uh his was influenced by
Rodney Brooks. Uh his was influenced by by biological things. If you look at a
by biological things. If you look at a cockroach, a cockroach is not a very
cockroach, a cockroach is not a very intelligent thing. But we know there's
intelligent thing. But we know there's there's there's not a central brain in
there's there's not a central brain in it and yet it does some magnificent
it and yet it does some magnificent things. We have been able to map the
things. We have been able to map the entire neural network of the common
entire neural network of the common worm. We're not flush with, you know,
worm. We're not flush with, you know, evil worms running around the world.
evil worms running around the world. There's something else going on there.
There's something else going on there. But biological systems have an
But biological systems have an architecture to them. So to go back to
architecture to them. So to go back to your question by looking at architecture
your question by looking at architecture from a systems point of view from
from a systems point of view from biology from uh neurology from systems
biology from uh neurology from systems in in the real world as Herbert Herbert
in in the real world as Herbert Herbert Simon and New did this is what's guiding
Simon and New did this is what's guiding me to the next generation of systems and
me to the next generation of systems and so I would urge you know people looking
so I would urge you know people looking at systems now go back to those
at systems now go back to those fundamentals. There is nothing new under
fundamentals. There is nothing new under the sun in many ways. We've just, you
the sun in many ways. We've just, you know, applied them in different ways.
know, applied them in different ways. Those fundamentals in engineering,
Those fundamentals in engineering, they're still there. And then as
they're still there. And then as closing, uh, you gave some really good
closing, uh, you gave some really good recommendations to read, to ponder, to
recommendations to read, to ponder, to educate yourself, and and get ideas that
educate yourself, and and get ideas that will probably useful in this new world,
will probably useful in this new world, especially as as we're going to have a
especially as as we're going to have a lot more agents. For example, like I now
lot more agents. For example, like I now just heard that agents will be part of
just heard that agents will be part of Windows 11 and operating system. So,
Windows 11 and operating system. So, they will be everywhere. But looking
they will be everywhere. But looking back at the the previous rises of
back at the the previous rises of abstractions and also the previous
abstractions and also the previous golden ages, the people who who did
golden ages, the people who who did great at the start of a new golden age
great at the start of a new golden age or at the start of a new abstraction
or at the start of a new abstraction even if they were not amazing at the
even if they were not amazing at the previous one, what have you seen those
previous one, what have you seen those people do? Like what and and based on
people do? Like what and and based on this historical lesson, what would you
this historical lesson, what would you recommend if if we were just kind to
recommend if if we were just kind to kind of copy successful, you know,
kind of copy successful, you know, things that that that people did because
things that that that people did because I feel this is an opportunity as well,
I feel this is an opportunity as well, right? we have this rise of abstraction.
right? we have this rise of abstraction. A lot of people will be paralyzed. But
A lot of people will be paralyzed. But there will be new superstars being born
there will be new superstars being born who will be basically riding the wave
who will be basically riding the wave and they will be the experts of uh
and they will be the experts of uh agents of of AI of building these new
agents of of AI of building these new and complex a lot more complex systems
and complex a lot more complex systems that we could have done before.
that we could have done before. >> So I as I alluded to earlier the main
>> So I as I alluded to earlier the main thing that constrains us in software is
thing that constrains us in software is our imagination. Well actually that's
our imagination. Well actually that's where we begin. We're actually not
where we begin. We're actually not constrained by imagination. We can dream
constrained by imagination. We can dream up amazing things and yet we are
up amazing things and yet we are constrained by the laws of physics by
constrained by the laws of physics by how we build algorithms and the like
how we build algorithms and the like ethical issues and the like. So what's
ethical issues and the like. So what's happening now is that you are actually
happening now is that you are actually being freed because some of the
being freed because some of the friction, some of the constraints, some
friction, some of the constraints, some of the costs of development are actually
of the costs of development are actually disappearing for you. Which means now I
disappearing for you. Which means now I could put my attention upon my
could put my attention upon my imagination to build things that simply
imagination to build things that simply were not possible before. I could not
were not possible before. I could not have done them because I couldn't have
have done them because I couldn't have raised a teen to do them. I couldn't
raised a teen to do them. I couldn't have afforded that. I could not have uh
have afforded that. I could not have uh done it because I couldn't have had the
done it because I couldn't have had the reach in the world as I did before. So
reach in the world as I did before. So think of it as an opportunity. So it's
think of it as an opportunity. So it's not a loss. It'll be a loss for some who
not a loss. It'll be a loss for some who have a vested interest in the economics
have a vested interest in the economics of this, but it's an a net gain because
of this, but it's an a net gain because now all of a sudden these things unleash
now all of a sudden these things unleash my imagination to allow me to do things
my imagination to allow me to do things that were simply not possible before in
that were simply not possible before in the real world. This is an exciting time
the real world. This is an exciting time to be in the industry. It's frightening
to be in the industry. It's frightening at the same time, but that's as it
at the same time, but that's as it should be. When there's an opportunity
should be. When there's an opportunity where you're on the cusp of something
where you're on the cusp of something wonderful, you should look at the abyss
wonderful, you should look at the abyss and say, you can either take a look and
and say, you can either take a look and say, "Crap, I'm gonna fall into it." Or
say, "Crap, I'm gonna fall into it." Or you can say, "No, I'm going to leap and
you can say, "No, I'm going to leap and I'm going to soar. This is the time to
I'm going to soar. This is the time to soar."
soar." >> Grady, thank you so much for giving us
>> Grady, thank you so much for giving us the the overview, the outlook, and and
the the overview, the outlook, and and for and for a little bit of perspective.
for and for a little bit of perspective. I I personally really appreciate this,
I I personally really appreciate this, >> and I hope I offered some hope as well.
>> and I hope I offered some hope as well. >> I think you definitely did. This was a
>> I think you definitely did. This was a really inspiring episode. Thank you,
really inspiring episode. Thank you, Grady. One thing that really struck with
Grady. One thing that really struck with me was when Grady pointed out that
me was when Grady pointed out that developers have faced this exact
developers have faced this exact existential crisis before, multiple
existential crisis before, multiple times, in fact. When compilers came
times, in fact. When compilers came along, assembly programmers thought
along, assembly programmers thought their careers were over. When highle
their careers were over. When highle languages emerged, the same fear ripped
languages emerged, the same fear ripped through the industry. And each time the
through the industry. And each time the people who understood what actually was
people who understood what actually was happening, that it was just a new level
happening, that it was just a new level of traction, they came out ahead. This
of traction, they came out ahead. This historical lens is something that I
historical lens is something that I think we often miss when some of us are
think we often miss when some of us are caught up in the day-to-day anxiety of
caught up in the day-to-day anxiety of new AI capabilities. I don't think we're
new AI capabilities. I don't think we're at the end of software engineering and
at the end of software engineering and neither does a Grady. We're at the
neither does a Grady. We're at the beginning of another chapter and if
beginning of another chapter and if history has any guide, it's going to be
history has any guide, it's going to be a pretty exciting one. If you found this
a pretty exciting one. If you found this episode interesting, please do subscribe
episode interesting, please do subscribe in your favorite podcast platform and on
in your favorite podcast platform and on YouTube. A special thank you if you also
YouTube. A special thank you if you also leave a rating on the show. Thanks and
leave a rating on the show. Thanks and see you in the next one.
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
