The Jordan B. Peterson Podcast - 272. Zeroes and Ones: Into The Depths of Computation | Jim Keller

Episode Date: July 22, 2022

James B. Keller is a microprocessor engineer best known for his work at AMD and Apple. He was the lead architect of the AMD K8 microarchitecture and was involved in designing the Athlon and Apple A4/A5 processors.Jim joins Dr Jordan B Peterson to give us a look behind the scenes at Apple, Tesla, and AMD, and explain the inner workings of your everyday computer.—Links— Hear Jim talk more about technology here: https://www.youtube.com/watch?v=32CRYenTcdwFollow Jim on Twitter: https://twitter.com/jimkxaFollow Jim on LinkedIn: https://www.linkedin.com/in/jimbkeller/GoodRanchers.com/Peterson or use code: PETERSON at checkout!Get $30 Off + Free Shipping!ExpressVPN.com/JordanGet 3 Months FREE!// SUPPORT THIS CHANNEL // Newsletter: https://mailchi.mp/jordanbpeterson.co... Donations: https://jordanbpeterson.com/donate // COURSES // Discovering Personality: https://jordanbpeterson.com/personality Self Authoring Suite: https://selfauthoring.com Understand Myself (personality test): https://understandmyself.com // BOOKS // Beyond Order: 12 More Rules for Life: https://jordanbpeterson.com/Beyond-Order 12 Rules for Life: An Antidote to Chaos: https://jordanbpeterson.com/12-rules-... Maps of Meaning: The Architecture of Belief: https://jordanbpeterson.com/maps-of-m... // LINKS // Website: https://jordanbpeterson.com Events: https://jordanbpeterson.com/events Blog: https://jordanbpeterson.com/blog Podcast: https://jordanbpeterson.com/podcast // SOCIAL // Twitter: https://twitter.com/jordanbpeterson Instagram: https://instagram.com/jordan.b.peterson Facebook: https://facebook.com/drjordanpeterson Telegram: https://t.me/DrJordanPeterson All socials: https://linktr.ee/drjordanbpeterson#JordanPeterson #JordanBPeterson #DrJordanPeterson #DrJordanBPeterson #DailyWirePlus #Psychology

Hello, everyone. I'm pleased to welcome Jim Keller to my YouTube channel and podcast today. Jim is a microprocessor engineer, known for his work at digital equipment, AMD, Apple, Tesla, and Intel. He was co-architect for what were among the earliest of 64-bit microprocessors, the EV5 and EV6 digital alpha processors designed in the 90s. In the later 90s, he served as lead architect for the AMD K8 micro architecture,

including the original Athlon 64 and was involved in designing the Athlon K7 and Apple A4 through seven processors. He was also the co-author of the specifications for the X8664 instruction set and hyper transport interconnect. From 2012 to 2015, he returned to AMD to work on the AMD K12 and Zen micro architectures. At Tesla, he worked on automotive autopilot hardware and software designing the hardware three autopilot chip. He then served a senior VP of Silicon engineering, heading a team of 10,000 people at Intel. He is president, president, president and CTO at Ten's Torrent Building AI Computers.

He's also my brother-in-law, and we've talked a lot over the last 20 years. He was a friend of mine before he married my sister. We've known each other for a very long time since we both lived in Boston. So I'm very happy to have you to talk to you today, Jim. I'm really looking forward to it. So thanks for agreeing to do this. Everything. So let's walk through your career first.

It takes some unpacking. Your resume takes some unpacking to be comprehensible, I would say. So let's start with digital equipment. You were working on very early stage sophisticated microprocessors. So tell me about that. The long story is, I graduated colleges in electrical engineer with a bachelor's and I took a job in Florida because I wanted to live on the beach. And it turned out to be a really interesting job as it Harris. And I turned out to be a really interesting job

as it cares. And I spent like two years working in the labs, sticking the up electrical equipment, and doing some networking stuff in some digital design. And at some point, a friend told me I should work at digital. So I read about digital. And I literally read the computer architecture manual for the back 780 on the plane and the way to the interview.

And then I interviewed them with a whole bunch of questions because they just read this architecture spec, which I didn't know that much about, to be honest, but I was kind of a wiseass as a kid. And they hired me because they thought I was funny and I think. And so I got my, you know, architecture education working on the Vax-8800, working for a dining bot steward, along with some other really great architects. I spent about seven years in that group, you know, learning to be a processor architect. And then I spent a little time at digital research in California for six months

and then went back and joined the Hudson team where they were building alpha processors and became co-architect with Pete Bannon on EV5 and with Dirk Meyer on EV6. Now those chips... 15 years and we worked on, I would say three very successful shipping products and then a couple other products that didn't get to market. So those chips from what I remember were remarkably ahead of their time, but that didn't seem to save digital equipment corporation. Yeah, fair to say. That's definitely fair to say. But digital literally made the world's fastest computer in the years they were going out of business. And there was a complicated market dyno in the digital. Very successful building mini computers and mini-compure age, which replaced the mainframes to a large extent.

What they missed about on the PC revolution and would say workstations. And they had a big expensive computer mindset rate when computer prices were falling apart. So we were building really fast processors for server and workstations and the market had kind of moved on and let's say a lot of crazy things were going on inside the company at the time. Yeah, well, we're going to return to the topic of crazy things going on inside computers,

but it's interesting to note right there so that that's a situation where a company has a great product, but doesn't know how to launch it into the marketplace or is blinded by its own preconceptions. It can't even say necessarily what it is. Gordon Bell was CTO and he was a really brilliant computer architect but he also had really good, let's say, observational skills. And like during midway through the Vax City at hundreds, he decided the technology technology were using was too little too late and redirected the program and it became a very successful product because he knew I was going on

in major decisions like that. When he left, I think that it will became an argument between business unit managers, not about technology. And also was a great technology, but it went into business units that were aiming at high prices and high margins, not market penetration, and not basically keeping up with the software revolution that was happening. So, Ken Olson was a great manager, but he wasn't a technical leader.

And without Gordon Bell, the company kind of lost its way. When companies lose their way, they fell. And they fell fast too. You know, they went from record profits to losing a billion a year and they kind of rectified that for a little while and then shall drop off again and over. Yeah, well, one of the things I've been struck by watching your career and talking to you over the years

is exactly that. The rate at which a company that appears dominant can disintegrate and disappear is really quite something, quite stunning. I think Fortune 500 companies tend to last no more than 30 years. That's approximately the span. That's not a tremendously long period of time. So there's always dominant companies and always a handful of dominant companies, but the company that's dominant tends to shift quite quickly. So we should return to this a couple of times

as you know the classic S-curve and economics. You start out low, you solve a problem, you ramp up, you plateau, and then you fail. And this dominates business and dominates humanity at some level and it plays out over and over. It sounds like you didn't have... How is it that you managed to do this job? You intimated when we were talking that you weren't really trained for it. You were trained as an engineer. Is it a bachelor's degree in engineering? How prepared were you as a consequence of your degree for any of the jobs that you undertook?

Training is highly overrated so so a good engineering degree is mathematics basic understanding of science and some smattering of communication skills You can probably do a great engineering degree in two or three years if you're dedicated to it You know the the things that stretch my brains the most when I went to college was with math and mechanical engineering and Penn State with the Penn State and they used mechanical engineering and massive stew of the weed out courses to find out if you had the chops or the gumption to get through engineering. So there was a fairly high failure rate there. But mechanical engineering is a really

interesting discipline because you have to think, think about solving mass problems spatially, like, you know, do things like how do you calculate the force on a rotating accelerating object? Like it's somewhat complicated and it makes you really think. So you have to learn the thing. And in engineering school, you never answer a multiple choice question. You learn stuff and firmness and stuff but then you calculate and to understand what the result is and the problem sets are like little design exercises. So how much of it do you think is pure screening, let's say, what wouldn't be pure screening, but fundamental screening for conscientiousness and IQ and how much of it is learning to think. How much of the education process is that like if you're going to hire an engineer, are you hiring fundamentally on the basis of IQ and you get smarter people from the top schools, or do you think that the engineering training actually does prepare people for a technical career?

Well, it depends on the engineer and depends on the school and depends on their approach. So my IQ isn't super high compared to really smart people. I mean, it's high enough. When I went to college, it took me about a year and a half to learn how to think properly and I found for me personally. I had to do the work on a regular basis early.

I didn't study for finals. I wasn't the kind of person that could pick up a book, understand, and get an aid the next day, and then forget about it. I can't do that. I had to learn how to do the work, go through the mechanisms, automatize some of the basics, so I didn't have to think about them so hard, but literally let my brain work on this stuff

so that I could use them to go problem-solve. And especially in engineering, there's lots of different kinds of engineering. There's like highly technical stuff we turn to crank, like a skilled lawyer might, but there's other stuff we have to be really creative. You have an unsolved problem and then we solve it for you. And as an engineer, you have a skill set, right? But you have to apply it creatively. And there's

a lot to high-eye people who aren't creative and there's low-eye queue people that are creative. And you find in a big engineering team, there's a real diversity of personality types. There's open-minded people, country adjust people, you know, various people. And it takes many different kinds of people working together to do something sophisticated. I'd say, you know, like some of my senior classes in engineering was just going a little deeper on stuff I already knew. Like I could have left it up after three years and been just fine. But I do think the work I did did help me be an engineer, but then the problems I saw,

I worked on after I graduated college. In school, most of the problems you're given, there's no answer, but they're in a book, in a room with 20 people and they're doing the same stuff. When you're doing an engineer working in the company, they never have two people the same thing to do, because that's waste of money. And when you start engineering, you're given relatively small tasks by, you know, your manager or supervisor.

But as you go along at some point, because again, on who you are, You're working on stuff that you don't even know how to deal with. There's no answering book. But it's not like physics. Like physicists, there are funny points I realize this the other day. Physicists, they're supposed to work on stuff that's unsolved. Whereas engineers, there's a big repertoire of engineering, and then it's reduction of practice. And then the world is complicated.

So you go build a new bridge that's never been built before. It's not like bridges are unsolved problem. This particular bridge hasn't been solved before. There may be unique challenges to it, but it's not like SIDSX, where you're looking for an unknown particle, or there's a pretty big divide unique challenges to it. But it's not like SIDSX where you're looking for an unknown particle or, you know, there's a pretty big divide line between engineering and insurance. Engineers typically work in domains where there's many, many knowns and unknowns are

problems of the combination of, you know, reality, you know, complexity. Whereas SIDSX physics and principles, they're working on stuff that's fundamentally on. And as soon as it's known, it happened to move on because because then it's engineering like like this is the, you know, translate the unknown into engineering and engineering applies known concepts to unknown problems. Okay, so you, okay, so now you, you went from digital to AMD. And you learn how to design microprocessor. So at AMD, you went from digital to AMD.

And you learn how to design microprocessor. So at AMD, you worked on the K8. And at that point, AMD was losing ground to Intel. Yes. And so how did you fix that? So basically dirtmire and I work co-architects of 86, the third alpha chip. He left about, he left a digital TND about a year before I did, he started the K7 project and I joined, I started

the K8 project and then helped and I worked with him significantly on the K7 as well. How do we do it? Well, yeah. So those were 64 bit chips that you guys designed to compete with the the fun the Intel chips that have dominated the computer, the home computer market at that point. Well, so there's a funny thing, which is like at some level building fast computers isn't that far right? So you have to have a goal like so a lot of designers, so they have a design. And then the easiest thing for the next one is to go look at that design and make it like 10% better, 20% better. But every one of those designs has limitations built into it. It's sort of like, if you buy a two bedroom house, you can add one bedroom. You can't add eight bedrooms. If you want to

eight bedroom house, you have to build a different kind of house. So every design build has kind of a range that it can play. And you build the first one and you know you can make some improvements, but some point the improvements don't really help that much. Right? So A&D, they had a design called K5, which for complicated reasons didn't work out that well, and they lost ground the Intel. Before that, they had literally the 386 and 46 AMD copied Intel's designs. They were a clone manufacturer.

The K5 was their first design and didn't work out that good. And then they bought a company called NextGen, which had K6, which is an okay design, but it wasn't competitive against Intel. And then K7, Durk was the chief architect of, and he designed a computer that was competitive in the head of Intel. And some of that came from our work at Digital

on UV5 and UV6, Terkwater on UV4 as well. And some of it was just saying, in this day, we have this many transistors because you get more transistors every generation. So you can basically imagine you're building a house. Suddenly you have way more bricks and way bigger steel beams. So your idea about what the build has to scale with that. And then K7 was a 32-bit chip, and then K8 was a 64-bit chip, somewhat related to that as it turned out,

but also was built to be bigger. And what I did is I wrote the performance model. I came up with the basic architecture and I started organizing the team around building it. And while we were doing that, we also wrote the thing called hyper transport, it's a fact, which became the basis of essentially all modern server computers

or what's called two socket servers. When we wrote that 98 in 2002 or 2022, they're still building them that way. And when you say you wrote it, what does that mean? What does the process of writing that entail? What is it that you're writing? And how do you do that? I'm dyslexic. So I wrote a complete, you know, protocol spec about how to computer chips talk to each other in 18 pages, right, which is relatively terse. And there's a couple of pictures and, you know, computer protocols are pretty straightforward. There's a command

There's the address we're talking to. There's the data you're moving. There's some protocol bits that tell you how to exchange commands Right, and then jerk jerk that to spec and said you mind if I flesh it out a little bit in three days later You send me a 50 page version of it which clarified all the little bullets and then that specification We literally use to build the interface between K8 chips. Right. So there's a couple levels design. What sort of impact did that have, what sort of impacted that have on the on the broader world? What's the significant, it's very difficult for non-engineers to understand any of this. And the market. Ground. AMD market share and server went from 0% to 35% which was a huge impact to the business. And it became essentially the standard because apparently Intel had a version of that, but

it didn't go to market. But after up to run came out the market. Intel built a similar version, some more protocol about how to connect the small number of processors together with that kind of interconnect. And then that, let's say design framework became standard in the industry. So if you go into a Google data center and you pull it out, it would be two sockets with an interconnect between the two of them.

Each socket will have memory attached to it. And they call it the twoP server, 2 process server. And it had a really big impact. We didn't do it because we thought it was going to have a big impact. We did it because we thought it was a better way to build computers. And the day and day, we were somewhat resource constrained.

So we couldn't build a thing that looked like a big IBM server. So we built was basically a small server with the minimal amount of interconnect between it. So it was a little bit of creativity by constraints. Steve Jobs line. And what function does those servers have in again in the broader world? What are they doing now for people? Well, it's basically the entire cloud. It's all Google and Amazon,

Facebook, all Microsoft is there. But here's the interesting thing when we built them, the big server guy. Server is used to be back plenty like this big with multiple CPU slots, multiple memory cards, multiple IOs slots, and the server manufacturer thought the server was oriented around the back. The IBM, HPDL, they all turned this down. But all the little start-ups at the time like Google, were using PCs as low-cost servers. And we made this basically to take a PC board and set it put in one computer on it, you could put two, which radically saved the money.

So when AMD made those kinds of servers, it was a way lower entry point for server-class technology. And the little start at the Pine News that, and then over 15 years, disrupted all the big server manufacturers. So it's one of those, I couldn't say we planned it. The constraints that we had to target in market, we didn't know that it was going to become essentially

how servers should build for 20 odd years, but it happens. After AMD went to Apple, you worked on the A4 through seven processors. Well, I worked at two startups that did processors for networking, side-byte and TA-7. And that was probably about five or six years. And then I joined Apple in 2008.

So I guess I was, now I'm most of the eight years. I was AMD 98, 98, 99, 2000. And then I worked at startups for about eight years. And then I went to Apple. Yeah, and worked on mobile processors. And so tell me about those chips and what you did at Apple. Where's that? Of course.

I had some friends who were working at Apple and they wouldn't tell me what I was going to work on. So when I interviewed there, they said, oh, you should have come here and be fun. And I didn't actually know what I was going to work on. And they had a group called Platform Architecture run by a guy named Mike Colbert, who was like the unofficial CPL of Apple. He worked for Steve Jobs. And he had a group of architects that looked at what Apple was doing and figured out what

they should do next. And I worked on a MacBook Air definition, like I wrote to Power Management back into this mother architecture work, which ultimately was an end to each up called MCPA 9. And then I was one of the chief architects of four generations of SOCs, which is called A4, A5, A6, A7. And we did a lot of stuff there, but the division was, you know, both... The SOCs are what? Yeah, system on it, yep.

Oh, yes. The pack of computer into a phone. You have a piece of Thil about that big and all the components CPUs the GPUs IO or all the same chip and when they first started building phone Shops, they were considered to be very slow low cost, you know, very integrated chips and And we thought if you look ahead, because technology shrinks about every two years, and about six or eight years, we'd have enough for insistors on a phone chip, that would be more powerful than a PC at the top. So we started architecting computers, interconnects, and other functions so that when we have enough for insistors, we could literally have a high-end desktop on a phone.

And Apple's DNA is you create the product that kills your turn card. You create the product that kills? So every company has a great product and they worry about competitors coming in and kill it. And Apple wanted to be the first to kill their own products So Steve Jobs sought phones and tablets with replaced PCs And he wanted to be the first to do it. He didn't want somebody else to do it to him And did you know jobs?

No, I've seen him a couple times. I said hi to him twice Um, I felt like I knew him pretty well. Everybody at Apple did. Like when Steve wanted something done, everybody knew the next day. My boss, Mike, talked to him every single day, multiple times sometimes. Mr. Joe, we'd walk in Mike's office and he'd be holding the phone out like this because Steve is pissed. We were like, yeah, asking you to. So that, but Mike could translate, but Steve wanted to do that into engineering stuff, and Steve trusted Mike a lot. And he could translate to vision into engineering.

Steve's judgment on stuff like this is spectacular. So, and did you have any sense? Do you have any sense of why that is? I mean, Jobs was famously, obviously originated Apple and then was famously brought back into save them when they were in danger of extinction and then in fact did seem to save them. And you never know when you hear about these things

from the outside, how much of that is sort of a mythologization of a person and how much of it is, you know, this person was really singular and unique. And so, and so, and so, and so, you know, this person was really singular and unique. Yeah. So definitely singular and unique. I mean, your psychological parlance, as we talked about, he would be considered high in openness and disagreeableness. Right. And I think negative emotionality, like he was a very difficult person.

But the solution to, you know, things could go really bad. And being disagreeable was, I'm going to make it as great as possible. And he's willing to take the risks for that. You know, his public persona was very well practiced. Like you used to say, the worst the practice for the, you know, Apple keynotes, the better they would go off. Like he was throwing iPhones, one of the iPhone pre-launched practices because nothing was right. But then when he showed up and his persona of technical explainer, let's say,

that was very real, that's what he wanted to portray. We believed every single bit of it, you could tell. So in the engineers, on a joined Apple, I watched some of his early keynotes when he came back to Apple and changed the Max. It's inspiring. But it's also super tough, right? Because he went into a company that was very dysfunctional.

Had a whole bunch of engineering groups doing basically random stuff. Let's say senior managers who felt like they owned their product lines and what they were doing. Steve wanted them to do what he wanted them to do and they didn't want to do it. I'm pretty sure he cleaned housework thoroughly. He famously reduced the product lines. Who knows how many products is like four? You know, there was consumer and professional.

So do you think it was that disagreeableness? I mean, we hear all the time now in the modern world about the necessity for empathy and so forth. And that's the agreeableness dimension. And you're making the claim that jobs was low in agreeableness and that he was able to kill off malfunctioning projects. And that's not exactly a nice thing to do.

And just to go through a room full people dedicated their life in the last five years of their work, five years of their careers, building products that you can sell. And you say, we have to do something completely different. Everybody's, you know, every day as an engineer, you're working something you embrace it. You love it. You care about it. Like, engineers are very emotional people somewhere in their point of little souls, right?

So, but if it's not working out for whatever reason, you have to do something different. And if you listen to everybody, you'll never change anything, right? It's difficult to get people reoriented. Now, another line you came up where it came from is you run fastest when you're running towards something and away from something. Yeah, that was from animal experimental literature. If you threaten a rat and offer to reward simultaneously, it will run faster towards the reward than if you just reward it.

Wait, because you get all your motivational systems on board that way. Yeah. So, Steve was very good at the vision. We are going to build this beautiful computer. And you better go down, Bill, now, or you're going to die. So that was his, okay, so the openness, the openness, that's the creativity dimension, that gives him the vision. He's extroverted, can he communicate enthusiastically? He can certainly put on the act, I have no idea if he was expert or not, I never saw them

be extroverted in a natural setting. I've seen him walk around, like I said, we'd see him in the cafeteria. He was visible on the Apple campus even until his last days. He didn't like to be bothered, like you didn't go up to say, just even say, hey, Steve, how's it going? Right. Well, that would be reflective of basic disagreeableness, too, right? You know, it's hard with, it's hard. Sometimes people can communicate very effectively, communicate a vision because they are high in openness, extroverted people are enthusiastic and assertive, so they tend

to be verbally dominant and can inspire people because they generate a lot of positive emotion, but that can be mimicked by openness. So we have to remember, Steve was part of Pixar and very much part of Hollywood and creating movies and creating personas and characters and archetypes. Well, he was super well grounded in how that stuff works and what works and doesn't work about it. Right, and he had a non-airing eye for beauty

and elegance. And he would fight for that. And that's hard, it's very hard to fight for beauty and elegance, and I suspect it's particularly hard, perhaps, maybe I'm wrong about this, but I would think that would be a hard sell to, to at least a subset of engineers. Yeah. So another, this is explained to my boss, the Tesla was, I worked both for Elon and for a guy named Doug Field. And Doug said there's this, no, there's this productivity graph versus order. So at the origin is zero productivity and chaos, right?

And then as you add order to your design methods, your productivity will go up. And what happens with engineers is they understand that it's a better process. You think it's a better train, they get better, working together. Every single thing that makes the whole organization more orderly improves productivity. Unfortunately, that peaks at some point. And then too much order productivity goes down. And so then, as I say, any idiot can see, you should be at the peak. No, enough order to really be effective, but not so much order you grind to the halt.

But why can't you stay there? And the reason is, once order takes over the organization, it's unstoppable. Right, it feels good. You get even better at doing what you're doing. You get even more organized. You micromanage, you're trying even better. You close out all the creativity, you're not open to change. A whole bunch of bad things happen. You shut out the disorder to be people who actually know how to make a change and do something

creative. And your organization dies. So successful. I think the jobs was conscientious as well. You know, like with he in or with working 18 hour days was, I know he was up in the middle of the night because he called Michael on that stuff. Well, the point is, both Steve and Elon with counter forces, the whole thing is going to be a lot of work. like was he in or not working 18 hour days was I know he was up in the middle of night because he called Michael on that stuff. Well the point is both Steve and Elon with counter forces the order

right you have to be really strong to avoid your organization getting captured by order. Well order also has this remarkable air of moral virtue right because it's yeah yeah it's pure and it's efficient. Everything about it feels good. But it's like alcohol. The first drink feels right, the second feels okay, the third one not sick or anything. But you know, you keep remembering what the first one did, so you drink it. There's lots and lots of processes, where some is good, too much is bad, but the counter force the more is weak. And that's the thing that, you know.

So Steve was interesting because he was simultaneously super creative and had visions which could inspire people, but he also prevented the company from being over-organized and preventing him from doing what he was doing. And that's hard because people, like I said, preventing them from doing what it was doing. And that's hard because people, like I said, they get committed to what they're doing. Yeah, well, it's an open question. Like imagine that the creative process has a productive component and then a culling component. And the productive component looks like it's associated with openness, but what the culling component is open to question.

And it does seem to me that at least upon occasion, it's low agreeableness. It's the ability to say, no, we're going to dispense with that. And to not let anything stand in the face of that decision, which would also include often human compassion. Yeah, and people have different approaches to it. Like, jobs would call things so they weren't beautiful for, they weren't great. Elon Musk is famous for getting the first principles and really understanding the fundamentally and cuddling from a standpoint of knowledge.

Yeah, and you've asked me, what makes an engineer great? So you have to have the will to creativity. Now there's lots of engineering jobs that aren't creative. Like you need a skillset, you can exercise a skillset. But if you're gonna build new things, you need to be creative. But you also have to have a filter good enough to figure out what's actually good and bad.

Like I know a lot of really creative engineers and they find the new thing excited and they go down the rabbit hole on it and they can work on it for six months and nothing to show for it. So you have to have that conscientiousness. I don't know if it's conscientious, but this is a real bulldozer that tastes on how. Well, the conscientiousness would keep you working in the direction that you've chosen and doing that diligently and orderly,

the low agreeableness, well, that's the open question because agreeableness is such a complicated dimension. There's obvious disadvantages and advantages at every point on the distribution. I mean, disagreeable people are often harder to work with because they don't care much about your feelings. But one thing I've noted about working with disagreeable people is you always know what they're thinking.

And if you want someone to tell you what's stupid and wrong, they're perfectly willing to do that. Yeah, I used to wonder. And so Dirtmire was a disagreeable manager, but he could tell you what was wrong with what you were doing in a way you would go, okay, like he was very unemotional about it. Like he could gem, I really like this and this, but this isn't working. Shit, like what are weemotional about it. Like, he'd go, Jim, I really like this and this, but this isn't working for shit.

Like, what are we gonna do about it? And you just would just be all shots matter facts. I would say when I was younger, I was a lot less disagreeable. I'm fairly open-minded. And I liked creating stuff, kind of stuff, things. But then I saw enough things fail over the years because we didn't make the, you know, let's say the hard choices about something.

And then, you know, you hate to work on something for two years and I would go away because at some point you realize you're doing a couple of wrong things and you didn't do something about it when you could. And so, as a manager and a senior leader, I'm somewhat famously disagreeable. I'm part of it's an act to get people to move and part of it. You know, I believe that I can't have people dedicate themselves to doing bad things for very long because it'll bite us. Yeah, well, we've talked a little bit about this too, but the moral dilemma between agreeableness and conscientiousness, they're both virtues. Agreeableness seems to me to govern short-term

intimate relationships like that between a mother and a child, and it involves very careful attention to the emotional reactions of another person and the optimization of those in the short-term, but conscientiousness looks like a longer term virtue. And they come into conflict at some point because sometimes they come in the midterm. Yes. Right. Yeah.

It's, you know, it could just be, you know, how our brains see the future. But it's like, you know, if you're managing the group and you have to fire somebody, it's hard, right? But do you want to fire five people an hour or everybody later? Like once you've internalized that and taken responsibility for that decision, then making you know, management, leadership, position choices is always hard, but it's so much better to make them and then succeed than it is to fail because it couldn't make a hard cause. Yeah, well, it isn't obvious at all who's got the upper hand, you know, someone who fires early

out of necessity, but is accurate and looking carefully or someone who, you know, is willing to let people drag on. I'll give you two counter examples of that. So Jack Wallsson's book, it's great from the gut, a weird thing. He said, you know, once you have a doubt on somebody you never had fast enough, which, you know, took me years to really believe that. And then the other weird one is people say, have this organization of 100 people and there's five, five people that aren't working out, but I'm not sure who they are. So I'm going to be really careful because I don't want to accidentally fire a good person. Right, that makes sense, right? You've got five bad people, you know, maybe you figure out who two or three of them are,

but there's this other group of five or ten, you're not sure which ones are the wrong ones. Here's the sad truth. There's a lot of people in the world. You're better firing too many than too few. And how did you come to terms with that emotionally? I mean, look, we have a mutual friend who fires people with quite great regularity, and I've talked to him, and he scores very high in disagreeableness, and I talked to him about firing, which he's done a lot of, and he was actually quite positive about it. He said, I don't fire anyone who I don't think is causing more trouble than preventing. And so by firing the person that I'm firing, I'm actually doing a very

large number of people, including potentially that person, a favor. He didn't bother him, but he was temperamentally wired that way, I would say. But I would say, you know, digital equipment went bankrupt because they had bad people who didn't fire. I've seen many groups fail because they couldn't clean house, right? And the impact on, you know, the greater good question is super easy. You wanna say 90 people or, you know, lose 100.

So that's true. The thing that took me a while to realize that, the world needs shaking up all over the place and individuals do, right? A lot of people who are not doing too good, they need a wake up call. You give them a bad review and they kind of shrug it. They're like, what are you going to do about it? It's like a spoiled kid, nothing, right? But when they actually get fired, they really have to do some soul searching. And then the fact that if you're doing something good, there's always a queue outside the door and more people.

And here's another way to think about it. Take a group of 100 people and rank them from top to bottom. Human beings, by the way, are really good at this. You have four managers in the group, except for the manager's individual friends. They'll tend to rank the 100 people the same way. I've done this experiment many times. They were really good at ranking. groups except for the managers, individual friends, they'll tend to rank the 100 people the same way. I've done this experiment many times. They were really good at ranking.

And there's a little bit of what are you ranking for? You're ranking for creativity, productivity, conscientiousness. But if you set that criteria right, people rank pretty well. If you have 100 people in your group and there's 50 people outside, the distribution of those 50 people is around the average. Helps a team, right? So there's this idea that you fire the bottom 10% of a team, because the random people you hired will be better

on average than the bottom 10% of your team, right? It's just math. On friendly statistics. But yes, I get the argument, right? Right. It's just math. On friendly statistics. Right. But yes, I get the argument. Right. Problem is, every company that does that, first it gets gained because managers hire bottom 10%

owners. So when they get the fire that's 10%, they don't have to fire their friends. Right. And it also really is hard on morale. Like people bond and there may be people in the bottom 10% of your group that are the social glue of the organization. So you may be inadvertently taking out the stuff that makes the team work. Right. Well, that's a measurement error too, right? It means that your criteria for competence aren't broad enough. Yeah. That's tough. At the point, maybe you're ranking a little wrong, but in fact, on morale is high. Teams generally speaking, Rory Riggs was CEO of AMD when I joined.

And we had a big layoff, which we had to do because we were running out of money, we're broke. And when we all just settled, we landed on just the right amount of people for the money we had. And you basically register right, I can say, you said, guys, teams have to grow. When you cut, you always cut further, and then you grow. People aren't happy unless they're growing, right? It's like when you prune bushes and stuff,

you don't prune the bush to where you want the bush. You prune the bush past that point, so it grows out and it looks nice, right? Things have to grow. It's really an amazing dynamic. Yeah, well, and it's never clear how much death there is involved in growth and the pruning in energy is exactly that. And this is harsh stuff, obviously. But you look on the one collapse or another. That's the thing that's not harsh. Because it's beautiful when you've ruined your

bush and it grows back beautifully. It's great when you rebuild an organization. That's really strong and powerful because you made the right calls, right? Like this isn't just negative stuff. It's hard stuff to do, that great, something really great. Like when I joined AMD and what was it 2013 or something like they had two product lines you know bulldozer and jaguar and they're both failing and I

had I can't I canceled both products like okay and so what was the human cost of that I would say both to you and and also to the people that were involved well I did I did the math on it. It's like, you know, we needed to be building a building bedroom houses and you're trying to add six bedrooms to a two bedroom house in the one case, both never going to work. Yeah. So you saw that as doom to failure. And the other one was structurally screwed up.

It seemed to be the right ballpark for the performance we should get, but the way it was engineered and built was sort of like, you know, you let the plumberummer do we architect and the house looked like shit. And it was difficult. I, you know, for a complicated reason, technical reasons, there was no path at it where they were. And when I realized I had to cancel them, yeah, I was sleepless nights here. We had revenue on that. We had people committed to it, people really liked it. When I canceled it, especially on the Jaguar team, a significant number of people quit, was they were angry about it. There was some pretty big organizations, there was some management, we had to let go. The best architect at the time, well one of the best architects at AMD was, he really was my way or the highway and He could not communicate what he was doing.

So I let him go, which is strange thing to do. So if you'd ranked the organization, you're ranked on top and I let them on those guys go, because he was ineffective working with the team. And how did you justify that to yourself? And how did you check yourself against stupidity and ignorance and self-interest and how did you know that what you were doing was right? Well, I'm a little lower in country interest than I should be first and earlier, first of all.

So I knew this wasn't gonna work. So you're in this space. The direction I'm going is not gonna work. So you know how mosquitoes work? Mosquitoes are fun. So they detect two things. They detect water vapor and carbon dioxide. So mosquitoes will fly along in a direction as long as the water vapor and carbon dioxide are staying the same or going up. But soon as it starts to go down, they change direction and the random direction. Right and within a couple of turns are aiming right for a mammal. They can they can fight. It's kind of colorful. So if you know you're going in the wrong

direction, a change in direction can maybe is just as bad, but there's some chance it's good. Especially with some smart, you know, some experience. Right. So I there was a whole bunch. So even a random move is better than no move if the outcome is is certain failure And so that is some justification for taking a risk now There's an incident number of failure directions, but you're somewhat informed right and then the other problem is like when you build a house It has a foundation once the foundation is built It's very difficult to change the top of the house a lot Like they have foundation for two story house It's hard to make change the top of the house a lot. Like they have foundation for two story house,

it's hard to make it into an eight story house. So when we cancel those projects, we consciously reset some design methodologies, some team organizations, some leadership, some let's say, we've said we're going to have the best in class, leadership, design methodology, and some of the architectural tools. We're just going to take those as given.

Now that the land has been cleared, we had the opportunity to go back to do that. And it was interesting, and the design teams, they're turned out, there was some very good pieces, you know, in the two processors they had, but they weren't working together organically like they should. And say the framework of the design wasn't big enough. And then the tools over the years had evolved into lots of little local improvements, but it wasn't really the right tools at the way. Now AMD leapt forward when you did this, and they were the only competitor to Intel in a realistic sense.

And so these actions on your part were part of what made that company thrive and kept competition within the microprocessor world. So these didn't have, these decisions didn't have trivial outcomes. Oh no, it had really great outcomes. And there was, the really cool thing was, you know, when we did that, we didn't really bring

in outsiders. Like that zen design was entirely based on people who worked at AMD at the top. Right. So what we needed was to clear the play a little bit to reestablish some, you know, first principles about how we were doing things. I have a better goal. It was a little bit ahead knocking on getting the methodology to straighten it out. I was fairly disagreeable

about how we were going to get through that, because people kept saying, oh, it's too hard to do this. Well, is it any good? No. Well, if it's no good, it doesn't matter how hard it is. You have to do it, right. If you're going to drown, you don't go, well, a mile is too far to swim, so I'm just not going to swim. You're going to drown me. If you're a mile offshore, you're drowning, swimming a mile is the requirement. And I've explained that in a million different ways. When something is pretty good, the world's divided into three things. Things are good, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad,

things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things

are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things are bad, things things are bad, things are bad, things are bad, things are everything could be approved. All right, so what was it? What was it? It was like, Jim, this wasn't that bad. Well, was it great? Was it going to win? No.

All right, it's bad. I defined everything that's not great best. If I moved a little just on the continuum, everything 5% or more away from great is bad, period. And how did you, like, how did you come to decide that was a good criteria? What's that? Why did you decide that was a good criteria that? Well, at the time we were competing with Intel and on a whole bunch of metrics, like,

like, literally, their CPU had twice the frequency, twice the performance per clock, a whole bunch of metrics were so good. So we plotted them all. Like, you know, I had a whole bunch of data on this stuff, but also as a mindset. Like, if it wasn't best in class, like a computer has a whole bunch of things in it, there's something called a branch predictor, which predicts which way branches are going. There's this way better than ours, we can measure it. So we did. There's a thing called memory system. There are memory systems with way better. It was twice as fast.

So it was like, well, we need to be within 10% of them on everything, or we're gonna get our assets paid. And it would be really nice if we were better on some things. So we measured all of our stuff. Like if you're gonna compete, like in basketball, you don't just play yourself. You try to see what the other teams are doing, whether they're good at, whether they

bad at, every coach is great at doing analysis of all the competition. Then you win two ways, meet the competition with what they're good at, and then you have some secret players that you you have better often surprising. Given recent Scotus wins, it feels like the pendulum may be swinging back to a time when the nuclear family was situated at the center of American life. Where real conversation,

learning and growth began at home. President Ronald Reagan said in his farewell address that all great change in America begins around the dinner table. Well, all great meals in America begin with good ranchers. Good ranchers cares deeply about providing families with steakhouse quality beef, chicken and seafood meat at a reasonable price. Their mission is to bring people to the table, making those shared moments with your loved

ones easy, accessible, and delicious. Good ranchers ships 100% American meat, born, raised and harvested in the U.S. right to your door. Plus when you subscribe, your price harvested in the US, right to your door. Plus when you subscribe, your price is locked in for the life of your subscription. Great food creates great conversation, and great conversation makes great change. So start bringing people back to the table with high quality American meat. Go to goodranchors.com slash Peterson to get $30 off your first order plus free shipping. That's goodranchers.com slash Peterson.

So you went from you went from AMD to Tesla. So and we talked a little bit about Elon Musk. I want to ask you about him and your experiences at Tesla, but also and what you did there. Sure. So let's talk about Elon Musk to begin with. Sure. Well, he's a pretty public guy, so I don't know that I can add that much. Well, kind of what you said about Steve Jobs was it true? Yeah, it's mostly true. Like, like Elon's the real deal.

He's a really good engineer. He has his belief that he can learn deeply about anything founds and he's practiced it and does it. I seem to do it. Like he gets into lots of details. Now he has done five impossible things. Yeah, it's pretty respectable. And he likes the details and he has a good eye for it. Usually before Tesla, when you do a technical presentation, you usually have some kind of methodology for resending the problem to an executive. What's the problem?

What's the background of that? Elon is a solution person. But if I don't like your solution, I don't care about the stupid problem and your data, just forget it. What's the solution? It's a solution great. Great. Then everything else is backup. You know, what's the solution? There's a solution, great, great. Then everything else is backup.

You know, what's the data behind that thing? Oh, we've got the data. What was the problem? Like, how do you figure this out? Oh, here's the original problem we found. Like he likes, you know, he has a reverse order for most people. Most people tell you this story.

It's a problem. You know, here's what we figured it out. Here's the background data. Here's all we've got the solution. Here's the solution. Here's the next step. So's all we've got the solution. Here's the solution. Here's the next step. So that's a typical technical presentation. It's not a bad idea.

Elon hated it. Like, stop with the bullshit. What's the end solution? And then- Can you give me an example of that? We had a problem with low resolution camera images, right? And we were trying to move like how that computer perceived roads and like low light conditions. So we started with, well, here's the resolution of the camera.

Here's a light sensitivity. Here's the images we're getting. And he was like, what the? Do you have a solution? Well, yeah, we do. We have the software that does this. Well, page 12, why is it on page 12? Page one of it, and we're a really good place. Here's the old image, here's the new image, here's how we did it. Right? That's what he wanted. Now partly, it's a high bad. So what I'm wondering is, what was effective about that? Was it that there was an ethos then that the most important thing that you had to bring

forward wasn't a problem, but it was a solution and so that people were striving constantly to generate and communicate solutions, which seems like a good strategy. Well, no, I think he's worried. So, the engineer sees a problem and they start investigating it. And then as you're investigating, you get to develop understanding. And you're understanding the problem is good. Like, you would think that, right? You think that. Lots of people think that. Elon doesn't think that.

Elon wants a solution, right? And if you're following in love with your understanding and you're following in love with your little details that you're looking at. Well, that also feels like work. work you know you mentioned earlier that just because it's hard doesn't mean it's useful right and and both of you know that you are focused like crazy on the solution. The best way to do that so then you have two states right if there's a problem there's two states you have a solution and you don't have solution if you have a solution solution on page one, we're all happy. Well, I've seen in the...

You don't have a solution. Why the hell are you talking to me? Why aren't you finding the solution? Yeah. I've seen in the software projects, other projects that I've been involved in too, that focusing on a solution, I think this is along the same lines as what you're discussing, is well, then you get to product a lot faster. It's like this thing has to exist and work. Maybe it won't solve. And the problem with the problem is

that you can indefinitely investigate the problem and expand it, and also that that feels like work, but it's not saleable. Yeah. Yeah, it puts in the forefront of your mind, that constant, you know, you need to be creative, pursuing the problem, but also make sure you're really on track of the solution, and you're just not following the love of the problems.

People call it admiring the problems. Some engineers are great at admiring problems. Like, I work lots of people to come in with a 12 page presentation, and when I'm done, I'm like, did you guys just give me a whole bunch more data on the problem? You said, yeah, we're really getting to the bottom of it. It's like, no, you're not getting anywhere. Well, the bottom of a problem is a solution

because why would you just investigate the problem, right? I mean, that your destination is... No, no, they just keep getting deeper and deeper into the problem admiration and nothing happens. Okay. I'd say three-quarters of engineers would be perfectly happy to do that their whole life. Because you explain this to me, complex mastery behavior.

So humans are very, we like to learn. We don't like to do dumb repetitive things. But we like to do things that are complicated that we've mastered that takes skill and you know you know insight but you can have complex mastery behavior just analyzing problems. Right definitely. Right and there's careers for that. Some people find they're really good at it. They're a problem to analysts. They generate lots of data. But if you're in charge of solving

problems, you know that that, that period needs to be focused, short, concise, and you need to move on to solutions. I think that's probably why I'm not so temperamentally fond of activists. Are they problem of myers? Well, that's what it looks like to me. It's like, well, this is one of the reasons I admire Elon Musk. It's like, well, you're concerned about the environment. Well, why don't you build an electric car then?

Right. Well, so a large number of people, this is the, my favorite thing I learned, it was working with McConodons near Zotasov. They think the world's made out of silly putty. Right. They used to design, when we were building model 3, they designed a part and they were joking about how

they're going to make it. Are they going to, you know, see building model three, they designed a part and they would joke about how they're gonna make it. Are they gonna, you know, CNC it, like millets, are they gonna injection mold it, 3D print it, stamp it, make it with a hammer, you know, cut it out, so there's, you know, carved it out of a block. They had this cool machine, that could carve 3D models out of clay, like it was, it was funny. Like, so they, they could design things in their heads

and on computers and then go build any dancing they want. You can view it. Look at that complicated mechanism. There will be some extrude aluminum saying it will be melt somewhere and then drilled and there's screws going through it. There will be some little tabs sticking off of it that holds another thing. They can make stuff.

They think they can make anything. And there's a whole bunch of people in the world who don't think they can make it. They think the world is what it is. I had a friend, he had a rattlesnum as dashboard. And he didn't know what to do about it. And I was asking him where the rattle was. And I was thinking that I was talking to him about how the dashboard is made. And I was asking him where the rattle was and you know, and I was thinking that I was talking to him about like how the dashboards made and he goes, oh, I get it. You think the dashboards made of a whole bunch of parts that are put together some way? Oh, it's not the dashboards, just the dashboards. Like, he couldn't, he didn't conceptualize it as there's a salver piece and

there's inter brackets and radio and there's these things. And as mentally, I can't help but see the whole thing in 3D and I'm wondering which knowledge pieces was the way it is, right? And then how to fix it, like, I'm not an accountant and you're in creative, but I'm visual. And for people who get stuck on activism as problem description, they don't think the world can change. Which at some level makes sense,

for human evolution, like it was pretty much the same for a million years. Like it's weird how good we are at change. And my best theory on it is from zero to 20. Like your brain is going through radical change because you're going from silly putty and not knowing much to be in pretty smart. So you have to change and adapt to those tasks

and then humans are adapted to deal with each other and those are fairly crafty. You have to deal with that. But the lifestyle of most people from, you know, say 30 deaths, you just fairly stat it. And so we have this funny capacity for learning rapidly exponentially. And then dealing with slowly changing environments, but we're not naturally that with the rapid. And the modern world is, well, especially in environments, but we're not naturally doubt that the rapid in the modern world is, well, especially in engineering is rapid change.

So, I was like, okay, so, it was just so funny. Like, you never knew what they were up to. Like, one day, like they were working on the interior for the car, and they made this crazy looking model, which kind of looked like a car, but it turned out, it was a thing you could move around and had the attachment points for all the interior parts. So you could basically, it looked like a weird skeleton,

but it had the attachment points and you could adjust and you could build all the interior parts and put a Tesla interior together right in the middle of the, or the engineering desks, where it was really cool. And let them go, build it and think about it. And then, because in the CAD model and the computer, you could see it, but you didn't always work out in real life.

Like, we have a scale problem. When you look at something that's small, even if you scale it up perfectly, when it's big, sometimes that's just what you thought, and sometimes it does work. And so, you know, you want to do, you know, computers like to change things fast, but like real scale models that you sit in and live it and, you know, get a human experience for it.

And it was really fun for that to just show up and be like holy cats. If I did a similar thing, we took all the electrical subsystems and motors and laid them out on two tables, two big tables, covered with all the electrical parts of the Model 3. We stared at it and once you see them all together, it's crystal clear that could be a lot better. Because you know, your three motors that look almost the same, why isn't that one motor? There's these two parts that are completely separate assemblies, assembly, but if you build it together, you could have one thing do both things really much more naturally,

like your way. Right. And by laying that all out in front of you, you didn't have to do the mental work of representing that. You could do the mental work of seeing how all the parts interconnected and what might be. Yeah. Yeah. Doug Clark is architect, I work with when I was a kid at digital call, that the inter-ocular traumatic test. when I was a kid at digital call that the inter-ocular traumatic test, when you look at it, doesn't bug you. And a lot of things when you're really laying out like that, you go, oh, we're not doing the straight. And Elon likes that kind of stuff. Like, you know, you're almost afraid to show them, like, when you lay

that all out, you look at it and go, just crazy. So it was like, do we show Elon or not? Because you'll look at it and think, just crazy. So it was like, do we show it on or not? Because you'll look at it and think, this is crazy. Like you built this car, you did this. So, so, okay. So I wanted to talk to you too. To walk, I want to talk to you, like I'm someone very stupid,

and in this particular regard I am, I really don't understand how computation works. And you're a microprocessor architect and you build computers. And so I listened to a discussion you had earlier this month. And there was a lot of it I couldn't follow. I thought it might be helpful and interesting for you just to walk through for me and for my audience, how a computer actually works, what it does and how you build it and then what it would be like to to design and to architect a microprocessor.

Well, it's somewhat hard to describe, but there's a couple simple things. So let's start with the easiest thing. The computers have three components, real memory, programs, and input and output. Right, those are the three basic things we always go. Right, so memory is like the DRAM or the disk drive, place where you store data, and it's just stored, and I can have different representations, we currently use ones and zeros.

Like, so you can take any, any, any bit of information and describe this as sequence of ones and zeros. And it's stored in silicon, in either static and dynamic memories or on disk drives, which, you know, there's a couple of technologies for that. So the memory makes sense to you. A place to store information.

Well, it does, although I have some difficulty in understanding exactly how the transformation is undertaken to represent things in zeros and ones. I mean, I'll give you a simple example. So if you shine a light on a photo of photo detector, right? So the light comes in and it's a stream of photons, right? And the photo detector counts the photons, literally. So every photon it hits it or a couple photons hit it. They cause some electric charge to move

and then it causes circuit to wake up and say, I saw all some photons. So say you're trying to evaluate how strong that light is. So, it can be anywhere from nothing to super intense. Right? And you might say, well, let's put that in a range of numbers from zero to a thousand. Right? So, and then you're trying to lay on it. And so, you count the photons for say, you know,

a microseconds, and then you translate how many photons you counted into the number. Right. So, so, and so just imagine those as the light varies up and down, the count, the number coming out of your photo detector is varying between zero and 1000. Right. And we use base 10. But you can translate that the binary, which is base two. And now you have one to zero. So you've basically now translated a light ray optical information to account. And so virtually everything can be represented by account apparently.

So just think of your computer. It has a camera, which is essentially doing just that. When you get different colors, but first you get some color filters. So you have a dream filter and a red filter and a blue filter. That's enough to represent the color spectrum. And then you have a little little photon countering underneath that. And it counts for a little while. Then you ship out the number and you reset it count again. Those are the light varies you're getting at. There's a pretty big grid, like a modern camera that's about million, you know, photo detectors, I mean, actually, 36 million because it's got different colors,

but well, it depends on how they build it. Like they might have different pixels be different colors and then interpolate the colors. Like a keyboard is really simple. So the fundamental issue to begin with is that you reduce everything to account and then you you represent that count in in base two base two. It's base two, right? Zero and one. And you can do the same thing with sound. You can have a sound

detector that basically counts, you know, in constant sound waves. And the keyboard, well, you have a little grid of keys and when you push a key, it sends what which key was that? Well, you have a little grid of keys and when you push a key, it sends what which key was that? That was key number 27. So now you can call it either on or off. On or off, you know, so D might be count number 26 and F is 27 and G is 28. So everything gets encoded into a number. And then computer is like binary numbers, you know, for technical reasons, but that's not a big deal. So memory, so input and output is the first thing. So the computer is built around the memory. So the input and output systems, so the inputs, all your photo detectors, sound detectors, keyboard detectors, and there's amazing numbers of sensors these days. You can detect gravitational waves, maybe.

You can detect, you know, photons, You can detect gravitational waves. You can detect photons. You can detect electrical waves, sound waves. You can detect temperature. It's very varied. You turn all that stuff into a number. And then you're input device right set into memory. And memory stores information. Memory used to be small and expensive,

and now it's big and cheap. But it's still just memory. And nothing happens to it in the memory. It just gets stored. If you look inside the computer, there's a big memory, it's full of numbers. Now, the person who's writing the program is telling the input output.

Like here comes the input video stream, put a video stream address, 1 million. So all the memories are addressed. And the address typically starts in zero and modern computer goes up to billions. Okay, so walk through that again, the addressing. So what's exactly the function of that? Well, you want to know where the memory is. Okay, right.

You need to, okay, fine. Yeah. So basically your phone probably, I don't know, has eight or 16 gigabytes of memory in it. Yeah, maybe four or eight. So billion, you know, eight billion bytes of information in there. So, and when you're designing your programs, some kind of layout, what is our operating system is going. Here's what input and output buffers are. Here's memory we're going to use on some program. So in all that's address. So you can think of the addresses, it's just like a post office, right? So you know every house has a postal address, you know, it's a street address and then your

house address. And so you can find every person. And the address corresponds to the physical location, in some sense, to the physical location of the, and how are the zero and ones represented in the memory? It's a literally a voltage that's either higher low, and zero is either ground, which is zero volts, and modern, you know, DRAM cells probably stored at 1.1 volts. And, you know, in a DR probably stored at 1.1 volts. And, you know, in a DRAM cell it's a capacitor that's holding electrons. But basically when you store the cell and either you drain all the electrons out, so it's zero volts, or you put a bunch of electrons in so that it holds a 1 volt.

So it's literally a number of electrons in there. There's a couple of ways to make memory cells. There's another way, which it's called a bicep in there. There's a couple ways to make memory cells. There's another way which is called a bicep table element where you have what's called cross-couple inverters, but that's too complicated to explain. And then the memories are usually built in rays. So there's an x, y. If you take the number and you say, I'll take the bottom half of the number and

figure out which row it's in and the top half of the number of which column it's in. And where the column and the row overlap, then I'll write my new data of a one and zero in that spot. It's literally that simple. So, if you look at a memory chip, you'll see this array of bits with little blocks on one, two edges, usually, you know, one side's the row, one side's the column, and then the bottom is what they call the sense

then when you read it back out again. So a memory process is you activate the wrong column to a spot, which gives you the address of that bit, and then you drive the bit in and charge up or discharge that cell, and then it holds them. And it's super simple. You can build a memory with a pegboard. You could build a memory I mean, it literally did, you know, way back when there was something called Clure memory where they had simply the X, Y, red and at each little place there was a little magnetic bead, which when you put the current through, you could put the current in the same direction, you could be able to be north to south and the opposite direction to south to north.

So the basically re-magnetized little beads. So there's lots of ways to make money, but currently the really dense money is called dynamic money, is where you literally put charge in there. And then your fun stuff that happens, like flash cells, the cells got so small that the electrons from the quantum, tunnel out of the case.

So you put 20. Right, because there's some doubt about where the electron actually is. Yes. And sometimes they could literally jump out of the cell once it comes out and keep those and come back. So they got down to like 25 electrons in a cell and they would wander off over a couple hours and you have to refresh them. So periodically you go back and read the data before too much of it's escaped and write it back in. So it's called refreshing the memory. But the D-RAM sold

more charge of math and then the flash guys figure out how to stack the cell. So mod and flash chips are the next wide grid but's also a seed dimension. They're like 256 layers thick now. So it's like a three-dimensional memory. But the simple thing still is it's a linear range of addresses where you put some data. Okay, so that's memory. So the next component is programs. This is the compute part. So a simple program, simple program is a equal b plus c. Right. So the data at address a, so when you write the program, you tend to use what you call variable names, a, b, and c. But there's a tool called compiler, which will sign a as the address of 100 and B to address 101 and see the address of 102.

And then the computer when it's running says, do what I told you to do. So you see this program A will be plus C. So you get B, you get C, you add them together, you put it in A, and typically what happens is you have what's called a local memory or a registered file. So you get the data from memory into the registered file, you do whatever operation you're supposed to do, like ads, and then you put C back in number. And what are the range of operations, or is that is that too broad a question? What are the fundamental operations apparently or arithmetic? I've done this like the number of operations that a computer does like the construction theft can have a hundred or five hundred or a thousand

different instructions. But the most common ones are low data from memory to the processor or the program ones. Store memory back. So your first two instructions and then add some track, multiply, divide, clear, very simple, it's a written. Then there's what's called logical operators and or not. It's stunning to me conceptually thinking through this that the computers, which can produce whole worlds in some sense, can do that as a consequence of zeros and ones and arithmetic operators. Sure. Well, your brain is doing something interesting like that. There's no magic to it.

So the key to programs is abstraction layers, right? So it's some low level, you know, like I understand computers from atoms up to operands, which is fairly broad range, but there's lots of people who can do that. Yet I understand them like the surface of the keyboard. Yes. Yes, monkey with military helicopter, basically. Beban and had a few questions. So, you know, computer science, let's say, tell me what happens when I move when I type a key. Right? Because you can, you can talk all day, you know, because the key is a position, which encoded a number, which

got sent into the memory. There's an interrupt delivered to a processor to say there's new data memory. We'll take a look at it. But you can describe that at many, many levels. Right. So it's a good place to start if you want to start that. Is it an interview question? It was an interview question.

Yeah, right. For people, by the way, are stumped. They go to college and they can't tell you what happens when you keep, you know, a key is clicked, which is weird. So so back to the computer. So yeah, the basic operations, that's the tracks, multiply, divide, you know, clear, set the one, and or not, XOR, you know, you can take a number and you can shift it around, you can mask it. And so different architecture. How are those operators discovered, Jim? I mean, I know that there's a arithmetic operators and that just the question of how was arithmetic discovered? But I mean, there's a logic.

Yeah, way after mass. So computers, at some level, they're doing arithmetic. Like, it's not very sophisticated. And I'll get to a little more complicated version of this. And by the time we invented computers, people have pretty good idea of number theory. They figured out that base 10 was just one of the bases you can have two, three, four, five, six, seven, eight. People had the philosophers have worked out what logic is. You know, if this is true and this is true, then this is true, this is true, or this is true. Like, the logical operators are real. Like, there's a whole bunch, there was a whole bunch of... Yeah, it's the real, it's the realism of them that's stunning to me.

Yeah. So, there's the basic operators at, and then there's something called control flow. So computers typically, they put a program like add, A equals B plus C, D equals E plus F, F equals E plus A. And you typically put that in what's called program memory, but it's just part of the memory of the computer. And you have a program calendar, which, you know, I know,

what's called calendar, the thing that points at the next instruction to execute. And it's the fault thing is, do this instruction and then do the one right after it. That became like the way computers are built. That's an arbitrary choice, by the way. You can have every instruction tell you where to get the next instruction.

You're just a bunch of things you can do. But for simplicity, people said, this piece of memory has programs in it, started at the first instruction and then do the next one and the next one, next one. The program counters, but that's not good enough because then you would just start at the first one and you go to the end of memory and be done.

So there's something called control flow. So a program called sorry called control Control flow. So imagine you wanted to add up a list of 10 numbers. So your first instructions says I'm on the first instruction and then you say that the sum equals the current sum plus the next number increment the counter of how many instructions I had, increment count by one. And then test is the counter equal to 10. If yes, keep going straight. If no, go back to get the next number. So you created the little loop.

And it turns out the computer scientists and invented a whole bunch of kind of loop which they call control flip constraints. Do this while X is true. Do this until the counter gets to a number. So you can create little, you know, basically subprograms in the program. Right?

And then there's a couple you can, you can test, like, hey, I need to decide if this is a dog or a cat. So if it's a one, go, look at here. If it's a zero, go look at that. Right? So that's conditional branch with loop branches. And then somebody famously invented subroutine. You notice how he was writing the program. He write, he writes this little routine, but it would be used a bunch of different times. So rather

than putting the code in multiple times, it was like define a word. And then whenever I need that new set word, I don't have to put the whole definition for the word. I just put the word The subroutine is like a local definition of something or a local computation. That's even multiple times So your top level program might be Go to the subroutine that counts up numbers comes up numbers and come back now go to the subroutine that checks whether it's your bank balance or not, come back. So the program just becomes sequential operation, control flow like doing loops, let's say do this until something is done, and then conditional branches that

says, depending on value, do this or that, and thenroutines to do something atomic and that's essentially all a program. Operations loops, conditional branches and subroutines. That's it. Now, why computers construct worlds? So I still remember when, though if you look at your screen, you know, your computer in front of you, it probably has two or four million pixel on it, it seems like a lot. Right? And when they first started, you know, televisions, when they let up screens, you know, they were scanning the little electron microscope, you know, electron beam across a phosphorous

and surface and lighting and modulating the intensity of the electron gun to mimic the little phosphorous brighter little. Right, and it was writing. It writes one line at a time at an incredibly fast rate by human standards and we saw that as continual motion. Right. And then the continual motion. The phosphorous was designed to decay at the rate. So by the time you came back to it,

we'd just gotten a little dimmer and then you wrote it with the next value. So it didn't flicker. So your IS on persistence. So the electron hits it, it makes the phosphorylite up with some photons of your right color. And then it's slowly decaying and you scan down

and it gets back there and writes it again before it's too dim. And so the screen on a phosphor-based television, is it analogous in some sense to the binary representation? That's entirely analog, so it's digitized in the sense it's discrete, I'd say, in the sense that each little pixel, you can see the little phosphors in the sense, it's discrete, I'd say, in the sense that each little pixel, you can see the little faster screen. Right. Especially notice that when they want to color TVs because they have a red green and blue thing. Right. Right. And they would hit them with the blue thing.

And they're either, they're essentially either on or off. Well, they have a range, though that that beam is a variable intensity. Right. So no, matter computers work differently. So the screen in front of you has a little, it literally has an x, y grid, and it can address each one of those things. Right, so you don't shoot a beam at it anymore. You have an x, y, you decode.

It's almost like the screen looks like a big, flat memory, but instead of storing ones and zeros, it's storing color. But they have the same kind of decay property and you write to the color and you're spongebunct stuff. Now, here's the wild thing. Computers are now so fast you can run a 10,000 line program for every single pixel on that screen.

Right. So what? And what does that imply? Well, it turns out for a whole bunch of reasons, like if you want to make something look really good on the screen, so the world's relatively continuous, right? But if you look at it, there's all this light reflecting around, there's all these things going on, there's no little pixels in the surface of your table, right? To make a discrete grid look that way, you have to, you know, combine the surface of your table, right? To make a discrete grid look that way,

you have to, you know, combine the colors, you have to do a whole bunch of stuff, you have to pretend you're shining lights on it, you have to, you know, there's a reflection from one surface of the next one, and it turns out when you have thousands of instructions per pixel, you can start to make those pixels look realistic. Right, The operations, and you go look in the pixel program, like it looks so beautifully,

you think that's incredible. But if you look in the pixel program, it's low the data into the register, add it to a number, test it against another, subtract something. There's something called clipping, like make sure that the pixel doesn't get brighter than this and dimmer the map. It's all simple operations. Like there's nothing in the computer that's like, do a, you know, pixel operation. Right? Well, there may be on subroutine names that, but underneath it, it's just the same old stuff.

Computers always do. Vodes store, had some track, multiplied by branch. So did we, okay, so how far have we got? I'm listening to so many things, I'm having a hard time keeping track of the order.

You mentioned earlier that computers consist of four elements. I believe that's what you said. Memory, yeah, input and output, yeah, and compute, okay, three you said. Memory, input and output, and compute. Okay, three. So I was counting input and output separately, but okay. And have we gone through all three of them? Okay.

So memory is just the place of store bets. Yeah. Input and output is typically the way to, you know, depends on what you're doing. You might just send bets one way to another, but it might also be, you could say input, input it out, but in the computer and sensors are slightly different things. Like sensors, you know, turn analog and real, real world signals into digital. Right. And then programs basically transform the data in some way. And programs is basically seek, you know, operations like how to subtract divide, and then branches that you do it loops or make decisions, and then the hardware that you do is opportunities

to break the program into pieces. And that's pretty much it. So to some degree, you take the world, you transform it into on off or yes, no billions of those And then you manipulate the yeses and noes or the zeros and ones and that can produce almost any sort of phenomenon that you can imagine Yeah, yes, no, it's not a very good, you know ones and zeros is better because then yet it's a it's a mathematical representation, you know a bind a digital representation of an analog reality. Something like that. And is the analog reality, analog all the way down, or is it digital at the bottom?

It's quantum at the bottom. So there's something called the fine constant, which makes the universe look discrete, but it's a very, very small number. It tends to be... Right. ...and there's a fun fact, which is... Is that the plank length? Is that associated with the plank length? Yeah. And that's the smallest possible length, I believe. Yeah. Like the mass of the universe is 10 to the 40th, and the plank length is 10 to the minus 40th.

And there's a physics thread about the mystery of why those things are 10 to the 40s and 10 to the 40s. All right, so let's move from that to, I'm gonna ask you, these are the questions. I wanna say so. Yep. The thing that makes computers do what they do is abstraction layers.

So, at the bottom, there's atoms. So, there's engineers who know how to put atoms together in a way that makes switches, which we call transistors. Right? So, and those guys are expert at that stuff. Right? And they just, they can operate at that level. Then there's another thing where you take multiple transistors together and you basically make what's called logic gates, which literally do the ends and oars in inversions, right? And then that's an abstraction layer. We call it the physical design library or something like that. And then people take those and they make them up into adders and subtractors

and multipliers. This is a well understood Boolean mass. How do you add two binary numbers? So you make those. And then there's another abstraction layer that says, are I going to take multiple operation units and put them together to make part of the computer? And then you make there's a bunch of those blocks. And then that thing runs a program very simply. And there's small number of people who write programs at the low level, but then there's people who use what's called libraries where they're doing some higher level program.

And so they're gonna do a majoring small multiplying and do this map, but they don't actually write that low level code. So there's a stack of abstractions. And when something gets too complicated, you split the abstraction layer into two things. There used to be when people wrote a program, there's a program called a compiler

that translated your C program or four term program into the low level instructions. But it turns out there's too many languages up here and there's too many instructions here. So now they translate it from the high level language into an intermediate representation, which is sort of a generic program. And then there's another thing that translates the intermediate representation to a specific

computer you have. But that just keeps going higher and higher. Like a lot of programmers, they use frameworks that can do amazing things. Like you can literally layer a program that says, search the internet for a picture of a cat soared by color output to my printer. Like, just a language where that's a program. Search the internet, holy cow, that runs a trillion lines of code

on 100,000 computers, find a cat. That's a really expensive, that's a really complicated program. So how much of the radical increase in computation power is a consequence of hardware transformation and how much of it is a consequence of the increasing density, let's say, of these abstraction layers? Well, so this is where there's a really creative tension or dynamic interplay. So when computers first started, they were so slow, you ran really simple programs, A equals B plus E times D, right?

And we've been going up the math hierarchy. So then you could run a program that did what's called no matrix math, like our linear algebra, systems of big equations, and then matrices and then more complicated ones. So as the computational power went up, you could dedicate more and more complicated ones. So as the computational power went up, you could dedicate more and more stuff to that kind of computation.

And then similar thing happened on abstraction layers. It used to be, if you bought a million dollar computer, you hand wrote every line of code because you didn't want to waste time on the computer. It's like overhead. But today, that milliondollar computer costs 10 cents. You don't really care how many cycles you use, you know, parsing a cat video or something. And so the computation,

capacity, let the abstractions that the programming level increase a lot. So, so many have made it had a graph about how many bytes is it take to store the letter A. Like, it used to be one. And then word for Windows, it's like 10 kilobytes per letter. Because the letter has a font, it has a color, it has a shadow, you know, there's a whole bunch of, you know, and that's fine. Like, for the computer with a million dollars for, you know, a thousand bytes of memory, you wouldn't store a letter A like that, you'd put it in one byte. But now you have gigabytes and terabytes of storage who cares. You probably already know that there are data brokers out there selling your internet data

off to companies who want to serve you a targeted ad. But you might be surprised to learn that they're also selling your information to the department of Homeland Security and the IRS. Mask your digital footprint and protect yourself with ExpressVPN. One of the easiest ways for brokers to aggregate data and tie it back to you is through your device's unique IP address. But when you're connected to ExpressVPN, your IP address is hidden, making it much more difficult for data brokers to identify you. ExpressVPN also encrypts 100% of network traffic to keep your data safe from hackers on public Wi-Fi.

You can download ExpressVPN on all your devices, your phone, your computer, even your home Wi-Fi router. Just tap one button and you're protected. Make sure your online activity and data is protected with the best VPN money can buy. Visit expressbpn.com slash Jordan right now and get three extra months free. That's expressbpn.com slash Jordan. Okay, so you walk us through the basics of computation. Now, can you shed some light on like I don't understand what you do as a computer architect like when you go to work, when you're working on a project, what is it that you're actually involved in doing? I had to go faster. So I'm a fairly low level engineer. You know, low level in terms of the abstracts and liars.

Like I understand Ireland, but you know, I talk to the people who make transistors and and gates and or gates. And they talk to the people who know the atoms. Right. So, and I hardly ever talk to the atom people, but I know something about atoms. So I build the architect and stuff, the functional units and then how they operate together at the low level that runs programs. But I don't write programs. I build my architect of the computer that runs programs. Then, it used to be you could look at a computer and you know how a program works. You run the first line, the second line, and if there's a branch, the branch, you get

a new branch. The computer would literally have that in it, such an instruction, load the data, do the operation, if there's a branch, execute the branch, if necessary, change the program counter. So, you know, people, you know, there was a period of time where computers had like five stages and each one of them could say, that's the branch, that's the fetch unit, that's the load unit,

that's the ad unit, that's the branch unit. Right, but monitoring computers are more complicated than this. Because computers like that would do one instruction, there would be five cycles. And monitoring computers, the vastest one I know about, is doing 10 instructions, 10 instructions, the cycle and parallel. And this is difficult. So the best way to unpack that, unpack that. So if you write a program, then it's you write, right? When you write, you write linear narratives, right? You write sentence, that makes sense, followed by another sentence, right?

And so as you're writing the law, sometimes the one sentence defines the meaning of the next sentence, right? And then group it in the paragraphs, you might call those subroutines, right? And sometimes the paragraphs have to be ordered and sometimes the paragraphs the order doesn't matter. So programs are written by human beings and they're written in the same linear narrative. So if you want to go faster than parsing the instructions one at a time in order, you have

to do some analysis to say, all right, I got two sentences, are they dependent or not? If they're dependent, I do them in order, if they're not dependent, I can do them in parallel or any order, right? And you start, so the modern computers, when they're reading the programs out, they're analyzing the dependencies and deciding what can happen in order. What has to happen in order for correctness, correct understanding, and what can be rewarded. And then it turns out, there's many places where you say, if there's an error, go here, but there's hardly ever an error, and you can predict that really well.

So you say, I'm going, you're reading along, and you say, here's a point where I'm not sure which should I read the next sentence or show a jump from the next paragraph. Right. So a monitoring computer predicts that. It doesn't wait for you to fully understand all the sentences up to that point. So you know exactly where to read to. So imagine, so now you're reading this book

and you're reading sentences in dependency order, which means you haven't, so you get to a branch and you haven't read all the sentences before that and understood them. So you don't know where to read the next paragraph or the next chapter. But we predict what's going to happen and we just keep on going. And how does that tie into the process of designing the? So the goal, the goal of monitoring computers is to go fast. Well, let me say there's three kinds

of computers. There's computers that run very simple programs in order. Right. They just do exactly what you told them to do. And they tend to be small and simple, but they're so small and simple, you can make a chip with 1,000 of those computers on. So when you build a GPU that does a little program very pixel on your screen, each one of those pixels gets its own program

It's very simple But you sort of say the first thousand pixels you run on these thousand computers So like a modern GPU has like currently like six or eight thousand processors in it And they literally you do the you know the first 6,000 pixels, and then the next 6,000 pixels, and they do that fast enough that you can run fairly big program on every pixel on the screen for every screen we've finished on. So you have simple computers that do stuff in order.

Right, and then you have, let's say, computers that are designed to run complicated long programs as fast as possible. And that's where you parse the instructions carefully and you figure out what order you can do them in and when possibly re-oportivate. And the reason you reorder it is because if this doesn't depend on this, I can do a parallel. Now I'm doing two things at a time. The next thing I can predict that I can do in parallel, I can do three things. And you know, like I said, the computer in your desktop is probably doing three to five things at a time

and the best I know of this can. Right, and that's because, and there's other sophisticated predictors in there. So to do that, you have to fetch large groups of instructions at a time, define the figure out where the sentence boundaries are, figure out their depends and they're not have to figure out. If you can predict where the next instructions are coming

from when you hit branches. And it turns out that's fairly complicated. The difference between a little computer that does, let's say, one instruction in the time, a complicated one that does, let's say one instruction in a complicated one that does 10 instructions in a fine. It's 100 times in a complicated one. And from a, what's the best way to do lots of instructions, complicated computers are not efficient.

But there's so many applications for people carrying them fast to those. So when you're like clicking on your web page, you want that to come up as fast as possible. So the part of it, that's let's say, what's it called, the logic of the web page. It's probably a serial narrative written by a human being. So you have to run that on a complicated computer

that does it out of order and predicts what to do as fast as possible. But when you render the screen itself, that runs on large numbers of simple computers to make all the pixels. Right, and then there's a third kind of computer which we're starting to invent, which is AI computers. And that's what you're working on now for 10s Torrent. Yeah. And there's a really good talk by Andre Carpathi, called Software 2.0. So the first two kinds of computer, simple computers and complex out of order computers, they're running programs written by humans.

Right. And if you look at the code, it's literally declarative statements about operations and where to go, and it's serial. It's linear narrative. Now, the different thing about AI computers is you use data to train the weights and neural networks to get the desired result. So instead of the programs are no longer written by humans. Now, it turns out there's components of the AI stack that are written by humans, but at a high level, you use data to train them. So, you have a big neural network and you want to train them. So they have a big neural network,

and you want to detect cats. So you put a cat picture into the network when you start training, and the output is gibberish. And you compare gibberish to what a cat does, and you calculate the difference in what the network said versus the desired result, which is the word cats. And then they do something called back propagation, which is mathematically sophisticated,

but essentially take the air and partition of the across the layers of the network, such that you've sort of bumped each neuron a little closer to saying cat next time. By taking the bigger at the end, distributing the across, let's call it back propagation. And then you put another CAD in,

and if you have the right size network and the right training methods, after you show the network in million cats, and you put a CAD in it will likely so it's CAD, and when you put a picture, it's not a CAD it will likely so it's not a CAD. Right, and you never wrote any code that I said, anything to do with CADs.

And can you understand what it is that the computer is doing now that it's recognizing cats? A little bit. So people for years worked on visual computing and they were trying to detect things like cats. Right. Cats have a whole bunch of artifacts around eyes, they have pointy ears, they have fluffy hair. So you could detect feet that is called featured detection. You would say this will be a cat if I see the following

colors, the following, not a fluffiness, the following number, you know, two pointy ears, not three, one or two round eyes depending on the view. Right. So you could write code and the problem with that is, well, now the cat has an arbitrary orientation. So you have to, you do your feature detect on the picture and the features have to search the whole image and you have to rotate around, you know, and it's sort of, and every single thing you want to detect, you have to write a unique program for it. You're done with cats, now you go to dogs. and then what about the dog that has certain point of years These dogs have round ears and cats have point ears

You know, so it was sort of endless Thing right right same thing with speed endless Detail my detailed construction. Yeah, I got a friend who worked on speech recognition years ago So you break speech into you know the, the phonemes, so you can see those, and then they have frequency characteristics, and you can differentiate vowels from consonants. So that those people working on speech were doing a whole bunch of analysis of analog waveforms that sound. And they were making some progress, but it never really worked. And then they train neural networks by you put the word, the word in.

And you have this, it's called supervised learning. So you play it language where you know what all the words are. And you keep telling the network how to correct. And with like a billion samples and a big enough neural network, it can recognize speech defined. And if you train it with a broad variety of accents, it can work across accents. And then it turns out the bigger they made these networks and more information they could put it. And then on the Cat one specifically, they found, so when they first they first had a neural network cracked the cat problem. I forget it was like 50 layers deep. And if you looked in the layers, you could see that it was detecting point of

ears and eyes, but it was also detecting a lot of other things. And some things we don't know. Yeah, well, if we see the back end of the cat walking away, we still know it's a cat. And it pretty much lacks eyes and pointy ears from that perspective. What do you think? If you take an object like in light, right, take a phone, you can project the phone onto a flat surface. That's a projection. Right. And as you move it around, you get different. Shadow.

Shadow. Let's think of it as a projection. Right. So that's a projection of a light source on a flat plane. It's a fairly simple projection. But what if you had a light shaped like a cat and you signed that on the phone? What was the projection book like? And it turns out mathematically, there's an arbitrary number of projections.

You can, like we think of projections and three dimensions, because we're three dimensional preachers. Right, but there can be lots of projections. And then you can have the projection project on another plane. So the neural networks are doing is are achieving out all the details of what that is.

And some of the projection planes give you what's called, you know, size and variance or rotation variance. Like you could recognize a cat in which it's pointing. Like your brain is a little specialized, like the space is. Right, it likes to be very cool. With a little bit of work, you can recognize an upside-down basically off as you have a problem. Okay, so we could do two things here.

We could either talk about your... No, let's go into your... You were an engineer and then you were a manager. And you've worked in lots of companies, some of which were incredibly creative, some of which were thriving to an incredible degree, and some of which were collapsing and irreparable. So what have you learned about what makes companies work and more important? What have you learned about what makes them not work and maybe what do you do then? Sure. Well, that's a fun question Well, first of all there's like I've noticed and many people have noticed this is not just me that people

Gen like engineering fields people kind of bucket towards you you know, technical people and management people. And it's not that there aren't good technical managers or you're not good managers or technical people can manage, right? Right, but that's an intersection of two skills. Say, yeah, but generally speaking, most people are one of you. And it's like, which wake up in the morning or you want to solve a problem or do you want to organize the problem? Like, you are you worried about your schedule and your head towns and how things are getting done and did you hit the milestones or you're working on technical

problems? And people and in the engineering fields, it's often there's the fellow track that the technical leadership position or the director of EP track, the management leadership. Right, so I'm a technical person. But you took on management rules, repeated it again because I found out that if you're generally speaking the top of the organization is the manager of the VT and as a technical person, no matter how high you go, you're an advisor to that person. And I decided consciously that I worked at Apple, and I was going to be VP, and I have everybody working for me, because then I can do it.

So then my skill set is somewhat unusual, and I'm not the only one, obviously. But I decided to, you know, get on the management track, but I could build the computers I wanted because sometimes when I wasn't the leader of the group, some managers at some point would decide they own the next decision, and they would make some random decision. I'd be grumpy about it,

and there's nothing I could do about it because people work for them not for me, so. So that's, you know, it was a conscious thing and I hired a consultant, Ben Katroup, who helped me reframe how I approached this. Now, I'm still a technical person, but I found that turns out there's a whole bunch of really good technical managers that I like to work with. I like to organize stuff. And I would say, you know, I maintain my openness and low conscientiousness and discreable behavior.

And I have people who work for me, or come to my team, or work with people that manage better. So even though I've been a manager of AMD, it was 2400 people total. At the end, then until it was 10,000, my staff, 15 or 20 people. And usually half of them are real managers and half of them are technical leaders, that's how we solve it. And there are lots of companies running away.

A lot of times founders tend to be technical people, but people working for them are non-technical, or they're stronger on the management side than the technical side. But for everybody, you need to decide who you are. Like I had a great technical manager at AMD and one day he was a little mess because I was looking to the, you know, a couple of the really technical heavyweights. It's all a problem. He said, you know, I'm pretty technical. I said, yeah, I know. I said, are you technical compared to Jim and the Barb and he goes, I guess, not really. He said, I know, I really like are you technical compared to Jim and the Barb and he goes, I guess not really. And he said, I know, I really like, you know, what I want you to do is you run in this project, you have 150 people working for you. You make all the technical decisions you can, but when it's

out of your wheelhouse, we got serious experts and you have two choices, you can call them or I can call them. And he later told me, he said, I found that it was a lot better when I called them and you called them and successful thing. And he was technically really good at making good decisions, but he wasn't the strongest technical person in the group. So that's the first thing, because you know, figure out who you are. I've seen a lot of people fail in engineering because at some point, they think, I'm technical, but I want to get on the management tracks, but they're bored by management, and they don't have a plan to deal with it. And so they start...

Yeah, well, you weren't bored by management. And so, I joke that I decided to see the organization that's computer architecture problem and treat people. Well, that's exactly what I was going to ask. What transformation did you have to undertake to? One of them was, what do I have to do to be effective? I hate to work on failed projects. The next was the organizational problem itself is an architectural problem. Then I kept kept, you know, for myself, well, it's a funny kind of, if something has a solution and it's being

constantly driven, I'm not that interested in that. I like problems. And so in a big organization, there's a million problems and then I start sorting them by priority and then solving some of them or handing them out to the right people. So there's a whole bunch of technical work to do on that. And then I'm fairly good at skill assessing people who are technical, either for management

or technical positions, and then giving them where I can even, I like autonomy and management. So if somebody's competent, they can do it, they understand it. Then gave me a bunch of books to read and one of the frameworks is Goals Organization contract and teamwork or capabilities, I guess, we usually solve for that.

So it was a goal, super clear. Do we have the capability to solve the problem? Is there a contract between me and the groups doing it? So they know what to do and what what their goals, you know, box are in. Right. And did they have the, you know, the, um, is the organization that, like a lot of times, you know, as a joke, that start-up start with a problem and build organizations supported, but on the second, third system, the organization defines the problem, rather than the problem defining the organization and then it breaks out.

Yeah, then the organization becomes the problem. Yes. Yeah, they constrain the problem and become the problem. Well, we had a number of discussions while you were doing this about ethics. And I mean, you said that you go, you look at the problems, well, that's hard, right? Because you have to know enough to know what the problems are. Then you have to be willing to look at the problems. Well, then you prioritize them like you, you, you skipped over that very quickly. But all of that's extraordinarily difficult. I would say both cognitively

and emotionally. Oh, sometimes it isn't. Sometimes it isn't. Like when I joined the A&P, the CPUs were less and half as fast as the competition. And they had no plan to catch up. So that that wasn't that hard. No, but what would be hard there? I would presume is figuring out how it could be that Such an obvious problem had gone undetected and unsolved and then no actually one of their architects when I was working at Apple told me that they believed that No, actually one of their architects, when I was working at Apple, told me that they believed that CPU performance had plateaued, wasn't going to get any faster, and they were going to work on adding features to the rest of the chip. And then Intel came in and said, we think computers are going to get 5 or 10 percent faster over here, and they did it.

One had one goal, which is things slowed down, they know, they're at a different goal. 5% or 10% isn't a lot, but you do that 10 years in a row. And, you know, the other guys weren't. So, that wasn't that complicated. Like, you're not famously said, he tells everybody secret plans and nobody believes and then does them and they still don't believe them and then they're like, oh, shut. So, Intel publicly said they were going 5% or 10% faster

every year and they said, no, they're not. You know, the results were at some point that the gap got bigger and bigger. You know, the people they were committed to their plan. I don't know why. It's interesting how these things get internalized and then you start even when they, you know, at some point, you know how it is, it's cognitive dissonance. You say you're going to do something different, but you learn how to do this other thing really well. You can't do anything. Right. And, well, you've been at a whole machinery

around it. Yes, exactly. You know, they had a big machine that did all kinds of stuff. That was perfectly used. Right. And good people doing it. Like I said, we didn't hire any people to build them, but we did refactor, you know, you know, reset the gold refactor a whole bunch of the engineering and. Okay. So while at AMD, you were successful twice. And so, and the success was both building a chip that was competitive. So you had to put together the teams to build the chip, but also to transform the internal structure of the company so that that became competitive. So you had to put together the teams to build the chip, but also to transform the internal structure of the company so that that became possible. And then also to communicate that to your customers.

And so what's the problem, say, if you communicate with the customers, like, you know, because, you know, computer were all performance cells. You know, okay, so that's the first thing you talk to the table, performance cells. And here, we're's the first thing you talk to the table. Performance cells, and here we're gonna break that down. Here's the measurements.

Here's the note. And there's lots of public benchmarks. Like everybody tries to game it, but generally speaking, there's a really big community of computers or some they know what they want and they know it's fast. Right, and you know exactly how a computer works. So you can actually say, once you just started that what faster is better, does that work on all of the elements of design? Well, I mean, there's complications too, right? There's certain things like, you can make a faster

nobody would care. Like, yeah, there's some types of calls in it, but it's not complicated. Like, you know, today on phones, there's a thing called geek bench. And you get a number at the end. Is your geek bench score 150? 100's better. Right, right, right. The people who made the benchmark tried to pick the components of your phone experience

such that the geek bench number represented whether the phone is faster or not. And then whether you care or not's another question, for the current applications that they got twice as fast, might not notice but as the computer gets faster some new applications are possible. And on the phone where it's possible it's great where it's not possible it feels as low and lag. So performance wins and you know different form factors like a notebook or a desktop or a phone that different nuts of power. They live within the budget. Okay. So, so you had a goal.

You had the measurements in place. You decomposed that into tasks. You assigned competent people. What, what psychological factors got in the way? Like, how did you seek? Yeah. Fair enough. All of it.

But what, what did you see specifically? Interfeat once you have a good plan in place, that doesn't necessarily mean it's going to be implemented. And so what are the mistakes that people make that you saw in large companies that doom the company? So that stop them from transforming internally? And so there's a couple of very separate problems. When somebody with a good set of ideas

that I need to transform this place, there's, there's, are the goals proper, right? And then you wanna say, do I have the capability and the team to do it? So like, like I worried when I went to NDO, I wouldn't have enough experts in certain things to do it. I'd have to go higher 50 people to fix it. But turns out there was, I did

planning of, you know, there was plenty of good people. Actually, it's a really great people. So I was like, you know, pretty quickly checked off the capability box and then you start wondering, well, why are how long are we doing the right thing? Well, the problem was, the goals are wrong and the organization was wrong. Right. And then generally speaking, if those aren't right so to begin so maybe to begin with the goals weren't unreasonable And no one knew but then across time the fact that once that goals was better than the other The beliefs that computers weren't gonna get much faster with a bad goal in the world Or the competitor believed they were gonna get a lot faster Yes, and could do it and that became incrementally worse across time to the point where it became cataclysmic. Yeah.

So, so you got to get the goals right and you got to establish where you have capabilities. You know, those are the kind of fundamentals. But then the organization built in this hard because somebody will tell you, so and so it's a great manager. Well, you see, or you know, like a lot of times, there's so many, it looks like a good manager, but you just have like a lot of times, there's so many, it looks like a good manager, but it just has three people working for us. The problem with that is when things are going well, the empty suit manager with his good

people supporting them, they take a look like they're making lots of progress. But when they run into hard problems, and the technical guys don't want to do, they go to him and they surround the decision or does something dumb or doesn't believe them. Like that happens a lot. The technical guy goes to the empty seat manager and says, you know, I think this isn't working, you need to change. And he says, now we're fine, we're just going to go right away through it. So you get these weaknesses in your organization because you don't have skill level.

Like I said, I work with a lot of really good technical managers who know when they can make the decision and they know when they have to front to somebody who's more of an expert. Mm-hmm, that's great. And it turns out some people are so good at that. They can operate way higher than you think because they're not technically strong, super good,

at translating and making judgment calls like that. So you've got to start looking building your organization and inner stuff about how do you build teams? Like some groups are what you'd call functional, but all the people who do software and one group and all the people who do hard-witting group and all the people do atoms in another group. Right, and then the managers,

but if the thing you're building needs a little of all three of those things, you know, it's it's called a, you know, functional organization versus product organization, you might want a team with a couple of programmers, a couple of hard group people, a couple of Adam people, and same team. So they're all they're all they all have one goal as opposed to the functional groups that I'm

making about software. Was it the right thing for this product? I don't know. And then we're going to product that we're on software. So I'm generally speaking, you know, product focus. So you're going to, so if you only have like five of some, some discipline, you tend to make a little functional team like that. There's a couple of things in computer design, which are functional.

But generally speaking, I like product focus organization. So everybody's like, they're all working together on the same thing. They may have different disciplines. So AMD one. Now you've encountered all sorts of frustration. Sorry, you've encountered all sorts of frustrating situations when you've gone into companies

that where you're trying to put together a good product. And so what have you seen? What do you see as particularly counterproductive? And what have you learned to how to conduct yourself so that you can be successful? We leadership, people who can't make the technical decisions they have to, that's a big problem. Functional organizations where people are optimizing for the function, not the product.

Bad goals is one of the worst things. Some organizations have real capability gaps. They think they have the right people, but they don't. Some managers play favorites, they think phones always really good and they're not. Yeah, so that's a real functional analysis. The company just can't do what it needs to do. Yeah, so we're still analyzing, here's the group, they're actually from some place, there's a belief that we're going to build this product, that has to be a great product, and how do you do the

basic blocking, tackling, and how to make that successful? That's different than the malaise, and the malaise that overtakes big companies, which you can generically call your credit capture. That's a different problem. Like a company that's bureaucratically captured will manifest all kinds of bad behavior in your organization and product development. But, and then, you know, some big companies

where the, you know, the bureaucracy is taking over, it might still be groups that are really doing a great job making great products. You know, so there's making great products. I think there are separate spaces and I understand both of them pretty well. And again, the way it's all big complicated problems, you have some abstractions about what you're dealing with. So, framework like goals organization capability and contractors is a super clear message for evaluating what the hell is going on and then making changes. You know, very specific changes to that. Culture clear, you know, if you're not clear, nothing else matters. Get the goals clear. Right, capabilities are they good? Get on direct capabilities, nothing will save you. You

have to have the ability to do the job you're doing. You know, this is your organization serve the goals. to do the job you're doing. You know, this is organization serve, the goals. That's a big problem. That's painful one. That's because that's when you start changing who works for who and what the boundaries are. But you have to do it. Okay, so let's tackle it this way then.

So you're going to pick someone who has optimal attributes to create and operate within a highly functional organization. What are you looking for in that person? What's crucial? Well, people are fairly diverse. That's the funny thing. So engineers need to have this will to create, after technical leaders, let's say. And then they have to have the

discernment to make, you know, decisions about whether they're actually making progress towards the goals or disposing their time on something cute. Right? That's, that's a thing. Uh, technical managers, you know, they need to know how to run a program. You need to have a higher in fire. They need to have a structure of work. They need to know how to evaluate how long it's going to take, how to evaluate whether people are making progress. There's a whole bunch of things, but then people have very different styles. Some people are very extroverted or were with this woman that she was great. She was having these team meetings and she would really get out there and energize the team. And another guy in the same building was

very low key and he would wander around and talk to people and have a really good sense of the team like an inferberg versus extra bird style. But they both worked. They were both very competent. They were both, to me, you know, really good technical competency. They weren't my technical leads, but they were technically competent enough to make the decisions and know when they had the punter decision up. So who do you not want? Who do you not? Okay, so I mean, that kind of goes along with the management literature. You see that you want people who are intelligent, especially for complex jobs, so they can learn. You want people who are conscientious because they work hard and they have integrity, then with the other dimensions, it looks like there's a fair bit of variability, although too much negative emotionality can be a problem. I think that's because it's associated with depression

and too much anxiety and so on, but there's diversity in the other personality dimensions and that might be task specific. But what sort of person do you not want to work with? Thanks. There's lots of fakers out there. You know, they have sales attributes or extra-verted agreeable. You know, they want to say everything is good all the time. They're not sufficiently concerned about disaster and beginning in the stuff. They may have some kind of narcissistic personality problem. So they're imposterous.

They're mimicking competence. They're mimicking competence. That's a problem. There are people who literally... They take credit from other people. Yeah, I kind of put that in a separate book, but there's people who credit for the team. I realize early on, there's two kinds of managers, mad people get up and people get down. Like, like, as a man, so I often tangled with the people I work for, but I always took care of the people

who work for me. But some other mad, I had this one that looks at me. I thought it was great. And then I I walked by, I'm meaning he was having, he was abusing his team and they hated them. I fired him because he always said the nice things to me and you know he's on those people. So it's, yeah, there's a bunch of weird stuff that happens to the man's and like that. Like you have to be excited. Like if you're a senior manager and I tech thing, there's many people in the group that are smarter. When you have to promote them and put that forward, you can't be uncomfortable because somebody's smart.

Well, as an A&D, I had 16 year fellows, I think they were all smart. They weren't as generalist for something, and they didn't have my interest in architecture organization. But man, it was smart, super good. I could talk to them all, I could keep up with them sometimes,

but you know, I was more than happy to promote them as smart guys. Why were you confident enough, do you think, to allow you to be surrounded by people that you I'm a bug average smart, but I met people who are so smart. I knew Butler Lampson was a famous unrated IQ, and his wife, the smarter, was a joke that he spoke at half-lampson, because his wife was smart and his smoke spoke really fast. But I had a fairly young age. I was confident in getting things done and work with people

that were smarter than me, but they liked my, you know, I'm an engineer and I built stuff, you know, the, you know, the rocket science would say, think it up and then they hope somebody would build it for them. Because they're all funded the next thing. But that's, you know, a belief I have. You know, it wasn't always easy. I still remember working on EV5

and I went to the digital research lab and there's half of those and super smart people. And I started describing what I was doing and I would describe something for about two minutes and then they would spend five minutes taking the part and analyzing how it could be like way better. And then they'd ask me the next question. After an hour of that I felt like, oh my god, it was just beating the desk. And they were like, this is great job.

I was like, you thought that was great. They're like, yeah, we're glad you're doing it. So I've always had that attitude since. But yeah, it's hard on some people and they realize how smart some people are. So what did I make up for it? Because I'm open-minded and I work my ass off for many years and then I've dived in lots of things. And then, you know, I'm not afraid to ask dumb questions. I, you know, like a lot of people protect, they're trying to reject who they are. So they don't ask for a question if they don't

learn it. And I'm like, I'm not really going to understand what hell is going on. I've done that in the room with 50 people. And they're like, well, we thought you should know. It's like, well, I don't, but I'm not going to leave until I do. And then to give all the information, and then I'm smarter than I used to be. And so that takes a certain mental resilience, and sometimes it's very hard on me. But again, it's sort of like, you fire the people you have to fire to save the group and save the product maybe save the company. Yeah, but said then that goodness. It's really high That's the right thing to do Exposing yourself is right thing to do ironically Now it's hard and it's hard and you know well if you admit you're stupid then sometimes you don't have to stay that way

Yeah, it's hard in some sick organization sometimes it's not safe And I feel for people who are in places where they would really like to be more open and can't because organizations that get political and bureaucratic are hard on people that are actually trying to do the right thing and learn. I totally understand that. It takes a while to, you know, the psychological safety thing

is it gets overused and gets a bad rapid, but having an organization where it's actually safe to open your mouth and talk and ask questions and occasionally looks stupid. You know, and fumble a little bit and have your peers like support you with that and be happy for you and learn stuff. That's really important. It's hard to do. And so, and there's great attention because, you know, as a leader, you have to be just real enough to do the hard things while still creating a environment where people can open up and do that. I would say, I'm mixed. I have mixed reviews on that topic because once I feel, I feel fine things that are wrong and people are doing the wrong thing, you know, I have to get to the bottom.

And I'm going to close with people. It's never happened to them before. Like, the people haven't really taken what apart. You know, they got Asin College and they got good reviews. They rose to their Peter principle and confidence point and all of a sudden, they're doing something over their head and they know what to do to do about it and have a lot of practice. So, yeah, it's a funny thing. So, I'm going to close with a question about your current venture.

You're now working with a company that does AI computing and what do you hope to do that you can talk about? Well, so I was an investor in this company when it first started, the B.S.A.J.E.J. was the founder, worked with me at AMD, and I always thought he was an especially smart guy, and I'd like to his approach to building AI computation.

I'm really intrigued about computer's program by data. I think it's more like how our brains work. Our brains are really weird, right? Because we think in this living or narrative, we have those old voices in our head, but we know we have 10 billion neurons, and they're collecting the way, you know, exchanging small amounts of brain transmitters and electrical pulses. You know, it's bloody hilarious and gap between what a neural looks like and what a thought looks like. And so, and there's a really interesting opportunity to make big AI computers that are actually really programmable.

So one of the things we're doing is we're building the software stack that lets you build a neural network you want and then program and get the results you expect reasonably well, as opposed to having a very large army of people tweaking it. And so there's a bunch of architectural, interesting things to do. And then it's the startup, which we have chips

that work, we started production, we're gonna start selling them. There's a whole bunch of work to do on how to engage with customers. A lot of customers who are talking to are super smart. There's all these AI software startups, and it's really smart people that know some problems that basically have to computer for a million times faster and easier to solve. So there's a huge capacity gap on what they want to do. So participating that is fun. Like I like that kind of thinking. And your goal? So you go into an organization, you have a goal for the chips, what's your goal for this organization? Oh, we're going to be successful selling AI computers or large-scale people.

You know, a significantly better performance, better programability in lower cost. And there's a bunch of innovation work to do around that, to make that really possible doable. Like, the AI field is relatively new. The computers that run AI today are relatively clunky. And to me, you know, need a lot of work and refinement so that, you know, from the idea that you want to express in the program, the ratings that result you want, better and cleaner. Okay, so one final question. For anyone who's listening who would like to pursue engineering as a

career, or let's say who wants to be successful within the confines of a big company, what advice do you have for people? What have you learned that you can sum up? Yeah, look straight, I'm gonna ask you that. First, you have to know yourself a bunch. Like, what are you good at? Like, you can't get really good at something you're not into, and you're not good at it. So you have to have some natural talent for it,

and then you have to really spend some time figuring out what you like. Like, I read this thing, it was interesting. People think of college as expanding their possibilities in the university itself. Has so many options. You think that would expand your possibilities. But once you pick one of them, and you study it for four or eight, ten years, you've narrowed your possibilities, right? You're kind of stuck with your discipline and you pick that 20, which I think is crazy, by the way. Like, I think if you wanna be an engineer, good general engineering degree,

like mechanical engineering or electrical engineering, we'll give you thinking skill sets. I'm not a huge fan of people getting PhDs unless they really, really know they love it. And then take some jobs where there's an opportunity to do something for a year or two and then do something else. My first job out of school was a random job, but I worked on like five different projects in two years. I was there fixing hardware, building something, debugging something. I learned a lot in the digital. I had many different roles, even though I set that company for 15 years.

I wrote program, did logic design, I did testing, I did lab work. And so I got to see a lot of different things and get a feel for what I really liked. I work with smart people that you know I had a lot to learn from. Working hard when you're young is really useful. You know some people like well you know it's like the 10,000 hour problem and if you want to be an expert you need to do that a couple of different times on different things and you can't do it unless you really love it. Friend of mine's life said when they put in a lot or all else you guys could just talk about work. Yeah. So you figure out what you're competent at,

because you need that. Figure out what you're interested in. I mean, men and women seem to pick different occupations, not based on their competence, but on their interest. And so interest is a very powerful motivating factor. Oh, and I've been in a lot of places with the best engineers for women. So, you know, we know that numbers are last, but there's plenty of really great.

Yeah, it certainly doesn't make it impossible. It's just an indication of the, of the, what would you call it, of the impact of interest as a phenomenon. It's important as well as competence. Yeah, and so a diverse range of experiences. Don't go on over index on something before you're really sure that that's something that you really going to like or be great at. Don't be afraid to ask stupid questions if you don't know what you're doing. Yeah. Try to work with good people.

Working organizations where like if everybody hates to come to your work and then move somewhere else, you want to work, work someplace where the energy is good. People are excited about what you're doing and why. Like sometimes you might be in a, in a company that has, you know, something going wrong but your group is, you know, going to change it. That can be really fun. But you need some camaraderie, some hope, or the goals clear.

Right, so that's an adventure. You have a destination and the camaraderie along the way. And there's so many places doing some of the wild things, we can stuck in a company you don't like, it doesn't go in nowhere for 10 years, man. You don't have that many 10 years swastling into life. Make sure you're actually getting, especially if you're on a different experience. Somebody said, you have ten years experience or one of your experience ten times.

Right. Now, sometimes you work on the same thing and you refine it and you become the expert, but then you should feel like you're making progress at expertise. But if you're just kind of going through the motions over and over and doing that, then it's time to fire yourself under this condition. You're bored, you're not moving, right? Against engineering, it's not boring, right? Relatively exciting.

Yeah, I think that's actually a pretty good rule of thumb. If you're bored, you're doing it wrong. Yeah, something's wrong. Yeah, it's something funny. Like, like, like, like, any of you had this group that did test and it was kind of just some sort of there's a couple of managers and nobody liked it.

And at some level, the test engineering wasn't the hardest thing. So, but I decided, that's stupid, why isn't always in our test group the best in the world. Well, we were organized around it. We had a really great later. We had a good team. I told him I wanted it to be really great. And I told the engineers to stop complaining about it. They had a problem come to me and we'll fix it. Which in two years people come to me and he's like, man, the test got you killed.

Yeah, they went above and beyond. They they made it something of value. You know, it was great. Super funding. That's a really good place to end. Cool. Thanks, Jim. Hey, good to you, man. Much appreciated. Thank you for taking the time. All right. We'll talk soon. Yeah, cheers. Bye. Bye.