Lost Developer Wisdom - Micheal Carducci

In this talk, Michael Carducci emphasizes the importance of slowing down in a fast-paced technology landscape to filter knowledge rather than simply accumulating it. He discusses the concept of 'person bytes' which refers to the maximum knowledge an individual can realistically obtain, highlighting that in an age of information abundance, the ability to filter information is crucial. Carducci shares insights from historical figures like Claude Shannon and George Boole, illustrating how timeless principles in technology can help navigate current challenges. He also addresses the fallacies of distributed computing and the often-overlooked wisdom that comes from understanding past mistakes. Ultimately, he argues that possessing the skills to define problems and make deliberate decisions is vital in a world increasingly dominated by AI, where the ability to ask the right questions matters most.

Our session this afternoon is going to be a little different than I think a lot of the other sessions this week. Uh because while everybody else is telling you to hurry up, go faster, catch up, I'm going to tell you to slow down just a little bit. Take a moment. Because especially when everything is moving faster than ever, it's so important that we take a moment to

think. If we have not had yet had the opportunity to meet in person, uh my name is Michael Carducci. And I am a software architect, I'm a magician, a speaker, an author. I do a lot of things. Because as I promised my wife when we got married, I don't know what's going to happen, but I can promise you this, it will never be boring. And I I

live anything but a boring life. And I've had a great life, a long life, which is a very generous way of saying I'm getting older. And every time I look in the mirror, I see more gray hair than I did the last time. And I've got this sense that maybe I'm slowing down. Maybe I can't keep up. Maybe I just need to give up. Maybe I'm just

the old man at this point who yells at the cloud because things are accelerating. Things are accelerating faster than we can keep up. Uh about a year ago, I was sitting in a I was sitting in a room like like this, listening to a session like you are right now. And the presenter, lovely human being named Justin Rook, had this slide right here. With all these different

tools and all these different technologies flooding the screen. And he captioned it the problem statement. How on earth can you learn all of this stuff? And this was before AI really entered the picture, by the way. This is not AI stuff. This is all the stuff that was there before AI. So, how can we keep up? Well, we can't. There's a fundamental limit. Years ago, I got

a copy of a magazine called Scientific American. This particular copy asked the question, "What is knowledge?" And that was what the entire issue was really centered around, this idea of knowledge, what we know, what we can know, what can be known, what is unknown. And so, in this edition, the April 1st edition from 2017, there was an article by a guy named Sam O'Neal. And he was

considering how much a single person can ever know. And he introduced this really interesting concept. The concept was what he called the person byte. Megabytes and gigabytes and terabytes exabytes and zettabytes and whatever other SI prefixes that are far bigger than anything I've ever worked on. And he coined this idea of a person byte as the maximum that a single human being can know. And the thing

is it's the the limitation isn't really how much our brains can store, but the bottleneck is in the learning, how much we can consume. And that was the the limitation, right? The the the number of things that we can learn in our lifetime. that maximum theoretical ceiling is the But I guarantee you, just in our industry, the amount that can be known in our field, even if

we start slicing and dicing it up into little pieces that we might be working on, even then it's more than we can Already. And it's only going faster. It's growing exponentially. And that's the thing. The whole landscape have changed has changed. The economics of learning has changed. So, at one point, we lived in an age of information scarcity. If you had a book, whoa, you had a

book. You would read that book multiple times. You would study it because you had nothing else available to you. We didn't have libraries. We didn't have the internet. We didn't have Wikipedia. And so in the in an age of information scarcity, the thing that we want to do is hoard that knowledge. Get everything we can, consume all of it, study all of it. But we don't live

in an age of information scarcity. We live in an age of information abundance. We live in the information age. And so, when that's the world that we live in, the goal isn't to accumulate as much as possible. It shifts entirely. The goal is to filter it. And if the goal is to filter it, that changes the entire dynamic of what it is that we're supposed to be

keeping up with. It means that we don't necessarily have to keep up with everything. And that's good because you can't. And more importantly, if you approach this right, this idea of filters correctly, you don't have to. The secret is you've got to develop the right feature, the right filters. Sometimes I sit in panels at conferences, and one of the most common questions that come up is "How

do you keep up with everything?" And the reality is, we always tell them, "Well, we don't. We have filters in place to help us figure out only what the most important things are and how to keep up with those things." So, you don't need to know everything. You just need the right things. And I think that's the key. And that's what I want to point you at

least in the direction of because I can't tell you what your right things are. But I can give you ideas on where to look and how to think about it, how to evaluate it. And I think that's what's exciting in this time when we have access to everything, then we have access to the right things. So, if you're chasing trends, you're always going to be behind. When

you're chasing wisdom, wisdom is different than trends. Trends come and go. Knowledge comes and goes. The number of things I've learned in my career that do not matter at all anymore. That was already a big number of things. And now AI shows up and there are whole categories of things that I don't have to do anymore and I will probably never be asked to do again in

my life because the machines can do it. So, what keeps me more valuable in this where a whole bunch of my skills become obsolete overnight, again and again and again, and this has happened to me probably a dozen times in the last 25 years as a as a developer, as an architect in the technology space. But somehow, I've always been valuable. I've always been needed and I've

always helped other people. And when you're chasing wisdom, you're always ahead. But the challenge with that is the real wisdom usually comes early before anybody can see the value of it. And by the time we realize we need that everything has come and gone. And it's buried in the past. But I am very, very fortunate in what I a job that I have to go to every

day at 9:00 a.m. or whatever crazy hours they make you work cuz some of you work odd hours. And all of us in the West appreciate it, although they probably never expressed that to you. So, I will say that on their behalf, thank you for doing all the things that you do. Y'all are amazing. And I was telling Dilip, one of the organizers of this conference, just

how impressed I am with everybody in this community. And the reason I come back here every year because you all inspire me. And I want you to hear that. I want you to know that. You're the reason that I come back every single year and sit 30 hours on a plane. You change everything for us. It really means a lot. But the wisdom is early. Let's talk

about some early wisdom that got overlooked. Uh this is a gentleman by the name of Claude Shannon. Who here's heard of him, by the way, out of curiosity? Hands, one, two, three, four. Uh okay. That's actually good. That's above average. Most people haven't we don't really talk about him anymore, but we take advantage of his ideas every second of every day. He's one of the one of

the ones who laid the foundation that we all stand on. Um he's an obscure, but very important figure in history. Now, if we rewind the clock back to 1937, he was a 21-year-old grad student at MIT, and he was working on his master's thesis. He was looking at relay circuits. He was looking at electromechanical so- uh hardware systems. And that was the state of the art in

electrical engineering. That's what everybody was chasing. And if you've ever seen these machines, they are insane. They are complicated. They are brittle. And they were designed not elegantly, the way we might ideally build our code today, but they were designed by intuition and brute force. So, let's look at what the state of the art looked like back in the 1930s. Now, there is a game that I

like to play. I don't know. I haven't had a chance to explore the arcades that might exist in India. But, uh pinball, is that a thing? Yeah. Yeah. I love pinball. I don't know why. I don't know, maybe it's the analog nature You know, with the flippers and the actual physical ball that moves around and all the mechanics and all the lights and the sound, but I've

always loved pinball machines. And mostly I played modern pinball machines that have a computer in there. But, we actually made these machines before we had computers. Before integrated circuits existed. And somehow, with no memory, no chips, no logic, just wires and relays and switches and motors, it's all they had, it could keep track of everything. This is a great video I found by a guy named Technology

Connections. He did about three or four videos. He bought that pinball machine and then he explained to us how it all worked. Fascinating videos. I watched hours and hours of videos on this old pinball machine. And what was crazy about it was his claim in this video thumbnail. He said the wires do the math. So, if we actually go look at this pinball machine for a second,

you press the button, it hits an actuator, hits the flippers, easy enough. It hits different targets on the playfield. And you get certain number of points. But then sometimes, you're in a bonus. You have a multiplier. So, your state changes. So, when you hit that target, you don't just get 1,000 points, you get 5,000 points or 10,000 points. There is state in just a bunch of wires

that can remember which ball you're on, whose turn it is, how how far you progressed in hitting all of the targets to get a multi-ball game, or any of these other things that happened. And then it can calculate all your bonuses at the end. Like this would be hard to program in code. But there is no code, only wires. And without somebody like Claude Shannon, this is

how computers would work today. I would never own a device like this that weighs less than a kilo and folds up tiny. These things would be enormous. At the time, at one point this was the pinnacle of This is what it all looked like. It was the latest and greatest. And Claude Shannon wasn't interested in He asked the deeper questions. You see, Claude was an odd fellow.

Cuz he didn't really chase the trends. He chased ideas. And not the ideas that somebody else told him were important. He didn't care about that. He just cared about what was interesting. He was on to something, and he latched on to something and hung on to something that most of us lose. Like when we're children, we just chase what's interesting. And then we become adults and everybody

tells us who we should be, how we should be. Some of you have parents like that, I'm sure. They're disappointed that you're a developer and not a doctor. And now AI shows up and they're saying, "See, you should have been a doctor." I can hear their voice already. But he didn't care. He's on a unicycle there juggling. Why? Cuz he thought it'd be interesting to learn. That

was it. I think this will be interesting to And that opened the door to something called serendipity. The little surprises, the little happy accidents that sometimes lead you to cool places like Bengaluru. Sometimes they lead you to amazing insights. And sometimes it's just fun. Now for him there was some understanding of logic, but it was a really narrow depiction of logic. Logic is a much larger field

than we think about it. Logic is far bigger than the logic that we inhabit with computers. Even in mathematics, mathematics is a subset of logic. There is a much bigger world of logic that none of us have probably ever been exposed to. And that's what he wanted to understand. So despite the fact that he was doing a dual degree in in um in electrical engineering and mathematics,

which is enough of a course load to make anybody's hair turn gray, he said I'm going to take more classes. We said you're insane. He said he says, "Have you seen me on the on the unicycle doing the juggling? Yes, I'm insane and it's working for me. Don't question it." So he took a class. He took a little elective class that he didn't have to take. Philosophy

class. Because logic has its roots in philosophy. And he didn't care. He already knew what the mathematicians thought about logic. He already knew what the engineers He wanted to know what the philosophers Even though people have come before him, they already looked at that and they said, "Oh, here's the useful bits. We'll take those and we'll leave the rest." He says, "Well, I at least want to

understand it." Cuz in philosophy logic goes all the way back to the ancient Greeks to this idea of logos, which is the the bigger philosophy of And as he was studying this, he happened upon an interesting little booklet by a philosopher who nobody knew anything about, who had been completely forgotten. Right here. An investigation into the laws of thought on which are founded the mathematical theories of

logic and probabilities. Some philosopher. This is published in 1854. Now, you might not have heard of Claude but you've heard of this person who wrote this paper. I guarantee you. was one of the most novel and largely rejected ideas in the philosophy of See, logic back in those days really centered around what makes a valid argument, the theory of the syllogism. You know, what what makes something

true, what makes something factual. And it's big, and it's heavyweight, and it's complex. And the author of that little booklet there said, "You know what? I'm going to strip all of that away. And instead, we're going to explore this conception of logic very, very, very simply. We are going to represent instead of the theory of the syllogism and what makes a valid argument and all the rest

of this, he says, "I'm just going to represent what is true with a one, and what is false with a zero." Starting to sound familiar? Starting to figure out who this philosopher is? It was uh George Boole. because he took that detour, because he paused, because he looked backwards, he got exposed to the very idea that the entire world had been waiting for. Now, when we say

who is the father of modern computers as we know it, most people would say Turing. Turing wrote that paper on computable numbers with application towards the Entscheidungsproblem. And that's where he described this special class of machine that couldn't do just one type of calculation, that could do any type of decidable calculation, the Turing machine. But it was entirely theoretical. It was a thought experiment. It was just

a proof that such a machine could exist, but nobody would ever build it like that. But because Claude Shannon read that paper, he saw how to actually build it. And here we are today. And that was just the beginning of that man's contributions, by the way. And the thing is, it was early because Boolean algebra wasn't new, but we'd never applied it to electrical circuits. Boole didn't

really have electricity. Shannon did. And Shannon had the insight that it was premature in 1854, but became timeless in 1937 when he started to apply this stuff. And he wrote his master's thesis, and this is arguably one of the most important master's thesis -ses, theses, I don't know. I've heard it both ways. Uh ever written. It laid the foundation for every digital system that followed. And we

would never build computers the way we built that pinball machine ever again. Uh then Claude Shannon went on to do more with all of this, and he developed something called information theory, which is basically what makes our entire world work today. So, an 80-year-old idea changed history. It opened up a world of possibilities, not because it was new, but because it was timeless, and there was one

person who was willing to look backwards. Years later, Shannon was interviewed, and they said, "How did you do it? You changed the world. Where did this brilliance come from?" And he didn't say, "Oh, well, I'm just that good." He said something more honest. He said, "It just happened that nobody else was familiar with both fields at the same time." He wasn't lucky. He focused on the timeless.

And he realized a truth that we are still figuring out to this day. That everything we have has a foundation. And those foundate we built layers and layers and layers and layers and layers and layers and layers on top of that But you track it all the way down to the bedrock, to the capital T truths of reality, and it goes back to the ancient philosophers. This

is a great article, by the way, in the Atlantic, how Aristotle created the computer. the talk is about lost developer wisdom, and I think we can agree that Boolean logic is not lost wisdom. But the reality is it's not lost anymore because it was rediscovered, and the person who rediscovered shared it with the world, and we all profit, and we all have that opportunity. So, what is

the lost wisdom? Well, getting old isn't all bad. I will say that. It's mostly bad, but not all bad. Because with age comes perspective. I've been programming now for 30, 40 years, something like that. No, not quite 40, 30, 30 and change, I think at this point. And uh uh And when I take a step back, I look around and I realize we keep reinventing the same

ideas. We see the exact same ideas with a new name. I see it in architecture, I see it in software development, I see it all over the place. And that's That means when you look at the acceleration, the onslaught of all the new tools and approaches, more and more they just keep looking remarkably similar. There are things that are just simply timeless in our field. And we

forget them, and we rediscover them, and we forget them, and we rediscover them. And that turns out to be a cheat code to being ahead. So, that's why I wanted to open with And why I wanted to talk about his the wisdom of his unusual pursuits. Somebody asked me at the end of last session about work-life balance. There's a man who understands balance. Literally. I can't ride

a unicorn by the uni- unicycle, by the way. I also can't ride a unicorn, for whatever that's worth. But, that's the thing. We're conditioned to believe that education is a means to an end. That we have to choose the right degree so we can get a good job. At least that's what our parents say. I remember being strongly advised against uh getting a philosophy degree cuz I

thought philosophy was And they're like, "Don't do that. That would be the dumbest thing you ever do." You know what I spend most of my time doing these days? Philosophy. Especially now that we're in the age of AI. I talked about this yesterday. That what is missing There's nothing load-bearing under AI right now. Because under computer science, there's load-bearing abstractions that go all the way down to

that logos. Mathematics, the same thing. You can trace it all the way down to the bedrock. AI, we like to pretend that that's on top of computer science, but it's not. It's inherently different than computer science. Computer science is deterministic. AI right now is not. AI has no foundation of the philosophy of language. It just computed a statistical model that can approximate And then we wonder why

it keeps hallucinating cuz there's nothing to ground it. There's nothing load-bearing under AI. That's why I gave that whole talk yesterday. The data architecture for AI was all about going back to semantics and ontologies and using that to give a grounding all the way down in a way that can can be done universally at web scale without rewriting everything. So, a lot of us were advised to

avoid useless degrees in favor of the valuable And the ones who didn't are sometimes the butt of jokes. But for me, my smartest and most insightful friends were the ones that have the useless degree because it gives them entirely different tools in their mental toolbox. Richard Feynman, one of the most brilliant physicists who ever lived, amazing fellow, and a flawed human being. I'm not going to lie

about that. He's got his issues. there were there were just things he could do that nobody else could do, and they said, "Why?" He says, "I just have a different box of tools." And that's the secret. What's in your box of tools? So, the information explosion that we're facing right now is a forcing function for how we learn over the next year and the next decade and

over the rest of our career because it's not going to slow down. There's so much right now that's clamoring for our attention that it's easy to let the marketing classify our information for us. So, this repeated framing of knowledge is useless or valuable can't help but stick with us. It unintentionally narrows our future mindset on our continuing education. We select books and conference talks based on utility,

sometimes ignoring our intuition. Now, some of you though are here because your intuition said, "Out of all the sessions, I think I'm going to get something." Now, some of you thinking it's a a magic trick. Regrettably, I don't have a magic trick for this talk. But, uh but tomorrow I do have I I had magic earlier today and I do have magic tomorrow and I did have

some magic yesterday. But, I'm trying to slide it in where it fits and where it adds But, uh but we don't want to dull our natural curiosity. We should embrace it. So, don't limit your education for the wrong reasons. We we want we don't That will rob us of the broader context and the lateral discoveries. And there are so many important lessons that we can learn from,

ideas from the past that are more relevant than ever. We need to widen our learning bands and build the future on the lessons of those who came before us, rather than wasting all of our time and energy relearning them. This isn't easy. Richard Hamming, the guy who said that all knowledge is connected. He said it is not easy to become an educated person. And he's right. One

of the things he said, he gave a set of lectures. Uh and if you want to read these lectures, they're actually outstanding. You can find them online. First of all, I think they're on YouTube. Uh but there's also a book where they collected all these lectures and the lecture notes and it's called the art of doing science science and engineering, learning to learn. And in his first

lecture that kicked off this whole series, uh Richard Hamming, by the way, is another person who's responsible for the fact that our entire world keeps spinning because he developed all the theories around error correction. He said, "In your future, anything and everything you know might be useful. But, if you believe that the problem is in one area, you've eliminated your your insight. He says, "If you believe

the problem is in one area, then you're not apt to use information that is relevant, but occurred somewhere else." So, what are some of the lessons that we keep forgetting? I'll tell you the one I see. I've been seeing almost every day of my career ever since I became an independent software architect, where I work with teams and organizations all over the world to help them solve

their most challenging architecture problems. And there's one that I see show up again and again and again. It's one that we are incapable of learning from somebody We have to learn for ourselves. I think it was the author Douglas Adams said, "Human beings are almost singularly singularly unique in their ability to learn from the experiences of others." And he went on to say, "We are also unique

for our apparent disinclination to do so." So, what is the thing that we all keep learning the hard way? Well, this is Peter Deutsch. Who's heard of him? Okay, this one is nobody. All right, stumped you. But you're going to know who he is after this. But more importantly, you're going to know why he's worth knowing, or at least what to take away from him. And you

might know what he told us. You might know what he gave us. Uh but this is what he said. He said, "Essentially everyone, when they first build a distributed application, they make the following eight assumptions. All prove false in the long run, and all cause big trouble and painful learning experiences." This is the one that I see everybody learning. I also, by the way, I'm not saying

like y'all are dumb and I'm smart. I learned the hard way, too, and not the first time. I didn't learn the first time. I don't know how many times it took me to learn, but it was more than once. So, don't feel bad if you're like, I did not know that. Also, one other thing that I want to mention, he talks about distributed systems. How many people

work on a monolith? Okay, yeah, some of you. Yeah, yeah. Uh it's still a distributed system. Is there If there's a web app, there's a client and server. If it's a database, there's the database There's There There There There you're talking over the network. They're very Sometimes you actually build truly monolithic non-distributed applications, but most of the things we call monoliths are distributed. But, that's an important

point. He says, "Everyone." He called these the fallacies of distributed computing. Okay, now who's like, "Okay, that guy." Okay, a few people. And the rest of you, if you don't know what they are, lucky you, because you're about to find out, and then you can avoid making the same mistakes that we all make over and over and over again. So, what are the fallacies? Well, the first

one is the network is reliable. The second one is latency is zero. The third one is bandwidth is infinite. These are all fallacies, by the way. The network is secure. Topology doesn't change. There is only one administrator. Transport cost is zero. The network is homogeneous. These are the fallacies. None of these These are the assumptions that we quietly make. And these aren't assumptions that we consciously made.

They were like, "Oh, I assume transport cost is zero." Because if I ask the question, "Is transport cost zero?" No, absolutely not. Bandwidth costs money. But, when we're building these systems, they're the the the silent assumptions that don't even announce themselves. That's why we keep making the mistake. So, these were first published in 1994. In other words, from the last century. Kind of like Shannon. So, we

wrote these down in the '90s, capturing wisdom that was already old. Like he'd seen this over by 1994, he'd seen this over and over again. And so he's like, "Yeah, somebody should write these things down so we stop doing this." We didn't stop doing it. CORBA learned them, DCOM learned them, SOAP learned them, REST APIs learned them or or didn't in a lot of cases. Microservices and

other distributed architectures learned them all over again. Serverless is learning them right And with everything to keep up with, who has time to pay attention to nonsense from the last century? There's no tools from the last century that we use anymore. We got all this to keep up with. all of this calls causes big trouble and So, the first one is the network is You have an

app that doesn't handle that isn't ready and waiting for network failures? Cool. It'll just hang there forever, eating memory, holding connections open, waiting for a response that's never coming. And when the network does come back, it's not going to recover gracefully. You're restarting it by hand at 2:00 or whatever time you sleep. I'm usually awake at 2:00 a.m. Some of you are as well. We talked about

that. Two, latency is zero. If we pretend that latency doesn't exist, we're going to write code that floods the network like a fire hose pointed at a garden hose. Packets are going to drop, bandwidth is wasted. And now you've made your latency problem worse. And if you treat it like it is, it you're going to build bottlenecks into your architecture that you're not going to find until

production under load or during the demo. The network is secure. If you assume the network is secure, you're not going to be ready when somebody proves that it isn't. Oh, it's okay. I don't need to worry about, you know, anything for my Docker images that are in the cloud because, you know, it's in my VPC. That's a secure network, right? We don't have to worry about lateral

movement in the network, right? And the thing is every time you think you've caught up, the attackers have already adapted. Oh, by the way, twice on this trip, I run a SAS CRM for professional entertainers. Uh twice under this on this trip, my apps come under attack. And now I'm like trying to uh uh respond to that attack, a distributed a distributed attack over the Tor On

flaky plane Wi-Fi, that's a little stressful. The fifth one is topology doesn't change, but network topology changes constantly. And when it does, your latency assumptions and your bandwidth assumptions are going to go with it. It's a cascading failure that you never plan for because you assume that the map was the territory. Uh another one is you don't control the whole network. Nobody does. Different subnets, different administrator,

different policies. Sometimes they're actively conflicting. Your traffic has to navigate all of it. And if you didn't know that, your packets are about to find out the hard way. Network costs money, real money, building them, maintaining them, running Bandwidth. If it's not in your budget, then you don't have a budget, you have a wish list. The network is homogeneous. Assume every node on the net We assume

every node on the network speaks the same language, runs the same stack, behaves the same way. And if you do that, congratulations, you've inherited the first three fallacies all over again. Now, the thing is this isn't a comprehensive list. That's just what he came up with at the time. We're still learning. Neal Ford, who's in another room right now that uh that I am honored that some

of you chose to listen to me instead of him cuz he's a smart guy. Uh Mark Mark Richards and Neal Ford gave us three more. One is versioning is simple. Compensating updates always work. If you've ever done a distributed transaction, you'll probably wish you hadn't. And the last one is observability is optional. These are These are big fallacies. These are the new fallacies. Learning is a great

I love learning. But relearning is costly. And every time the industry invents a new way of doing distributed system, they announce that they solved it and somebody else quietly points at Peter Deutsch's list. But forgotten knowledge isn't the only danger. It's just proof that the fundamental tensions of distributing computing don't change when the tooling changes. The tooling is just a costume. The tensions are the skeleton underneath.

And sometimes we have the knowledge and we optimize it away. That's a big one. Anybody do uh CS at some point in their lives? Yep, you recognize that graph? You probably have uh a favorite line, don't you? The best line, you know the one. Yeah, there's the best one. The rest of Some of them are terrible, some of them are okay, some of them are great. So,

the timeless wisdom though is that faster isn't always better. I know this firsthand. I once improved many times in my life, in fact. I say once, that's generous. Many times in my life, I have improved systems and made them worse. The thing is the performance is easy to measure. But just because it's easy to measure, doesn't mean it's the most important You know, years ago I got

a job. I was a lead developer on a project. I was really excited. It was first time I was a I was a project lead. It was back in 2003, something like that. And the first thing I did was crash every customer on the first day of business. Yeah. Yeah, that was that was bad. I think I I threw a sickie the next day and day after

that I kind of came in late, took the back entrance. I didn't want anybody to see me. My boss is waiting by my desk. He said, "Michael, team room in five?" I was pretty sure I was going to get fired. Somehow I didn't. But uh they were a little hesitant to let me do very much important for a little while. So they gave me one of those

go away kid you bother me projects. One of those little things that is so small and so easy to not screw up. They said we've got this one particular module in the code that could be performance optimized. See if you can make it faster. Spend the next 6 weeks on it. That was their way of saying we're going to give you this task because we're pretty sure

there's no way you could screw that up as bad as you screwed up the last time. I proved them wrong. So this was back in the day. This application was written in Visual Basic 6 and if you've never worked with it, lucky you. To give you one idea of of of how this language worked, one of the most prominent language features of the language was the the

directive on error resume next. Yep. Yep. Basically you're telling the compiler hey it's a Visual Basic how bad could it be? Just swallow the exception and keep on going. And that's how we rolled back in those those days. Now Visual Basic also wasn't a particularly uh uh let's say performant language. There was a lot of inefficiency in there. And so what I did first thing I did

there was it was we were doing string manipulation. The way VB did string manipulation it was very bloated very inefficient. So I made it more efficient. I rolled my own string class. And encapsulated in that class was a lot of low level API calls that when you would assign something to the string I would basically convert this into bytes and move them in the memory and all

the operations that I would do on that string I was calling those low level APIs to move little bytes of memory around. It was orders of magnitude faster. And then they said that then I realized I still have like weeks on this little and I was bored and curious and I said I wonder if I can make this even faster. So I looked at my code again

and I realized I'm just moving bites of I could implement this in assembly. Now they say you can't mix Visual Basic 6 and assembly. Lazy people say that. It can be done if you work hard enough. I discovered that the compiler for was the same compiler that Visual C++ used. And that meant that I could use all of the same compiler arguments. And so I could actually

compile my VB6 into assembly. Now I couldn't just stop there. There were manual steps that had to happen because when you compile down to assembly, you get all the compiler decoration on the methods and modules. It's going to be different every single time. So what I did was I basically created a stub in VB6 where I had all my methods, nothing in them and then I would

compile down to assembly and then I would look at the compiler decoration and then I would swap out my assembly module, update my mod model module name and method names to have the same decoration and then I would complete the compilation by hand. And we shipped it. It was fast. That code soared like an eagle on angel dust. They were very impressed. Code review reviews weren't really

a And we were doing annual builds at this time because we did one major release a year because our product was for the school system and we do releases over the summer and then they use it throughout the year and then we'd have the next version for the next term. And so after we got that release out and I did the build myself because I'm a team

player. Uh after that I met a girl. I was living in England. She was in America. And I said, "I'll move back to America." So, I quit my job and left the country. And then the next year they're trying to do the build. And it doesn't work. And then they go look at the code and there's nothing there, just the stub. Now, the assembly modules were in

source control, but they had migrated source control earlier that year. And there's two ways to do it. They did it the other way. They just checked in all the new stuff and they took the opportunity to clear out all the cruft that they committed by accident because get ignore wasn't a thing. And they saw my thing and they said, "Oh, that looks like a compiler artifact to

me." And they deleted it. They hired a private investigator to find me in America. I get a phone call one day. Two people at that point had my phone number. I'm looking at it's plus 44. That's England. I'm like, "Uh-oh." That can't be good. I answered the phone. It was my old boss. "Michael." Quick question about that conversion routine. Uh, where is it? So, I had to

explain all of this to him. And uh, he was not happy. And he says, uh, I So, I'm tell I'm telling him what to do. He says, "I have a better idea. You'll do it." So, I negotiated cuz I just moved across halfway across the world. I said, "Uh, okay. Sure. Sure." Um, I'll do it. Uh, so, I negotiated a price of free and a schedule of

now. And I fixed it. I'd learned that lesson the hard way. Let me give you another example. This is a big one. This is an important one. By the way, we're going to 10 after. Is that correct? Okay. Give you another example. And this is a more important one. This is also a more recent one. Sometimes optimizing the wrong thing happens without us even knowing it. And

cuz blind optimization is not just baked into our culture, it's baked into our tooling. Modern compilers don't just translate your code, they optimize it. Whether you tell it to or There are some optimizations are going to happen whether you tell it to or not. Redundant instructions get eliminated, dead branches get pruned, loops get unrolled. And you know, most of the time that's exactly what we want, you

know, except when it isn't and something vital gets sacrificed. See, modern cryptography is mathematically sound. The key spaces are so large that brute force is effectively impossible. So, attackers are forced to get creative. If you can't break the math, you attack the implementation. These are called side channel attacks. And one of the most common ones is a timing attack. So, consider digital signature verification. The system performs

a series of operations on the data and the public key. And if the signature's invalid, verification fails. Simple, right? But here's the nuance. If that verification exits early, it immediately realizes that something is wrong. And it's just like, oh, yeah, this definitely isn't it. Return, nope, doesn't match. That actually gave us a clue. That's what the poker players would call it, tell. You're leaking information. Cuz it's

short-circuiting the moment it detects a mismatch. And so, the total execution time varies and those tiny differences can be measured. Not by a human, but by a machine. So, cryptographic libraries go to great lengths to ensure that all these validations and verifications run in constant time. Even if an intermediate check fails, the algorithm is still going to do all the rest of the operations. To the compiler,

that looks redundant. That looks inefficient. But it's important because it guarantees that success and failure take the exact same amount of time. Dead code got optimized away. Microseconds got shaved off. And with it so did the security guarantees. This was from this year, a couple months ago. How the GNU C compiler became the Clippy of clip cryptography. And here's the thing. He says, "Modern software compilers are

breaking our code." This isn't abstract. This isn't theoretical. This is a real documented Because modern compilers are ruthless about performance, which is usually good. But they optimize only what they can measure. They don't understand the qualitative requirements like security. And they don't have to because they've never been asked to. So, it wasn't a bug. It was a blind trade-off. Performance was privileged. Security was not. Not deliberately.

Not maliciously. Just automatically. And so, that's another piece of timeless We think performance better more performance means better. It's easy get seduced by this idea that there's an objective best in software engineering. The best architecture, the best practice, the best pattern. But there are no best practices, according Mark and Neal again. Only trade-offs. Every single decision privileges The trade-off it's always a trade-off. Every single time. people

will tell us the people the the big influencers who want to tell you what to think they're going to tell you makes them sound clever and important. But it's not it's not architectural thinking. It's preferences and dogma masquerading as universals. And the thing is if we're not thinking about it, the trade-offs still happen. They just happen to us, not because of us. That's how you end up

with an accidental architecture, where systems collapse under the weight of their own complexity. Because we misunderstood better. We we look for shortcuts to get there instead of designing it. It's not new. In 1968, we called this the the uh crisis. Edgar Dijkstra talked about this. He said, "The machines get more powerful, so we rewrite write more code, but our ability to reason about the code doesn't scale

with it." And this was true back when it was mainframes replacing punched cards, and it was true when the web replaced client-server, and it's true right now with AI generating code faster than any human could ever read it or understand it. And so the crisis isn't the machines, it's the gap between what we can build and what we can understand. And this is why architecture matters more

than ever. Because architecture at its core is the discipline of deliberate tradeoffs, not pattern selection, not technology shopping. It's the act of defining what the system must protect and what you're willing to sacrifice. See, this is our filter. We don't start with solutions. We have to start with what matters. We can't start We start with the We start with the problem and then we balance it with

what matters. And in fact, a robust framework for this already exists. It was written down. It works, and almost nobody in our industry has read it. Not because it's hidden, but because it's old, and we assume that old means obsolete. Uh this is one of the things that I wrote about in my book because I discovered a bunch of old stuff, and I said, "Hey, this is

super valuable and more important than ever." But most people never found it. And that was uh architecture design by constraint. You see, sometimes we forget more than ideas. Sometimes what we forget isn't just an idea or a framework, sometimes it's a shape. It's a structural pattern so fundamental that we keep building things without recognizing it. Uh I made a video on my YouTube channel not that long

ago, uh which I'm very proud of. It was the one It was the second video we uploaded. It was the one that took off. Out of nowhere, we made one video, got 100 views, mostly friends and family. This one got close to 10,000. And it was the of phone freaking. Fascinating story. That there was a time when a sound could hack the world. That somebody with a

toy whistle that came in a box of cereal could take over the entire global telephone network with just that whistle. And they did. Boy, did they ever. People used to play games. They would uh they had two phones in a dorm room. And two lines. They pick the first one and they'd start calling different parts of the world. They'd say, "You know what? Let's call India." Now,

back in those days if you were to call India, that would cost you a fortune. So, they didn't call India. They called a free phone number. And then as soon as it started to ring, they'd play that blow that little whistle and suddenly the call disconnects, they're still connected, and now they have access to send whatever commands they want on the phone network. So, they play more

sounds. And they're basically they're they're reprogramming the network to route the call again, this time to India. And that's what they would do. They they would call somewhere and they'd forward the call and forward the call and under sea cables and satellites and over Europe and Asia and all over the place until they'd gone all the way around the world to call the phone next to them.

And then once it finally connected, the phone would ring, they'd answer, and they'd say, "Hello." And then about 10 seconds would pass because that's how circuitous that routing was. 10 seconds later they'd hear, "Hello." You know, very garbled because, you know, you lose a lot of signal over those distances. So, why did this work? Because the control plane for the entire system was the same as the

data plane. The channel that your voice goes over was also the channel that all the administrative commands go over. Does this sound familiar yet? it's a fundamental architectural vulnerability. despite the fact that we found it in the phone network, we also built it into every single computer that exists. This is the Von Neumann architecture. And Von Neumann had a really interesting idea. He's like, "Hey, let's keep

it simple. Let's put the instructions and the data in the same memory space." And then somebody somewhere overlooked a little detail in their C code somewhere. They're not boundary checking. So, you could put something bigger in that variable than it is actually fitting into the variable. And now your data leads into here and your computer says, "Oh, that looks like instructions. I'll execute those." That's every single

buffer overrun vulnerability on the planet because of this architecture. Because the control plane and the data plane are the same It's not a bug in the code. It's a flaw in the shape. We didn't learn that lesson, by the way. We did it again. Do you see it yet? You know where we've done it? Cuz in the age of AI, we have system prompts and user inner

interface or user user input. The prompt and the input are in the same context. Instructions and data share the same channel. This is why we have prompt injection. And this is why prompt injection is unsolveable. It is unpatchable. It is a huge problem. All we can do is have an LLM look at the input and say, "Does this look like a prompt injection?" And it will say,

"Oh, no, this looks safe." And suddenly your uh crypto wallet is getting exfiltrated because you download there was one extra line got added to you to your claw.md file. And this happened to somebody by the way. This is not theoretical. A guy he's like, "I'm going to play with claw code." He downloaded something and it put one more line in his markdown file. And the next thing

you knew, he had half a million dollars in his crypto wallet. And a moment later it was zero. That'll ruin your day. So, I'm getting old. Getting old makes you irritable. But time comes with perspective and a wider lens. So, when I slow out slow down when I zoom out, I see us learning those same lessons over and over again. Sometimes we rediscover them from the source,

but other times usually we just spend a lot of time and energy reinventing what was already there. Not by standing on the shoulders of giants, but by ignoring them and rebuilding the giants from scratch without even knowing they So, if you feel behind, if the pace of change makes you feel like you're falling behind, think about what we just walked through. Boolean algebra, fallacies of distributed computing,

optimizing the wrong thing, timing attacks, architectural constraints, control plane vulnerabilities. None of this is new. And the more I see the more I look at the world, the more I realize there's nothing new under the sun. I had a friend of mine recently we shared a we shared an hour-long car journey he was coming with me to hear me speak. I was speaking at a user group

somewhere in Colorado. And he was he's a he's a software engineering manager. And he's talking about all the problems. He's like, I I you know, we got to figure out how to solve these things. I said, "Man, we figured that problem out 20 years ago. We figured that problem out 30 years ago." He says, "What do you mean?" And I start telling him what the solutions were.

And he said, "Oh, there really is nothing new under the sun." So, sometimes the people who feel the furthest behind are actually the furthest ahead cuz they've I've here long enough to have already learned the lessons Learning the timeless gives you a head start. Perspective to navigate the chaos, the wisdom to filter. So, how do we apply this? Well, it starts with spending more time in the

problem space. This is idea that was first discussed in this book here, Human Problem Solving by Allen Newell and Herb Simon. Came out 1972. By the way, talk about AI. The guys who wrote this book invented AI in 1955. They were doing They did AI first when people didn't even realize that a mouse could exist or a network could exist or anything could exist. When your computer's

processing speed was measured in the hundreds of instructions per second, they were doing AI. The idea got rediscovered in a later book, The Lean Product Playbook, but we talked about these two conceptual spaces. The solution space has the technologies and the tools and the patterns and the frameworks and the libraries and languages, the things that look good on your resume. They have the answer. But the problem

space has the business drivers, the problem context, the underlying need, the questions, the things that will never make it into your AI's context window. That's the value that you bring. That's why developers still matter. So, the problem space might be less interesting, but it's where the questions reside. So, when we explore the problem space, we can ask the right questions. Most people focus on building depth in

the solutions. Well, those people are in danger right now because we got models that are better at the solutions than we are. But the people who ask the right and understand the problem and understand the things that won't fit in a context window. Those are the people who are valuable. That's the shift we need to be making. So, we need to spend more time on the question.

And we need to think. Because it's really easy to get into a rut in the solution space. There is a very famous experiment that was done years and years decades and decades ago called the water jar The water jar experiment looked basically like this. You got two jars. There's no markings, but we know one holds 29 oz or ml or whatever units do you want to use.

We use feetsies and silly things in America, but you know, the rest of y'all have like are doing better. We got some catching up to do over there. I'm just I'm just saying there's issues. But we want to measure exactly 20 oz. We got a jar that can measure 29. We have a jar that can measure three. How do we do that? Well, we fill up this

all 29. Then we take jar B, we fill it up once, and then we have 26 in there, fill it up once, and we have 23 in there, we fill it up one more time, and now there's exactly 20 in there. We don't need the markings. We can figure it out. So, that was the idea. That was the worked example. And then we do it again, right?

Uh right, we we subtract jar B, subtract jar B, subtract fill A, subtract jar B, subtract right right there we go. So, we can measure exactly 100 oz. Think about that for a moment. How do we measure 100 oz? we got 127 there. We fill that one all the way up. Then we subtract this. Now we have 106. We subtract that twice. We get 100. Easy. Okay?

Yeah. Fill up jar B, subtract A, subtract C, subtract C. And then the second question. Uh 99 oz. 163 subtract jar A, subtract jar C, subtract jar C, we get 99 oz. Then we do it again. 55 oz. Okay, easy, right? Fill up jar B, subtract jar A, subtract jar C, subtract jar C. This was the pattern that was showing up in the And people were doing

this as as ex- as as as as subjects of this study. 21 oz. Right, easy. Fill it up, subtract, subtract, subtract. Now, 25 oz. And everybody lost their mind on this They said it wasn't possible. Who says it's not possible? Okay, okay. Because people got so used to that one answer, they over-relied on it and they stopped learning how to think. Exactly. And you know what happened

when the when the examiners told that to the audience? They got angry. One guy flipped over the table. One guy stomped out of the room. He's like, "I don't want to be in your stupid study." Because he'd forgotten how to think. He got so used to the answer, he forgot how to ask the question. So, I'm going to talk the last thing in the last couple minutes

I have. I'm going to talk about this concept of rewilding. This is a concept in conservation where you reintroduce a species into an ecosystem that was eradicated. And when you do that, amazing things happen. In my home state of Wyoming, they got rid of all the wolves. And then they realized that that was a bad idea. So, in 1995, they reintroduced the wolves back to Yellowstone. Everything

changed. Grazing patterns shifted. Vegetation recovered. Beavers returned. Rivers changed course. That single reintroduction cascaded through the entire system. So, our industry eradicated the wolves. Not maliciously, but in the same way we forgot our foundation. And that and that's the that's the thing. The practice of deliberate decision-making, constraint-based reasoning, understanding the why before optimizing the how, these have been crowded out by speed and novelty. We can be

faster at the cost of understanding, but we lose the ability to reason about what we built. We accumulate legacy, and legacy became a dirty word, even though it's where most of the value lives. We became an industry that produces endlessly, but can't recycle, can't refurbish, can't even understand what we've already made. But AI is the forcing function. It's actually the crisis that forces the wolves back into

the ecosystem. The thing is that it would the the scarce thing is no longer the ability to produce code. It's the ability to define what the code must protect, to reason about the system, to make the deliberate tradeoffs, to ask the right questions before generating the answers at scale. Which means the fundamentals matter in the age of AI. It's not learn assembly or read every single paper

from 1968. It just means that the skills that were always underneath the code, the systems thinking, the architectural reasoning, the understanding tradeoffs, asking the question, "What problem am I actually solving?" before reaching for a solution. Now, these are the primary skills, not the background skills. AI didn't make them obsolete, it promoted Shannon didn't start with digital circuits, he started with a switching problem. Deutsch didn't start with

a framework, he started with a a list of things that break. The compiler didn't fail because it lacked speed, it failed because nobody defined what matters. The blue box wasn't a bug in the code, it was a flaw in the shape that nobody recognized. Every pioneer we talked about started with a problem. That's the lost wisdom, not the answers that they found. The It's the way they

thought. Problem first, constraints first, then and only then solutions. So, you don't have to learn all of them. You just have to understand why you choose any of them. That's a fundamentally different skill, and that's the one that lasts. In a world where AI can generate anything, the person who can define what should be generated, who holds the conceptual integrity of the system, is not the person

who's behind. That's the one that the world has been waiting for. Thank you. >> [music]