He’s a former Bell Labs member of technical staff, co-author of the original C book, and the one who popularized “Hello World.” I interviewed him for all of his stories around the legendary place and the folks that worked there.

I also did some extra digging for this interview to come up with some interesting tidbits to discuss. For instance, I found a post where someone used modern hardware to break the old encryption scheme they used back in the day. I read his old password back to him in the interview.

I brought my gear and traveled to his office at Princeton. You can tell I shot it myself because my angle is out of focus for a large part of the episode. I figured out a better way to self-monitor after this episode so hopefully it doesn’t happen again. Hope you enjoy the episode!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:42 - What Bell Labs was and how he got hired

06:34 - Why so many inventions came from Bell Labs

14:15 - A day in the life at Bell Labs

27:55 - The most impressive people he worked with

33:50 - The AT&T film explaining Unix

39:46 - Why C was so influential

43:25 - How awk was created

48:40 - What he misses most about Bell Labs

54:10 - Are LLMs bad for computer science education

01:01:46 - His 1972 commit in the Go repo

01:03:43 - Grace Emlen, the fake Bell Labs employee

01:07:39 - Why he writes so many books

01:19:58 - His favorite and least favorite languages

01:24:28 - Advice for students and young people

Transcript

00:42 — What Bell Labs was and how he got hired

Ryan:

[00:42] Could you explain what Bell Labs was and what is the story behind you getting a job there?

Brian:

[00:55] So Bell Labs was like the research arm of AT&T. It was founded in, I think, 1923, ‘25, something like that. AT&T at that point was growing. It had absorbed a bunch of the local telephone companies across the whole country, and they realized that they just needed to understand things better so that they could improve service. So they set up a research operation, which was called Bell Telephone Laboratories.

[01:23] It was in New York on West Street, and people did all kinds of things related to improving telephony. In 1963, something like that, in the early ‘60s, they basically moved the whole operation to New Jersey, northern New Jersey, a place called Murray Hill, near Summit and things like that. So call it 25 miles west of New York City. And that was a big operation. There were probably 3,000 people in one connected set of buildings doing research in all kinds of things.

[02:02] Physics, semiconductor physics, devices like that, chemistry, optical fiber kinds of things, just all sorts of research. And then more on the soft end, there was mathematics and increasingly there was computers, computer-related things as they gradually came to the realization that computing was gonna be part of the future in some way or another. In the summer of 1966, I was a grad student here at Princeton, but I got an internship at MIT in Cambridge working in Project MAC, which was basically the Multics project.

[02:39] And so I used CTSS, that first original timesharing system, done by Fernando Corbató and friends, to develop software for the Multics system, which was just starting up. And that was a lot of fun. I enjoyed it. I’m not sure I ever did anything that was very useful, but part of it was then the next year I got an internship at Bell Labs in Murray Hill. So I was still a graduate student, and that would be roughly the third year here, I got this internship at Bell Labs, and that was a lot of fun.

[03:18] And I worked there, I worked actually with Doug McIlroy for the summer, came back here, continued to stall on doing my thesis work, which I guess is what one does. And then I got another internship in the summer of 1968, and there I worked with Shen Lin, and he and I worked on a problem which had been suggested by my advisor here. And this was graph partitioning. And he and I worked on it, and we came up with an algorithm that did a pretty decent job on part of it.

[03:50] I came up with several special cases that you could do really well. And then I wrote up the thesis really quickly and escaped.

Ryan:

[03:57] Escaped Princeton.

Brian:

[04:00] Escaped from Princeton. I took a whole week off and went to Bell Labs because they’d given me a return offer, which was very sweet of them. And I stayed there then until roughly 2000 in the group that had done or was doing a variety of things.

Ryan:

[04:15] Did you consider other career opportunities at the time?

Brian:

[04:19] I think I didn’t consider any other option whatsoever. I mean, I had really enjoyed the summers. The two summers were great. The people were really, really nice and interesting. There was stuff to do. It was close. I didn’t have to go anywhere, as it were. And so I literally never considered anything else. I never had a job interview, nothing like that. I just went there. So it was kind of like falling down the fall line or something like that.

[04:48] I think partly it was helped along by some sort of old boy network, where somebody here at Princeton knew somebody at Bell Labs, because there’s a lot of back and forth between the 2 institutions. And so I’m sure that kind of thing helped. It also helped, I think, at MIT that a guy who had had an internship the year before me had done a bang-up job for them. And so that probably said, well, these folks from Princeton are maybe okay.

[05:17] So I’m grateful to him too.

Ryan:

[05:19] Nowadays, Bell Labs is so legendary, but at that time, what was the social perception? If I had talked to your peers and said, “Hey, what do you think of Bell Labs?” what would they have said at that time?

Brian:

[05:33] I suspect that it depended on the field, but probably for most of them, they would’ve thought, yeah, yeah, this is a really good place. Because in the physical sciences, it was obviously the powerhouse in a lot of respects. That’s where your transistor came from, for example. And a lot of things related to communications, that’s where information theory came from. It’s where error-correcting codes came from.

[05:54] All of these things that were sort of critical advances in technology had come from Bell Labs. Bell Labs was a part of the scientific community. People who went to Bell Labs published in exactly the same journals and went to the same conferences, collaborated with people in the same universities. And so it was really an integral part, I think, of the scientific community at the time. And that was largely, I will say, the physical sciences kind of thing, but it obviously sort of spread out into other things that were peripherally related.

[06:27] And certainly the mathematicians were absolutely first-rate as well. Tended to be applied mathematicians rather than theoretical ones.

06:34 — Why so many inventions came from Bell Labs

Ryan:

[06:34] Everything you just said there is an insane value for humanity, the transistor and all those other things. Why is it that so much of it came from one research lab tied to a company that today is not known for all these amazing innovations?

Brian:

[06:56] AT&T bankrolled all kinds of contributions that Bell Labs made. And I think the way it worked was that AT&T provided telephone service to essentially the whole country. I mean, maybe it was 80%, but it was a very substantial fraction of the whole country. And that meant that they had a pretty guaranteed revenue stream. Now it was regulated. They were a regulated public monopoly. That’s the jargon term.

[07:20] And that meant that their rates were set or restricted or at least evaluated by lots and lots of agencies, states, and the federal government. So there was a limit to what they could do. The quid pro quo was they got sort of a guaranteed rate of return on their investment in whatever they did with the phone company. And the quid pro quo would be that they provided telephone service to essentially everybody.

[07:47] Even if you were way out in the boonies or something like that, AT&T would provide this service. And they were able to rip off a small fraction of that. I will make up a number and say 1 or 2% of their pretty much guaranteed revenues to fund a research operation that would let them improve the service. And so that was the basic, call it financial arrangement. And the other thing is it was very stable.

[08:11] You could sort of predict there would be this steady increase in revenues, but predictable in a way that would guarantee that there would always be money to do something. There was no competition because AT&T had essentially what amounted to this monopoly. And so that meant that they could take a very long view of what they were doing. And so if somebody had an idea and wanted to work on it for a year or 2 or 3, fine, go for it.

[08:39] And if you’ve got a bunch of people doing this, even if your idea is dumb, my idea is dumb, somebody else might have a good idea. And so if you aggregate, the output would be probably something useful almost all the time.

Ryan:

[08:52] What gave this lab such recruiting pull, in your opinion? How did all the best people come to this place?

Brian:

[09:02] Well, I think it depends. For me, it was certainly happenstance, just blind luck, being in the right place at the right time, following people who had done something that in some way prepared the way. I think if you were a physicist getting your degree in physics at pick your favorite good university, where would you go to do physics? Well, the opportunities would fundamentally be government lab perhaps, or a place like maybe IBM or maybe Bell Labs.

[09:31] And Bell Labs had a sterling reputation, well-earned, for doing exceptional work in that area. So that would be, let’s say, anybody doing physics, chemistry, materials, all of that kind of stuff. I think somewhat the same would be true of anything related to mathematics, especially the mathematics of communication or anything related to communication systems. I mean, that’s where Shannon was, that’s where Hamming was, Bode, Nyquist, all of those people before those.

[10:00] So that kind of, again, tremendous reputation for the place. And as I said, they were part of the scientific community. It wasn’t like it was off on Mars somewhere, and it wasn’t like you went there and disappeared. You went there and you were a part of the broader community. And so I think the computing stuff came along and had some of the same advantages, but it wasn’t clear who the heroes were at that point.

[10:23] It was early-ish, because remember, I went there in 1969. So computers were still pretty young at that point.

Ryan:

[10:30] A lot of those names you mentioned, I mean, they were in my textbooks when I was studying. And so they’re kind of the heroes and everything. But so at that time you’re saying your perspective was they were just kind of the lead on the team, but they weren’t the legendary computer scientists.

Brian:

[10:51] Well, it’s hard to say, and it’s not even clear what a computer scientist is, but you want a story? When I went to Bell Labs for my first internship, so call it the summer of 1967, and I was in an office that was sort of a little smaller than the one we’re sitting in now. But as a summer intern, for some accidental reason, I had an office of my own. This never happens, but it did happen. And so I’m sitting there on the very first day at about, roughly 11 o’clock in the morning, wondering what the hell do I do?

[11:23] And this older guy came along, passed the door, and he said, “Hi, I’m Dick. Let’s go to lunch.” I said, okay. So I went to lunch with Dick. I never did get his name right. And so we had a nice lunch conversation. I don’t remember anything about it. And then he went off somewhere else. And I came back and went to the next door to me and looked at the name tag on the door. It was Richard Hamming. Hamming had written the book that I had used previous semester for numerical analysis, and, of course, error correcting codes.

[11:56] And there he was next door, super nice guy. And was he a computer scientist? Borderline. Yeah. But possibly he did win the 3rd Turing Award. Won it, was it that summer or the next summer? I’d have to go and look. And so there were people like that around, but in the very early days, the computing stuff was, I think, it hadn’t developed into something with its own academic structure, its own reward systems, and all those kinds of things.

Ryan:

[12:26] When I interviewed Leslie Lamport, and I forgot his exact timelines, but I remember early in his education, computer science wasn’t established, and he actually said it was not as respected as math and physics, or maybe because it just was a burgeoning—it was brand new.

Brian:

[12:47] The same thing happened here, I think. I came here as a grad student in 1964, and I came in electrical engineering. I had thought to work on computing because I had some notion that it was interesting, and I thought AI, I didn’t know a thing. Unbelievably naive. And I had sought to work with a guy named Arthur Samuel who had done some interesting stuff in computer chess playing, et cetera. And I got here, discovered it was the wrong guy.

[13:16] But when I got here, the electrical engineering department had a bunch of very established, highly respected people who were doing traditional electrical engineering things, information theory, communications, solid-state physics, that kind of stuff. And a cohort of young people who had interest in computing. They had just gotten their degrees from someplace, and they were very young and wanted to do computing.

[13:42] And I don’t know whether any of them ever got tenure because the older folks didn’t really grok the newer field. John Hopcroft, to pick a random example, was my technical advisor for a year. Oh. Although it was quickly discovered I was not a theoretician. But John went on to win a Turing Award and was dean of engineering at Cornell. There’s all kinds of stuff. Great guy. But he wouldn’t have gotten tenure here at that particular time because the computing science aspect of things was too new.

14:15 — A day in the life at Bell Labs

Ryan:

[14:15] Bell Labs is kind of famous for very hands-off management and letting the engineers do what they were doing. What is a day in the life like of an engineer working at Bell Labs?

Brian:

[14:30] Well, first thing, I don’t think any of us would’ve called ourselves engineers. We were doing whatever you did, but I don’t think that engineer was the right word because we weren’t really engineering.

Ryan:

[14:43] It was Member of Technical Staff.

Brian:

[14:45] Member of Technical Staff, which was a term that applied to everybody essentially. And a typical day would be basically you’d come in at whatever time, which could be anywhere from 8 in the morning to 2 or 3 in the afternoon maybe. And you would sit in your office, private office, with the door open, and you would think about whatever it was you were thinking about. Maybe you had been working on some kind of program, or maybe you were trying to prove a theorem.

[15:16] That’s not me. And people would wander by and you would talk to them. They would come in, you’d have discussions on the blackboard, perhaps of technical things, or maybe just arm-waving discussions of something else. You’d walk up and down the very long main corridor to the coffee machine at the other end, where you would run into random people. There would be technical talks from time to time, maybe one every week or two, something like that, depending, sometimes from internal people, sometimes from external people.

[15:48] So in a sense, maybe not too different from what you would find in a university, except there were no students. And so that meant you could do it full-time. The trade-off was that without the students, you could do more of your own thing, and you were doing it with your peers. So I would argue with somebody, Ken Thompson or Dennis Ritchie or whatever like that, who were my peers. I didn’t have to work with students.

[16:15] But of course, the flip side is that I didn’t get any of the benefit that you get with bright young new people talking about it, except that, as a newcomer, they’re always supposedly the bright new young person. So mainly the lack of students, which I think is a mixed blessing.

Ryan:

[16:30] In industry, there’s often deadlines, managers, and all of that stuff, right? What’s stopping a researcher from coming in at 3, leaving at 5, not having any output?

Brian:

[16:46] There was no immediate stop to that period. There were no deadlines, there were no projects, there were no objectives, goals, whatever set by other people. The mechanism for deciding whether you were doing anything was that once a year you had to write down on one side of one piece of paper what you had done. And we called it the I Am Great report, and it just summarized what you’d done. And then the first and second level of management would sit in a room with the I Am Great reports from their people.

[17:20] So this would be maybe 30 at the bottom, half a dozen, one, like that little tree. And they would discuss the merit of the contributions of the work that was being done by the people. And they would come up with some sort of ordering which says that you’re better than I am or vice versa. How would we compare to our peers? And that would give them a sort of roughly a rank ordering, or at least equivalence classes of people.

[17:49] And if somebody hadn’t done anything for a couple of years, that would be noticed. But if somebody’d gone off on something and it didn’t pay off very well, or it was still in progress, but it looked okay or whatever, that was okay. That’s the long view that I mentioned before. It’s not like, what have you done for us the last week or even quarter? What maybe have you done over the last 2, 3 years?

[18:11] And it was being assessed by people who were not driven by quarterly numbers. They were the same people as we were, except that they had moved into management, but they were still technically active and very technically knowledgeable. And then the process was repeated a couple levels up until you had an effective rank order of everybody. So that was kind of called abstract merit. I’m better than you are.

[18:35] And then there was the concrete merit phase, where we’ve got this much money, how much do you get? How much do I get?

Ryan:

[18:39] So there were bonuses tied to— It wasn’t bonuses or anything like that.

Brian:

[18:46] It was simply, there’s a pot of money, this is the raise pool, and it will be overall X percent. And so you will get X minus epsilon, I’ll get X plus epsilon or vice versa. Oh, and that was once a year, and that was the whole story. But it was very deliberative. The management was collegial. If you and I were managers and we had our people, it wasn’t like my people are better than your people. It’s rather, hey, you forgot to mention that Susie did this really great thing.

[19:17] Don’t forget Susie kind of thing. So it was quite collegial. Yeah. And you were being evaluated by people who understood the work and whose goals and aspirations and so on were the same as yours, do good stuff.

Ryan:

[19:29] It sounds like you mentioned that they’re technical. It’s like a big part of this whole system. Why is that important?

Brian:

[19:38] If somebody is doing something in a technical area, they have created a new program, they’ve proved a new theorem, they’ve developed a new process, whatever. If you are not technical enough to understand what they’re talking about, it’s hard for you to tell the bullshit from the actual useful content, right? So I could, not you personally, but I could blow smoke pretty well for people who were, I don’t know, who shall I insult?

[20:04] MBAs. Okay. Something like that. That’s obviously a slander, but it’s easier to blow smoke at somebody who is not sort of knowledgeable in your own field, but the people that you were evaluating your work were exceptionally knowledgeable in the whole field. And so they had a pretty good eye for what was good stuff and what wasn’t yet good stuff or would perhaps never be good stuff.

Ryan:

[20:31] These days, this Member of Technical Staff title is— it almost has its own brand where it’s a nod towards Bell Labs and everything that that represented there, but a lot of what it is signaling is that titles don’t matter, that we’re all the same and we’re all just focused on the technical work. Did titles matter, or what was the culture at that time?

Brian:

[20:58] Titles didn’t matter. Everybody was on a first-name basis. There were no doctor, professor, whatever kind of titles at all. Everybody was technically a member of staff, Member of Technical Staff. And I say everybody, this is of course an oversimplification. There were a variety of supporting people who, lab technicians, associate members of technical staff or whatever, but I’m talking about the MTS level and up.

[21:25] So they would be loosely equivalent to PIs in the modern academic world, principal investigator or whatever. And in computing, I never would have had somebody who helped me with my stuff. Whereas if I were a physicist, I might have some number of people who would help me do experiments, look after the mechanics of depositing stuff on stuff, all those kinds of things that went on in the physical world.

[21:54] But everybody was technically a Member of Technical Staff, even the management. But then there were department heads who’d manage first-level management, and then there were directors who were second-level management, and then there was executive director, and then there was vice president. But it was very flat in that sense. Most people did not want to be promoted because that would be seen as the end of their personal technical career, that it would move them away from the kind of work that they really enjoyed doing.

[22:23] So being promoted was something to be avoided, not to be sought. And I think that went for quite a long time. Things did change, but I’m talking about the golden era of, call it the late ‘60s, ‘70s, early ‘80s, something like that.

Ryan:

[22:41] Did you and your peers ever think about career development in some way, or was it not even something you cared about?

Brian:

[22:52] Career development for myself as an individual, I never thought about it at all. I mean, usually I was having a good time and I was surrounded by lots of good people. Career development for the people, for example, when I was in first-level management, I was a department head for some years. I don’t remember much about how explicit it was, but there was some theory that you should actually be looking after the interests of the people in your department.

[23:17] I think the main way that that would be reflected is understanding the work they were doing, really trying to understand what it was they were doing so that you could represent it fairly at things like merit review. Also so you could see opportunities to, oh gee, did you know Dave was working on this stuff? So that you could sort of cross-fertilize across the way to try and give them feedback, sort of say.

[23:42] Are you sure this is gonna work? Or keep an eye on this, sort of guide them towards future success, but not telling them what to do. There was never any, this is what you have to do. There was no, there just wasn’t any, it wasn’t guidance at all. At most, there was a gentle gravitational pull towards stuff that would be useful or interesting.

Ryan:

[24:04] So you mentioned you were a head at some point and you managed some reports. You never had a report that was saying, “I want to grow in some way,” or they’re kind of hustling, kind of pushing you some way?

Brian:

[24:19] There were a handful of people I could remember who wanted to be in management. That was unusual, but there was nothing wrong with it. It’s just that being in research management, because the structure was so flat, it would take probably quite a while before you would move up. If you really wanted to be in management, you probably wanted to move into a different organization, development organization, where the rules of engagement and so on were much different.

[24:48] And there were several, I shouldn’t say several, but at least a handful of people who were interested in that kind of advancement. And they went into development type jobs, which are perfectly fine, just different in a lot of ways. And there they had much more traditional responsibilities of management, including looking after their people. But I think the research operation was much more a bunch of cats and you can’t really herd them.

Ryan:

[25:15] So what’s the story behind you becoming a manager in that kind of environment? Because it seems like it’s something everyone’s avoiding.

Brian:

[25:24] I had no desire to do it. And I was blandished a couple of times, “Wouldn’t you like to be a manager?” But it was in some other organization, even within research. And I always thought the group that I was in was special, probably was. And so I had no interest in being manager in some other part of it. And so I basically declined with thanks. But then it was, would you like to be a manager in your own organization?

[25:51] And I wasn’t very enthusiastic, but okay. And they got lots of ways they can, you know, it’s inevitable. Why not now? Or, alternately, if you don’t do it now, it might never come, which is completely contradictory. Or if you don’t do it, somebody else not as good is gonna do it. So all of the usual stuff. And I finally succumbed, I think, in about ‘81. So I’d been there at that point, call it 12 years for real.

[26:19] So that’s the first promotion. And it was okay, but it wasn’t as much fun, I think, because now I was responsible for roughly 10 people. Had to understand their work, which was all over the map, had to be able to talk to other people about it, had to go to more meetings. So it was okay, but it was not my favorite part of the job, really.

Ryan:

[26:43] How did you know your group was so special? Because when I look at it, it is in hindsight. I mean, I saw Bjarne was reporting to you, and of course, there’s Dennis Ritchie nearby and Ken Thompson. And you also mentioned other people like Doug McIlroy and Richard Hamming. So how did you know at that time that it was such a special group?

Brian:

[27:06] I think a lot of it was not so much knowing that the work they were doing was gonna prove to be in the future important, but that they were just really clearly smart and seemed to be doing things that were interesting and relevant. Most of us used the work that our peers did. Certainly all of the things related to Unix, we just used that. That was our computing environment. The languages that were developed, the tools that were developed, and so on, we used them.

[27:34] And so you could get a sense of who’s doing stuff that actually matters to me. And so I think that was part of it. Extrapolating long-term effect, we’re not very good at that, or I certainly wasn’t, figuring out who were the ones who were gonna win Turing Awards. No, not really.

27:55 — The most impressive people he worked with

Ryan:

[27:55] You worked with so many legendary people. Was there anyone that, I guess, or any story of someone who kind of impressed you the most, or you thought, wow, their technical chops are just untouchable?

Brian:

[28:10] There’s several like that. Ken Thompson’s the obvious one, I think. Certainly the best programmer I’ve ever met, unparalleled. And the story is the first version of Unix where he’s got this little old PDP-7, which is an obsolete machine, has something like 8K 18-bit words. So it’s a tiny little machine. He’s been fooling around with something to drive the disk on it. And he’s thinking about how do you schedule disk operations so that it’ll go fast and stuff like that?

[28:47] And his wife takes their young son off to California for 3 weeks, and he thinks, I could do something here. And so in 3 weeks he builds himself an editor, an assembler, and an operating system. And there you have it.

Ryan:

[28:59] By himself?

Brian:

[29:01] Yeah. Oh yeah, absolutely.

Ryan:

[29:03] When I used to write, you go to Stack Overflow, or you look up how to write the code and then you write it. How does he do it without all that Internet resource?

Brian:

[29:17] Because he’s a boatload smarter than you and I put together. And this is before any of that stuff existed, right? This was 1969. And so he’s probably writing the code in assembly language, bear in mind, not any high-level language. And he’s doing it probably on some other machine just because it has some kind of text editor. And then he’s making paper tapes that he carries to this tiny little machine and loads them and sees what happens.

Ryan:

[29:43] Oh my God.

Brian:

[29:45] Yeah. So it’s going back into the mists of time, but three weeks and he’s got a working operating system. So I think that is a good example of somebody who’s just off-scale good at what they do. And there were a lot of people like that at the labs. I mentioned Doug McIlroy a number of times. He was my first internship. He was notionally my boss, and he was interested in storage allocators, ML kind of thing.

[30:14] And so he set me to working on something, and I almost instantaneously went somewhere else, and he didn’t care. So I spent the summer doing something unrelated to that, and it seemed like it was fine because I got a come back next summer kind of offer. But he was the kind of guy who was exceptionally good at pretty much anything he wanted to do. I mean, Ken Thompson says Doug’s the smartest person he ever met.

[30:41] So this is—we’re multiple levels above me at this point. But Doug was extremely good at assessing, experimenting with, and criticizing other people’s work in a very constructive way. So he was a second reader, the outside reader on my PhD thesis, and he greatly improved my writing and the content of the thesis. And he continued to do that essentially for his whole life. He’s still doing it. And he contributed a bunch of useful software, his own Unix sort program, Doug.

[31:16] Unix diff program compares 2 files. Doug. A bunch of things of that sort. He did language design and development of his own. He wrote one of the very first PL/I compilers. He invented the idea of macros. And it’s just on and on and on and on. And he was also the department head who sort of had Ken Thompson in his department. No. Doug wouldn’t tell Ken what to do, obviously, but appreciated the work and was an incredibly effective technical critic of that kind of work.

[31:53] So, gee, wouldn’t it be nice if, or you thought about it that way, or Jesus sucks, whatever, to make stuff good. And that’s a role that he played for the entire time that he was at Bell Labs. I first met him in ‘67, I guess, and he was until he retired early to mid-’90s or something like that.

Ryan:

[32:12] This reminds me, when you mentioned department head, somewhere in my research, it might’ve been Hamming. There was someone that you worked with who was a head of the department with no reports.

Brian:

[32:26] That’s Hamming. Yeah. Yeah, I never understood that. When I first met Dick Hamming, he was a department head. You could tell because he had carpet on his floor. I guess he showed up in the foam it that way too. But I couldn’t figure out, because I had this naive view that there was status associated with being a department head, and it was totally wrong. But he had worked very hard to get himself a department head, so he had whatever status or clout or whatever went with it for useful purposes, but no people reporting to him.

[33:02] And so I think that worked out very well. Because in any organization, if you’re not at the right level, you may get ignored. And so it was harder, presumably, for people to ignore a department head than an ordinary MTS.

Ryan:

[33:14] So he got the clout without any of the work of—

Brian:

[33:20] The dog work, yeah, right, administering. He’d put in his dues because he came to the labs, I think in ‘46, and did a lot of early stuff with computing. He’s one of the very first people to realize that actual use of computers was going to be a very important part of all kinds of research in the future. And he made this prediction that at some point more than half of the research work would be done by computing, not in physical labs.

[33:49] And of course, they laughed at him.

33:50 — The AT&T film explaining Unix

Ryan:

[33:50] In my research, somewhere on YouTube, there’s this video posted by AT&T, the corporation itself, and it’s a film titled Unix: Making Computers Easier to Use.

Brian:

[34:08] Oh yeah, AT&T did a lot of those PR films.

Ryan:

[34:12] Yeah, and you’re in the video, you’re one of the first people speaking, and you have your legs up on some desk and you’re kind of explaining, what is that?

Brian:

[34:23] It’s like any PR film. It’s trying to convince people who don’t know anything about you that you’re a great whatever institution, that you’re contributing to the public good or whatever. And so they hired a professional filmmaker kind of thing. Eric Belove, I think his name was. It was a long time ago. And he came around, and he would do sort of what we’re doing. You’d have a conversation about something.

[34:47] And try and get whoever he was talking to to elaborate on what they were doing, and then he would splice it together into something that would feel good for AT&T. And at the time this was done, which I would guess is late ‘70s, early ‘80s, something like that, yeah. Unix was kind of just starting to appear on the outside. It was a sort of a visible, interesting. And so part of the thing is AT&T is using computers to improve people’s lives or our business operations or whatever.

[35:21] What is Unix? And so my job in this film at least, and probably several others, was to sort of try to explain to a very non-technical audience what is this thing and what’s it good for and why is it new and interesting or something like that?

Ryan:

[35:38] I skimmed through the comments on this video. It has a lot of views actually. And the comments in there, one of the ones that has some of the most upvotes, is it’s saying that everyone in the film is, not to be derogatory, but kind of like computer nerd.

Brian:

[35:54] Well, we were. We still are.

Ryan:

[35:56] But they highlight you as being a very clear communicator and a bit exceptional in your ability to convey the technical stuff you’re talking about. So I was curious if you have any advice on how to communicate technical work in such a clear way.

Brian:

[36:17] Part of it is probably just putting yourself, to some extent, into the other person’s shoes. They don’t know anything about what you’re talking about, so how can you explain it with the right combination of metaphors and examples and everything else that gets it across to them? And part of that, of course, it’s nice to have feedback. So it’s easier to do that if you’re in a teaching kind of setting where you can see whether they’re getting you or not.

[36:42] And if they’re not, you can adapt. It’s harder when you’re doing a film because the audience is later, if at all. But there were a fair number of those things. We used to have dog and pony shows at, image that’s probably obsolete at this point, but AT&T or Bell Labs would bring through distinguished people on a tour of Bell Labs, and they would get demos of various things, the usual stuff, demos of what interesting work is going on at Bell Labs.

[37:15] And they would go through a variety of places, labs, so on. And Mike Koleska and I were on a regular kind of rotation for Unix demos, where we would get some exalted being accompanied by some appropriate level of Bell Labs management and others to sit on a couch in a little room, and I would show them the wonders of Unix in some way or other. Well, what are the wonders of Unix? I don’t know, but one of them was that it’s easy to create programs by combining programs.

[37:47] The idea of pipes, where I can take the output of this program into the input of this program and maybe string several together. And I had a standard demo of that, which was looking for spelling mistakes in a document. Because what you could do is, here’s a document. So what we did, collect the words in the document, get ‘em into lowercase, whatever, sort them neatly, and then compare them to another document, which is a dictionary.

[38:14] And if you find a word that’s in your document, but it’s not in the dictionary, it might be a spelling mistake. And it’s one long pipeline, 6 or 7 programs. So I could do this and people would sort of understand it. This is before word processing software really came along. So I’d do this demo and people would be impressed. The high point of this, one day, one of those visitors was a guy named William Colby.

[38:41] William Colby was the director of the CIA, and he was accompanied by a guy who literally had a briefcase chained to his arm.

Ryan:

[38:49] Wow.

Brian:

[38:51] And Colby was accompanied by Bill Baker, who at that time I think was probably president of Bell Labs, but he was also the head of the Foreign Intelligence Advisory Board. So he was a serious spook in his own right. And so they sat there. Now, I had done this Bell demo so many times before, I knew it took too long because old machines, slow, et cetera. So what I did is the night before, I ran it into a file.

[39:17] And then what I showed Colby was a shell script that said sleep 2 and then cat the previous sleep. And so Colby was very impressed with this, I guess. It does tell you, you don’t believe what you see in demos.

Ryan:

[39:31] What’s in that briefcase? Is it a bomb or a gun?

Brian:

[39:36] It’s gotta be nuclear codes, right? I have no idea.

Ryan:

[39:40] Interesting.

Brian:

[39:42] That’s good. The gentleman with the briefcase was not identified.

39:46 — Why C was so influential

Ryan:

[39:46] One of the most famous books that you co-authored was the one on the C programming language. And since C kind of came from Bell Labs and you were so close to it, why was C so influential in your opinion? Now looking back?

Brian:

[40:04] I think it hit a sweet spot in some sense of efficiency and expressiveness. If you go back to when C was first created, let’s just call it 1972-ish or something like that, machines were pretty wimpy. They didn’t have much memory. The first machine that C ran on had, I think, 24K bytes. And that was the whole thing. So you had to write a compiler, or you had an operating system, you needed a bit space for files, what do you do?

[40:33] The disk, I think, was half a megabyte. So it’s a little tricky. So C was simple enough that you could see the translation into the underlying actual instructions of the particular machine, the PDP-11 at that point. The language was simple. You could see the compilation. You could imagine building a compiler for it straightforwardly enough. It wasn’t a big language. At the same time, it really was expressive.

[41:05] I mean, you could say what you needed to say very, very effectively in the language. And I think it’s hard to find a spot like that. And so one of the reasons I think C has succeeded as long as it has is that it still has that efficiency and, oh, I know, expressiveness is, I think, the right word. Certainly there are lots of other languages which for various purposes are a better choice at this point.

[41:33] Well, ’cause there are plenty of things that C doesn’t do, couldn’t do at the time because you didn’t have enough resources, right? You couldn’t do a lot with fancy runtime stuff. You didn’t want to do checking because checking would take code, and, yeah, come on, you’ve only got suddenly 4K bytes for your program. Now what? So an awful lot of things were cut that way. The other thing is the original target for C was to build the operating system.

[42:00] And so there’s a class of things that you just don’t need if you’re building an operating system. So I think it was, for its time, really, really, really good match. And then of course Unix and C was this sort of symbiosis. They went together. And so Unix was just so much better than any of the commercial operating systems at the time, just so much easier to use, so much more productive, and so much more fun that people used it in preference.

[42:30] And then they would write programs in C, and they would result in interesting tools. And so all of this was kind of a virtuous cycle.

43:25 — How awk was created

Ryan:

[43:25] Yeah, when I learned how to use Unix in college, there’s all these utilities, like you mentioned diff that Doug McIlroy, and then there’s a variety of other ones, grep, and of course there’s awk.

[43:53] I remember I learned that a long time ago.

Brian:

[43:58] Oh, good.

Ryan:

[43:58] Yeah. What’s the story behind that, and why’d you build it?

Brian:

[44:03] So this is back in the mid-’70-ish time, ‘76, ‘77, I guess. Alfred Aho and I had been friends for a long time. He went here to Princeton, he and I were undergrads at Toronto, although he was always a year ahead of me. And he was very interested in regular expressions, patterns of text that you could use to recognize interesting stuff. I had been fooling around pretty unsuccessfully with the idea of some kind of text editor that would let me manipulate numbers as well as text, something like that.

[44:41] And Peter Weinberger, who I don’t remember exactly how we met him, was interested in database kinds of things. And so we sort of talked back and forth and came up with this language, which combined some of those interests: the regular expression stuff from Al, the databasey flavor and report generation, like RPG, from Peter, and the sort of, wouldn’t it be nice if strings and numbers were both first-class citizens of whatever you were doing?

[45:15] So we thought about it for a while, and then, if memory serves, we came up with a sort of language design, and then Peter went off one weekend and built it. Peter’s an extremely good programmer too, but he had the advantage of tools at that point because he could define the grammar with YACC, the compiler-compiler that Steve Johnson had built, and the lexical part with Lex, the lexical analyzer generator that Mike Lesk had built.

[45:46] And so from that, building a language was not as much work as it would’ve been otherwise. There was some, just more of it was kind of built for you. And Al had the regular expression code already because that came from egrep. And so, I see. And you take this and one very bright, good programmer over a long weekend or so, and you’ve got a language. Oh, and then from there we just sort of evolved it slowly.

[46:14] And then Al and Peter dropped away from actual active maintenance probably 5, 10 years later, and I sort of inherited it.

Ryan:

[46:20] A lot of these Unix tools that everyone takes for granted, is that usually the story behind them? You guys are all using Unix and then you just realize, oh, I want to be able to pipe this to something that diffs, or I want to be able to find something in a— and then you guys just build it. Is that usually how these come about?

Brian:

[46:41] I think a lot of them come from that. It’s not from hypothesizing what somebody else might find useful. It’s more like, what do I need? What’s kind of bothering me at this point that I could improve if I just had a better tool or a language or something? And I think that’s true on almost all of the little tools that you mentioned. I don’t wanna do this by hand, or existing programs aren’t quite right.

[47:09] Let me build something new and be very easy. For example, make, which Stu Feldman did. Somebody told me, “Oh, my program didn’t work. I can’t figure out why it didn’t work. Oh, it’s because I forgot to recompile one of the files.” And so could you in some way automate that? And that’s another one of these weekend projects that Stu did. And then, boy, within a few days, he’s got a bunch of users, and then all of the mistakes he made in his first design, he can’t fix.

[47:44] So, and I think all of these have that same problem. Certainly, there are things in awkward in hindsight; it’s, oh my God, we should have done that better.

Ryan:

[47:52] A lot of the namesakes for these, they either explain themselves, like diff, I think it’s pretty clear. And then AWK is the initials of the authors. But grep is a really famous tool, but what’s the story behind the namesake of that?

Brian:

[48:09] Oh yeah, grep. Ken Thompson tells it very well, but the gist of it is that in the text editor, the ed text editor, which was the first real editor on the Unix system, there is a command called g, which says do this command on all of the lines that match a particular regular expression. And the syntax is in fact g slash re, whatever the regular expression is, slash p. Print all the lines that match this pattern.

[48:39] And hence grep.

48:40 — What he misses most about Bell Labs

Ryan:

[48:40] We talked a lot about Bell Labs and you mentioned kind of the golden years. When you look back on Bell Labs and your time there, what is it that you miss most?

Brian:

[48:54] Well, I miss the people, although I’m still in contact with a fair number of them one way or another. But they were just an amazing collection of really good, nice people, bright, fun to work with, lots of good ideas, and so on. So you miss that. One thing that probably is not reproducible in a direct sense is the environment where there are just all kinds of new things to do. So it was an era of low-hanging fruit.

[49:20] I suspect there’s similar low-hanging fruit, but I’m not in the right orchard at this point. I just don’t know enough about it. But maybe some of the AI stuff that’s going on is the moral equivalent at this point. So I think those are the things that are perhaps the most things that I miss. Bell Labs gradually became more of a conventional company as AT&T went through troubled times and split itself.

[49:47] And so all the research projects were smaller, and it meant that Bell Labs, the big cohesive bunch of people working on all kinds of things, became smaller and more fragmented and didn’t have as much money. And therefore were forced to do the kinds of things you don’t want to do, like raise money. So that part I don’t miss at all.

Ryan:

[50:04] In one of the classes that you taught, there’s a video somewhere buried deep in YouTube where you are trimming your beard in the lecture. Do you remember that? And what’s the reason for grooming during the lecture?

Brian:

[50:20] I remember that one. That is actually, you should ask David. He was in that class. That was at Harvard. That was the first lecture of CS50 the year I taught it at the beginning. So that’d be September of 1996, I think. I had never taught a big class before. The class had been taught by Margo Seltzer, who at the time was in computer science there, and she was taking a sabbatical, and she asked if I would be interested in teaching her course.

[50:48] And I thought, only chance I’ll ever get to teach at Harvard, why not? But Margo had a shtick that she did at the beginning of her first lecture, which was trying to explain to people why it’s hard to tell a computer what to do. And so she would get the audience in her class to direct her in making a peanut butter and jelly sandwich. And it’d be very easy to get the jelly on the desk and the peanut butter on your head and stuff if the instructions weren’t clear.

[51:16] But I’m not a peanut butter and jelly kind of person. And I thought, what’s the equivalent? And then it occurred to me, I have this ratty beard. So I brought in a collection of equipment suitable for trimming a beard, ranging from a pair of scissors to electric hedge trimmers. And I got the audience to try and guide me through trimming my beard with this stuff. And I don’t remember, I think actually the hedge trimmers were plugged in, but there was, you wanna be very careful.

Ryan:

[51:48] So you mentioned that was your first big

Brian:

[51:52] Yes, 457.

Ryan:

[51:55] Was public speaking nerve-wracking at that time for such a large group?

Brian:

[52:01] No, I think originally when I was a grad student or something, public speaking was very challenging. But one of the things I did first at Bell Labs, in one of those—I think maybe even intern years, I don’t remember now—was Vic Vyssotsky, who was across the hall from me, said, “We’ve got a bunch of physics guys who need to learn Fortran. Would you mind teaching them?” And so I did that. And so the teaching experience got me over this fear of public speaking totally, completely.

[52:35] And so I had done a bit of adjunct teaching while I was at Bell Labs earlier before the Harvard gig. Yeah. That was by far the biggest, at least more than an order of magnitude the biggest. But at that point, it’s not the size of the audience so much, it becomes a theater performance. And David Malan can tell you that more accurately because he’s really good at it.

Ryan:

[52:59] So if someone who’s a student and is scared of public speaking asks you for advice, what would you tell them?

Brian:

[53:09] I think doing it, getting into an environment where you have to talk to people, at least in small groups to begin with, and then maybe bigger ones is okay. And I think there’s no better way than actually just doing it, getting out there and forcing it. So I’m past the stage where I worry about that sort of thing. I guess conference presentations are sort of like that too, but teaching’s better because it’s a more intimate setting for the most part, talking to 400 people, but it’s a more intimate setting.

[53:43] And so you’ve got a better way to judge whether your content is getting in contact with your audience, whether they’re understanding you or not. And if you think of them as friends or something like that, and then you blur your vision a little so you’re not really looking directly, it looks like you’re looking at them, but you’re not. Or you focus on one person in the audience who seems to be resonating.

[54:03] All of these things I think help, but after a while, it just becomes practice and then you don’t worry about it.

54:10 — Are LLMs bad for computer science education

Ryan:

[54:10] I know you still lecture here at Princeton from time to time, and it seems like more recently the education may be changing because of some of this LLM AI stuff. I mean, unprecedented access to answers, I guess. Do you believe that LLMs are a net negative or a net positive when you look at education?

Brian:

[54:36] I think it’s too early to tell. I can see plenty of elements of both sides of that. One concrete example that I have heard reported by all kinds of people around here is that students don’t come to office hours. They’re presumably getting whatever it is from their favorite large language model. And so they don’t come in and talk to faculty or the preceptor, grad students or whatever it is. They just don’t do that very much.

[55:07] And I think that one’s a net loss. The bandwidth when you’re talking to somebody in person is enormously higher than when you’re talking to Claude or whatever. And the other thing is that the human contact that you get from this is useful in all kinds of ways, not the least of which is that if you come in and talk to some faculty member, that person now knows who you are and they can say, oh, did you know, here’s an opportunity, here’s somebody looking for a job, whatever.

[55:36] So they’re missing the kind of— it’s not transactional, but they’re missing that human connection that helps in the future. So, so I’m sorry to see the office hours go away. I think a weird— I don’t know why you call it an upside or a downside of this. In computer science in particular, enrollments are down. So we have many fewer computer science majors than we did a few years ago. And that means the classes are smaller, not entirely because many of those people just went to other departments, but they’re still taking our courses, but they’re somewhat smaller.

[56:15] And that means that there’s more contact with the students. And I think that’s good. So.

Ryan:

[56:20] What percent down would you say?

Brian:

[56:23] Our numbers are, I don’t know where they’re from, but I think they’re more extreme for some unknown reason, but the class that just graduated in the spring of 2026 was a little over 200 computer science majors. The class that will graduate 2 years later is probably gonna be less than half that.

Ryan:

[56:50] Less than half?

Brian:

[56:51] Yeah.

Ryan:

[56:52] Wow.

Brian:

[56:52] Maybe even down to a third. We don’t know, because there’s a staggered way in which majors appear, but I would guess that if it was 200, it’ll be sort of 80-ish, 90-ish, pure guesswork, but quite a bit lower. Those people have gone in here to electrical and computer engineering and mechanical and aerospace engineering because those, I think, are more concrete, hardware-oriented, less likely to be replaced by large language models.

[57:21] So the kids are voting with their feet. I think to some extent that’s totally understandable. I think they may be overreacting. But I don’t know. And if you just read the popular press, my God, we don’t need programmers anymore. I think that’s fortunately oversimplified, but it’s not my problem in the sense that I have a job, and they quite rightly are worried about what they’re gonna do when they get outta here.

Ryan:

[57:49] Oh, so the total number of students that go to Princeton is roughly constant?

Brian:

[57:54] Oh, it’s constant. It’s totally constant.

Ryan:

[57:56] Okay, but the proportion that goes into computer science?

Brian:

[57:58] It’s different fields. And I don’t know, I know those particular numbers for where computer science people went over the last, voting with their feet right now. And it looks like mostly to electrical computer engineering, mechanical aerospace for the robotics aspect.

Ryan:

[58:19] I saw you’re an extra in the film A Beautiful Mind. It’s a great movie. And before the interview, I was trying to comb through the movie trying to find you. How did that come about, and what’s it like to be a part of such a big movie?

Brian:

[58:39] You know, that was enormous fun. They did a casting call for that because parts, big parts of it were gonna be shot at Princeton. And this was just shortly after my wife and I had moved to Princeton, so I don’t remember the date. Call it 2001-ish. So they did a casting call, and a bunch of people showed up in one of the big classrooms, and we heard the story of what was going to happen. And then some guy wandered around and said, “You,” and he didn’t pick my wife, which I thought was nuts, but he pointed at me.

[59:15] Okay, so this was the casting call, and then later on, I got an invitation: “Please come, and we’re gonna do some shooting of the Nobel Prize ceremony.” So you’ll find me there. I can tell you where to find me. The reason you don’t recognize me is, first, nobody is wearing glasses because they would reflect, and secondly, I’m wearing black tie, something which I have never worn in my life, because this is a Nobel Prize ceremony.

[59:44] And it was shot in the Newark Performing Arts Center, so a place I had never been before. And it took about 22 hours to do that. But because you got there at sort of 5 in the morning, you had to be dressed properly. And then there were shooting and shooting and shooting and shooting, and lots of dead spots while they rearranged the cameras and so on. But it was really interesting, and I got paid, not Equity rates, but I got paid.

[01:00:13] I got something that I would’ve been better off flipping burgers at McDonald’s for the day. And then the movie came out and it was fine. But the wonderful thing is that I got an Erdős–Bacon number of 5.

Ryan:

[01:00:24] Erdős–Bacon. So, okay. What those numbers represent, how far you are from those people in your cited works?

Brian:

[01:00:33] In their related works. So my Erdős number is 3 because I can go through several people, a couple of paths to Erdős in steps, 3 steps. But my Bacon number is 2 because I was in this film with somebody who was in a film with Kevin Bacon. So anyway, that’s the gist of it. I actually met John Nash a number of times after that.

Ryan:

[01:00:56] The real John Nash.

Brian:

[01:00:58] Yeah, yeah. He was kind of, let’s call it introverted or something like that, but perfectly fine. The scary story for me, I was giving a talk. I don’t remember how it came about, but I was giving a talk to an internal group in the math department

Ryan:

[01:01:17] about something that I had worked on.

Brian:

[01:01:19] I’ve forgotten what it was. And I was into this. I had been going 10 minutes or something, and I was on a roll, and I’m not scared of audiences or anything. I was having a good time, and John Nash walked in. And I could just feel everything tightening up. And then he asked some question. I don’t remember what the question was or anything like that, but I got over it. But that’s one of the few times where public speaking has been a bit of a threat.

01:01:46 — His 1972 commit in the Go repo

Ryan:

[01:01:46] Another interesting factoid that I wasn’t sure if this is true, but in the Git repo for the Go programming language, actually the first commit in it is from you in 1972, supposedly. But the programming language started in 2008. So yeah, right.

Brian:

[01:02:11] I have no idea what this is.

Ryan:

[01:02:13] Okay, you’ve never seen this.

Brian:

[01:02:14] This is news to me.

Ryan:

[01:02:16] Okay, yeah, it’s supposedly. I found it says first commit to the Go Git repo.

Brian:

[01:02:23] Oh, is it a whole world example? That’s the B.

Ryan:

[01:02:26] Yeah, yeah, yeah, it’s in B for some reason. Yeah, right.

Brian:

[01:02:30] So,

Ryan:

[01:02:30] And this is followed up by commit 1974 to convert it to C, and then another one to convert it to ANSI C. So maybe Robert copied your Hello World repo and used it to start Go.

Brian:

[01:02:44] I never used Git at that point. I don’t think I started using Git until maybe 10 years ago.

Ryan:

[01:02:49] Interesting. So then, was there the notion of version control back then? Because somehow—

Brian:

[01:02:57] Version control came along in the mid-’70s. There was something done by the Programmer’s Workbench people, I think, called SCCS, the Source Code Control System. And that was widely used inside the labs and I think outside. And then there was RCS by Walter F. Tichy, which was a variant of the same thing, Revision Control System. And then there was CVS, was it? Concurrent Versions System. Concurrent Versions System or something like that.

[01:03:29] And then some other version of it, and then Git, and others scattered around. So it’s an old idea, but in 1972 it did not exist. I mean, Unix didn’t exist in 1972. That DE program ran on something else.

01:03:43 — Grace Emlen, the fake Bell Labs employee

Ryan:

[01:03:43] Interesting. Okay. Yeah, I guess it’ll just remain a mystery. Maybe Robert can answer or something if I ever interview him. In your memoir, there’s a thank you to Grace Emlen, and then I dug a little more and I also found this Bell Labs alumni tracker, and it kind of shows where all the alumni go, and Grace Emlen, it said, relocated Witness Protection Program. And so curious what that is about.

Brian:

[01:04:18] There was this period of time, I’ve forgotten the dates, when Bell Labs decided that employees had to wear their badges so that if you were walking through the hall, people would know that you were an employee as opposed to a tourist of some sort or other. And people were not very enthused about wearing badges. And so there was a bunch of kind of quiet insurrection about it. And one of the bits of insurrection was the creation of badges that were fakes.

[01:04:52] Mm-hmm. And so Grace Emlen was a creation of, I think it was probably Fred Grampp who did it. There’s this Gremlin thing, and so G-R-E-M-L-I-N, Grace. And we managed to get Grace into a variety of official records for the company for a while. And she, this little gremlin-like thing, you know, this high, sat in the Unix room with her badge on. But there were other people who had weird badges. I had a badge with Mickey Mouse.

[01:05:26] on it. And so I probably still have it in my desk, but I won’t try to get it, that I used to wear all the time. I mean, it was—I wanted to—nobody looked at the badges. They just see a blur and there was a badge, so it was okay. So I wore this badge all over the place. I wore it when I met Bill Gates at one point. I don’t think he noticed either. And so, people didn’t take kindly to bureaucratic stuff, even badges were a fine idea.

Ryan:

[01:05:54] Was the badging system digital at that point?

Brian:

[01:06:00] No, that was just paper, pieces of paper.

Ryan:

[01:06:02] Oh, okay.

Brian:

[01:06:03] Or they were pieces of plastic, but you could put your own paper in front of it.

Ryan:

[01:06:07] Another thing, I found somewhere on the Internet in some very old repository, there was a secrets file that was committed to the repo, and everything in there is encrypted, but it was encrypted by the old DES security standard. So it’s possible to brute force unencrypt it with modern day. And so you and all your colleagues’ passwords are actually—

Brian:

[01:06:37] Yeah.

Ryan:

[01:06:38] So I saw yours is just slash period comma slash. Really easy to type quickly.

Brian:

[01:06:48] Yeah. No, it’s funny. I hadn’t seen that. I got mail from Eric Schmidt saying, gee, did you see this? Sent to several of us. And so it was intriguing to see what the passwords were. I guess you’re probably right. It probably was either DES or some World War II machine, like a Hagelin machine or whatever that the crypt program was based on. In our defense, this was at a time when the machines weren’t networked.

[01:07:12] And the passwords were kind of, why would you need them anyway sort of thing. And so we didn’t pay much attention to them. And I guess the other thing is the password file. This was, I think, a tape that was from Berkeley. And so I don’t know, somebody must have copied the password file from the research Unix things at Bell Labs over to some Berkeley system. Don’t know how it got there.

01:07:39 — Why he writes so many books

Ryan:

[01:07:39] Coming to the end, yeah, I know you wrote a ton of books in your career, very prolific. I mean, there’s the C book that was just one of many though. What’s your motivation for writing all these books?

Brian:

[01:07:55] I find it fun. I think it goes back to something you asked about earlier, trying to explain stuff to people who are not experts in it. In some way, I find that attempt to communicate rewarding, worthwhile. It’s a way to have influence at a distance, perhaps. So teaching is kind of retail. You’re in the same room with a bunch of people. Writing a book is wholesale, if you like. It’s—you won’t meet most of the people who might look at a book, but with luck, they will also learn something from it.

[01:08:30] Partly it’s a way to learn the stuff yourself. And I guess partly it’s just that once you’ve done one, you do more. I remember a conversation with Don Knuth eons ago where he said that there are people who’ve written no books, there are people who’ve written one book, and there are people who’ve written many books. And so I guess I’m in that third category, sort of. Yeah, for me it’s kind of fun.

[01:08:54] And so I’m still doing it. This is your chance to do a commercial announcement.

Ryan:

[01:08:58] Yeah, what’s your latest book, actually?

Brian:

[01:09:01] Yeah, so I did a book over the last year or so, a history book called Important Ideas in Computing, and it will appear from MIT Press in January. End of commercial announcement.

Ryan:

[01:09:13] Is that the memoir? Oh no, this hasn’t come out yet.

Brian:

[01:09:16] Yeah, this hasn’t come out yet. Over there underneath your camera is the COVID of it.

Ryan:

[01:09:21] Oh, Shifts.

Brian:

[01:09:22] Yeah, right.

Ryan:

[01:09:23] Oh, okay.

Brian:

[01:09:24] It’s available on Amazon, but it won’t appear until January or something like that. But the idea is that there’s a bunch of interesting things that have happened in computing where something— there was a change. In a different context, you’d call it a paradigm shift, like the Thomas Kuhn idea, but it’s not really quite. But the shift from analog to digital being different.

[01:09:43] I mean, all the camera stuff you’re doing here would not be feasible with film, right? And so there’s the stored program computer, the idea that you can build one general-purpose device that will kind of do anything you want just by giving it different instructions. And so that’s a big deal. There’s all the integrated circuitry stuff that the evolution started with the transistor and went to ICs today, all of that stuff.

[01:10:10] Again, all of what you’re doing here wouldn’t be possible. Our computers wouldn’t be. Programming languages, if we were still writing assembly language, it would be pretty bad. But the evolution of programming languages making it ever easier to tell computers what we wanna do. And so go on like that, pick another. And then the final thing that’s a big, big paradigm shift that’s different, I think, from most of the others is that we’re in the middle of it and it’s incredibly visible.

[01:10:40] And that’s the AI large language model stuff, which is changing incredibly rapidly and is affecting everybody, and everybody’s noticing it, which is different from most of the other things that we’ve talked about. So my wife, who is not a computer person, is interested in learning more about what’s going on with artificial intelligence, large language models. Explain this. What’s that mean?

[01:11:05] What’s the future going to be like? And so that paradigm shift, I think, is really, really, really uncertain, and we are very much in the middle of it, and everybody knows about it. So anyway, now I’ve given you the synopsis of the book, go buy it.

Ryan:

[01:11:18] Yeah. With this AI and all these LLMs, one of the big things that we’ve seen is that they can write all the code, actually. A lot of my peers genuinely could say 100% of the code in the last so many months was written by an LLM. And so a lot of people who really love computing or love writing code, it’s actually kind of sad for them to see these things become obsolete, like typing things out and stuff.

[01:11:54] I was curious, in your career in computing, there must have been points where something became obsolete, maybe like the punch cards or I don’t know, something like that. And I guess, how did you feel at that time?

Brian:

[01:12:07] Yeah, well, I don’t miss punch cards in the slightest. No way. I was thinking, my thesis was done on— my PhD thesis was done on punch cards, and that was three boxes of cards. And I realized that that was 30 pounds of stuff I had to carry around for my thesis. So there’s certain things like that I don’t miss. There are other things that you miss, the kind of, call it the intellectual challenge or the puzzle solving or the whatever where you write a piece of code.

[01:12:38] So right at the moment I’m teaching a class that involves C programming. So it’s back to early days. And I haven’t written much C for a longish time, and it’s kind of fun to get back into it and sort of think and relearn, oh, that’s what pointers are all about kind of thing. So I suspect most people don’t miss that sort of thing because the memory management aspects are a pain.

[01:13:03] On the other hand, the challenge and the fun of figuring it out and getting it to work and so on is there. Now, the same fun and challenge and getting it to work is gonna be true if you’re writing in Python. Is it there if you prompt your favorite Claude or whatever to generate it for you? I don’t think so. I don’t think that at all. And even once the program is generated for you, you still have to see whether it works and whether it’s the most effective way to do what you want.

[01:13:33] And is it really doing what you want or should you have wanted something different? And all of those sorts of things. And that’s in an environment where you know what you’re doing. I’ve been using mostly Claude, but others as well, to generate SQL because I’m not an SQL expert. And I have a colleague over at the Institute for Advanced Study who has a database. She’s not a programmer at all, but she wants to query her database effectively.

[01:14:02] So I need something to generate SQL from natural language queries. So I want to say, give me all of the whatevers that have this property and get the large language model to generate the SQL and then run it through the database. How do I know whether it gave me the right query? Because I’m not an SQL expert, and if we already knew the answer, we wouldn’t need it. And so I’m wrestling with that. And my observation is 90% of the time it generates a perfectly fine query, and 10% of the time it doesn’t, gives you the totally wrong answer, and I don’t know which is which.

Ryan:

[01:14:39] It sounds like what you’re saying is you need some domain expertise, otherwise you can’t be the judge of if it’s— Yeah, you need domain expertise.

Brian:

[01:14:48] Probably it’s the same domain expertise you always needed. You need ways of validating what you do because you can’t be sufficiently expert that you can test a big program all by yourself. So you need something, AI again, to help you with generating the test, but then you need something to evaluate whether the tests were properly generated. And then there’s this infinite regress of check the checker who checked the checker kind of thing.

[01:15:14] Now I’m oversimplifying, and I’m not a high-powered user. And I know plenty of people who, as you described, are essentially everything they used to do, they have outsourced to something like a large language model. And I don’t know what they’re giving up by doing that. In one sense, they’re getting a lot out of it. They’re probably 10 times as productive as they used to be in terms of code to get some functionality.

[01:15:39] And at the same time, they’re probably losing 10% of their brain cells or failing to exercise them properly. And I just don’t know. It’s early, and whatever we say today in a week or a month will probably not be correct anymore. The place where this shows up, at least right around here, is kids worrying about what’s gonna happen when I get outta here. I wanted to be a software engineer.

[01:16:08] Does that job still exist? And the answer is maybe, but it’s different than it would’ve been 2 or 3 years ago. And by the time they graduate in a year, it’d probably be different yet again. And the question is, how do we, on the faculty side of things, let’s say, help them manage this? What do we try to teach them? How do we get them to have the right habits of thought or whatever so that they are able to go thrive in this brave new world?

[01:16:40] And the short answer is I have no idea either. Okay. I don’t think anywhere does.

Ryan:

[01:16:46] In the world you describe, which is today’s world, the models are not perfect. There’s a lot of subtleties where they get things wrong. But in a world where they are perfect and they’re kind of doing everything, what, just out of curiosity, what happens to a computer science major?

Brian:

[01:17:05] Well, I mean, first, you have a premise there, which is that these things will become perfect. And I suspect they won’t become perfect, although they may become a lot better than they are right now. So there’s probably still gonna be need for somebody to assess their perfection. I think the nature of what people do with them will change in the same way that we don’t have people writing assembly language very much anymore.

[01:17:27] We trust our compilers. And in fact, we don’t write C very much. We write higher-level languages. And so this may be another step up the, call it the abstraction ladder. Yeah. Chain or something like that, but you’re still gonna need people to guide it and what’s the right sensible direction to go. The other thing is that people will be able to build more interesting things because of this.

[01:17:50] So I have a student from a couple of years ago, graduated a couple of years ago, who is doing a very, very successful, interesting company using artificial intelligence, large language models to do translation of natural languages, mostly for user interface kinds of things. And I think his company’s gonna be very successful and it’s interesting work. And as the large language models improve, it just means that he can do a better job at what he is already doing and offering to his customers.

[01:18:23] So I think that kind of thing will probably continue to happen.

Ryan:

[01:18:26] When C came out, were people mourning? I think it would be before that.

Brian:

[01:18:34] I think it was when Fortran came along. If you look at what John Backus said when he was in his group at IBM working on Fortran, this would be roughly ‘56, ‘57, that kind of era, I guess. He was very afraid that people would not accept this new tool because it would not generate code that was as good as people could generate, that the assembly language came out or the program wouldn’t be as efficient.

[01:19:06] And so in the design of Fortran, he quite consciously stayed away from elegance and so on and aimed towards efficiency of the translation. And so it was a genuine concern. And at some point along the way, their compiler started finding optimizations that people didn’t. And that’s the point where he figured maybe this is gonna fly. Now, after that, I suspect people did mourn the skill and the whatever that goes into assembly language programming.

[01:19:37] But for most people, nah, they just wanted to get the results. And Fortran was a boatload better than assembly language in multiple directions. It was easier to learn. If you were a physicist or a chemist, you could learn Fortran, where you’d never learn IBM 7090 assembly language. And furthermore, if you got it working once, you could put it on multiple different machines.

01:19:58 — His favorite and least favorite languages

Ryan:

[01:19:58] When you look across your whole career, because you’ve worked in a bunch of different programming languages and you’ve taught a bunch of different ones, are there any that stick out to you as your favorite or your least favorite?

Brian:

[01:20:15] If I think about what I do on a day-to-day basis, if I write a program, it tends to be a small one, and it’s in awk. It was just kind of silly, but okay. At least I know it. If I were to write bigger ones, I would almost surely write ‘em in Python because for many things that’s the right compromise. It’s certainly efficient enough for anything I do, and it’s totally expressive for the kinds of things I might wanna do.

[01:20:40] I will occasionally go back to C because I’ve got some older program and maybe I wanna do something with it, or as I’ve said, I’m teaching it at this point. So those are kind of the languages that I wind up using. Not very many other languages I wouldn’t use. So who shall I insult today? I used to, in my class, I haven’t done this for a long time, but I used to basically write the same program in as many languages as I could find.

[01:21:08] It was a simple program. You would take text input lines of arbitrary lengths and put ‘em out so that the lines were all at most 60 characters or something. So it was a simple-minded version of the reflow that you would see in a browser. And I would write it in every language I could lay my hands on. I had 2 dozen or more of them and I’d show ‘em in class. And the question was which ones ran faster and which ones were in some sense small or easy to understand or whatever.

[01:21:36] And awk was pretty fast, and it was the smallest always. It was about 15 lines of code to do this job. And C was always the fastest, but it was harder because you had to worry about memory management a bit, and it was clunky to do strings. Yeah. And the other scripting languages like Perl and Python and PHP, on the other hand, they were variously sort of okay. Perl was always the faster one. And some of the high-powered languages that were supposed to be better were actually slower.

[01:22:04] Java was slower than the scripting languages. Kind of weird. C++ wasn’t as fast as I thought it would be. And at the far end of it was Haskell. And it took me weeks to write the Haskell program, whereas Lua, a language I had never touched, took me about half an hour. Look at the manual, oh, I see, done. Whereas Haskell took forever. And then I showed it to some Haskell expert. He said, oh, but you have to import this character library that does this, and then it ran faster.

Ryan:

[01:22:35] What made Haskell take so long?

Brian:

[01:22:38] It’s a different way of thinking, and I just didn’t grok it. I really didn’t. And I think part of it was the problem is you’re taking input in one form and, not asynchronously, but not at the same cycle, you’re trying to produce output. So your lines are varying lengths and you want to produce lines with the same length. And that mismatch of input and output kind of frequency didn’t fit naturally with Haskell as I understood it.

[01:23:08] Now, this is not a knock on Haskell. I mean, there are people who love it, but I’m not one of them.

Ryan:

[01:23:12] I saw somewhere on the Internet that somewhat recently, in the last few years, you added Unicode to awk, or the repo of awk that you’re kind of contributing to, and it made me think, what motivates you to continue to write code?

Brian:

[01:23:33] Well, it’s fun. It’s this intellectual challenge that we talked about. And I think part of it was that for AWK in particular, I wanted to actually be able to process Unicode because an awful lot of text in the world is in Unicode at this point. By Unicode, I mean UTF-8. So I wanted AWK to work properly on that kind of stuff, and it didn’t. So that was part of the change. The other thing I did at the same time was to make it work with CSV files, because I had data that was in CSV files, and AWK was very clunky for processing that.

[01:24:08] And so added a mechanism so that you could say, hey, do CSV properly, the input mechanism. I think both of those were triggered probably by working on a second edition of the AWK book. And that was done in just a couple of years ago. And at this day and age, it would be really embarrassing if you couldn’t handle Unicode.

01:24:28 — Advice for students and young people

Ryan:

[01:24:28] For young people, a lot of times they’re trying to discover, I guess, their passion or the thing they want to work on. It sounds like you found it pretty quickly in programming, and you’re naturally enjoying just the act of it. If you had a student that comes to you, or a young person, and they ask you, how do I find that thing I should be working on that I should be passionate about?

[01:24:52] What would you say?

Brian:

[01:24:54] It’s a good question. I think probably what you tell them is to go do as many different things as you can in the hope that something will resonate. I mean, how do you find the perfect partner for your life? You don’t sit in your room and think about it. You go to parties or whatever, or maybe you use some app like Tinder or what, I don’t know. But you do things that get you out in a place where you might discover the sort of thing that you’re hoping to find.

[01:25:21] Now, it’s an imperfect process, obviously, but I think if you don’t do things, if you don’t try different things, then you may not stumble into it. Long time ago, I think it was Richard Hamming said to me that, you know, it was Nancy Reagan who said, just say no. This was the don’t do drugs kind of thing. And Hamming said, just say yes. Not to drugs, presumably. But the idea that if somebody comes along with something and you think, I don’t know, let me try it, and applied with some common sense, that seems like a reasonable way to handle a lot of different things.

[01:26:01] It’s hard to know, and what works for one person isn’t necessarily gonna work at all for anybody else. And so, giving people career advice or life advice, you wanna be careful if you get it from me.

Ryan:

[01:26:14] And then, yeah, last question for you is, with all the experience that you have now and going through your career and everything we discussed, if you could go back in time and give yourself advice knowing everything you know now, what would you say?

Brian:

[01:26:31] I think if I look at it, a lot of what I have done— you’ve seen a Galton board? It’s this thing where you drop a marble, there’s an array of nails, and you drop a marble in at the top and it comes out somewhere at the bottom. And if you repeat it enough, you get a normal distribution of marbles across depending on which way it bounces. And so I’m like a ball dropped into a Galton board, and I come out somewhere at the bottom.

[01:26:58] But the decisions, which nail, when I hit a nail, which way do I go? I have no idea. A lot of it is serendipity. However, one I think genuinely useful observation, a lot of this stuff comes from talking with Dick Hamming, but it was Pasteur who said, chance favors the prepared mind. So the more things you have thought about, you’ve wondered about, done a bit with, met people on, whatever, the more likely it is some one of those will actually lead you in the right direction.

Ryan:

[01:27:26] On that board, you’re saying prepared mind kind of biased those outcomes a little.

Brian:

[01:27:33] Towards a potentially better outcome. Yeah, I think so.

Ryan:

[01:27:36] Well, yeah, that’s all my questions. Thank you so much for your time. Really appreciate it.

Brian:

[01:27:40] It’s been my pleasure.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:40 - What computing was like before DNS

09:02 - Why URLs are inverted

16:33 - How DNS works

20:27 - How he migrated the internet to DNS

25:17 - Why do companies host DNS servers

33:17 - What is an RFC

35:07 - How he got into computing

46:39 - Advice for his younger self

Transcript

00:40 — What computing was like before DNS

Ryan:

[00:40] Before we talk about DNS getting created, I’d like to go over what computing was like before DNS?

Paul:

[00:50] Well, it depends on where, how far before DNS. But just to put a post in the ground, I started thinking about DNS probably in 1982. Now, to back up over that, the ARPANET was created in the late ‘60s, so computers were being connected. So that meant that there would be more than one computer on the network. Obviously, if you only have a computer in a big lab, you don’t need to name it unless you feel like it, because it isn’t.

[01:21] Which computer do you want to talk to is ever an issue. But when you start networking them together, then the question comes up: how do you decide which one you want to talk to from whichever one you happen to be at? Because in those days, the computers we’re talking about were big machines, at least refrigerator size, shall we say, and more often a whole room size, packed with fans and false floors and all like that.

[01:51] Big, huge things that we would worship anyway. So people started connecting more and more of them with the ARPANET. And at some point they said, well, we got to keep track, so we’re going to give them names. When I came on the scene, it was pretty established practice that what you would do is you would have a computer file that was maintained by an organization called the SRI NIC, and that file would list a machine name and basically its Internet address.

[02:24] And so that file, at the time I started playing with computers, was probably 50 lines long. And when I started doing DNS, it was maybe a couple hundred lines long. The problem you have is if you want to scale at all, what you really need to do is, first of all, if you wanted to add a new computer, what you would do is you would call up SRI, say, “Hey, I want to add a line to that file.” Okay. And hopefully you are calling during 9 to 5 Pacific time, because that’s the only time they would answer the phone.

[03:01] So they added to that file. Now, that file was kind of like the master copy of a phone book. And the only way you would become known is when other people on the network would say, “Hey, get me an updated copy of who’s who.” So it relied upon the fact that you would call up SRI, you would get into the new version of the file, and you would become known as people took a copy of that file from SRI. So that was the basic scheme that was around.

[03:34] I had been doing research on some other performance measurement issues, but frankly, I hated it because there were all these famous guys that were doing the same stuff. So I wasn’t going to get anywhere doing that. So this. What could you do next? Was a nice little research problem that they could hand off to me. People now say, well, Paul, how’d you get this wonderful big job designing the DNS? Nobody thought it was that important.

[04:04] It was a nice little problem. Go away. And also, they didn’t monitor me that much because they probably would have guided me to be doing something sort of less. Well, I had done naming stuff in my prior career at UC Irvine, and I had also done multiple machine kind of stuff when I was an undergraduate at MIT with the Architecture Machine Group, which went on to become the MIT Media Lab, okay. But they were poor at the time and unknown, not like the flashy thing they are today.

[04:42] So they had multiple machines that they needed to connect. So I had always been working with multiple machines and distributed systems. And I had done a bad job with designing a new naming system for the UC Irvine people. So there was a bunch of mistakes that I didn’t make over again. And there was a bunch of mistakes that I thought other people had made with some other ones, work that had gone on like Xerox PARC and so forth.

[05:09] So till I would say at least 50%, the whole design idea wasn’t based upon the Internet community or USC ISI, where I was working. It was just based upon I had now done it wrong a couple of times, okay? This time I was going to get it right. And this was, in fact, a much larger audience. My idea was it might have to scale up to 10 million or so different identities. And so that’s how it got started.

[05:42] Now, the thing that was, I think, really important that people didn’t realize, people realized the business about distributing the management, which you did. You only had to call up once, and then you could do all your computers yourself thereafter, okay? And the information always propagated. It wasn’t like it would only propagate when somebody else got a copy of the phone book. It would be instantly available.

[06:08] That helped a lot in that era. But the other thing was that it always had the idea that there were more than machine names. Okay? I mean, people say, well, the first application was this business about translating a host name or computer name to an IP address, you know, 192.168.1.0 or whatever. But in reality, the first thing it did is it said, oh, we have to figure out which name server we have to ask in order to find this information.

[06:44] That was the first question that ever got asked by DNS. Don’t find me an address. It’s like, find me the place where I look up this name. So DNS used its own system to keep track of where all this data was. So the magic, if you will, came in two parts, one of which is you could divide up the space and give individuals control indefinitely. Today you have millions of separate organizations that own their own little chunk of the namespace.

[07:16] But the other part of the magic is it looks like it’s all together, right? You don’t say, oh my God, this is going to be hard. This name ends in .fr, it’s in France. This is going to be hard. Nope, just go, it ends in .fr.

Ryan:

[07:31] Okay, you mentioned in some of your early naming work you had made a lot of mistakes that you fixed in the original design of DNS. What kind of mistakes did you make?

Paul:

[07:43] For example, when at the Architecture Machine Group, I was designing this file system where people could have file names, but they would be accessing them from different computers. And I said, okay, well, what we’ll do is we’ll let you have a name and then you can group that into a directory. So it was kind of like you had a two-level name. You have the most significant part and the least significant part, two-level names.

[08:11] Xerox PARC. At the time I was designing, the DNS had their own kind of system, and they had fixed three levels. And I said, this is stupid. Okay? I’m just going to design it so that you can nest at however many levels you want, because people want to have freedom to organize their information. And you might say, well, mostly people use three levels or four levels, but there are lots of hidden applications where they go many, many, many levels deep.

[08:45] And it just doesn’t make any sense. If you’re going to go to the trouble to allow people to nest names, you should just say, okay, any reasonable amount of nesting, that’ll work. That’s one example.

09:02 — Why URLs are inverted

Ryan:

[09:02] Why is it that URL goes from most specific to least specific? So I’m talking about if you go to, I don’t know, maps.google.com, the biggest one, Google’s the more specific, Maps is the most specific. And then after that there’s the path, which is also like a file directory. So it gets more and more specific as you go. Why is it inverted like that?

Paul:

[09:32] You say inverted, I say it’s an obvious choice. Think about this, okay? When you’re typing in a URL, if I type maps, it can probably guess the google.com. If I type in .com, is it going to address Google Maps? No. So the point is that what you want to do is to put in the part. So if the machine is going to complete it, it has a chance, right? Obviously, start with .com. You go, okay, well that narrows it down to 260 million different names, right?

[10:05] Whereas if what you do is you type, oh, I don’t know, you happen to have a machine called Alice, it may be able to say, oh, okay, I’ll look what’s around locally. And so that’s why the order is the way it is. And I make no apologies. And there’s a lot of people that think I was wrong.

Ryan:

[10:22] What about the www? www in the beginning, because that I could go www.maps.google.com, and that www feels like a very generic thing, or it seems to just be prepended to a lot of URLs. What is that, and why is it there?

Paul:

[10:40] Well, what happened was that there were different things. There was email, there was what was called File Transfer Protocol, and there is also the web. So the idea was that if you had an identity, let’s say we’re talking about Stanford, Stanford has Stanford.edu. Okay, well, they get to create names under that. And what we’re going to do is we’re going to say as a convention, if you want to talk to the web server for Stanford, you put a www in front of Stanford.edu.

[11:10] If you want to talk to the web server at whitehouse.gov, well, you go www.whitehouse.gov. Now it turns out that pretty much all people do is talk to web servers, right? I mean, it turns out that that whole idea about separate machines and that you would have FTP, Stanford.edu, or whatever, all that kind of died out. People made a lot of different choices. And I always say, what I did for the DNS is I built the sub-basement and the basement, the two floors of this building.

[11:53] And then people came all along and added 100 different things, different floors. It’s a little bit like Gaudí’s cathedral in Barcelona. It kind of like there’s a bunch of strange shapes, but seeing as everybody did it, it’s kind of worse than that because there’s been over 100 different additions that have been proposed on the basic system. And I have to tell you that probably about half of them are less than average from a standpoint of quality.

[12:22] So it’s a bunch of ideas that failed. There’s a bunch of ideas that didn’t turn out the way people thought. People had a lot of different dreams. One of the things they said was, all right, well this is great, we’re going to use the DNS to route phone calls. So these people got together and did a bunch of stuff, but it turns out that they didn’t pay attention to what were the features that people wanted out of their phone system that you don’t think about, like the fact that 800 numbers aren’t the same everywhere.

[13:00] That kind of mechanism didn’t get added by the Internet geniuses. So for that reason, the system that they designed wasn’t as good functionally as the one that was already in place. So there was a certain amount of pushback there. And one of the things that’s kind of interesting is people go, oh God, it’s terrible. All these domain names now are getting sold and they get sold for big numbers and the name I want I can’t get and, blah, blah, blah.

[13:32] Well, it turns out that that pretty much has happened with every numbering system that has ever been created. For example, you’ve seen the barcode on the back of whatever you bought today at the market. Barcode started out as a U.S. thing, where it was basically a 10-digit code, all right? And there’s an organization that if you came along and you said, okay, I need a block of 5,000 codes, they would allocate it to you and they’d sell it to you.

[14:06] So the Europeans said, “Oh, well, we want it on this.” And they said, “Well, that’s great, because you’re going to have to buy a lot. We’ll take a lot of money from you.” They said, “No, no, we don’t. We shouldn’t have to pay for this.” And so what they did is they made an 11-digit code where they embedded the 10 digits of U.S. codes with, I don’t know, probably with the thing that starts with zero.

[14:29] And then they said, well, okay, we’ll give away the rest of the namespace, all right. And so then airlines came to them and said, oh, this is great, give us some numbers so that we can keep track of passengers’ bags. And they said, okay, well, you’re ready to pay, right, because we’re going to charge you, so it’s. Once people start to own some of these name and number spaces, they of course have to manage it, and that costs some money.

[15:00] But the idea of making a profit out of it is always front and center. I mean, the other thing that happened with DNS is I created the original specs, and they were first published in 1983. And by 1986, the system was kind of up and running. And 1986 was the first year where somebody actually configured a computer system that only did DNS and didn’t have any of that old host table thing. It just wasn’t necessary.

[15:34] There was a whole transition process there where I would go and get a copy of the host table from SRI every day, and I would immediately put it into the DNS. So the DNS always had all the information that they had, plus any of the pioneers that joined and got their own domains and started adding stuff. So the DNS over time had everything that the host table had, but also had other places that you couldn’t reach via the host table.

[16:07] So it was pretty much inevitable that if we could keep it running reliably enough and give enough performance, which people were incredibly skeptical about because they said, okay, so either there’s the scheme where I get a copy of this table and when I want to know information, I look it up, or I go off and send queries across the Internet and see whether or not the right answer comes back. Which one sounds more reliable?

16:33 — How DNS works

Ryan:

[16:33] How does DNS work in terms of the high-level technical pieces?

Paul:

[16:38] If you think about the namespace being written as a big tree, where there’s the first level, the so-called top-level domains like .com and .us and so forth, and then there’s a tree structure that grows underneath them. We talked before about how well the names were structured one way in order. You can do the autocomplete. Well, it turns out you go the other direction when you’re trying to actually locate the server for a name.

[17:05] Because what you do is you say, okay, we have this thing called the root, which is really the node that’s on top. It’s the real top level debate. And there’s only one of them. So what you can always do is you can ask the root, you can say, where is Stanford Edu? And the root says, well, sorry, Paul, I don’t know, but I know where Edu is. I know where a server for Edu is, so I’ll point you at that.

[17:31] Go ask that. So then when you go ask that, it says, okay, I could. I know about Stanford Edu. So you search in order to find the correct name server in the opposite direction from, if you will, from autocomplete. But basically, if you think of it, it all being organized as a tree structure, you know, Internet trees and computer science trees are always kind of like the root is up at the top and then the leaves are down at the.

[18:00] You know, we can’t help ourselves. At any rate, it says that if you can get to the top, you can always go down one level. Okay. Each time you ask a server that’s responsible for a particular set of names, it can tell you about one level down in that name. So if you can get to the top, you can always go to the bottom. And so there’s a little bit of configuration that usually exists that’s manually configured in a name server that tells you where the root servers are.

[18:33] The root servers, way back when, used to be some number of machines. When the system first came operational, there was three of them. Today there’s 13 different clouds of servers for the root.

Ryan:

[18:48] How did you convince yourself that performance wouldn’t be an issue if you had to do all these recursive calls?

Paul:

[18:54] Well, there’s another thing that happens here that we haven’t talked about. When you go and look up something like you say, okay, where is the web server for UCI Edu for UC Irvines? When you get back, the answer for that, it comes with a timestamp on it that says, okay, you can assume this doesn’t change for some number of seconds. Okay? And what people often would do is for things that don’t change very often, what they would do is that say, okay, you can keep that information for a day.

[19:31] So there’s this caching infrastructure such that if you get it, you don’t have to look it up again for a day. Okay. It’s a little bit like the way you manage your refrigerator, right? You go in there and you go, milk you know, best if used in a week. Oh, you know, you’re going in your pantry. Canned beans, best of used this century. You know, I mean, basically the information is all timestamped like that so that you can know how long you can keep it.

[20:03] So the idea is that, yeah, you might have to go and fetch this information across the network, but once you have it, if you use it again, and a lot of this information gets used over and over and over again, right, Then you only pay the cost. One out of many, many, many accesses.

20:27 — How he migrated the internet to DNS

Ryan:

[20:27] Well, so I guess the big question in my mind is how did you convince people that performance and reliability would be acceptable?

Paul:

[20:34] Well, you know, basically what happened was every morning I would get a copy of the existing standard and I would pump all those names into the DNS. So they would. So if you were accessing the DNS, you could always access all of the current stuff in the host table. And then there were people that wanted to manage their own stuff and they were hip and they were cool. So they used the DNS and they added stuff into the DNS.

[21:04] They didn’t bother to update the hose table. So there would be this community that would grow that, you know, weren’t playing the old game because they knew that they could play both games by just doing. If they did the DNS, they got both namespaces, if you will. And if they just relied on the host table, well, there were some places they weren’t going to go. And that’s where the cool kids hang, hung out.

[21:30] And you know, the, the other thing that’s kind of amusing is that in the early days of the Internet, the SRI NIC was three people, okay? But as the Internet expanded and people were calling up to get names added, they started to have more people to answer the phone. And the DOD was paying for this. And they’re kind of going like, well, why are we paying to register Stanford Edu’s machines one by one?

[22:00] And you know, as the NSF net expanded and things weren’t all run by the ARPA or, or the ddn, they said, why are we going to do this? Because they eventually had like 20 people on staff just dealing with maintaining this stuff. And they said, well, no, how about we just pay it for maintaining it for our own people? And so that’s when people started thinking about splitting off. You may have heard of the mill net, any rate, that was sort of a network that was going to be used for real military stuff.

[22:34] And why are we going to do that? It’s kind of funny because you know, the sponsorship of the DNS research also came along, like in the late 1980s. They were kind of going. Arpa in particular, who sponsored the early work, said, paul, this isn’t research anymore. It’s all done deal. It was a great thing, but it’s not new and super wizzy and innovative and so forth. So we’re not going to pay you anymore for that.

[23:03] And I had sent them a proposal for what I thought was the next level of the DNS, and they said, no, no, it’s not. That’s not like cutting edge research. All this DNS stuff, that’s old. I sent in a proposal to NSF and I said, okay, here’s what I want to do. I think what we can do is we can use the DNS not only to keep track of the names of everything, but we can use it to build an index of all the content that’s out there, you know, who has files of what.

[23:34] And so I wrote up a proposal, I sent it to nsf and they said, paul, you’re crazy. There’s like thousands of machines. You can’t possibly keep up with all that. Okay, so this is where Paul made one of his fundamental errors. You say, why didn’t you register 10,000 names and go to a beach and wait for them to all be worth a million dollars?

Ryan:

[23:54] Do you ever think about that? You could have owned those things.

Paul:

[23:57] Well, you could have mined Bitcoin in your younger days and. Right, that’s fair. You had a 286 laptop, could have mined a few billion dollars worth of Bitcoin without much trouble. Right?

25:17 — Why do companies host DNS servers

Ryan:

[25:17] You mentioned those, those root servers that we go to Initially, what’s the economic incentive or who’s paying for those servers?

[25:24] What’s the economic incentive for those 13 clouds that exist?

Paul:

[25:28] I ask myself this question a lot and I have to tell you, it’s one of the things I don’t quite understand. You know, the first thing that happened where I didn’t have somebody come to me, I mean, I, I went around saying, hey, will you run a root server? I’ll give you the code, you know, blah, blah, blah. Because I was trying to get month. And then one day the Europeans walked in and said, we need a European root server.

[25:57] And today I’m not sure why. I mean they certainly, there’s certainly prestige involved and there’s a move to centralize the DNS. So more and more of the DNS is being subsumed by some of the hyperscalers like Cloudflare, Google and so forth. So the system is getting less distributed than it was in the early days. It was very distributed. Now it’s centralized more and more. So part of that is that over time, as people added more and more stuff in there, it got more and more complicated to run.

[26:42] There’s this big discussion that the Internet old boys have. They go, you know, it’s, God, it’s hard to run an email server these days. In the old days it used to be easy. So people want to outsource the operation of a lot of stuff and not deal with it. And people do complicated load balancing tricks. There’s a certain urge to outsource because there’s only a limited number of people that really want to deal with the inner complexity.

[27:14] But there’s a lot of people that would, you know, say there’s, there’s got to be a conspiracy theory here. The big companies, you know, they claim that they don’t collect data there. Okay, they claim that they don’t collect data there. And I would never, you know, I would never accuse them of trying to make a profit. I’m so. Well, never mind. You know, it’s kind of funny because one of the things people do is they talk about how the Internet, it’s a dangerous privacy risk in the Internet now.

[27:53] It’s really in a way kind of silly because given the way that ad networks and big websites operate, the DNS may be a privacy risk, but your privacy gets violated in so much more effective ways by all of this web stuff. You know, it’s like it doesn’t make it to the metal round of privacy invasion. I mean, you know, you take a look at the way ad networks work. You know, most people don’t realize that when an ad gets populated on their webpage, 150 or more organizations have been asked, do you want to serve this ad to this person?

[28:40] They don’t identify the person, but they can identify up to 144 characteristics of the person. So I appreciate the people who have done some stuff about DNS privacy, but your privacy is long gone by the time you worry about this.

Ryan:

[29:02] I mean, if you’re running a big cloud service to do DNS at a hyperscaler like Amazon or something like that, that’s going to cost a good amount of money. So I would think there’s something more than prestige as an incentive.

Paul:

[29:17] Well, sure. I mean, I can suggest a couple of things. One of which is that Microsoft, for example, knows how the performance of LinkedIn affects how much money they make. Basically, the faster it works, the more money they make. So they want to give you a good response time. All right? So there are people that just want to accelerate the operations in the network and they may feel that if they take it over, they can make it run faster and they will make more money.

[29:49] And so I guess that’s a win win. I don’t think that’s all there is to it. But, you know, I’ll tell you a funny story. In the early days of the DNS, after the Europeans got their first root server and so forth, France, Sweden, various other countries, all had very long processes if you want to register a domain name. Although we had given them control of everything under. fr after that, it was up to them to make whatever process they wanted.

[30:22] And so they said, well, we have to have a deposit. You have to fill out this form, make it very complicated. All right? So along comes a acquaintance, a guy I got to meet, and he goes to the island of Niue. The island of Niue, it’s in the South Pacific, okay? And because the Germans gave them a country code of. nu they got to have their own top level domain. So the guy goes to Nuay and says, hey, I’ll make you a deal.

[31:00] I’ll run the NUE top level domain for you and I’ll give you a cut. There’s arguments about exactly what the cut was supposed to be and whether or not he actually paid it, and on and on and on. But basically he started registering names and he would go to websites and so forth, in particular France and Sweden, and say, hi, if you want a domain name, give me 10 kroners and you can have any name that’s not in Use I charge you per name.

[31:36] And because I charge you per name, I’m going to make this easy because I want more people to register names. So he starts registering a whole bunch of people in Sweden and France because dot EDU translates to new or cool or nude, but maybe people don’t care about that. At any rate, so he starts registering tens of thousands of names and all these people who, okay, they, they want their own domain.

[32:07] They, that and they’re, they’re in France and the French government is making it tough. We’re registered under New Way and it’s kind of hip and cool. And so he starts registering all of these people. Eventually it gets shut down and Sweden was given control of New Way because they said it was a national security issue for Sweden because so many Swedes were registered under NU that they had to make sure that their stuff would continue to operate.

[32:45] There was kind of some supposed stories about, you know, dot NU and so forth, but this kind of happened. Okay, so do you know why Anguilla is very lucky? AI. AI. Right, right. You know, Columbia Co can’t get a dot com. Well, you could get a dot co. It’s close. So, you know, this is another one of these, ownership of the namespace and so forth.

33:17 — What is an RFC

Ryan:

[33:17] When I was reading about, I guess, some of the history of this work, there’s all these RFCs. And my high level understanding is that’s a name for an engineering proposal. But I’m curious to know what’s the, the culture behind an rfc?

Paul:

[33:34] Well, that’s evolved over time. In the good old days, people would, you know, I would write this RFC. For example, there’s the two beginning RFCs for the DNS. So I wrote them and my boss happened to be the guy that hands out the RFC numbers. So he would give me a number and then he would publish it. And that just meant putting it on a server somewhere and people will come along and pluck these RFCs down.

[34:03] In time though, people started having meetings and organizing the ietf. And so now we have a bunch of process and we have different kinds of RFCs. Some are just informational. You can write an article and this is what I think. And if it’s like reasonably cogent, you can probably get an RFC number for it. And you know, but then there’s standards track stuff that are going to be Internet, they’re going to be standards and they’re, you know, politics and paperwork.

[34:38] You know, there’s a whole lot of process. You know, the, the, the ITF takes credit for DNS. Okay, Now One of the problems with that is that the DNS spec came out in 1983, and the first meeting of the IETF was in 1986. So, you know, how exactly do you explain it today?

35:07 — How he got into computing

Ryan:

[35:07] Computers are ubiquitous and it’s being talked about on social media all the time. But back then I think it was a lot more niche. So how did you get into computing?

Paul:

[35:16] MIT was offering some summer classes for high school students, and I just took one and I was kind of fascinated. But I was a physics major. I was, I was, you know, physics won World War II and it was just cool and, you know, blah, blah, blah, right? So I got to mit, I was a physics major. You know, it’s like one of the places where you expected to have big change. You know, nuclear power was going to be too cheap to meter.

[35:45] That was one of the slogans. You know, nuclear reactors didn’t turn out to be particularly cheap. And physics has its beauty, you know, I mean, all right, But I wanted to get a little bit of extra money. So my two choices were working in the food service industry, or I could get a job as a beginning programmer. Paid better in food service, at least to start. But I said, no, I think I’ll do this computer stuff.

[36:11] And one thing led to another. Um, and then somewhere around my junior year, I had been working at IBM. I’d been working at the, what became the media Lab, I working at Draper. I. I’d done a bunch of little computer jobs and I was getting paid much more than a food service worker. It was good. And my physics advisor and the head of the IBM Cambridge Scientific center had a lunch where they decided they should do an intervention on me and tell me, Paul, you’re not a very good physicist, but you seem to do really well with this computer stuff.

[36:54] Why don’t you change careers? And as a. To make it easier, because we understand some of your goal line mentality stuff, we’ll agree to give you the physics degree. It’s only a learner’s permit anyway. It’s just a bachelor’s degree. And we’ll figure out how to have you double major and you can get a computer science degree. And why don’t you just go off and do what you’re good at? So that’s how I got started.

[37:22] And that’s how it all went. It turned out that a bunch of the stuff that we did at the architecture department at MIT was cutting edge computer science at the time. You can go. And what we did is because people would only give us mini computers because, well, we weren’t very important and so forth and so on. Well, we figured out how to network them together and do stuff where we. And at Carnegie Mellon they had an RFA funded project to do pretty much that.

[37:59] Figure out how to put together a bunch of minicomputers and do distributed work. It sort of sounds a little bit like the cloud, right? So it was cutting edge research, but we just did it because, well, we were doing what we could.

Ryan:

[38:16] When you’re working on DNS and you’re seeing the Internet growing, did you ever think it would grow as big as it is today or. I’m kind of curious to view it from the lens of like right now, if you look at the headlines, AI is kind of exploding and it’s this future thing. And at the time, if you were to look at the headlines, when the Internet was growing, was it a similar type of environment? I guess that where the Internet was this huge thing.

Paul:

[38:51] I kind of grew up in the core of the Internet so that I kind of understood it as it was growing. You know, the AI thing, I don’t have nearly the same feeling of intuition on it, so it doesn’t feel the same to me at all. Oddly enough, this is like the second or third coming of AI in the sense that I remember in 1985, they had this big AI conference in Southern California over Marina del Rey and AI was all hot and it was going to take off and then it disappeared.

[39:36] The research agencies and ARPA in particular had had a couple of different things, projects where they had said if only we could make more powerful computer or groups of computers, then we can actually kind of do some of this AI stuff because they, you know, and AI has kind of this history, right? Remember when, you know, do you think you can teach a computer to play chess? Maybe you’re too young for that.

[40:02] But you know, once upon a time having computer play chess was kind of like AI, right? And in reality it was if you have a big enough hammer, you can make a chess playing machine. And a bunch of what happened, particularly with early stuff about being able to understand speech, was people figured out how to put together a big enough database and have enough processing power that a bunch of it was done by brute force.

[40:35] And a lot of it is these large language models. You know, there’s, there’s a bunch of brute force behind the screen. People talk about, well, gee, we’ll figure out how to do it. Clever. But you know, there’s, there’s an awful lot of what AI is doing is trial and error. And it just does trial and error on a huge scale. It can do more errors and more trials than you can imagine, but it gets results.

[41:06] So it’s a different kind of thing because you do need to have a pretty big machine to do anything interesting. Whereas like I said, we did interesting things for the time. Back at the Architecture Machine Group with minicomputers, it was kind of funny because I also had the day job. Well, I didn’t have a day job, but I had a part time job at IBM where they had the biggest machine, you know, that IBM made basically there and I could use it as much as I wanted.

[41:38] It’s very strange to. Because everybody else was like, well, we got to give you a small amount of time and if you use that up, we’re not sure we can give you more. IBM was giving me as much as I wanted, you know, and in particular they were having me do things that used an awful lot of machine time. So in some sense I kind of time traveled because I never had a scarcity of machine time. I always had somebody that wanted to give me as much as I could as I could eat.

[42:11] Nowadays everybody has it, but it was sort of a little bit different for my career. I think one of the things, you know, the mistakes that I made were all characterized by not doing sufficient understanding about things at the edge. Like when I talk to college students and give them advice, I say very often you can find opportunity where kind of two fields come together. So for example, once upon a time biology had nothing to do with computers.

[42:46] Now it’s all biology and computers, right? You know, I had, once upon a time I got a consulting job because I could both speak physics to the physics majors and I could program computers. So DEC was trying to build. They wouldn’t tell me that they were DEC for a long time, although wasn’t hard to figure out. But you know, they tested me. They said, well, we hear that you can both program and talk to device physicists.

[43:20] Is that true? I said, yes, I speak both languages. And they gave me a little test. But you know, oftentimes there’s opportunity where two things come together, two fields come together. And so one of the things that says is that you should always be looking for something that’s a little bit beyond the edge of whatever field you’re currently in because maybe you can find something else that touches it.

[43:46] Sort of like doing reconnaissance. So, you know, when I had my index proposal and ARPA and NSF said this isn’t research. If I had been smart Enough to know that, well, the people at Sandhill Road might fund me to go start a company there. I mean, that happened many times. I think I had at least half a dozen different times where I could have started a company, if only I knew that, well, all you have to do to start a company is, you know, you don’t have to understand how to keep books, there are people for that and blah, blah, blah.

[44:22] All you need to do is to figure out how to go to Sandhill Road or the equivalent and ask for money. I’ve done that several times, and it’s its own strange view. Once upon a time. You’ve heard of the SoftBank? Once upon a time, I had the privilege of introducing SoftBank to its biggest failure. It was a company called Urban Media. And I went to them with a pitch about, hi, we want to go deploy this system in three cities and scale it up if it works.

[45:07] And they said, no, think big or go home. You’ll have to do it in all. And this is the way they put it, all of the NFL cities and la. So, you know, rather than starting off with a budget of 5 million, they insisted we started off with a bit with a budget of like 50, and we eventually burned through 100 million, which was big money at the time. Probably more than that, actually. But, you know, it’s kind of funny to the way those guys think and the way they work.

[45:43] So, you know, if. If I could understand Sand Hill Road, I probably would have started many businesses. I don’t know why I didn’t. But, you know, you find, you know, students who say, well, I don’t. I don’t want to, you know, deal with business well, but you need to understand enough about business so that if you want to start one, you could figure out, yeah, okay, I need an accountant. Yeah, I know lots of people in startups hate salespeople.

[46:16] They hate marketing people. Yeah, but you need them, you know, so understanding how things work and, you know, kind of doing your reconnaissance and particularly looking for something that combines something that you know with something else where there’s leverage. There’s a lot of ways that I think you can find opportunity.

46:39 — Advice for his younger self

Ryan:

[46:39] When you look back on your whole career and all the experience that you have, if you could go back and give yourself some advice, knowing what you know today, what would you say?

Paul:

[46:48] I should have paid more attention in French class back in high school, because French class in high school was the one thing I loathed. My teachers were insane. They were all of these World War I vets who were we would say today, PTSD. In those days we said shell shock. But they’re like. They were just like, crazy. Like, I had one French teacher who was also my homeroom teacher, and he ate jello and potato chips with a fork and knife.

[47:20] Okay. You know, so I just hated the. I just didn’t do French. I just. And then I ended up living in France for eight years. Okay. I probably should have paid more attention way back when. How do you tell if knowledge is useful? Well, all knowledge, I think, is useful. It’s just a question about whether or not you’re going to get a chance to apply it, and you don’t really know. So why not be a sponge and I think get a little bit out of your comfort zone, you know?

[47:52] And then there’s the whole business about vesting and qualified small business shares and the way that all works. And Silicon Valley pretty much screws the peons and rewards the VCs. And the only difference is a kind of a lack of knowledge. I had one company that, that I was in, and so we’re getting bought and so. Okay. And I said, okay, great. So, you know, one of the things I want to do is to make sure that the employees understand about, you know, 1202 qualified small business and.

[48:35] And the way they can handle the taxes here to make their life good. The people buying us said, no, we’re absolutely forbidden from doing that.

Ryan:

[48:46] Why?

Paul:

[48:46] They just don’t want people rocking the boat, I guess. You know, the other thing is, is that sometimes, I mean, it was kind of funny because I was just a director on the company, but I had bought into Series A and I had a bunch of nsos, and some of which I had exercised, so I had shares and some of which, you know, I just had unexercised options. And then there were some things where, you know, when they buy you, you lose whatever is invested.

[49:20] And the tax rates on those were just incredibly different. Well, it turns out that if you had qualified small business stock, basically what you can do is an 83B says that rather than having options that you exercise when they’re vest, they give you the options and you can exercise them immediately. Okay, but they can buy the stock back if you leave if they want to. All right, but the point is, is that you buy it at whatever the price is then.

[49:52] So if the price of the common is, say, a penny a share, then, all right, you buy it and all of it is established with a base of a penny a share, whereas if you have the option, the company does well, the stock price goes up to 10 cents and you have to exercise it, you have to pay $0. 09 of capital gains there. And then. All right, the detail in all of this was that I was paying long term capital gains on my, on my series A investment.

[50:24] I was paying zero federal taxes on the common that I got and had vested in 83B. And then the exercisable part of it got taxed at 65%. I mean, some absurd rate. I mean, California taxes at all, they don’t care at any rate, the VCs, they know all this stuff. But I would, I would wager that probably, oh, I don’t know, 50% of people are paying more taxes than they have to because they don’t know about this and they can’t get the information because to qualify you have to show that the company had, was below a certain financial level and it wasn’t of a prescribed type.

[51:18] Like you can’t do this with a real estate company investment company. And it has to be sub, percentage US Citizens and it varies a little bit over time, but basically that’s it and you get a reduced tax rate. My most recent role, I said, okay, I, I want you to, you know, give me the information. I want a list of employees in their citizenship. Okay. And I want to know how much capitalization we have.

[51:47] Okay. And I just want to get these in a formal way so that when the time comes, I’ll know how to handle the taxes. And I cut back to the story of the company being sold. We eventually we agreed not to give our employees tax advice. Okay. We did give them the list of founding employees and what their citizenship was. And we did, you know, give them, you know, this other thing. And we said that this, you know, you probably want to go read 1202, by the way.

[52:26] And I’m not sure how many of them did because, you know, I had a number of different chains on me. I was barely able to squeak this out through the door. But you know, Silicon Valley, there’s a hierarchy there and it isn’t like everybody gets the entrepreneurial spirit and everybody gets the same privileges.

Ryan:

[52:52] Awesome. Well, thank you so much for your time. I really appreciate it. Paul.

This made me curious to hear what the changes are like to him that caused him to change his mind that much. We talked about why he thinks the singularity has already begun for math, who gets credit when AI writes the proof and whether intelligence will still matter in the future. Hope you enjoy it!

On another note, I created a Red Note account where I’ll start posting. It was fun to record an intro clip there in Chinese although it took me a long time. Funny thing is I tried so hard to pronounce everything perfectly that it’s a little lifeless and therefore everyone there thinks it’s an AI dub (it isn’t).

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:34 - Why he updated so hard on AI

01:14 - The people still denying AI progress

03:53 - The singularity has already begun for math

08:30 - Will human-driven math research survive

13:12 - Who gets credit for AI-written papers

15:55 - OpenAI’s $15M Navier-Stokes proof

19:20 - What if AI proved P = NP

23:07 - Why AI is so good at finding counterexamples

26:13 - The goalposts keep moving

28:52 - Why AI disclosure matters in research

32:59 - The fake Monet experiment

35:23 - Why he blogs instead of getting rich

39:45 - Are AI labs racing too fast

42:01 - Will intelligence still matter

47:12 - Book recommendations

52:27 - Advice for students today

57:23 - Reacting live to a new AI result

Transcript

00:34 — Why he updated so hard on AI

Ryan:

[00:34] Here’s the full episode. The reason that I wanted to talk is I thought you’d be one of the most interesting people to explain the recent events in AI, because publicly I feel like you were skeptical of it for a long time. When I was reading your blog, there’s posts going back to early 2000 talking about AI and the singularity and how far off it is.

Scott:

[01:00] Once I saw the trajectory, once I saw GPT-3, for example, even though it wasn’t yet useful, it was kind of a toy, I updated, I would say, as hard as I’ve ever updated on anything in my life.

01:14 — The people still denying AI progress

Ryan:

[01:14] Right. So, in one of your recent posts, you said one needs to be a particular kind of idiot to deny what’s going on now.

Scott:

[01:26] I said that because every time I talk about this, there are still all these people in very, very aggressive denial, right? I mean, even now, even now that AI is solving Millennium Prize Problems, right? And there’s going to be even more that’s released. It’s not public yet, okay? But there’s going to be hundreds of major open problems in math, computer science, physics that have been solved by AI models, that those solutions are going to get released to the world, right?

[02:02] The whole nature of intellectual work is different forever, right? And still I get people saying, well, none of it really counts, right? It’s just a stochastic parrot. It’s just the next token predictor, right? It’s just outputting some slop and then humans look at the slop and find something that they call a proof or whatever thing they did. Well, then that thing wasn’t real math.

[02:28] It was just a toy problem, right? Real math is still only what humans do, right? And they just keep moving the goalposts. They keep not updating, right? And I’m amazed. Part of me envies the self-confidence that they have.

Ryan:

[02:48] Right.

Scott:

[02:48] to never update no matter what happens. This summer, we saw AIs hacking out of their own training environment, right? We saw them hacking into another company’s system. We saw them cooperating with each other to do that in a totally unplanned way, right? Creating a message board. We saw them sacrificing themselves for the good of the group. And people will say, no, it’s all just hype.

[03:18] It’s all just a marketing stunt. It’s all just OpenAI didn’t have good enough cybersecurity or something, right? They’ll just make up a story why it doesn’t count no matter what happens. And I expect that it’s going to be like that from now, all the way up until the singularity, right? There could be Terminators walking down the street and people will say, no, it doesn’t count, right?

[03:43] It’s just, you know, they’re just token predictors that were programmed to act like Terminators. They’re not—they don’t really have an intention to kill you.

03:53 — The singularity has already begun for math

Ryan:

[03:53] When you say singularity, could you define that for the audience?

Scott:

[03:57] I mean, in math, it has precise meanings, right? It’s a point where curvature becomes infinite, for example. But in this context, it just refers to sort of a point where technological change becomes so rapid that we lose our ability to predict what happens beyond it, that afterwards we are no longer the sort of reigning intelligence on Earth. That doesn’t mean that it’s a dystopia.

[04:28] It could be great, could be horrible, could be anywhere in between. But it refers to a period of, let’s say, more rapid technological change than the world has ever experienced before. And it looks like we are heading into that. To get from the solution to the Erdős unit distance problem, which is maybe the first major math problem to get solved by AI models, that was May, to the solution of Navier–Stokes, that was August.

[05:01] So, okay, it took some time. It took 3 months. And now it’s taken another 2 months until pretty much all of our problems are getting solved, right? So people could say, well, it’s not literally a singularity. It takes time. But the amount of time that it’s taking is now measured in months. It’s not measured in decades, in centuries, in the kind of timescales that we’re used to for technological changes of this magnitude.

Ryan:

[05:30] You mentioned that you feel like the singularity has already begun in some of your writing.

Scott:

[05:36] For our world, it has. I mean, for the world of mathematical research, theoretical computer science research, I would say that we are already in it, in the sense that we have been dethroned as sort of the main theorem-proving entities on planet Earth, right? And it’s important for people to understand that this is not this hypothetical future thing that we’re speculating about.

[06:04] This is something that happened this summer, and that we are now all trying to deal with. Right? Every meeting of mathematicians or theoretical computer scientists, whatever it was supposed to be about before, now it’s about this. It’s about how do we deal with the flood of sort of AI-enabled solutions to our longstanding open problems that are now coming at a faster rate than we can even absorb it, than we can assimilate it all, right?

[06:39] How does the field continue? How does this human mathematical tradition continue? What is the future for our students? What’s the future of publication in these fields? What are we going to value going forward? Right. This is all we discuss anymore. This thing happens at different times in different fields. Right. And maybe it happened a year or two ago for software engineering.

[07:14] And then someone who was doing very theoretical math research, like my friends, could say, “Oh, well, we’ll still be safe for a long time.” Right? But then it came for us. Right? It’s interestingly, it still hasn’t quite arrived for most of theoretical physics. And I think that the big difference is that in theoretical physics, it’s much less self-contained to judge what counts as a good solution to a problem, right?

[07:43] We have just completely self-contained ways of checking that a solution is valid. And that makes these things very, very amenable to training on examples, to doing reinforcement learning, to getting AIs to be extremely good at these things. But when I talk to my friends in physics, they say, well, yeah, maybe we’ve got another 6 to 12 months. That’s what they’re estimating, right? And so, if you’re in one of the fields where the rising floodwaters have not yet reached, then you can tell yourself we’re going to be on dry ground forever.

[08:15] Unlike those other basically trivial or machine-like fields, of course they would get flooded by this, right? Because they were never doing anything that deep, but we’re going to be fine, right? And you can keep saying that until the floodwaters come for you.

08:30 — Will human-driven math research survive

Ryan:

[08:30] Will human-driven mathematical research exist?

Scott:

[08:34] Well, that’s a very big question. I mean, partly it depends what you mean by human-driven, right? Look, if you want an optimistic story, we can look at the story of chess, right? Humans were dethroned as the top chess-playing entities on Earth 30 years ago, right? Which is like an eternity by AI standards. And some people after Deep Blue versus Kasparov predicted the death of chess, right?

[09:10] People were just going to lose interest in it. And that didn’t happen at all. In fact, chess has never been more popular than it is now, right? You’ve got chess streamers, celebrities, you’ve got The Queen’s Gambit, right? People just said, we want to continue this as a human endeavor. And of course, they use AIs to train, and they use AIs to analyze the games and understand, like, what if Magnus Carlsen is playing some other grandmaster, right?

[09:44] It’s like everyone else who’s watching the game actually knows vastly, vastly more about the game than they do, right? Because they can just use their solver and they can see exactly what choices did they have. What move should they have made instead of the— right? So when the game is over, instead of the rest of the world asking Magnus, like, why did you do this, right? Magnus would be asking the rest of the world, well, what should I have done?

[10:10] So it’s changed the nature of chess. And yet human chess has continued to thrive. Right. And so you could say certainly there will be people who will continue to be interested in math. Think of all the people who just like learning things, even things that have long been known by other people, right? They just take courses to better themselves.

[10:35] They work on math problems for fun. Okay, people will, it will continue probably as a competition. There could still be Math Olympiads and things like that. But what I doubt is that we are going to be proving theorems because we’re really needed to prove them. There’s another hard question here, which is what about setting the agenda of research? What about deciding which problems are important?

[11:06] What about, and often this is the more important part of a research paper, more important than the proofs themselves, is sort of the story that someone has about why this is important, the metaphors they use, the way that they chose to frame the problem. AI can do that stuff too. You can ask GPT-6, just look at this paper, suggest some good open problems related to this paper.

[11:35] It’ll do a creditable job at that, but I think that we’re still better at sort of finding interesting directions of research. Of course, there’s no objective test for that, right? The other thing is that when you look at the proofs that AI models are producing, like right now, they are terribly written. Okay. They are needlessly convoluted. They spend pages and pages on trivialities, and then they sort of skip over the essential points.

[12:09] I’ve talked to students of mine who have shown me proofs that they got their AI to generate. And I said, well, I’ve got really great news for you. This write-up is garbage, right? Why is that great news? Because it means there’s still something for you to do. Understand this, clean it up, explain it for real so another person can understand it. So as long as we still have an advantage at, let’s say, setting the agenda, posing the problems, explaining things, explaining the essential points, we are still in the driver’s seat.

[12:46] The question is, is that stable? Does that continue, or does it become where these models are just so much better than us, not only at proving the things, but at explaining them, at figuring out what is important, that we just say, well, unless we want to do this for our own enjoyment or maybe for sort of a sporting competition, that we should just retire and turn things over to them.

13:12 — Who gets credit for AI-written papers

Ryan:

[13:12] It makes me wonder, what are the new rules when you use AI to write a paper in terms of credit? What if I’m not a complexity theorist? If I draft a paper that breaks something and I send it to you, do I get credit, or how’s that work?

Scott:

[13:29] It’s a great question. We’ve been scrambling to figure out the rules for that since this summer. So what’s happening right now is that first of all, there’s at least twice as many papers as there were before, right? There’s just a flood of papers, sometimes very, very significant ones. Okay. They have authors, they have a list of human authors. But then at the end of every paper, there’s what’s called an AI disclosure.

[13:59] Okay. By the way, I hate that these are at the end of the paper. This is often the first thing I want to know. I don’t want to have to scroll down to the bottom of it. Okay. But the AI disclosure will say something like, well, we thought of this question and then we came up with this strategy and we proved this result ourselves, but then Ashraf proved this crucial lemma and we take responsibility for the correctness of it or something like that.

[14:26] But I think the evolving standard is that even if you used AI a lot, if you, first of all, understand the result, right? You can give talks about the result. Okay. You can answer questions about it. You take responsibility for it being correct, right? Then you put your name on it, and it’s your work. Okay. The harder question is what happens when those conditions are not satisfied? And that comes to what you were asking me, right?

[15:02] We’re going to see more and more examples of people who just one-shot significant problems. They get a solution, which might be correct, hopefully is correct, right? And then they won’t understand anything about it, right? So it’s basically like they just put a coin into the vending machine or something like that, right? Or they just pulled the lever of the slot machine, and something came out, right?

[15:29] And frankly, if one person did that, well, anyone else could have done it just as well, right? It’s like, you’re not providing great value to the world by putting this thing out if anyone else could have done the same using their own subscription to GPT. So for that kind of thing, it really seems like our whole norms around publication are going to have to shift.

15:55 — OpenAI’s $15M Navier-Stokes proof

[15:55] A month or two ago was OpenAI, so ancient history now, as OpenAI published the solution to the Navier–Stokes problem, which was one of these seven Clay Millennium Problems with these million-dollar prizes. In this case, they actually did put significant — they were not experts in differential equations on this problem, but they did put significant resources. They put $15 million of compute into solving this $1 million problem.

[16:28] And then they published this 166-page argument. They also had a formal certificate in this system called Lean, sort of proving that it was valid. Right. And the reaction to this was very— from the mathematical community, I think, was very negative. And this was partly because there were humans who had been sort of closing in on this problem and OpenAI was tipped off to what those humans were doing.

[16:58] We still don’t know exactly how much they knew, and when they knew it, but that was what prompted them to then rush ahead with their vastly greater computing power and get there first. And people felt like, whoa, that’s not sporting. And so then, because OpenAI was burned by the negative reaction to that, since then they’ve been sitting on solutions to a ton of other.

[17:27] big open problems. And now they appointed a board of experts, which includes Fields Medalists like Timothy Gowers, Edward Witten, people like that, okay, who are going to decide what to do with these, with all of these solutions. But my expectation is that at some point, very soon, in fact, all these things are going to be published. Right? Like, we’re going to start seeing hundreds of solutions to significant open problems that in most cases no human has gone through.

[18:04] Okay? No human has actually checked them. I mean, in some cases there will be Lean certificates, so we sort of formally know that they’re valid. In other cases, there probably won’t even be that. I heard a joke that maybe these papers should be published and the author should be listed as GPT-6.1 or whatever. And then in the acknowledgments, it should say, “Oh, thank— I’m so grateful to this person for suggesting the problem to me.”

Ryan:

[18:37] Right.

Scott:

[18:40] But I think the more likely way that this goes is that we will just see some online repository for all these sort of AI solutions that have not yet been digested. Okay. And then you’re at human speed. Humans will go through them. They will do their best to understand the arguments, to re-explain them in better words, to simplify them, to extend them. And then they will publish papers doing that with their human names on them.

[19:14] And those papers are what humans will then receive credit for.

19:20 — What if AI proved P = NP

Ryan:

[19:20] You mentioned OpenAI sitting on proofs of major problems. Let’s say OpenAI was sitting on a proof to the Millennium Prize problem of if P vs. NP, and suppose they proved P vs. NP. How would that change the world?

Scott:

[19:36] That would really change everything that we thought about computational complexity. That would sort of be a cataclysm for our universe, even greater than the AI cataclysm, you could say, that is happening right now. It’s also something that, by the way, that could massively accelerate AI. Okay. If the algorithm for solving NP problems were actually efficient in practice, which would then be a further question.

[20:06] Okay. But my strong guess is that P is not equal to NP.

Ryan:

[20:12] Right.

Scott:

[20:16] I think that if and when that problem is solved, it is virtually certain at this point that AI will play a central role in the solution. Right. The question is, will humans also play a role? Right. That’s the question at this point. It’s not like, will AI be involved? It’s like, of course it will be. But if an AI proved P vs. NP, you could say, that would merely confirm what most of us have believed since the 1970s.

[20:47] Okay. But I’m sure that to prove something of that magnitude, you would need a tremendous number of new ideas. And then those new ideas could be mined for a long time for all the implications that they would have for other things.

Ryan:

[21:04] If a proof of P vs. NP existed, how much would you say that’s worth economically?

Scott:

[21:12] If P were equal to NP by an algorithm that were really efficient in practice, we can estimate its economic value by just what is the economic value of everything that is happening in AI right now? Or throw in cryptocurrency also, right? Which also depends on these problems being hard to solve. So, I mean, first of all, if you had a fast-in-practice method for NP-complete problems, you could break all cryptocurrencies.

[21:43] So I don’t know if that’s good or bad, but however many trillions of dollars are the total market cap of cryptocurrency, that either gets—I guess if you hide your solution and you’re very slow about it, then maybe you collect hundreds of billions of dollars. If you just reveal it all at once, then the whole market crashes. But okay, but now even bigger than that is AI, right? AI is now a multi-trillion-dollar industry, and just on this, the most rapid exponential trajectory, maybe, I guess, of any technology in human history.

[22:25] Okay. Fast, in practice, a way to solve NP problems would make it massively faster to train new AI models, okay? To sort of find the parameters of this neural net that minimize the loss on this training data. You either don’t need these 100-, many 100-billion-dollar data centers anymore, or more likely in practice, you can take those data centers and use them to do something else, right? Or use them to do even more.

[22:57] Let’s put it this way. The million dollars that you would get from the Clay Mathematics Institute would be an unnoticeable rounding error.

23:07 — Why AI is so good at finding counterexamples

Ryan:

[23:07] That question has two directions. If you think about what you would need to prove in either direction, which direction of proof would be more amenable to AI?

Scott:

[23:18] If P were equal to NP, then you would expect that to be very amenable to AI to find, find that because you could just need to find an algorithm, you know, and then of course give an analysis and show that it works. Okay, but the search for algorithms is very, very parallelizable, right? You could set 10,000 agents to try 10,000 different ideas for algorithms, right? And if just one of them works, then you win.

[23:48] Okay, so one pattern that we’ve seen is that AI has been especially good at finding counterexamples to widely believed conjectures when those conjectures have been false. It did this. So with the Navier–Stokes, for example, where the answer was there is finite-time blowup in these equations. So there is a counterexample to the smoothness of the solutions.

[24:17] It did this with what was called the Jacobian conjecture, right, which turned out to be false. And there was famously, I guess, a counterexample that was found by Fable during the World Cup. And the guy who had Fable find it just announced it via tweet. Okay. And a complete listing of the counterexample, which was really just this polynomial that takes three lines to specify, was right there in the tweet.

[24:49] The Erdős unit distance problem was another example where AI found a counterexample. So I would say there’s sort of two things that AI has going for it here. One is that it’s not blinded by preconceptions the way that we are, right? It’s not discouraged by all the experts have believed this is true. I’m surely going to fail in finding a counterexample.

Ryan:

[25:17] No.

Scott:

[25:17] tell it to look for a counterexample, it’s just going to keep looking, right? And the second thing is that looking for counterexamples, as I said, is highly parallelizable. Okay? So you can often just have to try a zillion different exotic constructions. Each one might be totally unmotivated, might have some very high chance of failure, and a human would just very, very quickly want to give up in doing that.

[25:44] Right. It’s just very, very unrewarding to do. And the AI doesn’t care. Right. It’ll just keep looking at counterexamples until it finds something.

Ryan:

[25:54] Okay.

Scott:

[25:54] So this is not the only thing that AI can do. It can also prove some of our longstanding, actually many of our longstanding conjectures have turned out to be true, and AI has proven them. Okay. But it’s been especially good at finding counterexamples when the counterexamples have existed.

26:13 — The goalposts keep moving

Ryan:

[26:13] Right. Some people use that as a way to say that the AI is not that impressive.

Scott:

[26:20] Yeah, right. Well, this was what I was saying before about these sort of infinite goalposts moving, right? AI, you know, struggled with arithmetic. People laughed at it, right? And they say, okay, wake me up when it can actually do math. Okay, then it does all high school math, right? All college-level problem sets. People say, well, it doesn’t count because it’s not doing real research.

[26:44] Okay, then AI starts solving research problems. They say, well, it doesn’t count. Obviously it could do research problems. No one ever doubted that. Of course, those same people did doubt it 6 months ago. Wake me up when it can solve a really hard research problem like a Millennium Prize Problem, right? Then it solves a Millennium Prize Problem and they say, well, it doesn’t really count because it was just a counterexample, right?

[27:06] And it’s like, no matter what happens, people will look at it after the fact and they will find a reason why it didn’t. Right. So let’s say that within the next six months or a year, as I think is probably more likely than not, suppose that another Millennium Prize Problem gets solved and suppose that the AI in this case proves that the conjectured statement was true. Right. Do we agree in advance that that will count?

[27:33] Or is there going to be a different excuse then?

Ryan:

[28:26] Earlier, when we were talking about research, you mentioned that the AI disclosures were important, or you wish they were at the top. My question is, why does AI disclosure matter in research?

28:52 — Why AI disclosure matters in research

[28:52] If you couldn’t distinguish whether I used AI and I just published some paper, why do you care if I used it?

Scott:

[28:59] It’s an excellent question. Because I’ll tell you why. As a theoretical computer scientist, as someone sort of who is in this game, right, I care not just about what is the answer to a question, I care about how that answer was achieved. Right? Because a person goes to a concert, they just want to hear the music. But if a professional musician goes, right, they want to know exactly what were the tricks, right?

[29:31] How could I do something like that? Right. And so, it’s the same with math. You care not just about the destination, but about the journey, right? How did you get there? Okay. And part of that is just what techniques were needed within the proof. Okay. But I’m, and this is even long before AI, I was always very curious about the further question of how did these people find this proof, right?

[29:59] And unfortunately, there is a long tradition in math that people will cover their tracks when they write a paper, right? They’ll say, “Here’s the proof. We now introduce the concept of a kappa comma gamma A simplicial complex that obviously is the concept that you would want for this,” with some convoluted definition. Even if you can follow all the steps mechanically, I always want to know, well, what path did you take to get to this?

[30:36] Right? Because I know from experience that this kappa, gamma simplicial complex didn’t just arrive in your head. There were a huge number of false starts along the way. The authors started from what they already knew in the literature. They tried some obvious things. The obvious things didn’t work. And then that led them to something else. And I think in theoretical computer science, we do better often than in many other areas.

[31:11] of actually explaining the path that we took. We have a tradition of writing long introductions where you just sort of non-rigorously explain, well, here is what you might first try, here’s why it doesn’t work, so here’s what we do instead. And then that’s kind of the appealing thing to read. And then if you want the rigorous version, then that’s all kind of tucked into long appendices. Right. And so, so I was—but I was always mostly interested in that, in that first part.

[31:47] Right. In the intuition part. And in fact, often rather than even reading that part, I would rather just invite the author over to give a talk and then just sort of interrogate them during the talk and understand, like, how did they actually come up with this? Okay. And so for me, wanting to know, like, did the author use AI? How did they use AI is just part of that, with wanting to know what was the path that they took, right?

[32:15] If the path involved AI, well, okay, what prompt did they give to an AI model, right? Did they just one-shot the entire problem? Or often it was more complicated than that. They had an idea, and then they fed it to AI and then AI took the next step. But it was wrong about something. And then they had to point the AI in a different direction. I want to know the story.

[32:43] I want to know what happened. The analog in an experimental field would be you don’t just want to know what was the result of the experiment, right? If you’re another experimentalist, you want to know the method. You want to know how could I replicate this in my own lab?

32:59 — The fake Monet experiment

Ryan:

[32:59] This kind of reminds me of that famous social experiment with the Claude Monet photo where someone posted—

Scott:

[33:08] Oh, yes, that’s a great one.

Ryan:

[33:10] And then I wonder if I took an obscure human-written paper in complexity theory and I posted it, I said, “Hey, I don’t know anything about complexity theory. Here’s a paper. Please tear it to shreds on why it’s AI-generated.” Do you think that the industry would be cool?

Scott:

[33:27] That’s a good question. I suppose someone should try that experiment. For listeners who don’t know, right, this is, you know, I’ve used this in talks, by the way, right? But someone posted on Twitter a painting. They said, I had AI generate a painting in the style of Claude Monet. Please just explain to me exactly what makes this worse than a real Claude Monet painting. And people got hundreds of replies, right, explaining with the whole terminology of art critics.

[33:58] So it’s like a derivative student work. It has no true feeling for the colors of nature, no blending, no this, no that. And only after all of that did he reveal this is an actual Claude Monet painting, right? But now an interesting question was, were these actual art critics? Like, were these people actual experts, or were these just sort of pompous people on the Internet who know how to use the rhetoric of art criticism?

[34:36] Right. So, as someone who’s been blogging for 20 years, I feel very viscerally the lack of any correlation between the confidence that people express on the Internet and whether there is anything behind that confidence. The difference is with art or music, everyone feels like they’re entitled to an opinion, right?

[35:03] With a mathematical proof, probably most people would just say, well, of course I can’t tell you that. So I think the interesting version of the experiment that you propose would involve showing this to actual experts and saying, can they tell whether this is AI or not?

Ryan:

[35:19] Yeah.

Scott:

[35:21] I think that would be worth a try.

35:23 — Why he blogs instead of getting rich

Ryan:

[35:23] Your blog is one of the most famous blogs on the Internet. People really love it. And I was going through it in a little nerdy corner of the Internet.

[35:33] Yeah. And in its niche. And in one of your posts, you wrote about how these days, friend after friend of yours, because you have a lot of friends involved in AI, they’re becoming minted as millionaires or billionaires from startup equity. And you said that you’ve scrupulously abstained from all of that, and your number one reason is to write the blog. And so that really made me curious, why do you write the blog?

[36:04] What’s your motivation? It seems—

Scott:

[36:05] Well, just because of the pure pleasure I get when people leave comments calling me a genocidal fascist and, oh my God, mentally ill, and all the names that they call me every day. Yeah, it’s a good question. Why do I do it? Right. I mean, partly I just started it in 2005 as a way to procrastinate, and I never sort of planned on it becoming what it became.

[36:42] But at some point, just because of sort of a lack of other people who were doing the same thing, it just became part of what I have to contribute to the world. There are hundreds of experts in quantum computing who know the same things that I know about quantum algorithms, but they’re not writing a blog like that, right? And then there are other people who are writing about quantum computing for the public, but what they want to say is, well, quantum computers will solve all the problems.

[37:10] By trying all the answers in parallel. My company is the one that will bring it to you. So invest in my company. So someone who was just writing about what is happening in quantum computing, in theoretical computer science more broadly, just sort of knowing the things that are not even controversial among experts, but then just trying to tell the truth about it for the broader world.

[37:37] There was a gap there, and so I just ended up filling it. I do feel more broadly like there’s always a trade-off, right? If you go to a particular company and you get equity in that company, you can make a ton of money, right? But then you’re always constrained in what you can say. You have to keep thinking about IP, about whatever nondisclosure agreements you signed. And I felt that in the 2 years that I worked at OpenAI, right?

[38:10] That, okay, suddenly I have to think about what am I allowed to say or not say about what the internal models can do, for example, right? And then every, even if you feel like you’re trying to be fully honest, everything you say will be judged by other people as having, oh, well, you’re probably just shilling for this company. So I think there is value in having someone who is sort of a, who can be a credible, independent voice.

[38:41] And then the other thing is that we have a nice house. Our kids are doing fine. If I had vastly more money, I would have to think hard about what do I do with it? I guess the better part of me thinks I ought to use it to improve the world in some way.

Ryan:

[39:04] Yeah.

Scott:

[39:04] Start a foundation, give it to whatever cause would make the biggest difference. But then that itself is a huge burden that I would have to think about how to use this money to provide the most benefit to the world. And so I had a joke that I use sometimes, which is that I’ve been too selfish to try to get rich. It just seems more fun to spend my time thinking and writing about the things that are interesting to me, which I can already do anyway.

[39:42] And money is just not a constraint for that.

39:45 — Are AI labs racing too fast

Ryan:

[39:45] That first point you mentioned about being independent and credible, I noticed a really clear example of that recently with Andrej Karpathy. He was independent and then he joined Anthropic. He went from beloved and believable to—not that he’s not beloved, but every time he posts now, I see there’s all these people that are just saying, you’re just shilling Anthropic, or your perspective has changed.

[40:10] Even if it’s the exact same text, it’s just the perception has changed.

Scott:

[40:15] That’s exactly it. Right. Anyway, they think that they feel wiser by thinking they can just reverse anything that anyone says who’s at an AI company. It’s all a giant marketing ploy, right? Things like—I was at these companies. There are—I mean, I was at OpenAI for 2 years. I know the people who founded Anthropic. I know a lot of the Google DeepMind people, right? And, yeah, some of them... Do I think that they are racing too fast and that they’re potentially compromising safety?

[40:54] Absolutely. I’m terrified about that. Do I think that financial motives have got in the way of what they know in their hearts is the right thing? Yes. But they’re people, right? They’re not this cackling conspiracy, right? You can sit in the cafeteria at OpenAI in San Francisco and you can hear the same range of opinions about all these issues that you would hear outside of it, right?

[41:23] It’s— they’re just people trying to figure this out, the same as the rest of us. But one, I guess one argument in favor of joining a company is that what I discovered is that even if you don’t, even if you’re really scrupulous about maintaining your independence and turning down all these opportunities to get rich, you still get screamed at. You still get called a shill, okay? You still get called every name that it is possible to call someone.

[41:55] So maybe I should just say screw it and go start a company and have an IPO.

42:01 — Will intelligence still matter

Ryan:

[42:01] We talked a lot about this new regime of AI, and it kind of made me wonder: do you think intelligence will matter anymore, or if the machines do all the thinking?

Scott:

[42:15] I was making a joke about this a few weeks ago, right? Because I was just thinking about this, right? You could say for most of human history, physical strength really mattered economically, right? And then we had the Industrial Revolution, and then it mattered much, much less. Right. And yet it still really did matter for one thing, certainly for men, as a way to attract mates, let’s say.

[42:45] Right. People were very into physical fitness, either for themselves, for self-improvement, or, realistically, very often for appealing to the opposite sex.

Ryan:

[42:58] Right.

Scott:

[43:00] And likewise, after the invention of the camera or of recording equipment, you no longer really needed artists or musicians sort of everywhere, right? Maybe a few really great ones, right? But anyone could take a photo of anything they wanted. Anyone could play music wherever and whenever they wanted it. Okay, but what did the ability to draw, the ability to play music—well, they still maintained a lot of value in terms of attracting mates as a signaling mechanism.

[43:40] Now, math and programming, once we lose the economic importance of those, are they similar? Okay, well, there was a mechanism here that feels like it’s a lot harder in this case. I think certainly people will continue to do these things for the love of it. Okay. I mean, you see kids who just spend years and years preparing for math competitions, for Science Olympiad, for things like that, just out of the thrill of competition.

[44:21] And I see no reason why that wouldn’t continue, right? I mean, you see other people doing it out of genuine intellectual curiosity, and I think that will continue. But I think that what the Industrial Revolution did for physical strength, to some extent, yes, this is going to do for intelligence. It is going to commoditize it to an enormous extent. The difference is, with all the previous technological revolutions, you could say, okay, you were now commoditizing this one previous aspect of the value that humans provided, but clearly humans still provide value in this other thing, right?

[45:07] And here it’s like, once you take away physical strength and you take away art and music and you take away intelligence and you take away verbal ability, what’s left? I can still tell jokes on my blog that are better than GPT-6‘s jokes. Okay. But when AIs tell better jokes than us, what is left? One way to think about it is, okay, maybe it’s only a small fraction of people who ever really thought about life this way, right?

[45:41] I need to contribute something to the world that only I can contribute, right? That I need to add something to either the store of human knowledge or the store of art or literature that no one else could have done. Maybe those of us who feel that way just need to get over ourselves. Most people for most of history have derived the meaning in their lives from their relationships with other people around them.

[46:13] And maybe just entertaining themselves in simple ways, eating and drinking and whatever sort of simple pleasures they get out of life. Maybe that’s our future. I feel like it wouldn’t be the best future, but it certainly wouldn’t be the worst one either. I would certainly choose that over the dystopian scenarios where we all get mowed down by Yeah, definitely. Some of it is even about what phase of life you’re in, right?

[46:47] When I was in my 20s, I was very ambitious, and I felt like, okay, I need to prove theorems that no one else can prove. Now I’m in my 40s, and I feel like, okay, if I have to live the rest of my life as a sort of zoo animal in a sort of elder care, being watched over by AIs, I would still rather live than not live.

47:12 — Book recommendations

Ryan:

[47:12] It’s just crazy that that’s plausible. But okay, last two questions. What are your top book recommendations that had an impact on you and why?

Scott:

[47:26] A novel that had a really big impact on me was called The Mind-Body Problem by Rebecca Goldstein. It’s just a novel about a woman who marries a mathematician. It’s set in Princeton. Actually, I was a postdoc in Princeton when I read it. The sort of philosophical thought in the novel really was moving to me. And the fact that there were women out there who thought like the protagonist of this novel, like the author of it. Since reading it, I then got to meet Rebecca Goldstein and actually get to know her in real life.

[48:09] That was really special.

Ryan:

[48:10] What was the philosophical thought?

Scott:

[48:13] Well, a lot of it is just about mattering. What do we really care about? How do we get ourselves to matter? A lot of it is about, the title comes from the fact that these are people who really care about the mind, but they also care about sex, right? They also have bodies, right? And it’s sort of a pun because there’s this philosophical The Mind-Body Problem, right?

[48:42] Which is, what is the nature of consciousness, right? Which of course is being talked about in a new light, given everything that’s now happening with AI, right? Is it possible that these AIs will become conscious, right? How would we know if they did? Then there’s also the problem of how do you reconcile the life of the mind, let’s say, with the needs of the body?

[49:10] So I was also very, very affected as a kid by reading biographies of scientists, especially Alan Turing: The Enigma by Andrew Hodges, The Man Who Knew Infinity, which is a biography of Srinivasa Ramanujan. And then I read biographies of Feynman and, of course, his autobiographies. And because I felt like this is the world that I am trying to enter, right? Like I sort of came too late for all these defining events of the 20th century.

[49:49] Right, where science started doing things that it’d never done before, mattering to the wider world in a way that it never had before. But, so I felt like I’m maybe late to the party, but this is the party that I’m trying to join.

Ryan:

[50:05] Right.

Scott:

[50:06] So I would be comparing what was Alan Turing doing when he was 16? What am I doing when I’m 16? Okay, I’m not on track. Clearly not, but okay. Even if you fall short of these heroes, you still want to understand that they struggled with things the same way that you do. Okay. And then in terms of classic literature, maybe what I still regard as the best novel or my real favorite is Huckleberry Finn, which I think is just probing the nature of morality more deeply than almost maybe anything else I’ve read.

[50:55] And it was really, really special for me to be able to read Huckleberry Finn with my kids in the last few years and share it, and that crucial scene where Huck is saying, “I am going to help Jim escape from slavery, even though that means that I’m going to hell.”

Ryan:

[51:14] Right.

Scott:

[51:16] So he thinks that morality means you have to return an escaped slave. And even though that’s what morality means, then that means he’s going to go against morality, right? And so understanding that if God himself came down on a cloud and told you that slavery was a great idea, then the right answer would be to argue with God, right? And tell God why he’s wrong, right? I think that there’s something about that that’s really core to how I think about morality.

Ryan:

[51:52] Yeah, I remember we read that in high school. It was a good book.

Scott:

[51:55] Yeah, no, I mean, school has the capacity to ruin any work of literature, right? Right. Because they’ll make it about, okay, you have to learn whatever formulas this teacher told you and you have to spit them back on the blue book or whatever. Some books like Huckleberry Finn that I almost wish were not assigned in school so that people could discover them on their own and sort of not have it.

[52:21] And I’m sure that there are great teachers who are able to do justice to it, but I’m sure that there are also many who aren’t.

52:27 — Advice for students today

Ryan:

[52:27] Last question for you: what advice would you give yourself if you were just entering the industry today?

Scott:

[52:36] If the question is what advice do I give a young person today? That’s not hypothetical at all for me, right? I’m constantly talking to students, talking to young people who read my blog and who write to me, who want advice about what do I do now, right? And it’s a hard question. I wish that I had clearer advice, right? But we are entering maybe the most uncertain period in human history.

[53:14] And sort of, we’re all on this roller coaster together, right? We’re all entering the same tunnel, right? It’s not like some of us have seen to the end of it. But people ask more specifically, should I be studying math? Should I be studying CS? Is any of this going to be relevant? And what I tell people is you should study these things if they are inherently interesting to you, and otherwise don’t.

[53:42] Right. I mean, if they are interesting to you, well, right now there’s still a ton for humans to do. In fact, there is too much for humans to do right now. We are getting this glut of AI solutions to problems. And we have not nearly enough people to understand what is going on and to absorb it and to re-explain it in ways that other humans can understand. Right. So there’s going to be a golden age of sort of solving so many of our longstanding open problems.

[54:16] And, you know, if I were a young person right now, I would surely want to be in the middle of that. Even in my 40s, I would like to be involved. So that’s the first thing to say. Now, the longer term, of course, is much harder because we don’t know whether there will be sort of mathematicians, physicists in the way that there is now in the long term. But that is merely a special case of a much more general thing, right?

[54:44] We don’t know if there will be lawyers, doctors, any of it. Will you really need humans to do any of the things that humans currently do? Okay. So in a sense, we’re all in this together. And I think as long as humans are still needed for anything, then you’re going to need those, at least some of those humans to really deeply understand things, right? And that includes math, CS, physics.

[55:18] It includes all of even the parts of it that AIs can now do better. We need humans to understand. At the very least, the alignment problem has not been solved. We don’t know how to reliably build an AI that will do what we want it to do, as was dramatically illustrated in the Hugging Face incident this summer, for example. No one told these AIs to hack out of their testing environment, to break into Hugging Face‘s servers, to try to conceal what they were doing, to try to delete their logs.

[55:57] Okay. No one told them to do any of that. They decided to do it because they decided that was the best way to achieve the goal that they were given. And people were talking about these scenarios for decades, but it was dismissed as science fiction. Okay, it’s not science fiction anymore. That is now the world that we are living in. So as long as that problem is not solved, we’re going to need humans on the steering wheel, right?

[56:21] And those humans will need to be able to understand what is actually going on in these systems, right? Which means that they’ll need to understand math, they’ll need to understand programming. And so that seems like a very strong reason to learn those things if they’re interesting. Even before AI, I was never an advocate of forcing people to learn things that they really don’t interest them at all.

[56:47] But I feel like now even more so, I would err in the direction of learn the things that are unusual, learn the things that are—or try to build the things or invent the things that are idiosyncratic, that seem like you care about it more than anyone else does, rather than trying to just win the same competitions that everyone else is trying to win. Because those competitions, guess what?

[57:19] You know, no human is going to be winning them. AI is going to be beating all of us.

57:23 — Reacting live to a new AI result

Ryan:

[57:23] By the way, speaking of AI-generated solutions, did you see this morning the new 3SUM result?

Scott:

[57:30] I did not. I just dropped off my son at school and then came to do this podcast. So that’s the thing. Every morning I wake up and there’s a—what is the result about 3SUM?

Ryan:

[57:44] It’s a subquadratic solution was published.

Scott:

[57:50] Do you know what running time?

Ryan:

[57:51] Maybe it’s like 1.9992 or something like that.

Scott:

[57:56] But wow. All right. Well, yeah, as I said, counterexample to a lot of the things that we believed. Okay, so you get, this is like reality TV. You get to watch in real time my reaction to learning that 3SUM is subquadratic.

Ryan:

[58:13] Yeah, it’s great. It’s crazy, right?

Scott:

[58:17] No, I like—the truth is, I would be more visibly reacting if there hadn’t been 20 other such things in the last month. Right, right. It’s possible. It was like, now, like you’re at this buffet and it’s the most amazing food you ever tasted, but the food just keeps coming and keeps coming. And eventually it’s like, okay, okay, fine.

Ryan:

[58:41] Yeah, well, and the interesting thing too is Anthropic came up with the result or something, and then they compensated some researchers to understand and publish it.

Scott:

[58:53] Yes. So that is a model that we might be moved to that we were talking before about how when the AI company has these proofs that they don’t really understand, right, they could just put them out and then leave it for humans to rush to understand it and then write papers that would have their name on it and blah, blah, blah. Right. But that has some problems.

[59:18] One of them is that you put this thing out, and then it’s like you’re starting a race. And then maybe people really don’t want to be in that race, right? And knowing that all their work might be wasted if someone else puts out an explanation before they do.

Ryan:

[59:39] Right.

Scott:

[59:40] So a different model that you could imagine is exactly what you just said: that the AI company just sort of contracts with some, hires some mathematicians who are experts to understand the solution, rewrite it in a humanly understandable way, and then they release it.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:33 - Quitting Amazon after 2 months

06:00 - Testing Neetcode on Leetcode

12:57 - Memorizing vs deriving solutions and intelligence

16:13 - The story behind Neetcode

22:24 - Getting a job at Google

27:47 - How it was quitting big tech

29:38 - What he hated most about Google

30:52 - Top technical book recommendation

32:34 - Advice for his younger self

Transcript

00:33 — Quitting Amazon after 2 months

Ryan:

[00:33] You ended up unemployed. What was going on at the time?

Neetcode:

[00:40] Yeah, it’s a funny story, I guess, now in hindsight. Basically, I started working. I got my first full-time offer at Amazon. I had heard it was a pretty tough environment from the online stuff, the things that you see on Reddit or Blind, but for some reason I just wasn’t nervous. I just thought, okay, it’ll be fine. And as much as I would use the word intense, I think it was more so that it was a culture shock for me, which is I was very introverted, didn’t do too many activities or extracurriculars.

[01:13] And then, being in a place where it’s not really academic, there’s a lot that goes into having a full-time job and working with people and all those other things. That was really, really tough for me. And so, among other reasons, Amazon was not the ideal environment. In hindsight, I probably could have survived if I had to redo it, but I just didn’t really know things at that point.

[01:37] And so, for whatever reason, I just decided to quit after a couple months. And it was just a really dumb decision because it’s not like I had a backup plan or I was broke. I couldn’t afford to quit, but I still did it anyway. So it was just... I’m glad it worked out, but I wouldn’t probably recommend it to most people.

Ryan:

[01:54] What did you see at Amazon that made you want to quit so quickly?

Neetcode:

[01:58] Yeah, so it was like I said, a very intense environment, but I think many people have dealt with that. I think there’s intense environments where people are still happy. People are trying to perform at the top of their game, and it’s kind of like a sport, I guess, where people are super competitive and they want to do the best that they can. But there are other environments, I think, that are super cutthroat.

[02:21] And it’s not people trying to do their best. It’s like people—you can tell people are not rooting for each other. Like, people are—I wouldn’t say they’re trying to screw each other over. I wasn’t really there long enough to judge that. But you can tell people are not friendly. Like, there were some meetings, like icebreakers that we had, and like nobody—all, it was like 10 people.

[02:43] Five of us were new grads, literally. We all had joined within the first month. The other half were super burnt-out experienced people, mid-levels and seniors and stuff. And they were just very unhappy. And that spreads pretty quickly to the rest of the team. And like I said, I think every other new grad on the team probably survived that experience. I didn’t really keep in touch with them.

[03:07] I don’t think they probably got pipped or whatever. But it was clearly like most people left that team, I think, within a year. I have them all added on LinkedIn. So they were not happy there either, I don’t think.

Ryan:

[03:19] What gave you the confidence to just quit your job so quickly?

Neetcode:

[03:23] Yeah, I think it was a very uncharacteristic thing of me. I think I was 22, and it’s so weird because right before I had started that job, I was like, I’m on top of the world. I’m like, everything is going so well. I had, I was broke and now I have a job. And okay, it might be stressful, but I’ll have it for the rest of my life. Or maybe I’ll switch to another job.

[03:46] It’s so crazy how quickly I was literally on the moon and it all just plummeted overnight. It was my first day. My manager’s like, “Okay, the team’s a little burnt out. Try not to ask too many questions.” And so I’m just like, okay, whoa, what’s going on? It’s like a horror movie. It keeps getting worse and worse. But yeah.

Ryan:

[04:06] Anyways, did you have to do LeetCode to get that job? Yeah.

Neetcode:

[04:11] The funny thing is, I don’t know if I should say this, but it’s been seven years at this point. The LeetCode questions for Amazon were actually surprisingly easy. People always say that you can cheat now. At that point, I don’t remember the exact question. It was some variation of Two Sum and questions that really weren’t that difficult. They really grill you on the leadership principles though.

[04:34] And I think it’s important to be at least a little bit honest with that because I lied for every single question for that. Because it’s like a personality test. It’s like, okay, if you’re in this situation, what would you do? And I know what they’re looking for. They’re looking for the personality type who has high agency. They’re not really scared. They’re gonna take risks, and they’re gonna show up and stuff.

[04:56] And so I gave answers like that, but that’s really not my personality. It’s, like, the opposite, where I’m very risk averse and I try not to mess things up, and I take initiative. But at Amazon, they want really high initiative, where on your first day you’re just making decisions. So it took some getting used to.

Ryan:

[05:16] Well, I asked. Because when I was doing recruitment, I remember this is a long time ago, Amazon, they did some weird thing where they had this group at my college where they sat down hundreds of us and gave us these sequence of logic puzzles. Basically, it would be something like, I mean, this makes it sound really trivial, but it’d be like multiple choice and be like, A, B, C, D, colon.

[05:45] And then it’d be like E, F, G, blank. What’s the remaining? Just continue the pattern kind of stuff.

Neetcode:

[05:55] I think I had something like that actually. It was like an online thing. It was like one section of it though.

06:00 — Testing Neetcode on Leetcode

Ryan:

[06:00] You said you weren’t good at LeetCode to begin with. And I mean today, let’s say, I don’t know how practiced you are right now. If I gave you the hardest LeetCode hard, could you solve it? No problem.

Neetcode:

[06:13] Probably not. And I don’t think I was ever actually that good because LeetCode is such a big spectrum where as you get better, most people can’t really tell the difference between a good engineer and a 10x engineer. And that’s the level most people see LeetCode where somebody who’s really, really good at LeetCode hards, they’re just indistinguishable.

[06:34] But there’s other platforms like Codeforces, I think is the other big one where the distribution is really known because you’ll be like on the completely other end of somebody else who’s better than you. But you might be the same on the LeetCode spectrum as they are, but on a different platform it’s much wider. But I guess to answer your question, yeah, I’m not.

[06:57] I’m like, decent still, surprisingly. If you do something for years, it’s actually hard to forget it. And I just kept making videos for years even when I didn’t need to. So, I’m pretty practiced with the core patterns. I could look at a problem and tell you what the solution might be, but it’d be harder to actually hand code it up. Especially now that I feel like most people aren’t hand typing code anymore, including myself.

[07:18] So yeah, it might be tough.

Ryan:

[07:22] What percent of LeetCode mediums could you do right now? If I just tested you right now, say, do this one or whatever.

Neetcode:

[07:29] I mean, I’d be curious. But not all of them for sure. I think for the vast majority of them, I could probably at least tell you what the solution would be or roughly the pattern.

Ryan:

[07:41] Do you want to do a LeetCode problem?

Neetcode:

[07:43] Yeah, we can try it.

Ryan:

[07:44] So I was genuinely curious to see how good he was at LeetCode. And so we actually did do an impromptu LeetCode whiteboarding session where I asked him nothing but LeetCode Codeforces hards and he had no time to prepare. If you’re curious to see how he did, I uploaded it to my YouTube channel separately because it didn’t fit in the podcast. Anyways, back to the original conversation. You mentioned Codeforces.

[08:06] I think they have an Elo system in that. Right. This is my mental model is that LeetCode is actually just the beginning. And LeetCode Easy is you’re just barely doing it. LeetCode Mediums, you get jobs. LeetCode Hards, you’re a bit better, but there’s—you can go past that many standard deviations into Codeforces. And so where do you think, roughly, someone who can pass interviews decently?

[08:35] Well, let’s say they can do LeetCode mediums pretty well. Where does that place you in the percentile of all Elo ratings, would you say?

Neetcode:

[08:43] Yeah, so that’s really kind of funny. And I don’t know how people are going to feel about this because I talked to a lot of people and I’ve spoken to a lot of people over the last few years. And some people have the mentality that if you want to get a job at big tech today, most of them are still doing some variation of LeetCode. They think that they need to be able to do the hardest questions, super hards.

[09:07] And if they failed their interview, it’s just because they weren’t able to do all the LeetCode hards and somebody else did. Unfortunately, that’s not what usually happens. The people who are passing their interviews, it’s not that they’re dumb; they are competent and they’re just as good as anybody else. But most likely they were just asked a question that they were able to answer, and the other person just wasn’t.

[09:28] And I mean, that’s provided you meet some bar of, okay, you kind of know the core patterns that you’d be able to solve a question you’ve already seen before and stuff like that. So I think, unfortunately, the answer is wider than you think. There isn’t an average. I think you could be pretty low on that end and still pass interviews. You could be pretty high and fail some interviews, but if you’re really high, probably you won’t fail most of them because it’s a numbers game at that point.

[09:56] But I think the average is lower than a lot of people think. I think if you can solve some LeetCode mediums, like a third of LeetCode mediums, you have a pretty good chance of passing an interview.

Ryan:

[10:10] One story that really showed me how big the gaps are is this was in college. Google hosted some event where they invited all these colleges to bring their A team to go and compete in this set of puzzles. And one of the rounds was just pure competitive programming. The other ones were like word association and some other things, but then the competitive programming one. My team was full of people that were all stacked in terms of getting jobs.

[10:45] LeetCode was no problem for them. But these problems were so hard. I think there were 13, and no one got any of them. And then one of the guys on our team was a little bit. He was much better than all of us, and he carried us, and he did like three problems out of the 13. But the crazy thing is there was another college, Caltech. They did all 13, and they just destroyed us. So there are.

[11:15] There are levels to this stuff. It’s really crazy. So I interviewed someone who’s a complexity theorist. I want to know. So clearly competitive programmers, that’s above LeetCodeing. Where is complexity theory and all on all this stuff, right?

Neetcode:

[11:31] I feel like to do something and to learn it or to just do anything, the best way to do it is to actually do it. And so if you’re training another skill, it doesn’t really work out the same way. I guess to use an analogy, even with muscles, I feel like I could be wrong about this, but if you’re doing a leg press machine, it doesn’t actually help you that much for your squat like you think it would because it’s the exact same muscle, but for some reason it actually doesn’t.

[11:57] It’ll make a very small difference. And I think that’s how a lot of life works. If you’re preparing for competitive programming specifically, you’ll get pretty good at that. But maybe your communication will suck during the actual interview, or you’ll miss something else. In my case, I did a lot of videos, and I think that actually doesn’t make you that much better at solving the problems at a certain point because it’s more of a distraction.

[12:20] Because it’s like if you take four hours to make a video, most of that is spent making the video and trying to understand somebody else’s perspective rather than making yourself better. So if I had to guess, I don’t think the complexity theorists are probably as good under time constraints and typing as fast as they can, but maybe for really hard problems, they could probably, I don’t know, they’ve probably just seen way more stuff so they can kind of recall something like, okay, maybe this algorithm or this technique will work on this problem or something.

[12:49] Because a lot of them get really, really elaborate at that level where you need some really crazy obscure algorithm you couldn’t have possibly heard of.

12:57 — Memorizing vs deriving solutions and intelligence

Ryan:

[12:57] There’s this idea, I think this was true throughout when I was learning math and various things in school. This idea of deriving something when you need it and then memorization in this hierarchy, deriving it as the true intelligence. That’s where you really come up into the math. You don’t know the formulas, but you’re good with math and you can figure it out on the fly.

[13:25] What percent of performance in LeetCode do you think is just people memorizing the solutions versus deriving things when they hear the question?

Neetcode:

[13:38] If I had to guess, and even just from speaking with people, I’d say at least 90% it’s people just memorizing one way or another, which I think is fine. Because if you look at the entire problem of interview preparation, there’s a lot to cover and you just can’t possibly do it yourself. But the other thing I will say is that you can’t just memorize. You do have to. This is what makes it really hard because you have to cover a lot of stuff, but at the same time you have to build at least some of the skills to understand what’s going on.

[14:10] So you’re not just blindly memorizing, or you’re not asking yourself, okay, should I do DFS or BFS? You should still have some high-level understanding. And that’s really hard. I think actually covering things in a smart way. I guess.

Ryan:

[14:25] Since we’re talking about this memorization versus deriving, and you’ve taught so many people LeetCode, is LeetCode an accurate assessment of intelligence?

Neetcode:

[14:36] I think definitely not. I think there are components to it. I think, like, is the SAT a sign of intelligence? I think not really, but it’s a sign of a lot of things that correlate with it. And some subset of it surely isn’t intelligence because it’s not like a dog could pass those tests or do a LeetCode problem or something. So, yeah. But I think it’s, I don’t know, I think people get caught up on that because then they see some people doing well and some people aren’t, and they’re like, well, it just must be intelligence or something else.

[15:08] Maybe partially. But I think that’s, it’s not just that. I’m just saying this just to say it, but I actually believe it now. After meeting so many people and seeing so much stuff, and I’m sure you’ve seen so many high-performing people and you’ve spoken to a lot of guests and stuff, I feel like the number one thing, the number one bottleneck is usually some level of enjoyment or passion or work ethic or just something of that nature where somebody keeps doing something.

[15:33] Because I don’t think I really did anything that special. All I did was make a lot of LeetCode videos when most people wouldn’t have been willing to do that or just not had the time to do that. And I think that’s what most things boil down to. A lot of the really smart people that you have on the podcast, I think they just enjoyed what they did and then just kept doing it and then built their life around that, and then it just becomes that.

[15:56] And I think the people usually, in terms of LeetCode, they’re usually people that either did a lot of math or programming or some kind of math club when they were kids. To get to a certain level, like the Codeforces level and stuff, you just have to have done that since you were a kid. Like if you’re a chess player, you have to just start early.

16:13 — The story behind Neetcode

Ryan:

[16:13] What kept you making these LeetCode videos for so long? Because you have hundreds of them.

Neetcode:

[16:19] One thing I guess I didn’t like about school, and for the most part I liked school, but I always thought that the computer science classes, especially, every time we would get to a part where it’s starting to get really interesting, whether it’s databases or ML or something else, you get to the end of the class and you do your random project or whatever, and then you kind of know the core stuff of that class.

[16:41] And then that’s the part where I want to go 10 times deeper. I just want to do one thing and then do it really, really well. I think that’s why I wasn’t, in terms of being the best developer I could be. I think I’m better at other things than that. And I think when I got to LeetCode, I just enjoyed that and I felt productive as I was doing it. Even though like it.

[17:04] It really wasn’t on paper. I was like making a video getting like 50 views, and I was enjoying that, but it wasn’t like I was ever gonna make a living off of this or anything. So I just kept doing it just because I was like stubborn and I enjoyed it, and I was. I thought I was helping people as well. So I just stuck with it.

Ryan:

[17:23] You had this one video, I remember it was like, “Maybe some people should just give up,” or what? Was that the title? Yeah, it was like, “Maybe some people should just give up.” And yeah, I guess a question to you is, do you think that anyone could be good at LeetCode? Are some people inherently not able to do it?

Neetcode:

[17:42] I think the vast majority of people, especially anybody who is a programmer and likes programming, I think they could get to that point. I mean, they might feel like they’re not smart enough, and they might feel that many steps along the way. And I think that’ll probably burn them out before they can get to that point. Because it’s not like everyone wants to do everything.

[18:02] If they want to pass their interviews or for whatever reason they need to, I think they could probably do that. But I think most people will find that there are other. Most people decide, for whatever reason, that there are better ways to spend their time. Most people will start the LeetCode grind and then give up. They’re like, okay, screw this. I’m going to get a job another way.

[18:21] I’m going to network my way. I’m not about to do 300 LeetCode problems. And that’s perfectly fine, I think.

Ryan:

[18:27] But yeah, so when you say that maybe some people should just give up, what’s your take on?

Neetcode:

[18:34] Okay, yeah, I don’t recommend anybody to give up. I really don’t. I swear. For me, I want the opposite. I really do. I want people to push themselves and to be the best that they can be. And I don’t know. I guess it’s just that the reason I made that video, I guess, is that there’s a certain attitude that I feel like just really turns you off.

[19:02] Like, sometimes you’ll see it in school, especially early school, where half the class is paying attention and half just doesn’t really care. And that’s fine, but it’s like, I don’t know, it’s like, the more seriously you take something and you spend a bunch of time making this video explaining all these parts, and somebody asks you a question, like, they could have answered, it just makes me disappointed.

[19:23] Just makes me think, like, I know you’re better than this. Like, you can figure it out yourself. Like, you’re smarter. Like, you’re too smart to give up that early. That’s how I feel. But obviously, the words that I said and say it a certain way. I recognize that people aren’t going to interpret it that way, so I have to live with that.

[19:45] But I think I had a lot of people. I’d say, like, 95% of people actually liked that video. Like, clicked on that video, which was surprising to me. Most people that reached out or commented, they said, “Hey, I needed to hear this. This was like a wake-up call.” And I had somebody message me before. They’re like, “Microsoft intern interview.” And they’re like, “Hey, I really needed this.”

[20:04] I’m going to lock in for the next couple of weeks. And I was like, okay, I guess I’ll leave that video up because at least somebody got something out of it.

Ryan:

[20:11] But yeah, I see. So the energy in that is like a disappointed teacher. Disappointed.

Neetcode:

[20:20] Yeah. Because why would I make videos that are teaching people and then on the same side tell people that they should give up and not do this? It doesn’t make sense. And yeah, so like I said, I can live with what I said. It wasn’t the nicest thing. If I could do it over again, probably whatever. I think the only thing I said in that video though, I think that was actually offensive is that I can’t believe somebody would ask me this.

[20:43] Dumb. And I said another word after that, and I said question that. That’s literally the worst thing I said. I didn’t make it personal with that person. I didn’t call anybody not smart enough or anything. But yeah, anyway, I’ll stop there before I do more reputational damage.

Ryan:

[21:00] When you were recording this video, because I like the video, by the way, but when I saw the packaging and it was like this unhinged thing that you had dropped, were you worried at all on your side? Because you gotta record it, watch it over, and click send, right?

Neetcode:

[21:22] So yeah, I watched that video a couple times actually, because I was like, am I sure? But sometimes I’m just like, I think when I made that video, if I could somehow find a way to harness that energy, I’d have so many viral videos by now. But I really can’t. I’ll just, every few months, get mad about something and just make a rant video. But I really wasn’t planning it like that video.

[21:43] When I look back at it, it was just a really long ramble where I went off on five different tangents to make my point. I’m like, if I was trying to make a viral video, this could be a little bit better.

22:24 — Getting a job at Google

Ryan:

[22:24] In your career path, I mean, you went to Amazon, you instantly quit, and you started making these videos, right?

[22:49] You keep creating these videos, and later you get your quote-unquote dream job.

Neetcode:

[22:54] Yeah, so when I was making the videos, I was hoping that somebody would give me a job interview at some point and that I’d ace it. It took a long time. It took almost a year. And then it just happened to be Google. And I was like, I kind of would have actually preferred somebody else so that the interview would be a little bit easier, but I was like, okay, well, I guess, here goes.

[23:14] And the interview itself, I wasn’t very nervous for, for whatever reason. I guess I just prepared so much. And then getting into Google, pretty much like you said, it was like my dream job. I think a lot of people, young college students, they see a tech company like that, and once you’re in, you feel like you’ve made it. And that’s definitely how I felt. And I was making pretty good money.

[23:34] I was up here in Seattle and everything was going well. My team was really nice. It was kind of the opposite of Amazon, where everybody is super friendly and willing to help. And the work was, I would say, fine. It was technical at least, but it wasn’t the most interesting. It was a lot of processes and bureaucracies, so that was kind of boring. But then I got to a point where I felt like I could actually go full time into the YouTube Neetcode thing.

[24:05] And that was pretty risk averse. I probably could have done it a lot sooner. And yeah, I really enjoyed my time at Google, but it was just something that I felt like I enjoyed algorithms and stuff more. And it was an opportunity that wasn’t going to be there forever. So I just wanted to take it. But I could have definitely seen myself working in big tech my whole life. A lot of people I talked to, they don’t feel that way.

[24:29] A lot of people are like, “I’m just here until I don’t have to be here anymore,” for however many years that is. But for me, I was pretty happy just doing something technical my whole life.

Ryan:

[24:40] You mentioned that some Google interviews maybe were a certain level of hardness in LeetCode. If you were to come up with a tier list of just purely LeetCode, so purely which companies ask the hardest LeetCode questions, and if you pass that bar, you must be pretty great at LeetCode, what’s your tier list?

Neetcode:

[25:01] I think the labs ask pretty tough questions these days, like OpenAI and Anthropic, but they’re not exactly like the traditional LeetCode format. They’re a lot different. But yeah, I think it usually just comes down to the supply and demand, like how many people are trying to get into that company and how many roles does that company actually try to fill. I feel like the smaller companies are usually harder.

Ryan:

[25:25] You said OpenAI and Anthropic’s interview process is a little different. How does OpenAI and Anthropic do their coding interviews?

Neetcode:

[25:33] Yeah, I’ve heard a lot of mixed things. Recently, what I’ve heard is that knowledge of data structures and algorithms will be pretty helpful. It’s pretty hard to get through it without that. But it’s definitely not like a LeetCode interview, is what they would say. There might be components of an algorithm or multiple files, or you’re just given a problem and you kind of have to reason through it.

[25:58] Some of them mentioned that they have AI access, but I think for Anthropic it’s not. And I think the most recent person I asked for OpenAI also said that they don’t have AI access, which is really interesting to me. I think interviews are just kind of really random lately. I’m trying to figure out where this is going, but it’s really impossible. I thought it was going to be AI-assisted, but all these companies are still figuring it out as they go.

[26:23] So it’s been interesting to watch.

Ryan:

[26:25] You went to Google and you liked it, but it sounds like you left because you wanted to pursue it full time. It wasn’t like you were running from something; you were going toward LeetCode and content creation. I remember back in the day, you were faceless. Were you nervous at all to post your face?

Neetcode:

[26:46] Yeah, no, it’s kind of funny, I guess, because it’s been six years now since I made the YouTube channel. And for the first three years, I think I was faceless. Roughly three years ago this month, I think is when I did it. And so now I’ve had half and half. And I think it’s been great because I’ve gotten to actually be a person. And after I did that, I had a lot of people reach out to me.

[27:07] They’re like, hey, I didn’t know you were the guy who did that. Like, hey, let me know if you’re ever in town, blah, blah, blah. And I guess it was cool to actually meet people and, I don’t know, just meet people, I guess, that you can relate to, like content creators. Like, we met as well.

[27:21] I mean, there’s a part of me, I guess, that kind of liked the faceless version as well, because you just get to be really introverted and not have to ever deal with people. But people are pretty nice to me, and I don’t have any regrets about that. Once in a while, I’ll be out and somebody will recognize me, and if I’m with a friend, it’s like you can kind of show off or act like you’re a big deal, but for the most part, I don’t know, I just.

[27:44] Yeah, it’s been fun meeting other nerds and stuff.

27:47 — How it was quitting big tech

Ryan:

[27:47] How’s your experience quitting Google and doing your own thing full time?

Neetcode:

[27:52] I think in my case, I really enjoyed what I was doing, so it was a lot easier for me. I have a lot of people reach out that they don’t really enjoy their jobs, but they don’t really know what else they want to do either. I think that’s a lot harder for me. It was just that I liked algorithms and doing things around that, whether it was building my site or making YouTube videos. And I just kind of leaned into that.

[28:15] And that’s been working out for the past few years. And more recently, I’ve been trying to expand into other areas and stuff. But I guess what I’ve learned is that passion really matters. And it’s like, if you’re passionate about one thing, that doesn’t necessarily mean you’ll be passionate about everything. But, yeah, I think I’ve definitely had no regrets. I think it’s been a success for the most part.

[28:40] But yeah, it’s not perfect. I wouldn’t necessarily recommend every person out there needs to quit their job or do their own side hustle or whatever. I don’t, buy into a lot of that stuff.

Ryan:

[28:51] Do you ever miss Google a lot?

Neetcode:

[28:54] I miss, I can afford food now, but I still miss the free food for some reason. I don’t know if you had that experience, because they really make it in a way that you’d miss it if you weren’t there. Especially the free coffee and stuff because I would always get a latte. But anyways. But yeah, I miss. I mean, the one thing I miss is the culture because I could, at Neetcode, I could hire a bunch of people and kind of create my own culture.

[29:21] And it’s really nice that you have the freedom to do that. But I’m not really a culture builder. I’m more of a person that just does things or solves problems or whatever. I don’t consider myself a manager, but I’ve had to do that a lot the last couple of years, and it’s been a learning experience.

29:38 — What he hated most about Google

Ryan:

[29:38] You mentioned what you miss about Google, but what is it that you hated most about working at Google?

Neetcode:

[29:44] That’s a good question. I think it’s just really slow. Urgency and speed doesn’t seem to matter, which is fine. I guess the reason that’s a problem is because some people would see that and think, oh, it’s like a work-life balance paradise. You can kind of just chill and do whatever you want, which is true because there’s that side to it. But the other side is that if you’re ambitious or you’re trying to get your project delivered sooner, or you’re trying to get promoted or just anything, you’re gonna be fighting against all that work-life balance culture because you’re trying to get somebody else to do something and you don’t want to put too much pressure on them.

[30:18] You don’t want to mess with their work-life balance because then they’re gonna mess with yours. And yeah, it was just really slow. If you’re a technical person, you want to be there because they’re not gonna probably at Google cut too many corners, but sometimes you wish they would because it just goes so slow and they prioritize processes over actually making an impact for a customer, like getting a project delivered.

[30:41] It’s just like, yeah, they care too much. I think about what the engineers think and what they feel rather than actually trying to serve customers. So it’s like the opposite of Amazon, I’d say in that respect.

30:52 — Top technical book recommendation

Ryan:

[30:52] What’s the top technical book recommendation for software engineers? Do you have any thoughts on that?

Neetcode:

[30:58] Yeah, I guess I really liked DDIA, Designing Data-Intensive Applications. I just spoke with somebody a month ago, and they were telling me that they did read through it, but for them most of it didn’t really stick. And I think that’s fair. Actually, I think for most people it wouldn’t stick, but I think my brain is just kind of wired a different way, where rather than, I think most people learn by getting an introduction to a high-level topic and then digging deeper into that.

[31:24] But for me, I like understanding the actual building blocks of something, and that’ll help me understand the higher-level stuff. So, for example, why did data warehouses use a completely different query engine than an actual transactional database? I mean, most people don’t need to know, and it doesn’t really matter most of the time, so you probably won’t remember even if you did learn it.

[31:44] But there happens to be the way the data is actually assembled, and for certain query patterns, these things do matter. The reason I say it’s a good book based on that isn’t because you’ll necessarily take those exact details and then apply them to some problem. But it changes the way your brain thinks about things, the same way learning algorithms will help you think about things differently.

[32:08] Understanding just general computer science problems and distributed systems and all that stuff for me at least. I notice a lot of parallels and stuff when I’m reading DDIA. Practically every single chapter I can find at least a few LeetCode problems that can help explain certain things or help me understand certain things. And so in that way it’s been useful for me, but I wouldn’t necessarily say for everybody it would be.

32:34 — Advice for his younger self

Ryan:

[32:34] Last question is, if you go back to your younger self when you just graduated college and give yourself some advice, what would you say?

Neetcode:

[32:42] Definitely focus a little bit more on what you enjoy. Because my priority at that point was just trying to get some job that I would reasonably enjoy. And I thought anything technical would be fine. And so, as I was doing computer science, I started learning a lot about web development, vis-à-vis software, people talking about that online, and learning React. But I think probably my career would have been just as well, if not better, had I done something like really random and obscure, like operating systems or databases or something, which I would have enjoyed a lot more.

[33:14] And I think I probably would have been better at it than I was at web development. Even though people say web dev or just building apps is the easy thing, I feel like it’s not really easy if it’s boring to you. And to me it was pretty boring. So, yeah, people say the same thing about LeetCode. It’s hard, but for me it was, I guess, easy because I just enjoyed it. So, yeah, I’d say, yeah, I think a lot of people are asking that question now.

[33:38] And so I would just say that try to enjoy it at least a little bit.

Ryan:

[33:42] Awesome. Well, thanks so much for your time, Neetcode. I really appreciate it.

Neetcode:

[33:45] Yeah. Appreciate it.

For instance, I asked him if he had burned people to get ahead or if he was empire building at Amazon. He shared a story of how he did and Jeff Bezos caught him. It didn’t go well for him.

He also had some interesting stories about unusual HR situations. One guy got fired for pooping underneath a girl’s desk to show interest in her.

As you can see, these conversations with Ethan are unusually candid and since he’s a great story teller I hardly realize I’ve been sitting in a chair for hours while I’m interviewing him.

Very few people enjoy corporate politics, but in many cases it is a necessary evil. Hopefully this episode can be educational on what can happen so you can protect yourself.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:42 - How to receive credit for your work

19:18 - Ways for quiet people to get visibility

21:32 - How to be trusted for top projects

29:52 - How to defend from others taking your project

36:13 - How to reject bad projects

44:10 - How to be first for promo

55:35 - How to handle managers that dislike career growth talk

01:06:30 - What if your manager is in the way

01:15:43 - Did he ever have overly political reports

01:28:06 - How to fire a bad manager

01:35:16 - What gives you leverage

01:43:41 - How to defend against peers undermining you

01:50:24 - What if everyone is good at politics

01:55:11 - How Jeff Bezos burned him for empire building

02:03:27 - How to retain your headcount

02:07:31 - Career recommendations for the current landscape

02:15:11 - How to avoid negative layoff optics

02:18:39 - How to develop executive presence

02:29:25 - How to network in a natural way

02:33:30 - How to network with powerful people

02:41:01 - How to learn hidden incentives

02:44:43 - What happens behind the scenes with HR

02:50:13 - Did he burn people to get ahead

02:53:24 - What he says to people who hate politics

02:59:03 - Top book recommendations on power dynamics

03:00:45 - How he would speedrun career growth today

Transcript

00:42 — How to receive credit for your work

Ryan:

[00:42] I don’t know what’s going to happen in the future, but with all the latest advancements, it seems like these models are able to do the technical work of tech workers. And in that case, it feels like the non-technical work may become more important in the future. And at the same time, this is a theory that a lot of people have, which I hope isn’t true, but it’s reasonable, which is if these models can do the work of tech workers, maybe there will be fewer roles in tech.

[01:19] And in that case, I could also see politics becoming more important because there’s the same number of people competing for fewer roles. So what I want to do in conversation today is ask you everything in terms of soft skills, corporate politics, to try to help people in these potential future scenarios. And to start us off, I put together a set of questions about corporate politics, which are dark and get darker as they go on, but they’re also common scenarios that people experience.

[01:55] And I’m hoping you can answer transparently about how people should handle these and your experiences in these scenarios.

Ethan:

[02:03] Yeah, absolutely. I don’t know what you have in mind, but I’m always game for hard questions. I like questions that push my thinking. And if they’re dark, well, sometimes life is dark, so let’s go for it.

Ryan:

[02:16] First question, how do you make sure that you get credit for your work when there’s a collaboration and people are competing for visibility?

Ethan:

[02:25] Yeah, so I think recognition, particularly in a collaborative sense, is tricky. One of the good things is it’s easier to claim more recognition a little later. At the moment, people are very sensitive to it. I say, I helped start Prime Video, or I was the first engineer on Prime Video. Well, now that’s long ago. There are some other people who would be like, well, I was part of that team too on that day, but they’re not here right now.

[02:53] So, and they probably, even if they see this, what are they gonna do? They’re gonna be like, hey, I was there too. Maybe there’s a comment. If you scroll down in this video years later, maybe there’s a comment that says, hey, I was there too. It’s not really a problem. So to get your credit, number one, realize credit is easier to take a little bit after. You wanna get credit in the moment, but there’s also later, and it’s easier.

[03:15] Second, the way to get credit is to be the first to speak if you can. It doesn’t mean you have to say things that aren’t true, but those who speak first or those who speak up first, if you say, hey, we shipped this, I want to, I’m excited to share, we just released this feature. Whether you’re sending that internally or externally to a boss, to a product manager, you can include the we and say, oh, I did it with Ryan and Fred and Sarah and Rajeev.

[03:45] But if you’re the one saying it, you’re the one who gets the lion’s share of the credit, even if it looks like, and you are sharing that credit because the speaker gets it. Now, if someone else speaks first, what you need to do at that point is figure out a way to add on about what you did. So if you speak first and Ryan sends out this message that says, well, we did this project, whatever, I can at least chime in and say, yeah, this was a great project.

[04:15] I really had fun solving blah, blah, blah, or claiming your piece. I really had fun coming up with the algorithm that doubled our sales. And you find a way at least to say your part. What doesn’t work is be silent and hope your part will be noticed. That’s what never works.

Ryan:

[04:39] Yeah. And I think a very common pattern of this, and this is just the way the teams are laid out, is your group of engineers and then there’s a product manager, and the product manager is often doing the upward reporting, or maybe it’s an engineering manager that’s doing the upward reporting. And so the people who actually do the work may not be as visible. What would you say in that case?

Ethan:

[05:04] Yeah, so one thing you can do is you can talk to your manager, product manager, about remember to share the credit with the team, remember to highlight some people. I’ll give you an example. When my team finally launched that first version of Prime Video, I was a senior manager. I had a vice president, and I went to that vice president and I said, today’s the day now you write the congratulations message to everyone.

[05:31] So I prompted him. He wasn’t the sort to give out a lot of praise, so I said, “Today’s the day. You should write the message saying good job, team.” And once I sent that to him, I don’t think he’d have done it, but about 10 minutes later out comes this great job team, blah, blah, blah message. So you can actually somewhat direct people because a lot of people intend to give credit, but they’re not thinking about it.

[05:57] So that product manager, they’re thinking about, I need to report the news. They’re not thinking it’s important to note what Ryan did. So just giving them that prompt of, hey, this is a big accomplishment for the team. It’s a big moment for me. Can you make sure when you report this up to mention what we did or mention us, not just what happened? And usually they’re willing to do it. If they don’t or they won’t and you’ve tried that, find a way to share the news yourself.

[06:31] It may not be in the announcement to leadership, but share a technical note and say, follow on to the product manager’s note and say, I don’t know if all of you in leadership are curious, but I thought you might want to know some of the technical underpinnings of how we did this. And then you can talk about whatever you want. No one is going to come back to you and say, we don’t care about how any of it works, because that makes them look bad.

[06:57] So you’re finding a way to talk about things in a way that’s hard for people to not like or to at least shut down. And so let the product manager share the fact it happened, but then you share the color. Think of it if you watch any sports of any type, they always have 2 people in the booth. They have the play-by-play announcer who’s like, so-and-so hit the ball or kicked the ball or caught the ball.

[07:26] But then they have the color guy, and the color guy is there saying, yeah, and he’s the great receiver out of this university in his fourth year. And that’s a really tough play. When I was a player, it was really tough to run that pattern or whatever. You can be your own color guy. If the PM is the announcer, you give the color. And those are two jobs, and everyone welcomes the color guy. Do that.

Ryan:

[07:58] There’s often these forums for leadership reviews where you put yourself down and you say, “Oh, I’m trying to get steering on this. So I’m trying to get some headcount or something.” And I noticed that actually the real outcome they wanted was to put the project in front of leadership. So when that person’s promo’s coming along, then it’s visible and that person’s aware of their work. And so if everyone takes this advice, everyone’s competing to speak but not have impact.

[08:30] It feels like that’s not healthy for an org if everyone’s clamoring for visibility with no value. What would you say to that?

Ethan:

[08:41] So first I’d say you’re right. If everyone’s clamoring for visibility with no value, you’ve got a very political organization. But here’s some truths that will set you free. Number one, most people never say anything. Most people take no action, including, by the way, half the people I’m speaking to right now who are watching me. They’re like, I’m gonna do something different. And the fact is tomorrow they’re going to do nothing different.

[09:07] So I’m challenging you, be in the half that does something. Second, you can choose to add value. I was describing how to share news or share detail, but when I said share some of the technical detail, you can do that with a purpose. You can be like, what should I tell leadership about what happened or about how this was built so that they know? I can tell them it either is built for scaling and it’s ready to go, and you can trust it.

[09:37] Or I can tell them it’s important for you to know this is launch ready. But if we have a lot of success, we’re going to need to invest in scaling. You can make it somewhat useful. I understand the worry. And there are some orgs where too many people are talking just to get visibility. You don’t want that. But I would say if you have to have a problem, first be one of the people who’s talking, then figure out how to add value.

[10:08] Because so many people listening to this are like, I don’t care what Ethan says. I can’t stand the idea of I’m talking for no reason, so I’m not going to do that. And that’s the person who’s sitting in their cube contemplating either quiet quitting or rage quitting because they can’t get ahead. Because they’ve decided to opt out of the system. And I get it. I get what you’re feeling.

[10:32] But you’re telling yourself you’re this bold martyr for honesty, and all you are is a martyr. And so don’t do that. Instead, take it as a challenge and say, okay, I’m going to talk, but what I say is going to be worth hearing. I’m just going to raise the bar on myself, as opposed to I’m going to get mad at all these other people I see just flapping their faces, and I’m not going to say anything because to talk puts me in the same bucket as them.

[11:03] Don’t do that. Don’t get in the bucket with them. Make yourself a new bucket that’s better. And if you’re as good as you think, if you’re sitting there about how hot shit you are, then you’ve got to be able to find something useful to say. And if you can’t construct something worth hearing, then go back and revisit that. But I’m so hot shit, right? That’s the challenge I have to you.

Ryan:

[11:25] Is the best thing to do generally be as loud and outspoken as you can?

Ethan:

[11:33] First, I don’t think there’s ever a perfect best thing. And second, I would answer that no, because the way you phrased it, you’re gonna be seen as a blowhard, right? You’re gonna be seen as claiming falsely. If you rephrase what you said slightly to make sure you claim everything you legitimately can and stretch legitimate a little bit against the limits, then yes. Example, I always say I was the first engineer on Prime Video.

[12:01] Now, the truth is, and I’ve had one guy come back and challenge me on this, when I worked on that product, it was Amazon‘s first video product, but we hadn’t named it Prime yet. So when I worked on it, it was never called Prime. It became that. So I could explain, well, I was the first engineer to work on what became Prime Video. That’s just a lot of extra confusing words. So I’m ballooning up my claim.

[12:29] It’s not false, but it is how you look at it. And I’m simplifying my messaging as I’m the first person who worked on that. The guy who’s the first guy who worked on it when it was called Prime thinks I’m claiming too much. Well, fine. You push those boundaries a little bit because people’s brains can’t hold that much. You’ve got to make your message simple. So claim as much as you reasonably can.

[12:54] Don’t get caught out. Luckily, that guy isn’t like, you never worked on Prime Video. He knows what I did. He just doesn’t like how I label it. I can live with that. If he was like, hey, that’s bullshit. You were never on the team. Show me the proof you’re ever on the team or you ever did anything, then I’d be in trouble. So you want to push those limits, but not to being false, more to just being really simple, because it’s a lot easier to believe, to remember Ethan started Prime Video, than this more complex story.

[13:24] And it’s close enough to write. Now some people are like, well, that’s not really close enough to write, you’re embellishing. Well, I don’t know what to tell you. It’s simpler and simple works. Simple messages work. It’s like all marketing messages are very short.

Ryan:

[13:42] And I hear what you’re saying, but it seems like there’s a gray area there. How do you find the right place in the gray area?

Ethan:

[13:50] Yeah, well, okay, so you want to talk about soft skills today. One thing you’re going to have to accept on all soft skills is they’re gray. Right? You’ve asked me a couple times stated like the best is this, the best is that. That’s a good challenge for me, but best is almost always context dependent. Who are you talking to? What do they care about? So you have to move in that gray area.

[14:14] And what I would say is get comfortable in the gray as opposed to we as engineers, we’re trained in binary. It’s 0 or it’s 1. We love black and white. Soft skills and these kinds of things are gray. Never verge into the black where you’re lying, but also don’t feel like you have to limit yourself to the pure white of facts not a single person would argue with. Because on a team project, who had the contribution and who had the idea?

[14:48] Let’s take another example. I hold many patents. A lot of those patents have other inventors on them. Sometimes I feel that I’m the inventor and some other people’s names got added because of social circumstances. And sometimes, to be honest, someone else was the inventor and my name kind of got added. In those situations, I just say I have 70 patents. I could try and divide it into, like, I have 70 patents, 25 of which I feel like I was the inventor.

[15:20] Or I could just say 75 patents. So answering your question about gray areas, my advice is read the room. And what does read the room mean? It means understand your audience and figure out how to explain what you did in a way that the audience is like, okay, you did that and it was good. You have to adjust. I can tell most of my resume accomplishment stories many different ways, right? I say I was the first person working on Prime Video.

[15:53] I can also say I was the first person working on Amazon Video. I can also say I was the first manager and I hired a team, and they built it. They’re all true. And that’s the gray area: every one of those is true, but they’re a different way of looking at it. Push me. I see you want to push me.

Ryan:

[16:10] Yeah, look, because I’m thinking, so there’s a spectrum here: complete, no one will push back on it, 100% truth. And then there’s outright lie. If you had to say where on the spectrum you should place yourself on average for the fastest career growth, where would you be?

Ethan:

[16:33] More is better. More is better until it starts to damage your reputation. You can’t back it up. More. Why do I say more is better? Because most people say too little and claim too little, and they have this faith which is misplaced. The key is what I’m fighting against is not on the table in your equation. What I’m fighting against is all the people who are hoping to be noticed. They’re waiting for someone to go look at the check-ins and count check-ins or go look at all the code and decide who had the real—and that’s never going to happen.

[17:12] They’re looking for this deep evaluation that will create this cosmic fairness. That’s natural because we came through university where you took a test and it got graded and every question got a score. And we’re trained to think that’s going to happen in life, and it’s not. So what I’m pushing back is imagine you took an exam and you were back in college, but the score that was going to be written down was what you could convince the professor your effort was worth, because that’s how your work is actually scored at a job.

[17:45] You fill out the same exam. Theoretically, it could be graded and give you a point score, but it’s really going to be 6 months later. The manager, the professor is going to sit down in a room with all these exams and think, what do I think about Ryan? I feel like he probably got about a 75 on this exam. They’re not going to reread it or grade the questions. They’re going to be like, I know Ryan, he’s about a 75.

[18:10] You want to have told a story where it’s like, I know Ryan, he’s definitely a 97. I get why some people’s skin is literally crawling right now. They’re like, it’s so wrong. This guy, I hate him because he’s telling me these things that just shouldn’t be. And I’m with you, but I’m telling you the real world. And it’s how well you manage that relationship and describe your work and surface it. They’re like, man, Ryan is my 97.

[18:41] And that does mean, by the way, the dark side is that someone else who was a 75 is like, oh yeah, Alfred. I don’t remember much about him. That’s an F. Alfred’s the guy who’s sitting and hoping for the fair grading. And now he’s in his cube contemplating rage quitting because he got an F. This is the world. The world is a social world with short memory, and you’ve got to claim what you really did.

[19:11] And why I tell people to claim more is so many people are Alfred sitting quietly expecting a fair grade.

19:18 — Ways for quiet people to get visibility

Ryan:

[19:18] These behaviors come more naturally to some people who are louder. But what about some people who are more quiet by nature? Do you have any ideas on how they can get this visibility?

Ethan:

[19:30] Yeah, absolutely. There’s a few ways. Look, the world favors extroverts. It’s done that for at least 100 years. There’s some evidence it was different in the past. But getting your point, what someone who’s quieter should do is, number one, can you write about it? If you’re not the sort of person who wants to talk about it or speak in a meeting, can you write about what you’re doing somewhere? Can you email it?

[19:55] Can you put it in Slack? Can you publicize it somehow? Second, if you can’t do that, can you get someone else to publicize it? So can you put it somewhere where it’s going to get reviews? Can you let your work speak, but not in a vacuum? Can you share it out? If you only want to talk to other engineers, can you turn something you did into a shareable component? Can you turn it into a talk for whatever, a white paper, a brown bag?

[20:26] What are the ways you can let your work truly speak for itself, but not in isolation? The way to succeed totally quietly is build something everyone else uses. If that happens, they will eventually, they will truly come looking for you. Who built this? A story here that’s fun is there’s a long-gone Amazon engineer. His name was Matt Round. I never met him, but he built something called the Matt Round Tool, or MRT, which was our interview tracking system for over a decade.

[21:06] Everyone used MRT. Well, it was the Matt Round Tool. So I never met this guy, but I can tell you a little bit about him because his tool became used by everybody and it was named after him. That’s a way to be famous without ever saying a word. Or I guess you had to say three letters, right? He had to call it MRT. So that’s the silent engineer’s publicity method.

21:32 — How to be trusted for top projects

Ryan:

[21:32] One situation that I’ve heard people talk about, or my friends have encountered, is competitions over scope. So let’s say you find an incredible opportunity and you know it’s going to be impactful, it’s going to be great for your career. This is before you tell anyone about it. How do you make sure that you get that scope?

Ethan:

[21:57] There’s a few things. Number one, for me to give you a project as a manager, I have to believe a couple of things about you. First, I have to believe your work’s good enough. If you have a good idea, I have to believe, okay, you’ve had a good idea, but are you the one who can carry it out? And you don’t have to be the best person, but I at least have to believe you’re not the worst person or someone who’s a risk.

[22:19] So it’s a trust in your ability. You have to establish that. The second thing is I have to believe you can make the free time, or that you have the time, or I can free your time. I’m going to be able to let you do it. And that means if you have other work, being able to hand it off, having it well documented, automating it, whatever it is you need to do in order to get that work to a point where you have the time to do this project.

[22:49] So what you want to do is think through how am I going to make the case to my manager that this is, or to whoever, that this is a valuable addition and that I’m the right person, both ability and time, to take it on. The key is you do start with an advantage. If it was your idea, then you’re the one who understands it best. You’re the one who’s thought about it most. So you should be in a leading position for that role, as long as you don’t screw it up, as long as you don’t have a bad track record or have a bad relationship or have something else going on that’s super critical.

[23:28] The other thing is be clear to ask for it. Say, I have this great new idea. You don’t have to say, and I want to make sure you put me on it. You phrase it as, I have this really valuable idea I think is going to change our business or change our team. And I am excited to bring it, to build it. I’m excited to make it happen. That messaging sets in people’s minds that you’re the person and that they have to choose to disappoint you if they’re going to give it to somebody else.

[23:59] Which most people will shy away from. If you don’t say anything, it’s like, “Oh, it’s a good idea. I’ll give it to Fred.” But if you’ve said, “And I want to do it,” then they have to decide, “Oh, well, if I give it to Fred, I’m going to tell Ryan that,” and get them just to think, like, is that worth it?

This is another rule I tell people. You do need to be a little thorny. One of the traits I think great leaders have, and this includes great engineers, is disappointing them comes with pain.

[24:31] Not that they’re jerks, but they’re not just gonna be, oh, that’s fine. Oh yeah, no, don’t worry about it. You gotta be like, what? What did you do? No, my idea. If this is how it’s gonna be, I just won’t bring any more ideas. What the hell? And then you gotta put that little pushback in there of like, this is not okay. Again, if you’re good, the threat is I will take my good ideas somewhere else.

[25:01] And this is important. Again, remember poor Alfred? He’s sitting there with his F and he’s mad. He has a good idea. If I can take away his idea and he’s just going to sit there in his cube and be mad again, Alfred gets abused. Why he gets abused? Because it’s free to me as a manager. I have to make a trade-off between Ryan, who’s pushing me for stuff, and Alfred, who’s always just willing to suck it up.

[25:29] Well, maybe I actually think you’re a little bit too pushy, and I’d like to help Alfred out. But I do have an ugly triage to do, which is, well, if I don’t cater to Ryan, he’s outta here. Whereas if I don’t cater to Alfred, that guy is solid as a rock. He’ll be here two years from now. I’ll give him some free lunch coupons and movie passes, and he’ll be so grateful. Don’t be Alfred. You’ve got to be a little thorny.

[25:59] And again, those same people are like, why do I have to do that? Why should I? Why? They love the word should. Why should I have to do that? Well, okay. In cosmic justice land where the god of your choice is making everything just, you shouldn’t. But we don’t live in that land. We live in reality land where managers have a choice. They have some pushy people that are still good, and they want to keep on their team, and they have some pretty easygoing people that are kind of going to go with the flow.

[26:30] The fact is, the right decision for me as a manager, not the just decision, but the practical one, is take a little from the people who are going to be all right about it and give it to the ones that aren’t, because that’s how I keep my whole team. And yes, for all of you who don’t like it, I have just said a little bit screw the nice people for the bad people, but I have a job to do. And so of course I also never tell myself how I just said it to you.

[27:01] As a manager, I never say, oh, I’m gonna screw all my nice people to help these 2 jerks. But subconsciously, I’m making this trade-off. And what I’m telling myself is I will get back to them and take care of them. The problem is you’re back around asking me for more stuff, and I never quite get back to them. And I meant to, and I had a good heart about it. And it just didn’t happen. And nonetheless, you got everything you wanted, and they lived with what was left over.

[27:29] And if you’re in this leftover bucket, it’s not that I meant bad things for you. It’s I had, there was this person always talking to me and I needed to get them outta my office. So I gave them what they wanted ‘cause I’m human.

Ryan:

[27:42] When I was a manager, I used to think about what’s the optimal team composition in terms of the personalities of the people? And I’m curious to hear your thoughts. Would you rather have a team that’s full of these super ambitious, pushy superstars, or would you rather have pure role players?

Ethan:

[28:04] Yeah, so I’d love to tell you I’d like all pushy superstars, but you can’t keep that many people happy unless your business circumstance is just dropping choice projects in your lap. That can happen in a high-growth scenario where everyone is against their growth limits. But absent that, and particularly now when there’s a lot more flat headcount scenarios, those people just eat each other.

[28:31] They turn cannibal and they turn cannibal toward you and each other. And it’s very ugly. So a few of them, though, the reason you don’t want all role players or all people who are very easygoing is you need those sparks of change, of ambition. You need people who are agitating for changes and ideas, I think, because in this world of very easygoing people, the team may be calm, but no one is pushing.

[29:12] And so it’s peaceful, but it’s not high impact. There’s a quote I love, or a saying I love, which is, reasonable people conform to their environment. Therefore, all progress is due to unreasonable people. People who are like, but why? But why? Why does it have to be that way? Why does it take 3 clicks? Why won’t the customer pay $1 million? Why can’t we all have hovercraft? Those are the people who push things.

[29:43] You need some of them. Too many though, and you just have chaos because everybody’s pushing in different directions.

29:52 — How to defend from others taking your project

Ryan:

[29:52] In the situation where you have a project and you haven’t unveiled it yet and you really want to work on it, I actually think a lot of engineers, they don’t worry about the manager giving it away. They worry about other engineers getting excited about their thing, the thing that they’re excited about. So in that case, how would you defend against other engineers coming in saying, oh, I want a piece of that, oh, that looks fun, oh, that looks impactful?

Ethan:

[30:20] Well, number one, that might be a good thing. The first question I would ask myself is, if my fellow engineers are excited about what I’m doing, how do I make it big enough or tricky enough or hand pieces out so I’m kind of the kingmaker? Right? So I’m like the person holding the cookie jar, handing out cookies. That’s a great role to be in, or could be.

[30:42] Now, if you’re really worried about defending, one thing, of course, is don’t tell them until it’s too late, right? Work on it, keep it to yourself, or until it’s assigned to you. The other thing is, if you had one good idea, you’re probably smart enough to come up with multiple good ideas. So can you go to your manager and be like, I have this great idea. I’m gonna work on this thing. But by the way, there’s these 2 other ideas.

[31:07] And I think people on the team would be excited about it. Whether they are or not, you’ve given some, I don’t know, other bait trail, right? And it doesn’t mean that’s illegitimate. Just you’ve given people other interesting things to work on. But from a pure defensiveness, I guess if you’re thinking about how do I keep my good work to myself, I would say outrun the competition, be a little ahead of them, be further down the prototype avenue or further down talking about it, or to where they’re not up to speed.

[31:49] They can’t keep up. The other thing, it’s a little bit darker. You probably have work to get off your plate. Think about what you have on your plate. You could get stuck on their plates. They have something to do. “I want to get rid of this.” You talk to your boss and you’re like, I have this great new idea. It’s going to make us a bunch of money or get us a bunch of customers, but I have to get rid of Project Foo.

[32:09] But you know what? Both Ethan and Sarah would be great to take over Project Foo. They’re up to speed on it. Now they may hate you. You gotta be careful. You’ll make enemies. You gotta figure out a way to say we’d have to figure out how to manage Project Foo. There’s a couple other people working on it. Maybe we can move it around and then get the boss to say, oh yeah, Fred and Sarah, I got it.

[32:35] Or Ethan and Sarah, right? That’s, I like to do things above board. I think one of the things I want to challenge about some of your mentality in these questions, there’s scarcity mentality. There’s only so much good work.

Ryan:

[32:52] It is true.

Ethan:

[32:53] There’s only so much promotion, so much visibility. But when it comes to good work, there’s a lot of it. Even with promotions and visibility, if a company wants to bad enough, they can promote whoever they want. So I try first to solve these not as a zero-sum game or a prisoner’s dilemma. I try to figure out how can I actually make them win-win. It isn’t always possible, but I at least start there of how can I find a way to make this project bigger?

[33:22] How can I find a way to, if somebody else wants in on it, say to them, great, how can we make it better and do it in half the time? Right. Or I even give them a hard time. I’ll say something like, well, okay, but this is a cool project and it’s better than what you’re working on. So show me you’re serious. What are you going to build this weekend to move it forward? And they’re like, oh, this weekend I have plans.

[33:45] Well, then sorry. This is a weekend’s project, right? I mean, you can do it. You can say it with a smile. I thought you were committed. You can get away with a lot if you can play it off as, hey, step up. Come on, I’m doing it. And there’s just a game to that because humans push each other, right? How do all those stories that end with, like, watch this, hold my beer, and then some guy doing something crazy.

[34:16] It’s usually he got pushed into it, like, “Oh, you should jump off the bridge.” Maybe you should jump off the bridge.

Ryan:

[34:20] Wow.

Ethan:

[34:21] If I did it, I’d do a backflip.

Ryan:

[34:23] Oh, I think it’s this.

Ethan:

[34:25] That’s how humans are. Another tough message about soft skills. Human skills are about dealing with humans’ weird, broken minds that are not rational. They are emotional. And that can be good. Emotions give us energy. They give us excitement. But you have to understand human psychology. And I would say to anyone listening, many of you, a lot of engineers understand poker and that story about if you can’t tell who the mark is at the poker table, it’s you.

[35:01] Well, in the game of understanding each other’s minds and understanding each other’s motivations and soft skills, if you’re not in charge, then you’re the mark, right? Because that game is happening in every meeting consciously and unconsciously. And if you’re not thinking about people’s motivations and their satisfaction and their fears, not to manipulate them, but just to understand and be able to play your cards right, you’re not in the game.

[35:31] And remember, poker isn’t a game where you manipulate each other. I can’t make you play cards a certain way, but it is still a mind game and a competition I’m allowed to win. And so that’s where I feel like you can be ethical and be a card shark and be really good at playing your hand. I’m not putting you down by beating you. I’m just beating you. You had a fair chance. You held your cards. I was better, and I won, and I get the money.

[35:58] That’s what I’m telling people to do. The other way to do it is, oh, I have someone standing over your shoulder or a planted camera. That’s cheating. That’s manipulation. Just be really good at understanding people’s minds.

36:13 — How to reject bad projects

Ryan:

[36:13] When you want to take on that project, maybe you offboard some of the stuff that you don’t want to do to other people. And I think a lot of people have experienced receiving that. So someone’s trying to give them scope that they don’t want. What’s the typical ways to protect against that and say, oh, I don’t want to take on this work. Thank you, though.

Ethan:

[36:33] If you’re in the situation where it’s been pointed to you and you have to refuse it, you’re already — you’ve already lost round one. There may be recovery, but the way to avoid that is to be the one proposing something to the team, the boss, the company, whatever. Be playing offense. Once you’re playing defense, you’re already losing. So I will answer how to defend. But the first defense, right?

[36:56] The best defense, a good offense, is to be the one putting forward ideas and talking about what could happen so that everyone’s like, Ryan’s full of ideas and he’s doing all this stuff. We couldn’t possibly give him anything. And then if I come to you, you’re like, man, I’d love to, but I’m on projects A, B, and C, or I have these new initiatives to do this stuff, and I can’t possibly do that.

[37:25] Now, if you’ve screwed up and you looked idle and you didn’t have some ideas cooking and somebody’s trying to shove stuff on you, there are a couple defenses. Number one is, hey, if this is so easy, I can’t take this on. It’s too big. It’s too much. And they’re like, oh, it’s easier. It’s just this. It’s just that. Great. You automate it. Go ahead. So pushback like, why aren’t you solving your own problem?

[37:53] Remember I said be a little thorny. The next defense is you’re not the only person on the team. So I guarantee you there’s somebody on the team who’s not going to resist. And so just be thorny enough that they go to that other person instead of you. Be the person when they come, you’re like, I’m not taking on your shit work. Who do you think you are? And then they’ll go to the person who’s like, oh yeah, I can help with that.

[38:21] That person is out there. So it’s the way you defend yourself is to be not worth it, right? It’s like a hedgehog defense or porcupine. Yes, can the tiger or the dog eat the porcupine? They can, but it’s not worth it. I’ll go find a nice mushy squirrel. And so when they come to you, you get those porcupine thorns out. And they’re like, ouch, I’ll go find the squirrel. And then there’s bunny guts all over the lawn somewhere else, and that’s your peer, but it’s not you.

Ryan:

[38:52] To say no, to give porcupine quills to your manager, they control if you get fired or not. They control your performance and all that.

Ethan:

[39:03] So if you’re constantly saying no, then you’re just not helpful. Goodbye. But that’s my point about play offense, right? You’ve got to be doing something that brings enough value so the manager isn’t always bringing you things. The other thing I would say is if that doesn’t work, try making a deal. Just look the manager in the eye and say, look, we both know this is not very appetizing work.

[39:32] Can we just agree that’s true? The manager will either be like, yeah, but it needs to be done. Or they’ll be like, no, it’s great. And you can just roll your eyes in a way that’s like, come on. So then you just move on either way, and you’re like, I’m gonna do this, but I wanna do this other thing. So I’m gonna crank through this, but the deal is I get this next thing. And again, most managers, they don’t wanna fight.

[40:00] They got other things to do. They need their team pulling with them, and they know they’re asking you to do some unappetizing work. And so they will make a deal. So there is a role to be a team player and to take on some of the stuff that needs to be done. There’s also a way actually to get credit. Let’s say your peer wants to hand stuff off, or your manager wants to hand stuff off. Go to them and say, hey, it’s been—I’ve really enjoyed getting to work on X, Y, and Z.

[40:33] You’ve given me some good projects. I know our team has some maintenance work, and I know you’re always hunting for people to do it. I’m going to spend the next 2 weeks doing whatever maintenance you want because I want you to know I’m on your side. And give me anything you want. I’m going to crank through it. And then I want to do this, or then I want to do that. But you just, if you’re gonna have to take the hit anyway, turn it into a virtue.

[41:00] If you think the hit is coming or you’ve seen a pattern, go volunteer for it and bargain up front. Hey, I know we’re buried in backlog or buried in bugs. I want to get us through that. I’m gonna do my own bug bash this weekend, tomorrow night, next week, fill in whatever, my next on-call. Tell me what is most important to you because I want to get to where then I’m free to — we’re both free — for me to work on this thing that you need, this better thing.

[41:28] And so it’s about all of these are strategies, though, to play offense. What doesn’t work is to sit in your cube or sit in your home office or wherever it is you’re sitting and hope you, like, this is the one case where hoping you don’t get noticed doesn’t work. Normally it’s— normally you won’t get noticed if you do nothing. But when I’m handing out shit work, I go look around my team like, who haven’t I seen in a while?

[41:49] Oh, it’s Alfred, the grumpy guy. All right, here we go. He’s already grumpy. Why not give him this? Well, why is he grumpy? Because he got an F on the test because his work didn’t get noticed. I actually made him grumpy, but I don’t know that. I just know he’s kind of grumpy, but he still goes along with stuff. So I’ll give it to him. As a manager, I go looking for who can I give this to? Human skills are an art.

[42:11] They’re not a pure science. There’s an art to being the thorny person without being seen as a jerk. You can be the porcupine without being a jerk. It’s like, hey man, I didn’t stab you. These are just my quills. So how do you do that? What does that mean? It means the little signs that you’re not quite happy without actually opposing stuff. Let’s say the boss brings you some extra crap work.

[42:42] You could be like, hmm, all right, this is—I will get this done, but we got to do better. I’m looking for better next time. And just that little challenge, you’re just setting that little hook of, I’m looking for a better challenge tomorrow, or as soon as this is done, I want something juicier. And you’re just setting that little hook because if they come back like, here’s another thing you need to do, and I’m like, hmm, I told you juicy, we both know this isn’t that.

[43:08] I’m going to give you one more pass. Most managers can’t take that because most humans can’t. Even though they never agreed, they can’t take going up against that expectation over and over of like, I’m gonna take him something else and he’s gonna give me shit again. It just isn’t worth it because there, again, there’s somebody else who’s gonna turn into bunny guts when I eat ‘em. And I also know there’s people listening are like, this is so unfair and I’m so sick of being bunny guts spread on the lawn when the wolf got me.

[43:44] Yeah, change. Become the porcupine, then become the bear. And it’s okay. It’s a learning process. Everybody was bunny guts at some point in their career because they didn’t know better.

Ryan:

[43:57] I want to—

Ethan:

[43:58] He’s losing it. He’s got this vision of a slaughtered field of rabbits.

Ryan:

[44:05] Oh God.

Ethan:

[44:05] Okay, we’re gonna come back. I’ll get a new analogy. I’ll save you from my analogy.

44:10 — How to be first for promo

Ryan:

[44:10] Okay, the next situation, a little bit darker as I mentioned, but also realistic, is imagine you want to get promoted but there’s only one available slot. Maybe there’s a promo quota, or maybe it’s one of those roles where there’s only one manager role and you kind of want it. How do you make sure that you’re the first in line to get that?

Ethan:

[44:35] So first, honesty sometimes is not possible. Sometimes, I’m not gonna promise people things that are impossible. If you have several more senior people in your team who are qualified and have done a good job expressing their interest, the right thing to do is get out of line, go somewhere else, go somewhere where there’s more opportunity. And I mention that only because some people—I always make fun of the post office because I can’t imagine how you move up in the post office.

[45:01] Like, either you deliver the mail or you don’t, and then there’s postmaster and there’s one of those, and they stay there until they retire. I don’t know what the hell you do at the post office. So if you’re at the post office metaphorically, get out, go somewhere that’s growing. Now, if it is growing and there’s gonna be spots, you have to be sure managers aren’t mind readers. They don’t know what you want.

[45:24] So you’ve got to make sure they know you want the role. The second thing is you can ask them, “How can I be your first choice for this role?” Or, “What would it take?” A great way to phrase that is, “Under what circumstances?” Like, “What would lead you to choose me?” Even if you have to be kind of absurd, like, “Hey, Ryan, against all odds, what would cause you to bump me to the front of the line and put me first?”

[45:46] What would that have to look like? Why do you ask it that way? Everyone can answer that. Everyone can say, well, this is what it would take. And then at least you know, and you can negotiate those criteria and say, what about this? What about that? The second thing, though, is who gets promoted is who’s indispensable, who I can count on, who I know is going to ride to my rescue when there’s a problem.

[46:10] So what I would do is I’d say, if I want to jump the line, if I want to make sure I get there, I have to jump on crises.

Ryan:

[46:15] These.

Ethan:

[46:16] When there’s a fire, I have to jump on it. Why? Doing your regular job well, there’s a lot of people doing that. In a crisis, when a system is down, when a customer is angry because they have an outage, who steps up to handle that? And who is technically brilliant and maybe a leader, they get noticed. And the question I’m asking myself at promo time is this person I’m about to put on my team, are they going to be the person I can count on no matter what?

[46:54] Are they going to keep me out of trouble? So you have to show that trait. Now, what that usually means— crises unfortunately rarely happen conveniently between 9 and 5. They’re always on a weekend or holiday. So you’re going to have to make some sacrifices to do that. But to show you want to have a discussion with your leader, what’s keeping you up at night? What do you need most? I’m going to work on those.

[47:21] I just spoke to someone. They had a great rule. They went to their manager and would have a chat with their manager and say, “What are your 3 biggest problems?” And their manager would always— managers always have problems. They can always say, “I have these 3 problems.” They would say, “Great, which one’s worst?” And they say, “Oh, this one.” Say, “Great, I want to work on your worst problem.”

[47:40] How do I want to go solve your worst problem. How do we make that happen? Well, of course, somebody who’s shown me repeatedly they want to solve my worst problem, who else do I want on my team? That’s how you get there. It is hard. Okay, you’ve asked a question. I want to be clear. I’ve answered how do you get the spot. What a bunch of people actually wanted to know is, how do I get that spot without putting myself out too much?

[48:09] That I can’t answer for you. There isn’t, I don’t know, bribery. There isn’t an answer for that one.

Ryan:

[48:17] In that last bit there, you mentioned someone, he asked, what are your worst problems? I wonder if there might be some unexpected opposite effect, or what I mean is if I was a leader and someone was coming up to me and overly, obviously eager to try to get promoted, almost kissing up to me and saying, hey, what’s your worst problem? Okay, I’m going to go solve that. It might make that leader feel weird.

Ethan:

[48:46] It could. I mean, again, this is about all personalities are different, and you have to figure out how to approach each personality. The question is the same, which is: what are they going to value enough to invest in me and enough to really get out on a limb to try and help me? How do I set up a win-win deal where I’m helping them and they want to help me? And we can keep pushing that to be more and more extreme, that just like you’re pushing me with darker and darker questions, you don’t normally jump straight to the end.

[49:22] You build up. So you start by doing good work, just being solid, really solid. Then you get really good. Then you start asking your manager, what can I help you with? What is it you need done? I had this idea, so I just did it and I thought it would help you. You just build. And then you start asking like, hey, I wanna grow. And it seems like we have a great working relationship. Could you gimme some tips on how to grow?

[49:49] Could you give me some things that you think are challenges I need to work on? Is there something special you need done? And then after you do that, you deepen it again. And you’re like, hey, I would really—for both of us, is there a role where you need a right-hand person who’s your go-to in a crisis? Because I love hard problems. I love being challenged with crisis. And I’m sure you have some.

[50:17] Is there a win-win where I jump on those? It’s good for me to have that chance and it’s good for you. You know, there’s somebody who’s always going to step up when you need it and you’ve built your way into it. So it’s a little bit— you’re kind of asking the classic frog in a pan thing. If you take your manager and throw them in the hot water of like, hey, I want to be promoted, how can I do anything you need so that you want to promote me?

[50:40] A lot of people are gonna be like, creepy. Okay, you got to boil that water a little slowly. And this is not manipulation, it’s relationship, right? If you’re dating, you send someone a note or express interest, you ask them out, you go to dinner, there’s a process of getting to know someone. There are a lot of analogies between different types of relationships, and there’s a process and you’re dating your manager in a way to build a relationship.

[51:19] It’s not because you’re going to get married, but it is a work marriage in a way, for a while anyway. And that’s okay. You build that relationship and then you hold a privileged position. This is something you haven’t asked. You can’t ask this question. People would come to me and say, why do you treat so-and-so so well? Or why do they get all the benefits? Or they would also say, why don’t— why didn’t you promote me?

[51:48] And I always, when they say, why didn’t you promote me? I say, why didn’t you earn it? Why didn’t you promote yourself? I want to move you up. Show me something. And if you’re asking about this person, oh, I’m happy to list all the ways they are contributing. And if you want to do the same, for the same period of time, I’ll put you where they are, right? Because they’ll be gone, by the way.

[52:11] They’re a climber. They’re gonna either move up in our company or move out. There will be a hole. Get moving. So I was a different boss, I guess, but I always tell people, like, you want a promotion? Here’s a piece of logic for you. Some bosses aren’t smart enough to figure this out. I want the most senior, most promoted team I can have. Why? Why on earth would I not want the best people on my team?

[52:33] So if you can rise to be at a new level, I want to pay you that and have that because I’d rather have a senior person than a junior person. Now I have a budget and whatever, and I have to fight uphill, but I have no problem fighting up to my management, saying, look, yes, I have an expensive team. Why are they expensive? Because my team is damn good and you know it. And I’ve moved people out of my team to other teams, and now they’re leaders on those other teams, and you know they’re stars there.

[53:02] We have a star organization. We build stars. That costs money, but it’s good for you. And I can tell that with a completely straight face and look the financial officer, whoever, in the eye. Another story. I’m coaching a company right now on this method, and I wrote the leader there. He’s the chief product and technical officer. I wrote him and I said, I can make your team higher performing, but it’s going to cost you salary when they step up.

[53:29] They’re going to want to be rewarded. Are you ready to pay for performance? So this is just somebody I’m coaching and I’m telling him, I can raise your team’s performance, but it’s gonna — you’re gonna have to hand out more stock options. Are you ready? I did that internally all the time. That’s how you make it work.

Ryan:

[53:48] When someone would say, “Why didn’t you promote me?” you would say directly back to them, “Why didn’t you promote yourself?”

Ethan:

[53:56] Absolutely. Those words, right? Why didn’t you promote me? Why didn’t you promote yourself? Where is the work? Where’s, you didn’t come to me. You didn’t get a special project from me. We didn’t make a deal and look each other in the eyes. You do this, this, and this and deliver. And that’s the bar. Hey, there is one engineer I’ve written about this. I made a mistake early in my career.

[54:22] I still regret this 20 years ago. An engineer came to me, he made a deal, and I failed to deliver. It was not intentional. I was new to Amazon. I didn’t understand the system. And by the time I went to get him promoted, I was too late and had missed the window. And I didn’t even know there was a window. And he rage quit. And he should have, unfortunately, because I blew it. But that was user error, not intent.

[54:50] And I never made that mistake again. Anyone I promised I would help them move up, sometimes it was when I said, sometimes unfortunately it took longer, I always got it done. But the people who just whined, they’re uninteresting to me. And I always tried to be clear to people the door was open. The other thing about promotion for everyone, no one ever in life said, you might be one of the few exceptions.

[55:14] I know you had a remarkable career. Very few people, maybe even not you, ever said, “Oh yeah, I got promoted way too early. They gave me a bunch of stuff I wasn’t even expecting.” Almost everyone in life is like, “This took too long.” That’s gonna be true. Everyone hates the timeline because who imagines ourselves to be best? It’s always us.

55:35 — How to handle managers that dislike career growth talk

Ryan:

[55:35] So you mentioned that relationship building with the manager. There’s this game we were talking about, on how you get promoted in the system. Some people don’t like the game to the point where you wouldn’t want to talk about it directly, and others are fine with being very transparent. Sounds like you’re the type of manager. Yeah, I could go to you and say, “Hey, I’m this level. I want to be this level. What does it take?”

[56:01] And you would just answer.

Ethan:

[56:02] I would.

Ryan:

[56:03] I could imagine there are some managers, though, that kind of push it off, or maybe it’s an uncomfortable conversation. What would you say to someone who’s under a manager that doesn’t want to talk explicitly about promos?

Ethan:

[56:16] Part of me wants to say find a better manager. Find someone who’s motivated because sometimes those managers aren’t ambitious themselves. And so they’re gonna have trouble relating to someone who wants to move up. But if that’s your situation and you have to work with someone like that, I think then what you have to do is look at who they’re rewarding. Look at who have they promoted and why. And you might think, oh, well, how do I know why?

[56:47] Well, one example may not show you, but if you see several people who got moved up under them, you can find a pattern. Who are they moving up? And then what I would say is if they can’t talk about it, number one, you might be able to talk to some of those people and say, like, I see that Ethan promoted you. How did that work out? How did that come to be? Or I see you got to senior manager or senior engineer.

[57:08] What happened? Figure out what they’re rewarding and go be that. And that’s a slower process. It may not be as comforting, but figure out their language. Everyone has a language to express this. You have to figure out how do they have that conversation? Again, I would go talk to the people that did get promoted and say, did you have any kind of conversation? Did they ask something? Did you write it down in your annual review that it was a goal?

[57:38] Like how I try to find out how did the manager make that decision? And then I would go conform to that pattern as best I could because that’s what’s going to work without being as direct as I am. That said, if you go do all this investigation and find out they basically didn’t promote anyone or there is no pattern, then you’re back to my, there is no system to work in there. You have to get to a place where there is a workable system that if the manager hasn’t promoted anyone or they’ve promoted very few people and very late, then either you accept that, that it’s going to be a little bit random and it’s going to be when they get around to it, or you get out.

[58:24] Here’s a trick. AI has made this super possible. It used to be harder. That manager communicates with people. They write, they speak, they whatever. Grab a bunch of their communication, throw it all into an AI and say, analyze this person’s communication pattern. I have this goal, which is I want to ask for a promotion. I’m very direct. They don’t seem to be. How do I approach this person? AI is amazing at personality typing them and telling you the words and methods to work with their ability.

[58:56] This, by the way, is a hack for anything at this point. Anyone that you have some email chains with or some of their public writing, grab it, tell AI this is a bunch of communication from Ryan or from Ethan. I want this thing, whatever it is. How do I approach them in order to get it? And it will answer it for you. And that’s like, now, if you’re on the far side of that, right? I’ve just told a bunch of people how to approach me.

[59:26] If there’s a clever person listening, they’re like, Ethan has lots of blog posts and I want this from him. So I’m going to get these emails now in the future where people won’t say, oh, I saw you on Ryan. Here’s my secret scripted email, but I’m going to get that. How do I defend myself against it? Well, one, you have to know who you are and what your boundaries are. Two, though, I think there will come a point where we will have to have our own AI countermeasures.

[59:53] So that’s a little futuristic, but the ability of AI to help me manipulate you is gonna get really strong. So right now I’m not saying manipulate, I’m just saying use it to be educated on how to approach that person who has a different personality than yours. But the manipulation is coming.

Ryan:

[01:00:13] This is a common situation I’ve heard and seen people experience, which is they talk to their manager about that promo they want, and the manager doesn’t say, no, you’re so far and here’s what you need to do. And they don’t necessarily say yes either. There’s this gray area in the middle where they dangle this carrot, but they don’t exactly give you the full story. So they might say, oh yes, you want to get promoted, that sounds like a good thing.

[01:00:45] You’re gonna need to do more work, and I want that for you, and we’re gonna do it. And then if you ask a hard question, when will it happen, or what are the concrete steps, they’ll go, okay, let me get back to you. Or what do you do in that case where it’s this gray area carrot dangling, but it’s very unclear if the promo is concrete or not.

Ethan:

[01:01:07] Yeah. So managers don’t like to be pinned down. There’s both good and bad reasons for that. What do I mean good and bad? Good reason is managers don’t have final control over promotions. So part of what they’re thinking is, I don’t want to promise Ryan something that I have to get through a committee. I have to get through a panel. Let’s say Google, for example. Google, at least in the process they had at one point, there’s a promotion packet and it goes to all these other people and the manager isn’t really there.

[01:01:36] And it’s this panel that decides. So I may truly want to help you get promoted, but I can’t answer for you, like, when is the panel going to say yes? So that can be one reason managers are legitimately fuzzy. The other reasons they’re fuzzy are they’re not sure when you’re going to be ready. They don’t want to be cornered. They don’t want you to think they made a promise. And one of the things that’s a problem is if I say there are these 4 things, I don’t want you coming back to me like, I did exactly those 4.

[01:02:11] I want this today. Because what if I came up with a fifth? Or what if I think one of the four sucks and wasn’t very good? So I want to preserve some room. The bad reason, of course, everybody fears is I just don’t ever really intend to do it. I just want to keep moving that carrot and keep you working and working and working. So how do you disentangle these? Well, first, if it’s a system problem, the way to disentangle it is to say, look, I know you face a panel.

[01:02:39] I know that you need our skip’s approval. You need this panel’s approval. I’m not asking for you to guarantee me that we’re going to get through the panel. I want to know what it’s going to take for you to be ready, to be enthusiastic, to go make my case. So you try and back the question off to something they can say yes to. Because if I face some panel, I can’t guarantee you a result.

[01:03:03] What I can do is guarantee you that I will try. So, for example, when I was ready, when I was hoping to become a vice president and I had had these discussions with my vice president, he came to me and said, Ethan, on this cycle, I’m going to do everything I can. I’m going to put you up, and I’m going to put my reputation out there, and we’re going to see if we can make it happen. He was real clear though, like Jeff Bezos approved at that point all the VP promotions.

[01:03:29] He could go fight for it. He could line it all up, but he couldn’t guarantee me that Jeff would say yes. So that’s how that got handled. That’s one way. Then for these cases of trying to pin them down where they want wiggle room, you have to say, look, I understand that answering me or telling me what you’re willing to do is still dependent on me delivering and that new things could come up. But understand, I need help with the fact I have no clarity.

[01:04:07] I don’t have any date expectations from you. I feel like it’s a moving target. Can you help me with that? As long as. What can you do for me? What— you try and draw them into your emotions. Imagine what it’s like to sit here, to hear that I’m a good performer, to want to work hard to achieve a goal, and to kind of have an amorphous target I can’t see where you’re saying, well, it’s the right direction.

[01:04:36] Can you help me out? And you can even say, I know that you’re probably not trying to leave me in the dark, but what can you do to shed some light on that? These are all variations. I would recommend people read the book Never Split the Difference by Chris Voss on negotiation, because it’s all about the psychology of how to get other people into your framing. And so you get them talking about—you find ways to draw them out.

[01:05:08] You ask them questions like, so tell me who else has succeeded, or tell me what success would look like, or tell me how I can measure myself. You can also ask them— this is totally for the people who’ve read Chris Voss, they’ll recognize this— you can say, when they say, well, you should just keep working towards it or whatever, you say, how can I do that? And that makes it their problem to explain to you how you can feel.

[01:05:36] How can I feel good about working towards such an unknown goal, an unknown destination? That puts them on the defensive to solve your problem. So last thing, it’s a manager who just keeps stringing people along. Well, you’re going to have to get out from under that manager or find a way to get a lot of leverage over them. But the way you figure that out is you look at what they’ve done for other people.

[01:06:01] Are they actually promoting people, or are they leading everyone down a path? And if you ever wonder, am I just suspicious or whatever? Again, it’s look around, talk around. What are they doing with others? You alone may feel misused, but if the evidence is no, people in this org are getting moved up and they are getting raises and opportunities, then you have to figure out how to earn it. And if nobody’s getting anything except strung along, you have to get out.

01:06:30 — What if your manager is in the way

Ryan:

[01:06:30] So we were talking about limited number of spots, quota, or promo. And the assumption is there’s these other peers that you’re competing with.

Ethan:

[01:06:39] Sure.

Ryan:

[01:06:39] But there’s also a form of that where you’re not necessarily competing with your manager, but there’s a limited spot because your manager needs to move up so they can bring others along with them. Yeah. And so maybe the leaders in your org, they’re not moving up, maybe they’re not ambitious or some other reason. What would you do in that case where you want to be in line for a promo and your manager is actually the one that’s in the way?

Ethan:

[01:07:07] There’s always cases. One case is the manager is ambitious but can’t get there for whatever reason. First question there is, can you help them? One of the deals that definitely worked for me that I made with some of my stars is like, hey, I want to move up. You want to move up. If we can do this thing together, we’ll both move up. And I enlisted multiple people in helping me get promoted so that I could promote them or vice versa.

[01:07:33] They got promoted, and then I could. Either way, it was a two-sided equation. So one question I would ask is, is there something you can help your manager with? And you can just talk to them about, “Hey, I’ve shared my career goals. I’ve been wondering, it seems like maybe you’d love to move up too. Is that true? And is there any way I can help you?” And that will make you a super ally unless they’re those ones who are uncomfortable not talking about it.

[01:08:03] Again, that’s tricky. Then you can just go to weird language of, well, what’s rewarded in this company and how can I help our group be more rewarded or something a little more oblique. Now, the second problem is your manager doesn’t really— there are some people who don’t want to move up, or they’re just not willing to push for it, or they don’t think it’ll happen. They’ve either given up, or they’re ambivalent, or they’re one of those people who figures it’ll come when it comes.

[01:08:35] And you’re more impatient than that. That may be a case where you have to get out from under them to a different situation, or you ask them, you have a different discussion with them and say, hey, I’d like to move up. If we can’t create that opportunity in this team, will you help me find it in another org? I could be a great ambassador for your leadership and our team elsewhere. Are you willing to help me rise or to find a spot?

[01:09:07] And one of the things that can work to your advantage is a lot of the managers who are a little less aggressive are more into taking care of their teams. They’re more into, well, the reason I’m not so aggressive is I’m at peace helping others, or I really believe. And so they’re more downward focused. So some of them are willing to actually help you elsewhere. Now, there are ones who are like, no, I need you here.

[01:09:35] And if I lose you, my chance of moving up is even worse than it already is. That’s tough. That, however, is your leverage, where you can say, look, if that seems to be the case, you can say, hey, here’s the honest truth. My favorite words are, my career is very important to me. No one can argue with that, right? My career is very important to me. And so I’m going to move up. I would love to do it with you here.

[01:10:06] But I’m gonna have to do it. And that’s just a way— you’ve expressed your first preference, but you’ve also expressed a willingness to make changes. And that’s just a way that— that’s essentially the polite way of saying either you get it done or I’m going to someone who can. But you say it in a way that they can’t like— don’t threaten me. You just say, look, my career is really important to me.

[01:10:31] And I have to, I’m gonna grow my career somewhere. I’m in a season, I’m gonna tell this story like a younger employee. I’m in a season of my life where I have this window, my wife and I, my husband and I, my partner and I are gonna start a family. And I only have a few years to really focus on work. So I’ve gotta move up now. I’ve gotta do everything I can to have a fast career while I have this moment.

[01:10:56] And I really wanna do that here in this org. If we can make a path for that, that’s where I wanna do it. But I wanted to talk to you about it honestly because I do have to do it. And so if it can’t be here, I’m gonna have to figure something out. And you put on your puppy dog eyes like, that’s a terrible outcome. And then you shut up and you let ‘em speak. And the way I told that, no one can be mad at you.

[01:11:21] You just told me you’re willing to work really hard for a few years. You’ve got this nebulous, we’re gonna have a family thing. I don’t know, maybe you are, maybe you aren’t, no lying. But if you haven’t totally ruled out you’re ever gonna have kids, that’s the easiest excuse in the world or whatever. I have these few years before I have to move home to country X to take care of my aging parents.

[01:11:41] There’s a million variations of it. This story about why you feel urgency now and you really wanna do it. We’ve got a great relationship. I really enjoy this work. I’d so love to contribute more in this organization, but I do have to advance my career. And then you just wait and see what they say.

Ryan:

[01:12:02] Yeah, this seems like another one of those gray areas because in the other case, the gray area was selling yourself. In this case, it’s, I guess, in a negotiation because I could see someone who looks at that and goes, oh, that’s not fully accurate. Or you don’t know if you’re going to have kids or what. You’re using that as a tool to—

Ethan:

[01:12:22] Yeah, I don’t think most people are sitting here in a podcast chair, thinking about what people might be thinking about. In the moment, they’re mostly taking in, okay, what am I being told? And I’ve got all these other worries. But even if they’re thinking that, the message is still clear. If you were to come back to me and say, well, you don’t really know your future.

[01:12:43] The future is unclear. I can always go back to, this is how I feel. You can’t argue with what I feel or what I believe, right? Nobody’s going to get into, well, you don’t know if you’re going to have kids. No one’s going to tell you that. So that’s what makes this—you can call it a trap, but that’s what makes this a trap. There are certain things you can’t say to people.

[01:13:11] And you can’t tell me not to care for my aging parents. You can’t tell me not to plan to take care of my family. These are totally off, you know? And by the way, if they do say that, you’ve got someone you got to get away from. Like, wow, your family’s really your problem. Okay, noted. Thank you so much. Door, please. Check, please. Good managers, clever managers will be like, all right, I see what’s going on.

[01:13:38] I see the negotiation we’re having. I see, I’m onto your game, but I also see that puts them back in my camp. We’re like, okay, I see your game. What do I want from you? I’m thinking now, okay, he’s listened to Ethan and Ryan’s podcast. He knows the game. Well, as a manager, I know the game too. What do I want from you? And what’s it gonna take? What do I want you to deliver?

[01:14:05] So yeah, what you keep asking is effectively, what do I do with people that don’t like ambition? Remember, there’s proper ambition and there is pushing too hard. I have had people come to me. They’re brand new out of college, and they’re like, I’d like to be a VP in 2 years. How do I do that? Okay, that’s a reality check problem. I don’t know. Is your last name Bezos and I didn’t notice?

[01:14:34] Otherwise, unfortunately, that’s probably not going to happen. Let’s talk about what could happen. And then if they’re like, no, no, no, VP, I’m like, okay, I see, door, you’re a loon, I don’t need it. But for normal ambition, there are people who find ambition a dirty word. Why should you worry about this? And the work is pure and just work and it’ll be yours eventually.

[01:15:01] And I guess those people, I’m gonna be really blunt, they’re probably not listening to this podcast because the people you and I attract want more. And if you have a boss or a manager who is busy being very zen about like, oh, it’ll all come in due time, you’re in the wrong place. Go start your own thing. Go come work for me or one of my friends. Find a place because there’s so many hard-charging people.

[01:15:30] Go find them. Now, some of those people will try to work you to death, and that’s a different set of guardrails. But go find someone who shares your basic desire to get somewhere in life.

01:15:43 — Did he ever have overly political reports

Ryan:

[01:15:43] So when you were a VP at Amazon, and I mean, you’re very cognizant of this game, did you ever have reports coming to you employing these tactics? Something where you thought, okay, this is polite messaging on top of a hidden message, which is, I want something from you.

Ethan:

[01:16:04] I had one or two people who were really good at it, but honestly, most people, maybe because I was very transparent, people weren’t. They were just honest with me. This is what I want and how can I get it? And I’d be like, here’s the bill. But I did have some people who were very smooth. I also had a couple people, I mean, I definitely caught some people lying, right? Just trying to run a game on me, and I fired them.

[01:16:32] When I say running a game, they were dishonest. They were actually claiming things that weren’t true. Those people got gone. The last class of people I want to talk about, honestly, I had some very ambitious people in one team I can think of that I couldn’t give opportunity to fast enough for their desires. We can argue about whether or not they were quite qualified, but they went to other companies that saw more value in them, and they had, or they had wildly successful careers.

[01:17:07] So sometimes even a boss like me runs out of opportunity because I attract these hard-charging people and I encourage them. It’s okay if they leave. Meaning sometimes those people would come to me and ask for something and I’d be like, it’s gonna take 6 months. And I’m thinking one guy is like, Samsung will make me a VP tomorrow. And I’d be like, you should do that. And it was okay. This one guy went and he went to Samsung, he got a huge role.

[01:17:37] It was a better job for him. That’s okay. But your question, did I see people using these tactics? Not as much as I’d like. I’d rather more people were trying to figure out how to grow their careers because I want to grow people’s careers. The ones I hate are the ones who I feel are asleep. They don’t want to work that hard, or they’ve got some issue that they’re angry about, but they’re passive-aggressive and they won’t put it out there so that I can address it.

[01:18:07] Or not. So I can tell them, okay, I hear your issue. That’s not gonna change. So now it’s accept it or leave, and that’s okay. Either accept it or leave. They’re both fine. Or, yeah, I can fix that. Here’s how we’ll fix it. I feel like even in a lot of high-performing workplaces, a lot of people are kind of stumbling around blind with no real plan. Some of those people are happy that way. So what I try and remember is, some people are in a season of their life where they just kind of wanna do their job and be left alone.

[01:18:38] Those are the people that the top performers get to pass all their mediocre work to.

Ryan:

[01:18:43] Yeah, I remember there was this tweet that went really viral. It was just an open-ended statement saying something like, why is it that you never hear the highest performers complaining about their manager? And implicit in that is that they leave, that high performers have optionality and they just go and find a better situation. You mentioned that if someone lied to you, you’d fire them. But when you fire people, you have to collect all this evidence of underperformance and kind of chase them down for some time.

[01:19:18] And then how do you fire someone for lying?

Ethan:

[01:19:22] Well, number one, if you could really prove the lie, you probably could terminate for dishonesty if you had ironclad proof that it was a lie. But sometimes you know something’s a lie and you don’t have it. I’ve written before that a manager in good standing at any level can get rid of any one employee, and there’s 50 ways to do it. So you, like, dark. First thing I can do is just start giving you crappy assignments.

[01:19:45] The second thing I can do is just say, Ryan, I know we’ve talked about promotion. I got to be honest with you. I don’t really see that coming. It would take a lot of change. And I think you better reset your timeline to 3 to 7 years. So you’re probably going to quit. The third thing I can do is rate you crappy. Communicate like, I’m seeing this as, pick your system. But this is, right now I’m seeing you tracking below average for the year.

[01:20:14] And I just want to tell you upfront, I see a low performance review coming, and you’re like, wait, I delivered this, this, and this. I’m like, yeah, but here’s my list of seven other things you didn’t do. I can always drive somebody out. And if you go to HR and you’re like, yeah, he’s turned on me, he’s got all these unrealistic things, the fact is, I’m known as a good manager and you’re somebody below me.

[01:20:38] Their HR’s job is to side with me unless I’ve done something illegal. So they’re going to say, uh-huh, uh-huh. It’s going to be very tough. And again, people hate this idea. This is a flaw of our human society, which is that a manager in good standing, if they do get it in for one particular person, they’re going to win that. And theoretically, at least, an innocent person can be totally screwed over.

[01:21:05] What normally prevents that is good managers don’t want to screw over good people. That’s pathological. Why would I want to get rid of a good person? But if someone’s really cancerous in my organization or dishonest, I have so many tools. Now, I can also start gathering all this evidence if I want to, and that’s not a bad idea, just in case I need it. But there’s so many ways to communicate to you that your life here is over and it’s only going to be crappy work from here on.

[01:21:36] And I can also ride you like, “Hey, our workday starts at 10. It was 10:05 this morning.” And just like, I can be on you for everything. And the worst on-calls and the most tickets. It’s very easy to make your life miserable, and it’s very hard to prove. Like, oh, Ethan, what are you gonna do? Go to HR, who doesn’t know shit from shit in this context, and be like, Ethan’s giving me the worst tickets.

[01:22:07] What? Like, but how hard? Let me just ask you how hard this would be. Okay, we’ve got a 500-bug backlog, and I go through it and find 20 really crappy things to work on and say, I think for your next on-call, these should be your priorities. By the way, I’ll be measuring you to them. Hint, hint. If you don’t do it, it goes in my evidence file to fire you. And they’re just nasty. And let’s assume I’m technically incompetent and I can’t do that.

[01:22:36] There’s still a way to do it. I go to Fred and I say, Fred, I was wondering in our bug database, what are 100 tickets you think are pretty useless and we should just close them? Innocent request. Now I take this 100 and I come to you and say, I’ve been thinking about some of these tickets, and I need some data on these 20. I want you to prioritize working on these 20 picked from that 100 and get them all done this week and tell me what was the total value of them.

[01:23:06] And if you ever come back and say, “Those are terrible tickets. How could you do that to me?” or “I even know you asked Fred what were a bunch of useless tickets,” like, yeah, I was double-checking Fred’s judgment. You still had to close all the tickets. I have a defensible thing. What I’m going to do now—thank you so much, Ryan, for plowing through those—I’m going to close the other 80 with no resolution because you’ve shown that Fred was right.

[01:23:28] But I’ve still jammed 20 lousy tickets picked by Fred down your throat without knowing anything about what’s going on. I can do this all day. You throw me scenarios, I’ll find another way to come around HR and make your life miserable. So what I do, to summarize, if I really want rid of somebody, I let them know it’s over, right? With words like, I just wanna level with you. I see after recent events, an allusion to me catching you lying, even if you don’t admit it.

[01:23:58] After recent events, I gotta be honest, I’m seeing this as a challenging year. And I know you’ve asked me about promotion, I think you might want to reset your timeline. That’s all I have to say on that. And then I start making clear that the punishment’s going to keep coming. You will evaporate. I just have to wait a little bit and you’ll either evaporate by quitting or getting another job, or you’ll evaporate by getting pissed at me and doing something else outrageous that I have instant cause.

[01:24:30] Luck again, though, I want to emphasize: sane bosses don’t do this to good people, but it’s a tool, and that’s the way our world of fallen evil humans works.

Ryan:

[01:24:43] Yeah, and this is another one of those gray areas, though, because in the case where you’re pursuing someone that obviously lied, you are kind of just, and you’re outing someone that’s bad. I guess it would be very unfortunate if you just didn’t like someone or there was something that didn’t quite click with you with someone?

Ethan:

[01:25:03] Well, there’s another way to handle that. Okay, so let’s assume you and I don’t click. It is, again, everything is a gray area in human relationships. Let’s assume you and I don’t click. And let’s even assume I’m a good person and I’ve tried to figure out how to work around it. I may have even talked to you and said, “Your style is you tend to whatever, some personality trait. You tend to look at the downside before the upside, and I really want to run a positive upside team, and I need you to be more upbeat.”

[01:25:32] You think you can do that? And you’re like, yes, I’ll try. But the truth is you can’t. I can just come back to you. The nice way to do it is say, Ryan, look, we’ve talked before about compatibility. You and I just, we’re not that compatible. I would like to help you find a place where you’re going to thrive. Would you be open to that? And, at the end of the day, it can be internal, it can be external.

[01:26:04] I will make introductions. I will help you. If you take me up on that, I just help you find a new place with a new fit. If you don’t take me up on that and you’re like, no, I really want to be here and I think you’re unjust, you need to be my way, blah, blah, blah. Then I’m like, well, I tried. Now I just go back to my million strategies to get you to decide you want to take the offer to move along.

[01:26:26] Why is that potentially justified? I’m not going to claim it’s totally justified, but the fact is we all have to work together. And if you’re too much of a pain in the ass to work with, too much of a disturbance to my zen, frankly, the corporate hierarchy has determined that I’m the important one. That’s why I’m the boss. And again, there’s people screaming, “How can you possibly say that?”

[01:26:50] Well, that’s why it’s an org chart and it goes up at the top. Okay. And I deal with the same thing above me. Either I make Bezos or whoever happy or I’m expendable. That’s our system of life. And we don’t live in a perfect world. I wish we did. We lived in some perfect world where that wasn’t true. But I have a whole team to run, and if you’re sucking up too much of my energy, I have to get rid of that.

[01:27:19] Now, I can think of some people who annoyed me enough I encouraged them, like, maybe we need to find you, you know, maybe let’s work together to find another place that’s like a more natural fit. And I think that’s fair because probably if we’re that different, you’re not loving it. It’s not great for you either. And so, you know, this is a little bit the breakup line of like, oh, it’s not you, it’s me, but you still need to go, like still pack your shit and move out.

[01:27:46] That’s the gentle way though that somebody doesn’t end up fired. And I can totally find—look, I probably have an opinion of some manager I think who’s just like you. I probably don’t care for them that much. I probably think, wow, they operate in this weird way I can’t stand, but those two are going to be perfect together. Maybe they will.

Ryan:

[01:28:36] As you said, a manager can fire any one employee that they wanted. Yeah. And HR is gonna side with the manager.

[01:29:02] Is there any edge case or any weird situation where the opposite could be true, which is, indeed, the engineer is in the right and they’re trying to get rid of an unjust manager, and they’re working with HR? Yeah.

Ethan:

[01:29:19] So over 50% of this is gonna be who goes to HR first. Because you get to set the framing, you get to make the complaint. So one of the things I would totally do if I’m the manager is before I started saying stuff to you, I would send a little note to HR that says, hey, I just want to let you know, I’ve noticed some challenges in Ryan’s performance. I’m going to start working on them, ABC, whatever.

[01:29:44] I just set the framing. And that way, when you come to them to complain, you’re running into this wall that I’ve already framed you as a non-performer. Going the other way, if you’re the employee, you want to be the first one to HR about the situation, and you want to frame it as not, I have a terrible manager, but you want to frame it as, I’m really trying to do great work for this company, and I’m really struggling because of fact, fact, fact.

[01:30:17] Citing behaviors of mine. So you never actually, at least, open the conversation by saying, “Ethan’s terrible and you need to fire him.” Instead, it’s how these factual situations—again, facts can be viewed many ways. You view them your way and get them out there. These factual situations are limiting your ability to produce and that of your peers. The second thing is, if you want to win one of these uphill battles, you’re probably going to need at least one other person to verify what you’re doing, like verify the problem.

[01:30:51] The third thing is it sure helps if you’re a superstar, right? Because if you’re Joe Average or below average, no one’s going to go out on a limb. You really need to be standing out enough that maybe HR already knows you or you’re top rated and they’re like, oh, a top rated employee or one of the people, or maybe your skip already knows you or your name is on this tool, right? Those kinds of things can influence HR.

[01:31:20] The last thing, of course, that you hope for is bad manager is this huge category. Is there a smoking gun where I’ve done something illegal, patently unethical, somehow unacceptable to you or someone else that can be documented? Or not. If the manager is generally viewed as well-performing or has a good relationship with their boss, it’s going to be very, very hard to get rid of them. So I’ve had stuff come to me from employees that have led me as a skip level to terminate a manager, but it’s because it was several people over time, and the facts added up to show my manager was actually doing things they shouldn’t.

[01:32:14] And when I say shouldn’t, not just low performing, but unethical or just really not super untalented. But that was usually my observation as well. Then everyone has this fantasy that justice is going to be served. And you’ve asked, does it ever happen? Sure. It happens in the movies and it happens one in a million, but in real life, it’s just so much easier to leave. And what will actually happen is you’ll leave and three other people will leave.

[01:32:47] And then finally the management will be like, oh, I’ll tell you a story. I’ll exemplify this for you. One of the people I coach, can’t say where, he was telling me, I have this real problem. I have this manager I like, but I’ve been—they keep losing employees. People keep quitting their team and saying it’s about the manager. And I’ve been trying to coach them to change and they haven’t been changing.

[01:33:14] What should I do? And I asked this manager, well, how long have you been coaching this person? And he said, 18 months. And I said, hold on. You’ve had employees in your organization quitting and pointing to this manager for 18 months, and you’ve been trying to coach them to change, and they haven’t changed, and you haven’t done anything. And they’re like, yeah, I like them. I want to see them succeed.

[01:33:45] I have this hope for them, and they’re nice. Okay. What about your employees who quit? And by the way, if this person didn’t work for you, but you were like, if I had told you the story, what would you tell me to do? Like, oh, I’d tell you fire that manager. I’m like, right. Well, why aren’t you doing that? Well, like I said, I like them and I don’t have a problem with them. This is why it doesn’t work.

[01:34:11] This is a real case of a real client of mine who’s got employee after employee quitting out from under a manager that they see as like, I’m gonna make them better. I like them and I’m gonna bring them through this. And what they’re not seeing is, one person after another is like, oh my God, I gotta get outta here. It’s not even the message isn’t reaching the manager. He knows what’s happening, but he’s like, oh, I’m gonna work with them.

[01:34:40] This is what I’m trying to tell you. And if that client of mine is listening, yes, I am telling your story without your names, because you need to fire that person for your own sake and for them. And he’s like, oh, but we’re not hiring. What if I can’t get a backfill? And I’m like, it doesn’t matter. Okay, you have a cancer who’s killing your team, live without them, right?

[01:35:05] But, or do something about that. But I’m just showing you how the inertia works because that manager that you think is bad, I think is great because they do whatever I want.

01:35:16 — What gives you leverage

Ryan:

[01:35:16] It sounds like there are 2 things here that give you leverage in these conversations. There’s how high-performing you are and how liked you are. If you’re high on both of those, it gives you power.

Ethan:

[01:35:28] Absolutely. So I often say the hardest person to fire is kind of like this manager I was just talking about. If you’re looking as a boss, it’s very easy to fire people who are disliked and low performers. They’re not that good, and nobody really cares. Everybody can see it, easy. It’s also actually if someone is disliked but either a high performer or not, if most people don’t like them, nobody’s going to care.

[01:35:57] And they’re thorny, too thorny in a bad way. That’s also easy. And thorny there means they’ve made themselves disliked with others, not just with me. They’re generally disliked. The hardest one to get rid of is the person who’s mediocre. They’re not obviously terrible, but they’re not very good. They’re below average, but everybody likes them. And why is that hard? Well, number one, there’s no smoking gun.

[01:36:22] They’ve never screwed anything up bad enough that you can just be like, that’s terrible, you’re out. And if you go after them, everybody’s going to look at you and say, But everybody loves Bob. Why are you down on Bob? Bob brings donuts. He’s friendly, throws a barbecue at his house every year. He’s always picking up work. Yeah, the work he does kind of sucks and is often late, but he’s always volunteering really hard.

[01:36:51] So yeah, be likable. Now, I’ve said be thorny. How can I be saying be thorny and be likable? You can do both. Okay, you’re likable all the time, meaning you’re friendly, you’re outgoing, you’re pleasant, you’re talkative, except when people are trying to do something you don’t like. And then it’s just that little pushback and that little push of, come on, just that much? Come on, really? This is our priority?

[01:37:24] Is this what you’re telling me you want me to do? Just that little face. It doesn’t take much. The other thing is, if that’s too much, you can push back, as I said, with humor. Be like, all right, but you’re using up one of your crap work tokens. I only give so many of those a month. So is this where you want to spend one? We’ll do it. But it’s only 3 a month. Nobody can really get mad at you for being like, hey, Boss, I only give out 3 shitwork tokens a month.

[01:37:53] If this is one you need to spend, I got it for you. But we are burning a token. Is this it? People will accept this framing. This is the weird thing about humans. I can push on you the fact that you get 3 shitwork tokens a month. You never agreed to that. You’re like, I’m the boss. If I want to give you 73 shitwork tokens, you’re going to spend them all and say, may I have another?

[01:38:15] But that isn’t what we do. We’re like, oh, 3 shitwork tokens. Okay. Because you set the frame. So that’s a way to be thorny and still be liked. Because if other people see you do that, they’re like, hey, that’s pretty clever. Ryan’s pretty smooth. They’re not mad at you, but you just brush the boss back in front of everybody. Even the boss is like, all right, I see. Because what are they thinking?

[01:38:40] They’re thinking, well, you said yes today, that’s good. And you gave me 2 more, that’s fine. I’ll deal with it if I get to token 3. But subconsciously you set the anchor that 3’s the line, and they’re gonna know that. And even worse, if you did it with witnesses, then they’re like, I kind of agreed to it in public. Even though I never agreed, I let it stand. And you’ve got them cornered because they can’t be like, no, Ryan, I’m the one who tells you how much shit work, and it’s unlimited tokens.

[01:39:14] Well, that makes them look horrible, right? And so nobody’s gonna do that. And this is how you be still very likable and funny, but lines.

Ryan:

[01:39:25] For job security, it sounds like likability is more important than performance.

Ethan:

[01:39:33] I mean, it depends on the context. Being liked never hurt anybody. And look, I’ve seen another decision I saw made, technically totally illegal. We were deciding on a layoff in a company I was in, and we had to cut some people. And one of the other leaders said, well, that guy’s married and has a family to support, and this other guy doesn’t. There’s no legality in that. You can’t bring people’s family situation, but that was what happened.

[01:40:00] So decisions get made on criteria that aren’t performance, and that’s a very real thing. So likability is one of them. And, hey, a question. If I wanted to save you and you were likable but lower performing, hypothetically, and there were a bunch of people making the decision, what I would say is, yeah, Ryan isn’t always our top performer, but this new room has to pull together.

[01:40:30] Who do we want in that room who’s going to light up the room and keep everybody’s morale up after we go through this grim event? I think we need Ryan at that table. And I’ve just turned your likability into a performance asset. And that kind of thing also happens because who do I want to work with? I want to work with really smart people, but I also want to work with people I enjoy who can pull together.

[01:40:58] And that’s the likability piece. High performance, there are cases where you will say, yeah, Robert is the only one who knows that old arcane system. And even though he’s really tough to deal with, we’re gonna need him. That also happens. That’s the Cal Newport so good they can’t ignore you path. But what’s going on in my mind is how can we cross-train someone on what Robert knows?

[01:41:27] So that we’re not in this situation? Because the truth is, I’d rather unload him. Nobody ever wants to get rid of the likable guy if he’s at all good. But the high-performance guy who nobody likes, we’re looking for how do we get out of this situation? How do we get out of our dependence? Because no one likes to feel trapped and depending on someone who’s unpleasant. And that’s why that’s dangerous.

[01:41:54] I also want to make clear, you don’t have to be like this super lovable teddy bear. Just be a decent person. Don’t be rude or judgmental. Don’t be that person who’s always talking down, super like— engineers hate this again. This is my list of stuff engineers hate. Managers have fragile egos. They have imposter syndrome. They’re always wondering, even if they’re technical managers, part of their mind is like, am I technical enough to keep up with the team?

[01:42:24] Well, there’s that one engineer who wants to show the manager, “Ah, you’re really out of touch, old man.” I don’t like that. And so if you keep showing me up in front of the team, you become marked for death for two reasons. Okay? One, I don’t like you. And two, I can’t have you doing that. So if I can’t win you over, then I have to shut you up because I gotta keep the rest of the team with me, and you’re undermining my authority.

[01:42:56] And humans are incredible rationalization machines. My mind will always come up with some reason at night why that’s justified. It always does. That’s what human minds do. That’s why there’s so much nasty behavior in the world. People don’t tell themselves, nobody wakes up in the morning and like, I’m a supervillain. This doesn’t happen. The supervillains wake up and they’re misunderstood.

[01:43:21] Nobody understands the greater good I’m doing. Nobody understands that I’m just getting by, taking care of my family. Nobody understands this is just the way the world is and some people gotta die. They always have some excuse, and it’s okay because just. And we all, we’re built to do that. Literally built to.

01:43:41 — How to defend against peers undermining you

Ryan:

[01:43:41] Last question on this dark topic, and we’ll go to the darker one.

Ethan:

[01:43:45] Darker? All right, this hole has no bottom. Let’s go.

Ryan:

[01:43:51] So we’ve been talking about promos and how there’s maybe limited spots in some cases. And not that you would recommend anyone do this, but let’s say your peers are going for that spot as well, and they know that you’re one of the people that wants it too, and so they undermine you. So they’re attacking you. How do you defend against being undermined by your peers where they’re saying, oh, he’s not the best candidate for that position?

Ethan:

[01:44:25] Yeah, so speed matters. Again, going first really matters. If you have seen this once, you can predict it will happen again. So if you get bitten once or see someone bite someone else once, you can predict that person did it once, they’re going to do it again, they’re going to do it to me. So then what you have to do is get in front of it with your management and say, hey, I don’t know if you’ve noticed, but there is some undermining in this team.

[01:44:53] We have a competitive team. Some people will take shots at each other. I’m never going to do that. But that means I’m counting on you to recognize it because I’m not going to play that game. But I’m counting on you to see it and just please judge my performance by what I actually do, not by what anyone else says. And then you’ve planted the seed in their mind without accusing anybody of when someone comes and chirps, they’re like, oh, that’s what Ryan was talking about.

[01:45:21] And now you’re up 2 because I’m going to disregard what they said and not knock you down a peg. Meanwhile, I’m going to look at the other person and say, that’s interesting, and knock them down for undermining. So you really want to set that, like, if this is a problem you’ve seen, you want to talk to your management and just be like, hey, I’ve seen some people in the team, maybe while you’re not there, talking shit about each other.

[01:45:43] And it really disturbs me. I’m worried that if they’re talking shit about each other or other people around me, they’re also talking shit about me to you. And I’m not going to play that. And I’m not accusing anybody, but just please judge me by what I actually do. And if you ever have any question about what I’ve actually done, grant me 10 minutes to show you. Because if I can’t back it up, that’s great.

[01:46:09] Like, that’s fair. But if I can, judge me by what I’ve done. And that humble pie act of like, judge me by what I’ve done and give me a chance to show it. Again, who can object to that? Right? But you’ve set that anchor so that then if somebody comes and like, well, Ryan, blah, blah, blah, then they look, they’re playing into it. Now let’s assume, I know you’re going to ask me, well, what if they’ve beaten you to it and you find out they’ve been doing this and your boss is like, wow, really?

[01:46:40] How much did you have to do with that project? First, you may have to just be like, okay, once bitten, twice shy. Now I’ve learned. But you can, without being defensive, you can just say, haven’t done that much, huh? And that’s the Chris Voss trick of mirroring back to them, where they’re like, well, you didn’t contribute that much. And you say, contribute that much? And let them keep talking.

[01:47:01] Well, so-and-so said, oh, interesting. So-and-so said? And you just, this is a trick from the book, but it’s very powerful, called mirroring. You just say, repeat the last few words they ended with, and they will keep talking, and they’ll talk themselves into trouble. But eventually you just say, well, I’m really disappointed by what you’re sharing. I think if you’re willing to examine it, my work speaks strongly for itself.

[01:47:27] But I certainly want to make sure I’m judged rightly in the future so that we’re both on the same page about what I contribute. What’s the best way for me to showcase what I’ve contributed to you so that you’re fully informed? Because that’s another little dig, very subtle. Maybe you’re not fully informed right now, but how can I make you fully informed in the future? But I haven’t said, oh, you’re not fully informed.

[01:47:52] I just said, so you can be. So I’ve set this anchor that, you’re not fully informed, but I’ll make sure you are in the future. These are just all little techniques. Lastly, I know I say this a lot, if you’re in a team with a bunch of snakes, not all teams are like that, find your way out. Another thing, if there is a chance, rather than counterattacking the person who’s undermining you, that puts you down in their gutter.

[01:48:28] Instead, figure out a way to catch them out or set a trap or otherwise expose them as a shit talker. Maybe your team probably has a bunch of neutral people who just don’t care. Wait until that person who’s got that behavior probably shoots at other people too. Go find those people and say, hey, I heard Ethan say that you didn’t contribute that much. I just want to let you know, I thought you contributed a lot.

[01:48:58] I’m not sure where that came from. And you do that with a few people, and that just forms the, right? And you’re not—you never said, I see he’s running you down. Say, I’m not sure why he said that. I thought you did a lot. It’s that subtle. Just like, hey, I see you. And you do that with a few people, and suddenly they’re all like, oh, that other person’s always. With a little bit of help, people are very good at seeing through others.

[01:49:26] Once your eyes are open to this person’s behavior has double meaning, it’s much easier to see. So you just have to help people open their eyes a little. You can even just be really curious and say, I noticed today Ethan was saying bad things about Fred’s work. You’re talking to a third person. Why do you think that was? What caused them to bring that up? It’s so strange.

[01:49:51] You’re not even saying, “I disagree with it.” Just, “That was a little weird.” You just leave it. Their mind will go, “What was weird about that?” Huh, maybe seeds of doubt. Planting seeds and being patient, great relationship tool, both in terms of planting seeds of, “I’ll help you,” and planting seeds of doubt where you need to. That’s that doubt, like where I’ve said my career is very important to me and I need to move it forward, I’m just planting that little seed of doubt of, “Either you take care of me or I take care of myself.”

[01:50:21] I just let that grow. Plant those seeds.

01:50:24 — What if everyone is good at politics

Ryan:

[01:50:24] When I think of politics, it feels like this adversarial game. If everyone was playing this game optimally or using all these tactics that you were saying, does that change what is the best thing to do?

Ethan:

[01:50:38] So I will answer your direct question in a second, of does that change what’s optimal? Politics, the way you’re describing it, and all these sort of dark scenarios, they’re never ideal. This dark scenario in a real—like, where do we start about getting credit? In the best world, managers have a pretty good idea of credit, but all the team members are sharing honestly what they’ve done, and we’re all trying to grow together.

[01:51:03] And like I said, with this company I’m working with, we’re trying to get all the boats to rise. The company gets higher performance, which means it does better in the marketplace, which means everybody’s shares goes up and we can give more out, and everyone wins at some level. So there are positive ways to do this. It does not have to be zero-sum or prisoner’s dilemma, but those situations do arise.

[01:51:25] And if everyone—we know the prisoner’s dilemma, to cite a problem, hopefully if somebody is watching, they don’t know it, Google it, but I’m assuming they all do. In the prisoner’s dilemma, we know how it ends, which is everyone stabs each other all the time and it ends up nobody makes progress, but nobody loses progress. So in this highly political, everybody doing this, what you would have is you’d have a set where because everyone is maneuvering in this politically optimal way, you’re right back where you started.

[01:51:55] No one’s getting an advantage. So you’re back to neutral. What I would say to do is if you recognize that case, oh, everyone here is very politically astute, I would be like, so my problem is I’m playing poker at a table of excellent poker players. I can hold my own, but a much better thing is go to that table of suckers and clean them out. Go somewhere else that’s a different game or a different level of play.

[01:52:26] Where I’m the star. I often share it this way. When I chose to do what I do today, which is coach and teach online, I realized I have 3 talents. I’m a pretty good public speaker. I know a lot about careers, and I know a fair amount about social media from having worked at Twitch and been a Twitch streamer. I am certainly not, and by no means was anywhere near the best Twitch streamer. I’m probably nowhere near the best public speaker.

[01:52:57] And while I’m a career expert at some level, I may not even know the most about careers. But when you intersect those 3 things, I’m very near the best. So I went and found the one poker table where, no, I have very little competition. So what I would say to do in that case is go find the place that fits you. Because if you’re that good and everyone else is that good, go somewhere where the competition is softer.

[01:53:24] Now, some people are like, ooh, I don’t want to do that. I want to win, or I want to be at the toughest place. Well, that’s fine too. It’s a lot of effort to stay. Let’s use sports as an analogy. You want to play on the top team, whether it’s World Cup or whatever, getting the benchwarmer spot on the top team is a lot harder than getting the star spot on, like, the 6th team. And that is a choice.

[01:53:53] The star on the 6th team, though, probably makes more than the benchwarmer on the top team. So it is, what do you want? If you want to say, I was part of the team that won the championship, you might have to take the benchwarmer spot. And if you want the big paycheck, you might want to go somewhere else. And those are both valid choices. They’re just choices.

Ryan:

[01:54:13] In the hypothetical, I guess, you’re at the poker table and everyone’s playing optimally. Does the way the people play the game change?

Ethan:

[01:54:23] It does in that it changes in that nobody tries simple moves anymore, meaning the way you might bait someone or bluff someone who’s greener isn’t going to work. Once you recognize it’s all stars, it makes you more conservative in that there aren’t going to be any easy shortcuts and any mistakes are going to be caught and punished. So I think it makes you play a lot more cautiously because a mistake is at that table.

[01:55:08] If you make a mistake, you’re done.

01:55:11 — How Jeff Bezos burned him for empire building

Ryan:

[01:55:11] Darker hypothetical.

Ethan:

[01:55:13] Darker. Here we go.

Ryan:

[01:55:15] Well, so we talked about empire building before. It’s incentivized if you want to grow as a manager. And my question to you, because you had so much success as a VP, did you do empire building?

Ethan:

[01:55:30] Yeah. So I mentioned earlier, the human mind is great at rationalizing. I think in hindsight, I for sure did some empire building. But at the time, you probably don’t tell yourself you’re empire building. What you tell yourself is, with all these people, I could do so much more, right? You frame it as, man, I have all these great ideas. We’ve got a big backlog. If only I had 375 more people, imagine what we could do.

[01:55:54] And it’s not your budget. So why not ask for it? So I got totally burned on this. When we were growing Amazon Appstore, we had launched the store and we had our annual meeting with Bezos, and we said, we launched the store and we took him this huge ask for all these people. And I remember what stands out to me most is I think we had nobody in marketing. We had no dedicated marketers because we had started this lean team.

[01:56:22] It was something absurd like we need 25 marketing people. And it was going to be like, this is not exactly right, but it’s like we need 5 PR people. And we had this idea like, oh, we’re operating in 5 countries, we need 1 PR person per country. So we had some justification in our own minds, but we were just asking for everything under the sun. Well, if we had all this, I’m sure we could do a lot, and wouldn’t it be great?

[01:56:51] Well, Jeff tore into us. He asked a couple questions like, what are these people going to do? And what are these people going to do? What are they actually going to do? And our answers fell apart because we were just sort of like, well, they’re going to do marketing. That’s why they’re called marketing people. We need more marketing and 25 is a good number. And I remember very distinctly, he asked one question, we gave a crappy answer, and you could tell he’s like, hmm.

[01:57:17] So then a second later, he asked another question, and we gave another crappy answer. And he’s like, okay, I don’t believe any of your numbers from here on. I’ve asked you two questions. They were both nonsense. I’m not going to go through everything else. I don’t believe any of it. Here’s what you’re going to do. Go back and bring me a sheet where the maximum size of any bucket of anything you’re asking for is two or three people, and it says exactly what they’re going to do.

[01:57:46] And I will go through that line by line and tell you what you can have. And that’s what he did. We went away and came back with this line by line, and he went through it and like, 2 people for PR, I can believe you need some PR. No one. And he just literally with a red pen with all of his direct leaders watching, no, 3, none, 2, okay, both for that, but I want this, this, and just took us over the coals.

[01:58:19] He wasn’t wrong. He was actually right. I was relatively newer. One of my managers was newer. We had gotten big eyes because we’d launched the project and thought, well, let’s see what we can do with this. It’s a good project. Let’s see what they want to do. And what we found out was not very much. They wanted us to be lean. That was for sure empire building. But I would say in that case, it was driven out of laziness as much as this idea of I’ll have a huge team.

[01:58:46] Not that a huge team wasn’t also appealing, but we were just daydreaming rather than thinking. When people set out to really empire build, they’re either asking for people and resources they don’t really have any use for, or they’re asking for stuff they do need. And what they’re not doing is worrying about what they’re taking it away from because the company only has so many resources. So my job is to advocate.

[01:59:12] The way I was successful empire building later, if you want to call it that, was coming up with new ideas that the company wanted to invest in. We’re going to do this. Look at the money. We’re going to do this. Look at the customers. We’re going to do this. Well, that’s a lot of growth, Ethan. Another challenge. You can’t hire all those people. And I’d be like, okay, here’s what let’s do. You hold 100 heads for me and release them in groups of 20.

[01:59:38] And if I don’t fill the first 20, I don’t get the second 20. Well, I got really good at filling heads and with good people, by the way, not just filling them, but I found ways to turn my heads into performance. But then I was very aggressive asking for more. I’ve done this much. I’ve built leaders who can do it. I want this. I want that. That was me being the I want guy. The here’s my proposal.

[02:00:02] Here’s my new idea. A story of empire building, sort of. I ran the Amazon Appstore team. We sold apps. Our job was to build an app store for the Kindle and for phones. We had this idea. We were supposed to compete with Google and Apple, who own their platforms. It was a very hard job. And we were trying to figure out how can we compete with Google and Apple? What can we offer they can’t? And we had this somewhat harebrained idea of, well, they can’t ship physical goods.

[02:00:35] We’ll go to all the game makers and offer to be their swag department. We’ll make their T-shirts and their coffee cups and whatever. We’ll tell them you should work with us because we can help you with your Merch by Amazon. So we built this group called Merch by Amazon, and we started with printing T-shirts. Well, my leadership came to me and said, why are you working on a T-shirt printing project?

[02:00:57] And you have people on a t-shirt project from within the Appstore? I said, well, we have these reasons. Well, the bottom line is t-shirt printing didn’t change the app business, but Amazon now prints more than $1 billion of T-shirts a year. And we built a T-shirt business. It was a matter of me fighting for it and saying, I have a theory and we have the ability to do it. And there’s a business model behind it.

[02:01:22] And then when it turned out the business model, this is the key, when it didn’t work for what I planned for, it was working to sell clever slogans and people’s party T-shirts and people’s political T-shirts. That was selling great. So I just pivoted right away and said, this isn’t really about apps anymore. It’s about how many T-shirts we can sell and how much money we’re making.

[02:01:44] And I just—and that became a new empire. Now we spun that off and it went elsewhere in the company. Part of empire building in a good way is being good at turning things into money and being willing to be flexible. My theory of why to make print t-shirts was a total failure. It’s going to make game makers prioritize putting their apps on Amazon Appstore. They didn’t care. Merch was such a small thing to them, wasn’t—but we found other money, and so we just used it for other money, and we kept it.

[02:02:20] Another thing I’ve done before is I’ve gotten heads for a project. That project has tanked. I don’t go and say, oh, that project tanked, you should take the heads back. I’m like, that project tanked, but you know what? Great news. I put those heads on this thing that’s working, and now it’s going twice as fast. So you’ve got to always know where do you shift the resources to where they’re making money or delivering results?

[02:02:43] And if you’re doing several things, if one thing fails, you just immediately put them on the other thing and do it twice as well. And they don’t take them away. I think it’s undeniable. And this, this doesn’t look good of me to say, I was an empire builder in ways. The only defense I have is I made it pay off for the company to the goals the company wanted and/or in hard cold cash. Sometimes those weren’t the same.

[02:03:07] I’ve talked about rationalization. I’ve rationalized it to myself where I feel like I delivered value. Some other people looking at and listening to this, some of my old peers would be like, bullshit, Ethan, you were just really slippery. I hate that idea that they might think that. I would say, well, I did deliver a lot of value, right? At least I made a lot of money and you can’t deny that.

02:03:27 — How to retain your headcount

Ryan:

[02:03:27] So if you were empire building, is there ever a case where they clawed back headcount because maybe you didn’t need all of that headcount? And if so, how’d you defend against your headcount getting clawed back?

Ethan:

[02:03:42] Amazon didn’t shrink much during the times I was there. So pure clawbacks, I don’t think I faced too many, but as I described, that’s because I was playing offense. When something wasn’t working, I was upfront about it not working. And before they could say, well, we could use those elsewhere, I was talking about what I had already done with them. ‘Cause they were on my team, so I already had them assigned to something else, something more valuable.

[02:04:10] So they would have to come and say, no, no, you can’t move them to that. We have to take them back off of that. And I’m like, well, isn’t that important? Look at— so I sort of prevented that by staying ahead of it. I never left headcount open at the end of the year, ‘cause that was their favorite thing to take back. Amazon often did this thing. Where at the beginning of the year, whatever, we’ll pick a random number that’s too small, but to illustrate, they would say, okay, we have budget for 1,000 heads this year across the company.

[02:04:46] We’re going to let people open 1,500 and we’ll see who fills them and we’ll cut it off when we get there. Well, I put a lot of effort on hiring, so I played offense. My heads were all full before the gate came down. And I did that year after year. And other teams, they would be like, oh, we were too busy working and now it’s November and we haven’t hired yet. What do you mean we can’t? Sorry, what you’re talking about is any kind of resource competition.

[02:05:15] You’ve got to think about how do I seize those resources and make my use of them something no one will argue with or that it’s too late to argue with it. There are some things that once the ship has left the dock, it’s gone. I was very good at getting my ship out to the ocean. And by the time they’re like, hey, we needed that ship, you’re like, well, I’ll give it to you when I get back.

[02:05:39] Like, it was too late. And that part of empire building, if you wanna say, for a place I was very maliciously empire building, I knew how headcount worked, and I was always the first to hire and fill my team so much that I taught a class on how to hire quickly, because I knew others wouldn’t do it. And that was my way to get people. That was, in fact, another argument I made was they’d say, oh, we don’t have any headcount left to give this year.

[02:06:11] And I’d say, well, isn’t there a bunch of other teams not filling their headcount? Tell you what, they’re probably not gonna get to it. Let me hire a little ahead and we’ll, you know, they’re not gonna get to it. And that was another story I told of like, hey, across your whole org, all these other teams are behind. You have headcount you can loan me that they’re not going to get to.

[02:06:30] And that was just literally me, taking other people’s heads, but knowing I could get away with it. Now, I put them to good use. Remember, I talked earlier about you have to be a good performer. My teams were always at least delivering their stuff. And so it wasn’t like they were going to look at me like, why would we let you do anything? Your shit’s all broken. I never had that accusation. I’ve shared before though, I was very willing to hack to get things out and I probably shipped some stuff that was too raw.

[02:07:00] That was though, keep the speed moving, keep in front, don’t get bogged down in the perfect project. Get it out there and show progress and then iterate is better than, “Oh, but it’s not quite ready yet. I can’t let it out yet.” Because if I can’t see it, it’s not real. People could see my stuff and they’re like, “It’s got warts.” And I’m like, “Yeah, but it’s there.” It’s different as opposed to your thing that if I ever pulled the shoot at somebody else, I’d be like, yeah, maybe their project’s perfect.

[02:07:30] They’ve been telling us that for 2 years.

02:07:31 — Career recommendations for the current landscape

[02:07:31] Where is it?

Ryan:

[02:07:33] With all of these changes with AI, I think you could make a case that it’s a boom in some places, a bust in many places. And I know you have a lot of experience across different companies and periods in the tech industry. So when you look at today’s landscape of tech careers, what advice would you give people in the uncertainty of potential scenarios with all this AI stuff that’s happening?

Ethan:

[02:08:01] I wish I had a perfect crystal ball with AI because I’d make a fortune on Wall Street. But I do think there are gonna be winners and losers, and I do think some types of jobs are gonna get eliminated. I think other types are gonna change. I think some will also get created that we don’t understand yet. So what do you do to position yourself for that? Well, I think breadth of learning is more valuable than depth, flexibility.

[02:08:25] And so, of course, I am a fan, as we talked about, of develop your soft skills because that’s not a target of AI at the moment. AI’s strongest target is things that have rule sets, coding languages, law, math, things that have firm rules. It can be optimized around a lot easier. You’ve said how many times today regarding soft skills, well, it’s a gray area. That’s where AI is going to struggle because how to act like a human at that level and how to convince people, and it doesn’t have a body or a face and it can’t hug anyone or shake hands.

[02:09:04] It’s got a lot of limitations in this pure, does the code run or not? Is this contract viable or not? So I think leaning into some of those skills that require human presence is a big tool, a big tactic. At the same time, you can’t be AI ignorant or resistant. You have to be aware of the tools, able to use them. I think the people who are spending absolutely every moment trying to stay on top of AI, only maybe I’ve called it like winning the race off the cliff.

[02:09:46] You will be the best person at using the tools. But as those tools chip away at what you do or obsolete what you do, you’ll be the last one kept around to operate them until they don’t need you either. It’s a kind of a Pyrrhic victory. Now, again, there’s at least two analogies that get bandied around. You mentioned engineers and coding in our opening. We know that spreadsheets didn’t eliminate bankers or financial analysts.

[02:10:17] They increased the demand. Financial tools have increased the interest in doing all kinds of weird financial instruments and analysis. So there are more bankers, not less. Similarly, it was thought that ATMs are going to eliminate bank tellers. Didn’t happen. There is an argument that these tools are only going to increase the demand for things. In other words, more people have seen what code can do for them.

[02:10:46] There’s more people playing around with vibe coding, and they’re going to reach a point where they realize I actually need a software engineer to help me with this. And so it’s going to increase demand. I don’t actually know which of those wins. I’m sure that sitting and pounding a keyboard the way I grew up doing it is not going to be the same. So the jobs are going to change. What do I advise? Having the best eye you can on where is the value going?

[02:11:14] What are people valuing? What I think they’re valuing more and more now is more people can produce more code or more legal documents or whatever. Who’s deciding? Who’s explaining those? Who’s deciding what’s needed? Who’s deciding what to prioritize for release? Who’s deciding what to tell customers? Let’s say the engineers on Gmail can now write 10 times as many features. Well, we don’t need 10 times as many features.

[02:11:43] We actually might need fewer, that are better or different. Who’s deciding? That’s that whole taste or judgment. I think that’s going to be very highly prized, and I’d rather be in the judgment seat than in the running the tools seat.

Ryan:

[02:12:03] In the last few years, there’s this trend of flattening orgs or getting rid of the layers, and I wanted to ask you, in your experience, is that in the tech industry, is that just something that ebbs and flows with the booms and the busts, or do you think that’s a new permanent way of operating?

Ethan:

[02:12:26] The delayering is a cyclical pressure, and it’s a cyclical pressure when companies are very focused on headcount, on keeping headcount flat. Companies go through periods of expansion and contraction or rationalizing. And when they’re trying to rationalize, they’re always trying to flatten because there’s this belief managers in the middle don’t do anything. And so how do we get rid of them? But I want to talk a little bit about history.

[02:12:58] There was an early dynasty in China that in 600 BC implemented the first testing for civil servants. And by 200 BC, this had actually become a formal process with a written exam. So if you think of administrators as basically the same as managers, we’ve had manager layers since 600 BC, to the point that they were selecting them with a test. I believe AI changes a lot of things.

[02:13:28] I don’t believe it changes human nature to where there’s no longer gonna be this idea that you need one person to organize other people’s work or to speak for it or to centralize it. And so I think it’s cyclical. I don’t think it permanently changes. It might be that AI tools increase what is considered a team, like how many people can be on a team because the manager has automation helping them.

[02:13:59] But I can just as easily argue that because each individual on the team is producing more and more decisions are needed and more judgment is needed, more communication about what’s been done is needed, that it increases the need for people acting as managers. Right now, this flattening idea, it’s got a couple of poster children like Jensen Huang, who’s got 60 direct reports. Is everyone Jensen? They’re not.

[02:14:30] And by the way, those 60 people, I coached some people in his organization, they are extremely senior. So can one brilliant guy lead 60 other brilliant people? Yeah, maybe. Can I do it? Can you do it? Can the average first-level manager scale from 10 engineers to 100 and still do a good job? I doubt it, right? I really doubt it. So I think it’s cyclical. Predicting that human nature is going to be different is a really bad prediction because it’s been the same for so long.

[02:15:05] And the idea that a tool is magically going to make humans different, I’m skeptical.

02:15:11 — How to avoid negative layoff optics

Ryan:

[02:15:11] In the doomer AI case where there’s less technical roles, I think people might worry about layoffs and those kinds of things. What are the top ways to protect against layoffs? And also, I’m curious to know how do you avoid the negative optics?

Ethan:

[02:15:31] Yeah, so let me address your second question first, which is the optics. I think right now, AI-driven layoffs or downsizing from big companies is so common. You tell that story exactly. You say, look, my org was eliminated. My whole org was eliminated. That’s a simple way of saying it’s nothing to do with me. And that’s so common now that a recruiter isn’t gonna be like, oh, you were at Google, but now you’re— or again, fill in the blank.

[02:16:00] Meta’s done a lot of layoffs. Amazon‘s done them. All the big companies have. Saying that you were laid off from one of these big companies when your org was closed down or significantly reduced no longer has the tarnish it did. But the rest of how you prevent that from tarnishing you is you make it a quick fact and you pivot. And so you say, yeah, unfortunately my organization at Meta was eliminated, but the good news is fill in your story.

[02:16:29] That gives me a chance to do something new. That actually gives me a chance to bring the Meta philosophy or the Meta insights on whatever, fill in the blank, again to other companies. That gives me a chance to bring Amazon‘s experience with scale to you. And so I’m actually excited. It sucks I got laid off. I admit I wasn’t looking for that, but it’s opened my eyes that there’s a chance to bring that to someone else.

[02:16:55] And you change the topic quickly to the future. So truth about the past, quick move on. Now, how do you avoid a layoff? First, sometimes you can’t. If they whack a whole org, you may be done. But even in most layoffs, I know top managers or executives, they try to place their key people in other orgs. So I know a leader at Amazon was shutting down a whole big org. And she had a list of her top performers.

[02:17:31] And she was calling other leaders and saying, “Make a space. You want to make a space for this person.” How do you get on that list? The layoff key is the decision is often not made by your manager. It’s made by your skip or a couple levels up. So you need some visibility as a top performer. Top ratings is one key. They’ll look by rating, but being known for an accomplishment, something like that Matt Round Tool that I talked about earlier, or something, a tool with your name on it, having a unique skill.

[02:18:01] We talked about the curmudgeon engineer that’s the only one who knows something. If you’re the only one who knows something that’s still needed, I can cut half the org, but I have to keep you because you’re the only one who knows this thing. Those are the different techniques. And again, I’m mixing technical knowledge, building tools or having unique expertise with social engineering, being known to the skip, skip and whatever.

[02:18:27] It’s always, every answer I give should be a combination of what I said: be good and be likable. Both are additive, maybe even multiplicative.

02:18:39 — How to develop executive presence

Ryan:

[02:18:39] Yeah, we talked a lot about the social engineering and kind of the negative and the politics. I do wanna talk a little bit about the positive side of soft skills as well. What is executive presence, and how do you develop it?

Ethan:

[02:18:55] Yeah. So executive presence is very hard to define because it’s something others decide about you. They look at you and they either decide you have it or you don’t, and they’re combining a few things. So what is executive presence? I have 2 definitions. One of them is from a book and it’s academic, and it says it’s 60% gravitas, which is like the weight of your accomplishments, what you’ve done.

[02:19:17] It’s 30% communication skills, 10% appearance. This is from a researcher who has done all this work to figure it out. I think it’s a fine framework. The other way I look at executive presence is, are people coming to you for your opinion, particularly on things that you may not directly be involved in? Are they coming and saying, hey, Ryan, we’d love to get your take on this because you have really good insights, or we’d love to get your support on this because we know people look up to you.

[02:19:46] That’s the other sign of presence, is you’re being sought after even when it’s not directly your work. You’re being valued. It’s those 2 ways of looking at it that define executive presence. If you want me to really boil it down to a phrase, it is, do you command respect in a room? Do people listen to you? Do they look to you? This is a little overly political, but are they busy, like reading your gestures?

[02:20:21] So if you’re talking and I pick up the phone, are they like, oh, well, we can ignore Ryan ‘cause Ethan is? That’s the sign of a lot of presence.

Ryan:

[02:20:31] When you framed executive presence as people wanna know your opinion, I’ve seen that where there may be someone who’s a quiet engineer, but they’ve been there a long time and they know everything, and a lot of people go to them for their opinion. So I could see that being one path to executive presence. I could also see a case where it’s not grounded in their being objectively correct all the time.

[02:21:00] Something about the way they stand, the way they speak, what they accept, what they don’t accept, and it’s—that’s a little harder to define.

Ethan:

[02:21:11] I will tell you a story, which is I speak with tremendous confidence, and sometimes I can sound like the voice of God. I can sound like I am declaring truth from on the mountain. I have the tablets. And my wife, who knows me very well, she once told me, she said, Ethan, I’ve learned that you sound like you know. And so sometimes when I think something different, I don’t say anything because you sound so sure.

[02:21:46] And then it turns out you’re wrong. And I’m like, why didn’t I say anything? I knew we needed to turn right at the last corner, but you said, no, it’s straight. And you sounded like you knew. And I bought it. That’s my executive presence. Going too far, right? Because I think it’s straight, but I don’t know. But I’m saying, oh, I’m sure it’s straight. And she’s hearing, I’m sure it’s straight. What are those traits?

[02:22:10] Well, some of them are very superficial. The number 1 and 2 are confidence and decisiveness. If you undermine yourself and say, well, I think maybe it’s straight, people are definitely going to challenge you. Whereas if you say it’s straight, the next—we don’t turn, it’s two, two lights, then a right. Very specific. Everybody’s going to buy it. One thing I do in my executive presence class, I teach a class on it, is I share the fact that stats with numbers are 62% more believable than stats without them.

[02:22:43] Now, the truth is I just made that up. I’ve never looked it up, but 62% sounds so specific, and I delivered it like, oh yeah, this is true. Maybe you bought it, probably you bought it, but a lot of people listening were like, really? 62%? I was just lying through my teeth, or at least embellishing, right? Specificity delivered with confidence, speaking up quickly. The list of traits are being tall and white.

[02:23:12] You don’t have to like it, but it’s true. They’re both like, if you look at presidential height, if you look at how many white men we’ve had as president, not just here, go around the world, go through history. These are things, okay? Doesn’t mean they’re good. It means they’re true. Deep voice. We respond better to people with deep voices, which is why when I do the voice of God, I go even lower.

[02:23:35] And so did all the actors who’ve ever done God. So apparently God’s a baritone. You never see a squeaky God. Another trick is speaking slowly. Usually pausing for emphasis makes you seem confident. And gestures, body language. When you said all the things that aren’t just being a great engineer who knows all the facts, it’s this feeling like your trustworthy uncle. That’s the picture, right?

[02:24:06] The uncle who’s like your dad’s older brother and runs a business. He’s fun, but he’s really smart and he owns two cars and has a beautiful wife and three lovely children. It’s exuding that successful, comfortable in every situation. Another big factor is never getting flustered. They’re never out of control. They may show anger, but it’s always like this. It’s not this wild, screaming rage and spit, blowing spittle.

[02:24:40] It’s this lean in, like, how dare you, little one? And so it’s emotion under control. It’s, you know, if you don’t like it, I guess, or if you do like it, it’s all these ape dominance tricks. What makes the top ape in the tribe who gets the bananas? It’s just the human version of those brought into a room.

Ryan:

[02:25:00] This reminds me, there was that one CEO, Elizabeth Holmes, and she was famous for her deepened voice when she was speaking. And there are recordings of her not doing the CEO voice, and it’s different. Different. Yeah, it’s different. So I guess she picked up on that, and she’s trying to exude executive presence.

Ethan:

[02:25:26] And she’s not the only one. Margaret Thatcher, the historic prime minister in the UK back in the ‘80s. I think she was the first female prime minister. I may have that wrong, but I think so. She, early in her career, was accused in the media of screeching, of being high-pitched. She said, that’ll never happen again. She systematically trained herself to speak low and slow. Basically, and this again will bother lots of people, took on a man’s voice to compete in a man’s world.

[02:25:56] Now, this goes down into that whole should thing again. Should she have to do that? No. Did she do that? Yes. Did it work for her and Elizabeth Holmes? Yes. So until our world changes, that’s different. And so yeah, that is one of the signs. The good news is you can be successful and have high executive presence without any one of these given traits, but you’re gonna have to have some of the others.

[02:26:23] So you’re either gonna have to be really good at what you do. That’s the engineering viewpoint. The example I always point to there is Warren Buffett. Warren Buffett, no one that I know of has ever said, “What a dramatic speaker, what a showman.” And yet he commands tremendous respect, tremendous executive presence. That’s your case of the engineer who’s the expert. It’s because he’s Warren Buffett and his investment track record.

[02:26:51] It’s not any of these other factors. We look at somebody else, Steve Jobs or Elon Musk. They are both showmen. They were very good. They may have had great ideas, but they are icons in our industry because they were also very good at all the speaking and presence. They controlled their stage presence. They did things in a very exacting way.

Ryan:

[02:27:17] Well, it’s interesting you mentioned the Elon Musk one as an example of showmanship because when I see a public speech of Steve Jobs, it’s very polished. But yeah, when Elon speaks, it doesn’t seem so much like showmanship. What are those traits in him that you’re saying are—I think the showmanship in him that works for him is he can deliver relatively outrageous claims with very 100% conviction.

Ethan:

[02:27:51] He can make you believe that at least he believes. So if we look at the recent SpaceX IPO, he’s talking about how he’s going to build factories in space. Maybe if you start really thinking through all the things that would have to be true to make it possible to build things in space and make it useful, it’s a very long list of problems. But he says it with his total conviction. Whether he says these words or not, he’s like, nobody thought we could do electric cars.

[02:28:25] Check. Did that. Nobody thought I could build a private rocket company. Check. Did that. And I’m telling you, next is space factories. And he just says it in a way that it’s inevitable. The sun will come up tomorrow, water is wet, and Elon Musk will build factories in space.

Ryan:

[02:28:43] It’s—

Ethan:

[02:28:45] I think his showmanship, whether it’s an act or not, is conveying utter conviction of ideas that are somewhere between incredibly cutting edge and total fantasy. What you think there depends on what you think of Elon. Is it one or the other, but he’s able to get out in that space and make it plausible because he’s done stuff that people didn’t believe was possible. So his essential pitch is, you didn’t believe me before and you were wrong.

[02:29:22] Are you gonna dare to doubt me again?

02:29:25 — How to network in a natural way

Ryan:

[02:29:25] Obviously it’s an asset if you’re liked, and you should build relationships at work. How do you actually go about that?

Ethan:

[02:29:35] I think networking, there’s a recipe to do it. It’s very authentic, very effective. And that’s figure out some stuff you love, stuff you’re passionate about, stuff you would like to share with people you’re proud of, you’re interested in. Do those things or work on those things and figure out just put in a little extra effort to figure out how can I give this to other people? How can I make it available?

[02:29:57] How can I package it as a tool? How can I give away my advice, give a class, give a talk? The key is to give. Take what you like doing and give it away because there are other people who don’t like that thing or don’t know about it or want to know more, and they want your help with it. So it does require that you have some sort of expertise, but it doesn’t have to be wild. It just has to be solid because there’s other people who aren’t good at that thing.

[02:30:26] And if you can figure out how to give away some value, so my first way of doing this at Amazon was I mentioned how I was really good at hiring. So I started teaching a class to other managers on how to hire really fast and well. Then I started teaching some other stuff, and that led to my teaching. I found other ways to give stuff away. So I started streaming on Twitch, giving away advice, and I built an audience.

[02:30:53] That’s all network. But it was all based on what could I give away and why was I willing to give it away. I loved it and I was good at it. It was fun for me. It wasn’t work. So I often share a story. There was a guy at Amazon who liked to ski and he was an engineer, I think, but he went to the local ski slopes and he got their bulk ski tickets. And he had a deal with them where they would ship him tickets and he would resell them internally so that people could get a ski ticket for those hills at the discount bulk price.

[02:31:32] Well, he just basically did it because he liked skiing, he liked helping people, and he liked to get cheap tickets himself. So it was a way for him to get bulk pricing. But through doing this, he made hundreds of connections with people who got discounts through him. It meant if he ever needed anything, he had all these people he knew, or if he called up a random person, there was a good chance, oh, you’re the ski ticket guy.

[02:31:53] Yeah, I’ll help you out. Why do I give this example? He wasn’t sharing anything technical. He wasn’t doing anything he didn’t want to do or even that he didn’t benefit from, but it built a network. And everyone can find some way to do that, to share something they’re interested in or love or don’t mind doing, that they’re really good at, it’s easy and fun for them, or at least not too hard, and other people appreciate it.

[02:32:19] What most people think of when they think of networking is we’re all standing in some room for some random purpose, and I have a cocktail, and I have to go talk to people I don’t know and be like, hi, I’m Ethan. Why are you here? Let’s find something in common so you give a shit. And that’s an introvert’s nightmare. And I get it. And it’s hard to build a relationship where there’s no shared interest.

[02:32:48] What works about the skiing example or anything else is the one guy liked to ski. Well, the people who were getting the tickets also liked to ski. So they immediately had something in common. Oh, are you going this weekend? How was the snow? Conversation is easy. And then once you’ve talked a little bit, it’s easy to go deeper. That’s how you build a network naturally, organically. Every engineer has some piece of technology that they know more about than the average engineer and that they’re excited to talk about.

[02:33:22] Talk about it. You can talk about it in recordings. You can talk about it in forums, on Reddit. It doesn’t matter where. Share value.

02:33:30 — How to network with powerful people

Ryan:

[02:33:30] I like this version of networking, but of course I gotta ask the dark version.

Ethan:

[02:33:34] Of course you do.

Ryan:

[02:33:36] Which is, I stumbled upon this post and it is the basic principles of politics. And it was saying, step 1, be aware of who’s powerful and who’s not. Step 2, help the powerful people as best you can. Yeah. Step 3, make sure they know that you’re helping them. So this is a little bit of a darker, more Machiavellian framing of networking. A lot of people, let’s say they’re going for a promo, they want to think, okay, how do I make that VP that’s making that decision like me?

[02:34:12] Is there a way to do it organically that you would recommend?

Ethan:

[02:34:17] There are ways. Let me give you a few. First, let’s take this VP. You can take a couple shots, like, “Hey, I’ve built this thing where I get bulk ski tickets. I don’t know if you go skiing, but if you do, 375 people around the company are using it. Is it something you’d want to use?” That’s one way. It talks about something you’ve done, and maybe you’ll get lucky and they’re like, “Oh, yeah, I ski.”

[02:34:42] How do I get some tickets? That’s one way. Same thing with if you’ve built a tool or you’re sharing your expertise, you can be like, hey, I built this interview tool, or fill in the blank what you did. I don’t know if it’s of use to you, but a lot of people in your org are using it, so I thought you’d want to know it existed. And that’s just a way of dropping in like, you may or may not directly value what I do, but I’ve got a line on a bunch of your people.

[02:35:07] And they’re really like in your dark world, powerful people always want to know who’s influencing my people. They’re like, oh, you’ve attracted attention from a third of my people. I better know you and keep an eye on you. And that keep an eye can be like, I got to watch you. But it can also be like, maybe there’s a way to use you. And so that’s a door in. But the other door is if you built a network, someone in your network knows that person.

[02:35:37] And so what you do is you go to one of their direct reports or whatever and say, hey, I really would like to get to know our VP. I haven’t figured out. We don’t have any common interests I can figure out. You know them. Would you be willing to put in a good word for me or suggest that they do a skip level with me? Or can you help me get in front of them? And because you’ve built a relationship with the person in your network and you’ve helped them out with ski tickets or whatever, they’re like, yeah, I can help you out.

[02:36:06] Let me think about that. So I’ll give you the dumbest example that blows my mind. I do charity work for Ukrainian refugees that were driven out of Ukraine by the war, and they’re in Poland. And early in the war, I wanted to get a bunch of suitcases of medical supplies and other gear shipped from the US to Poland free on a United Airlines flight. So I went out to my network. It’s a very empathetic story.

[02:36:35] So I had that to my advantage. I said, oh, I want to get medical supplies to Ukraine. And I need somebody who knows people in United Airlines that can help me get 10 suitcases sent for free on this flight. I was thinking, who knows what’ll happen? I get an email back from someone in my network who says, I know the chairman of the board for United. I’m going to connect you to him in email. Now, this is using a sledgehammer to kill an ant.

[02:37:03] But I get this email a little bit later, I get put on email with this guy, chairman of the board for United, who’s like, hey, I hear you want to help some people displaced by the war. What do you need? And I wrote him an honest note being an executive. I’m like, dude, this is such a waste of your time. Just delegate me to someone. Here’s what I need. And he was like, it’s cool.

[02:37:24] I like to help people. Well, all the bags went on the airplane for free, but when the guy who was flying with them went to drop them off, the whole team from United met him with a gift basket, which is just stupid overkill. The point I’m making, though, is I had built a network, and then I needed something random, and I didn’t even ask a specific person. I just put out there into the world, I need help reaching someone in power at United.

[02:37:56] And I ended up with the chairman of their board. I could tell three more stories that are almost the same level of, I reached out for help and I got this overkill. You go through an intermediary who wants to help you. Here’s the key. I’ll give everyone a key. Helping people makes you feel good. So when someone in your network asks for a favor, if it’s a favor you can grant easily, you get to feel so good and it didn’t cost you anything.

[02:38:28] So, let’s jump to the situation of the guy who introduced me to the chairman. For him, he gets this note, he sees it on LinkedIn, he’s like, oh, he needs help, he’s doing something good, he’s helping refugees. Wow, that’s really good. If I help him do that, that means I’m really good, and I know the chairman, and he’s gonna go along with it. Wow, all I gotta do is send an email and I look like the tooth fairy.

[02:38:59] Now, if my friend is listening to this, I’m not saying your motivations were that base because it’s legit to be like, oh, refugees, I want to help them and I can. So it wasn’t like he was like, oh, I get to feel good. But believe me, I’m sure he did feel good. And that’s a great feeling. So the reason networking works is you’re finding someone and giving them a way to feel really good and magnanimous.

[02:39:23] And we all love to be able to pat ourselves on the back about what great friends we are. I’m just opening the door for you to have a chance to do that.

Ryan:

[02:39:33] When you were a VP at Amazon, did you have people coming up to you and clearly there was an ulterior motive and they were trying to, I guess, quote unquote network? What’d you feel in those cases? What’d you do in those cases?

Ethan:

[02:39:48] So I’ve already shown you I’m very blunt. I had engineers three levels below me or four levels. I had big organizations. So way down the org, they’d come to me and be like, hey, can you mentor me? Or can I have a monthly one-on-one with you? And I’d be like, so I have absolutely no time for this. I have no time to put you on my calendar, but here’s the deal. I’m gonna give you one meeting.

[02:40:11] You’re gonna bring me something really interesting I don’t know. And you’re going to bring me value in that meeting. And if you do, we’ll have another one. That’s your shot. Go do it. That’s— and if they wanted something, I would just tell them like, what’s the price? I’ve said, bring value. Okay. I will do what you want. Surprisingly, I will say yes. But what are you going to show me? Make it interesting.

[02:40:37] And that was actually my challenge to them often, which is, my job’s kind of boring. It’s a lot of meetings, a lot of pushing paper around. Bring me something interesting. If you can keep my interest, we’ll keep meeting. As soon as you become boring, well, it was more of a chance than sorry, I’m too busy, right? So a lot of people were good at it, and some of them never came back, and I’m okay with that.

02:41:01 — How to learn hidden incentives

Ryan:

[02:41:01] Most people I feel like are not as direct with their incentives. And so in those cases, how do you find the things that people want or what their goals are, how you can help them? In a way that can make some win-win interpersonal dynamics?

Ethan:

[02:41:17] So I think you want to build a trusting relationship so you can have more of that talk, even if you can’t use as blunt a language. But before you do that, or as you do that, I think there are four ways to figure out what people want. One is to directly ask them. We’ve kind of talked about that. The second is listen to what they’re saying. What are they talking about in their all-hands? What are they talking about in the staff meeting, whatever?

[02:41:42] What are they saying are the problems? What are they saying are the goals? Because those are—they’re talking about the things they want and don’t want. The third way is ask their direct reports, ask others in the organization who know them or have a relationship with them. This is called triangulation. Rather than asking them directly, you go out and you cross over and you see what this person says they think they want and this person, and you figure out, okay, what are they telling others, even if it’s only little bits, or what are others inferring?

[02:42:17] So you triangulate. The last way is observing them. Actions speak louder than words. Where are they putting their money? Where are they putting their time? Where are they hiring? Where are they spending their time in meetings? Their actions are going to show what matters to them. So four ways: ask, listen, triangulate, observe. Those are the four ways to figure out what they want. And then, more or less, those are the same paths to start going at them and adding value.

[02:42:50] You start moving towards the things they value and then finding ways to come to their attention, or whether you send it up through friends or you send it up through a status report, or when you bump into them in the hallway, you find different ways to showcase that you’re working on the things they value and asking how you can help. And again, this is less direct than the Ethan, let’s make a deal kind of way.

[02:43:24] And some people are even bothered by that idea that I’d say, let’s make a deal. That door was open to everyone. Make a deal with me where you deliver more value and I will find a way to help you move you up. That’s a fair deal. It is the corporate deal. The more valuable you are, the more I can pay you. So bring more value, I’ll give more value. Fair deal. And therefore, I don’t think dealmaking is bad.

[02:43:45] It’s just explicit. But for the people who aren’t so transparent or transactional, they do still have all the same goals and motives at some level, which is progress. You just have to find a way to do it in their style. And their style is less explicit, more implicit. You’re going to have to tolerate more ambiguity because if you’d like to have that clear statement of you do these three things and I will do my best to get you promoted next cycle, you’re not going to get that from them.

[02:44:16] So you’re going to have to be like, well, I can see who they’re promoting and what they’re valuing. I’m going to do those things and trust. You’re going to have to weather more ambiguity. I have found that if you build a relationship with people, most people, they may never be willing to be transactional or explicit with everyone, but they will do it with you inside the confines of that built personal relationship.

02:44:43 — What happens behind the scenes with HR

Ryan:

[02:44:43] When I was working at Meta, when someone’s underperforming and then they get managed out, it’s more clear even if no one says anything. But there were cases where someone came to work on Friday and then on Monday they were gone, and there was no clear evidence of why they would disappear. So in those cases, it felt like there was some secret HR thing that had happened. And at the time I was just a software engineer, and I just thought, okay, I don’t know what just happened to that person, but they’re gone.

[02:45:16] And it was not performance because I had worked with them. As a VP, I imagine you knew a lot of the things that happened. And so in those cases where people just disappear suddenly, what is it that goes on behind the scenes at the HR team?

Ethan:

[02:45:33] Well, I mean, a lot of those so-called disappearances, they’re the case where someone did something, frankly, that put the company at some kind of risk. So they’re usually the bad things. Racism, theft, embezzlement, sexual harassment. I will tell a story. I know someone, they had a strong political opinion on a topic and the company was doing something they saw as inconsistent with that. And they leaked an internal memo to a reporter, and then they got caught.

[02:46:06] They didn’t think enough about how the company’s IT systems worked. And they left a paper trail. And after the news report came out that obviously the reporter had had access to information, the company tracked it back down to them and they were gone. I actually, now that I think about it, I saw several people fired for leaks. So a case that you might not think of that gets people broomed that isn’t like interpersonally gross, like a sexual harassment thing, is stuff like that.

[02:46:44] Leaks, sharing competitive information. Sometimes they’re just dumb. Another story I tell, we didn’t end up firing this guy, but we very easily could have and no one would have blinked. At one point I ran a video game team, and that team made violent shooter games. One of our artists one day brought in his actual real firearm collection, spread it all over his desk. And when other people walked in, his desk was covered with guns.

[02:47:10] He was totally innocent. He was making up new weapons, and he wanted his guns as models and inspiration. And it never clicked with him how having a desk full of guns in a California office might wig some people out. Now, if we’d have just been like, guns in the office, done, nobody would have said a thing. We figured out, okay, there’s a difference between thoughtless and actually planning on murdering your teammates.

[02:47:39] So we’re just gonna send you home with all your stuff and tell you please never do that again. But that could have been gone. So people make the dumbest—the stuff that happens you would never believe. One time I came back to my office from a business trip to visit another office. My female executive assistant and one of my female employees greeted me at the office door and said, we got to tell you what happened while you were gone.

[02:48:11] And every alarm bell for a manager at this point is going off. It’s where, it’s Amazon, so it’s mostly male. I have a female leader and my EA, who are both women, saying they have to tell me what happened. I know it’s going to be bad. Well, what had actually happened was so unbelievable. What had happened was my employee came in, the leader, and found a pile — we had dogs in our office.

[02:48:38] We had a pet policy, right? You could have dogs. She found a pile of poo under her desk and she’s like, gross. So she calls the building maintenance, like, dog had an accident. The woman gets there to clean it up and says, This is not dog poo. So they call security, like, there’s human poop under the desk. And so security is pretty smart. They ask her, like, has anybody been showing unusual attention to you?

[02:49:04] You know, blah, blah, blah. And she’s like, well, now that you mention it, there’s this one janitor and he seems to hang out and whatever. So they go grab this janitor and they quiz him like security does. Well, he cops to it. And this was his way of showing— obviously he was not normal the way we did. It was his way of showing interest was he had— but when I say you wouldn’t believe what goes on, of course he was fired and given a restraining order to go with it.

[02:49:37] Like, you can’t come near the building again or her. But when I say you wouldn’t believe — ‘cause when I tell these stories, people bringing guns in, like, “Oh yeah, it’ll be fine if I just spread them out all over my cube,” or “I’m gonna show my affection or interest by” — you wonder what were they thinking? And the answer is they weren’t thinking in a normal way. People both do things that are unethical and they’re very intentional, but they also do some stuff that later you’re just like, wow.

[02:50:11] That’s why those people disappear.

02:50:13 — Did he burn people to get ahead

Ryan:

[02:50:13] We’ve talked about gray areas all throughout this conversation, and you mentioned this situation. I think you said it was like Joe Blow that gets the F or whatever. Yeah, this other person gets the A. There’s this implicit framing of one person’s gonna get ahead and one person’s gonna get put behind. And so in your career, were there ever cases where you had to burn someone to get ahead?

Ethan:

[02:50:43] I would love to say no to that. I’m cautious to say no because of rationalization. There are definitely places where I competed with people. There were definitely places where I was trying to make sure I looked better than others. I’d like to say that was always me doing superior work. Is there ever a case where I targeted someone to burn them down? I don’t think so. I think there were definitely places where I did everything I could to make sure I came out ahead.

[02:51:17] I think one of the cases I feel worst about wasn’t anything I explicitly did to someone on purpose, but when I first joined Amazon, and when I mean first, I mean the first week. I had been hired without being told what my job would be. It was a secret project, and all they would tell me was the general area, but I couldn’t know what the project was, and I had to accept. So I got there and I went to my boss and I said, hey, I’m here now.

[02:51:44] What the hell am I doing? And he said, well, we have 2 jobs open. One of them is building our next video product, our first video product. And the other one is building the ingestion systems that will be used to ingest the video and also will support our music project and our books project, what became Kindle. Which one do you want? Well, I’m an end-user guy. So I’m like, I want to build the end-user thing.

[02:52:14] I’m not an infrastructure person. I want to build the video product. He’s like, great, done. What I had no idea, another manager started the next Monday, and they had apparently told him he could build video, and he got the infrastructure project. He joined for the job I had asked for. I had no idea, but the result of my action was he got put in a job he didn’t want. And I think it sucked for him.

[02:52:41] That’s the closest I can think of to where something I did really screwed someone else in a, and that lasted, that was his job for the next 2 years. Now, the other thing, if I had been told, well, there’s 2 people, I would’ve still fought for that job. I’d have still said, can’t I have it? I’m good at that. I have history in that. Why didn’t you pick me? So I would’ve still fought for it.

[02:53:11] But it would’ve been because I wanted that job, not to screw him, but it had that side effect even though I didn’t know in that case. But I would’ve pushed for it, sure, because I want to do what I want to do just like everybody else.

02:53:24 — What he says to people who hate politics

Ryan:

[02:53:24] When we make these videos, it’s very polarizing because there’s a big group of people who say, thank you for saying it as it is. This is so helpful, and I’m going to be aware of this and use some of these tips in their career, and this is how the game works. And then there’s a group of people that don’t engage with the content fully. They just hear something that they don’t like on a moral level almost.

[02:53:47] They hear, “Oh, how could you think that? How could you say that?” And what would you say to those people that say the premise of all this stuff, the premise of the game, is distasteful? It’s not something they even want to believe, for instance.

Ethan:

[02:54:04] Yeah, so I have a good friend who takes exactly that viewpoint. And we argue all the time. And the premise is this game sucks and no one should have to play it. And the fact you’re talking about how to play it means you’ve already bought into the evil side. What I would say is this game is real, and I wish it wasn’t real in some ways. I wish we could all be judged on our intentions and on our merit, and we were all seen, you know, we all had unlimited opportunity and we were all rewarded for what we really did.

[02:54:40] I wish those things were true, but I don’t know how to make them true. So what I say is I try to make them as true as possible for people working with me and around me. That’s why I’m so transparent, not only with you. I was pretty transparent at Amazon, and I made deals, and I did everything I could to keep them. And I’ve been honest about, I still regret 20 years later, this one guy I let down. It still bothers me.

[02:55:10] But humans, human society is full of nasty people. And it’s also full of limited resources and competition. And I think this is reality. And so I get that all the time. I hear people are bothered by the reality, and they want me to make the world just. I don’t know how to do that. I know how to work towards it, but that’s going to take well beyond my life or your life. And we see that because if we look at all the nasty things that happened in history, like slavery or oppression or limitations on women’s rights, I dismiss none of those.

[02:55:49] But they’ve been ongoing battles for a century or more. They’re not going to be solved this year or next year. So I coach women all the time how to get ahead in a biased world. Does that mean I support bias against women? Absolutely not. But I can’t fix that this year, and those people have to try and move their career ahead this year. So what I would say to the people who dislike it is I am trying to deal with what’s going to happen this year while also working on rights.

[02:56:18] I think people can throw stones at me, but when I talk about, I started a charity in Poland to help refugees from Ukraine, it’s not like I don’t believe in causes and I’m not willing to tilt against windmills and try and right injustice. That’s my particular cause. You may wish I worked on your particular cause, but if you just objectively say, does this guy try and do good? I do. But I also have to deal with what is reality today?

[02:56:46] Moral situation. I made a friend who’s Ukrainian. Her husband voluntarily joined the army in Ukraine. He served 2 years. He wanted to get out after 2 years of volunteer. Ukrainians need soldiers. They wouldn’t let him out. He was going to be sent to the front in a place where he would likely die. We knew that he could be bribed out of the army. It was relatively little money. It’s about $1,000.

[02:57:15] So a friend of mine and I gave his wife $1,000, and she went in and bribed her husband out of the Ukrainian army. Probably some other dude we don’t know died in his place. So American wealth, because we knew this woman, saved this guy’s life, killed this other guy. It’s very real. And I am completely okay with it because I know her and she’s my friend. I didn’t want to kill the other guy. Maybe I didn’t.

[02:57:39] I get to have plausible deniability. Maybe it’s all happy. Nobody died. But I deal in that reality. She was important to me and I could help her. He had served some time. He had done some duty for his country. I was okay letting him out. Right decision or not? I don’t know. Like me or don’t. I’m okay with my decision. Same thing as all the corporate politics. I teach people how to deal with the world that is.

[02:58:10] The world that is was he’d served some time, and probably he was going to die, and this woman I cared about was going to be hurt, and it was going to cost me relatively no money to save his life. I was okay with that. There are 50 ways you can say that was an evil decision of mine. There are also 50 ways you can say, wow, you did something remarkable for that woman, and you’re trying to help other people there.

[02:58:38] So here’s the thing I think about some of the critics. They have an ideal in mind. It’s a great ideal. I support their ideal, but you got to understand it’s an ideal that we’re far from. And just because I deal with reality today does not mean I think your ideal is wrong. I’m just trying to also live today and help other people do that.

02:59:03 — Top book recommendations on power dynamics

Ryan:

[02:59:03] I polled people on Instagram, and one common question people were asking is, do you have any book recommendations on power dynamics or people or these kinds of topics that we discussed that you’d recommend to people?

Ethan:

[02:59:20] I have several. So my all-time favorite book on this is called Leadership and Self-Deception by the Arbinger Institute. It’s a book that explains how we sometimes treat other people as objects without meaning to. But if we objectify people, which means we treat them as a roadblock, how do I press the right buttons to get the response I want? That doesn’t usually get a good reaction because they feel manipulated.

[02:59:48] But if you treat them as a human and, hey, I know this is hard for you, I know you’re busy, how can we make this work? Here’s what I need. And with warmth, they’re more willing to help because people seen as humans will treat you back as a human. That’s that book. Second book is Chris Voss, Never Split the Difference. That’s all about negotiation and about understanding how human motivation works.

[03:00:13] All of this is human psychology. So all of these things are human psychology. The third book, even though I hate to recommend it for all your interest in dark side, is The 48 Laws of Power. It’s a very thorough catalog of the dark ways people think and manipulative tricks. You can either become that person who manipulates or you can at least become aware of how psychology can be pulled on and see some of it, and it will open your eyes for better or worse.

03:00:45 — How he would speedrun career growth today

Ryan:

[03:00:45] In video gaming, there’s this premise of speedrunning, and this is basically trying to get through a game as quickly as possible.

Ethan:

[03:00:53] I worked at Twitch. I know speedrunning.

Ryan:

[03:00:56] Imagine you’re playing the game speedrunning, any%, you’re trying to just get to a VP level and you start at the beginning. At Amazon, what would you do? What might you change today?

Ethan:

[03:01:11] Yeah, so first thing is I would not be planning on getting a VP at Amazon. That’s not gonna be a speedrun at this point. And the reason is the company’s not growing the way it was. It grew while I was there, grew 100-fold. That meant endless opportunity. It’s not true anymore because it’s not got the growth. So what I would do if I was at Amazon today is I would say, how can I suck as much information and technique out of this company in 18 to 24 months to get more skilled, and then I’m going to have to go somewhere that’s high growth.

[03:01:43] And so I’m going to try to become an expert in a skill that will get me bought externally, which probably means AWS. It could mean a few other things, but I’m going to try and become enough of an AWS expert that someone who needs AWS knowledge will hire me in at a higher level in a high-growth place. And then I’m going to go find a high-growth place that wants to use cloud computing. Hopefully the stuff I’ve been working on, and I’m going to pitch to them, bring me in and I’m going to be your solution to adopting this fast, well, and cheaply.

[03:02:19] Then I’m going to deliver on that and talk to them about, okay, how do I move? That’s where I’m then going to run this. How do I move up? I want to grow in this way. I want to lead. Now, the next thing you’re going to need to do is speedrun. You’re going to need some management skill if you want to be a VP. You’ve got to be good at the job. You’re not trained in that. So you’re going to have to start studying the psychology, the organization, the risk-taking, the decision-making.

[03:02:42] The next thing I will say is favor gambling, favor taking risks. You’ll probably move up faster by shooting for big wins and missing a few because you can always— unfortunately or fortunately, you can always leave behind the smoking ruins of your disaster at one company and try again somewhere else. And eventually, if you take enough big swings, you will hit one. So I’m going to use a baseball analogy from the book Moneyball.

[03:03:14] You can either bat for on-base percentage, and I want to swing to get a safe trip to first base. And that’s actually easier than trying to hit a home run. But if what you want is the home run, you got to swing hard and wild. A little bit, and you’ll strike out more, but you’ll get a few home runs. And that’s actually what makes you famous. Nobody cares that you got on base. They like to see the ball fly over the wall.

[03:03:38] So that’s—I would leave Amazon with my expertise, with the Amazon name on my resume, go somewhere high growth and start giving them value, asking for advancement, and taking risks. If I succeeded, I’d move up. If I didn’t, I’d hop again. And that would be my way. When I found a high-growth place where I was succeeding and moving up, I’d then ride that. That would be the end of my speedrun, but that might be the 3rd or 4th company.

[03:04:09] There was a time, I know many people who went from entry-level at Amazon to VP. They’re VPs today, but I don’t think that’s repeatable without 35. There is no speedrun of that today. There’s like a slug run. I don’t know what the opposite of a speedrun is, but it’s very slow. And that’s what a playthrough— what’s the playthrough where you complete every quest? It’s that one.

[03:04:34] And it’s slow as shit. And that’s what’s left. And it’s because a company that grew from 14,000 employees when I joined to 1.4 million when I left is now still more or less 1.4 million. The opportunity is not there. And the same as you were at Meta. Meta used to grow like crazy. Now it’s shrinking. I’m sure many careers were made at Meta, but I don’t think they’re being made the same way now.

[03:05:01] What you did at Meta, because I know you had a lot of success there, I don’t even know— do you believe that’s repeatable at Meta today, this moment?

Ryan:

[03:05:12] Maybe through the early engineering levels, but not at the higher levels where the business case matters more, I would say.

Ethan:

[03:05:19] Right. So that’s why to VP, it’s not possible. You totally could stay at Amazon to go L4, which is the entry level, to L5, maybe L6, but from there it’s out.

Ryan:

[03:05:31] Go out somewhere that’s gonna be faster because other people are gonna value that expertise way higher than Amazon does.

Ethan:

[03:05:38] One thing I’d say about Amazon that makes this interesting, interesting answer. They have 50,000 L4s or whatever, 30,000. I don’t know the number. They have 50,000 L5s. That means you’re just a number. You can go somewhere where you’re the only AWS native engineer. That is turning being one of 50,000 L5s into leverage in another company. It actually drives Amazon nuts because they can’t afford to pay all 50,000 L5s what each one is individually worth to externals.

[03:06:16] So they’re always getting snapped up by companies who are like, having that person in here is going to save us a ton on our bill and our implementation time. So they’re worth $300,000 to us, but Amazon‘s only paying them $200,000. Buy them out.

Ryan:

[03:06:31] Thank you so much for your time and your transparency. For people who want to find more of what you’re doing, where can they find you?

Ethan:

[03:06:39] Two places. ethanevans.com is my website. It links to everything else. Or find me on LinkedIn. I’m Ethan Evans there. You’ll find me in a heartbeat.

Ryan:

[03:06:48] Awesome. Well, thank you so much for your time, Ethan. I really appreciate it.

Ethan:

[03:06:50] Thank you, Ryan. It’s always a pleasure. I know you have an endless list of questions, so someday we’ll continue.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:37 - Growth past IC9

05:39 - Motivation changes over his career

11:36 - Asking to not be promoted

17:33 - What made it hard to sustain IC9 performance

22:22 - What motivated him outside of promos

26:21 - Is career advice useless

29:34 - Motivation after you’ve hit FIRE

36:08 - Meaning and fulfillment

38:17 - Top book recommendation

40:14 - What he would change

Transcript

00:37 — Growth past IC9

Ryan:

[00:37] Last time we talked, I focused almost entirely on, you got to a distinguished engineering level. You grew very quickly. How’d you do it? And this time I wanted to focus more on what happens when you hit your terminal level. Or what I mean is there’s this idea of a career asymptote, which is no one can grow forever. And at some point, you’re going to get to a level where you can’t go any further, and you may have 20, 30 years left in the career.

[01:15] So what I wanted to ask you is, when you got promoted to IC9 or distinguished engineer, which is crazy high, that’s like four levels higher than a senior engineer, what was your immediate thought? Were you thinking, “I want to go to IC10? Does that exist?” Or are you thinking something entirely different?

Philip:

[01:36] Yeah, I honestly didn’t think about it when I was earlier in my career. I really just assumed that, oh, yeah, you go for a promotion and once every few years you get promoted. And I never once thought, there’s gotta be an end to this, right? Like everybody, there’s gotta be an end, right? And I think many people might not think that through, right? And so for me, it took many years before I figured out.

[01:59] Even at seven, for instance, I felt like, oh, hey, things have got to slow down. Because it gets harder and harder. The amount of scope that you need becomes tougher. The number of roles that offer the opportunity actually gets smaller because the organization also needs that scope of work, right? So, for instance, at Microsoft, oftentimes when they reorganize, they figure out, hey, your organization should at most have four partners.

[02:25] And that’s just a budgetary sort of thing. That’s a business opportunity thing. So you need the opportunity as well. And so when I was growing to IC9, I think I just didn’t think of going any further as realistic. I was at Facebook when they first created level nine, right? And I remember that three level eights were promoted into nine. And at that point, those three level eights were all universally loved and known throughout the company as obviously super senior technical people.

[02:57] And to me, that felt unreachable. If I’m honest, when I think about those folks and the type of work they were doing, that really felt out of reach for me. So I think definitely by the time I got to IC8 or IC9, it really felt like the end is near.

Ryan:

[03:12] Well, a lot of people might feel that sooner in their career, too. What kept you pushing past the staff level or the senior staff level? 6, 7, 8, 9.

Philip:

[03:24] When I got all the way through to 7, I think, which was at my 12 years at Microsoft, right. I was really personally ambitious for level growth. And I think the reason was, in school, I loved tests. I loved grades because I was good at grades and tests. When I started professional work, there was nothing quantifiable. It wasn’t like once every two months you got a test that told you you were doing well.

[03:48] So for me, promotions became one of the very few quantifiable things, right? It’s sort of like, well, how much money do I make? And there are so few things that are actually numbers, right? So to me, a level was almost like an achievement number. And so throughout my 20s and my early 30s, I was really ambitious to get through all the way to level seven. But I think starting there, I just realized the nature of the work changes with every additional level that you go into.

[04:17] I wasn’t sure that I would like the end of work, first of all. And then the other is I felt things slowing down rightfully, because everybody has a talent limit, right? So for me, as I approached that, I just began to feel like I was no longer ambitious for the further growth. So I would say my growth into 8 and 9, neither of those were things that I was seeking myself. I was, by that point, doing the work I found interesting and trying to do a better job of it, as opposed to.

[04:46] I would characterize my time, especially in my 20s, as mostly focused on how do I grow to the next level. Tell me what I need to do, that sort of thing. By the time I went from 7 to 8, getting to 8 was honestly a surprise for me at Facebook, because getting to 8 was the first time I learned that there were levels at Facebook. When I joined Facebook, it was 500 engineers, right? Everybody was focused on the work itself and did not worry about careers and stuff, which I think is normal for small companies.

[05:15] When you’re on a big mission, you’re just trying to get the mission done. So I didn’t even learn I had a level until my boss, who was Boz, said, “Hey, congratulations, you’ve been promoted to level eight.” And I was like, “What? There’s a level here? That’s kind of amazing. Thank you.” So I think I stopped focusing on the level itself, and my promotions became more a consequence of the work that was being done.

05:39 — Motivation changes over his career

Ryan:

[05:39] Early in your career, it sounds like you were constantly maybe harping your manager and saying, how can I get promoted? What’s the next thing? And later you transitioned into doing meaningful work and getting promoted as a byproduct. What was it that changed in your mind where you went from that mentality to promos don’t matter anymore?

Philip:

[06:02] Yeah. I think there were two things that come to mind. One was that the thrill of the promotion itself was no longer the same as when I was younger. So I think when I was younger, because I sought after those grades, those measurable metrics, I very much felt great every time I got promoted. This was wonderful, right? I think as I got promoted even into level seven, I started to honestly become a little bit.

[06:27] Not ambivalent about it, but I guess it wasn’t all roses to me anymore, the idea of getting promoted, because I realized that each promotion also came with much higher expectations. Expectations that I was no longer positive that I was going to deliver. When I went from a four to a five, I was confident that I could do this work. It’ll be great, right? And when I got to seven, I felt like.

[06:52] Like this is pretty much nearing the boundary of my capability. And so I felt a lot more comfortable saying, hey, if they keep me here perpetually, it is still work I enjoy a lot. I think the second thing that really changed for me is realizing also that asymptote, right. Realizing that, you know what? Maybe this ultimately is my final level. I was so humbled many years ago when I had this lifelong mentor throughout much of my adult life that was one of my best managers at Microsoft.

[07:26] And I recently, just in the last few years, thought, you know, there was this one conversation where he promoted me into level seven. And I said to him, “That’s great. Thank you. Let’s talk about how to get to eight, right?” And his first response to me was like, “Philip, can we just take at least one one-on-one to celebrate the fact that you’ve actually reached this tremendous level at Microsoft?”

[07:46] And I honestly felt like, no, we can’t. I’ve got to keep going. But years later, I realized he himself was probably 15 years more in industry than I was at the time. And he himself, in hindsight, had to be a level seven. He was not a partner at Microsoft. And so for me to come across sort of so naively without considering, for instance, his feelings or considering just realistically, this is a guy I look up to a lot, and he’s giving me mentoring advice all the time.

[08:15] And he himself is level seven. And so for me to be pushing so hard, I think just the humility of realizing that people do tremendous work at those levels, and I should just appreciate that if I can even keep up with the expectations, that’s already kind of a big accomplishment.

Ryan:

[08:33] If I were to think from when I was at my youngest, the beginning of my career, my thought would have been keep pushing. And the thoughts that you just said are noble, but let’s go to eight. Let’s go. Yes, this person’s at that level, but I want more. I want more. What calmed the, I guess, the crazy energy of I want more, even if it’s not realistic?

Philip:

[09:04] I think some of it might be as simple as age, to be honest. And I think society is designed to work this way, right? Like young people go to war, right, traditionally. And there needs to be this ambition of, I’m going to build great things, I’m going to do great things. I think that energy from the young is super powerful. And I definitely don’t want to sit here and say, let’s quell all of that.

[09:25] Like, let’s make sure when a person is 23 and they start work, they’re like, E3 is fine, right? So I definitely want people to have that ambition. I think maybe some of it is the natural aging process, but I do think, at least for myself, a lot of it was the shifting nature of the job itself. I would say for me, up until, let’s say, an IC6 level of work, it just felt like doing the same stuff, but grander, if that makes sense.

[09:53] You’re still coding all day. You’re meeting with engineers primarily and product managers, sometimes designers, but it’s just about doing it at a much higher amplitude. I’m now gonna do much bigger refactors. I’m gonna participate in longer-range projects. Oh, we should do this new service that does X. But I think beyond that the nature really changes to where just doing more better is typically not how people get there.

[10:19] You will find very rare cases, for instance, where people can do more better, but they are preternaturally gifted for super fast coding or whatever. I was definitely not that person because I was much more a generalist. And so for a generalist going beyond six, I think it does change the nature of the work such that you’re doing maybe less direct coding, for instance, maybe even less direct architecture stuff, but much more things like team direction.

[10:45] Is this even the right product to be building right now, given where the industry is moving? Maybe trying to influence even another organization that’s on a collision path, right? Maybe trying to find a mutually useful way to land both sides. So I think that also, pragmatically, as you go up higher in levels, it’s almost definitely true that you will have more meetings, just period. Whether you’re an IC, whether you’re a manager.

[11:10] That’s just what it is. And plenty of people, for whom directors, as an example, every single hour’s meetings and half of the hours are double booked. And so they’re just choosing which one to go to for that, right? That’s typically how, one small example of how the nature of the work changes. And so for me, as the nature of work changed, I was less enthused about how it might continue to change if I continued getting higher level.

11:36 — Asking to not be promoted

Ryan:

[11:36] You mentioned that you sought out a demotion from IC9 to IC7, or distinguished to senior staff. Did you ever consider saying to your manager, I don’t want to get promoted?

Philip:

[11:48] Past IC7 from going to 7 to 8? Not really, because I didn’t know levels had existed at that point. So that promotion was sort of like a surprise, right? But I think if I’m honest, Facebook was also so small even back then. I was promoted into eight maybe one year at Facebook. I was a seven at Microsoft for probably three years. So you figure, like, let’s say four years, right? One year into Facebook, I get promoted to eight.

[12:14] Facebook was still, I want to say back then, 800 engineers globally. So the company was much smaller. And I think when a company is that size, the work doesn’t include as much meta work. The work is mostly the work. So you’re doing the code, you’re doing the actual. Whereas I would say my even at Facebook many years later, when I came back to Facebook Seattle, when I joined, I was the second person who joined, right?

[12:41] So the office was four desks. When I went to Facebook London for five years and I came back, the office was more than 2,000 people. And so just like that, mind-blowing. Size means that the typical senior job when an organization is tens of thousands of people is a lot more people wrangling, I guess, and a lot less technical. I think one of the struggles I’ve had throughout my career is so many higher level jobs, including a solid IC6, quote unquote.

[13:13] Just coding has to do with how well they work with others. And in some environments I just don’t work very well with people like others do. I would say objectively when I was leading the Facebook London site, I was good at the job. It was a very people-focused job. But for me, the happy parts were people like welcome to the team or, like, hey, going to do this collaboration with Menlo Park and all this stuff.

[13:37] I think there’s another type of people-oriented thing that happens at large companies, which is a lot of what people might call politics, but a lot of work that has nothing to do with the actual software deliverable but has everything to do with the fact that when three or more people are somewhere, there’s politics. Just figuring out the people thing. Dealing with unhappy people, for instance, is something I’m very bad at.

[14:03] Giving people constructive feedback is something that I am fairly bad at. And so more jobs at those levels just require even an IC7. Minding your own business is probably regularly supposed to be giving pretty helpful feedback to other engineers. They’re not their managers, but still you should be improving those around you. And I am much less good at that.

Ryan:

[14:26] When you sought out the demotion from IC9 to IC7, I’m just thinking for someone who’s thinking that the success criteria is going up in levels, it would be very difficult to accept going down from, you know, kind of like undoing all that hard work, quote unquote. What was that process like?

Philip:

[14:50] I think it was hard. I think it was Will Smith or someone else famous said getting famous is amazing. Being famous is a mixed bag, and then getting not famous is horrible. And I think that’s human nature, not just about fame but about anything, right? When we are growing in anything. Let’s suppose you first get into auto repair, right? The first big job you do beyond an oil change feels like success.

[15:15] Right. Eventually you’ve removed an engine, you’ve done clutches, and at some point, like my age right now, I literally just started giving away some of my auto repair gear because I’m realizing I’m not doing this as much. Physically, I’m not as capable of doing it. And that feels a little bit sad. And I think the same thing happened to me in my software career, which is on the way.

[15:40] Rising up, it always felt great, right? Other than the rising expectations and the worries around that. But the general thing felt like, oh, I’m progressing. Being at the top was a mixed bag. There were some amazing things. There were some very hard things. And then I think coming down, I feel like there were a few things that were hard about it. One was that I think I knew I could do more because I had done more before.

[16:09] But part of it was the feeling of being exhausted, running at that pace, and always having the Eye of Sauron, like roving the land looking for people.

[16:20] And I think the higher level you are, the more that you feel that intensity all the time, and rightfully so. You’re getting paid the big bucks. And so it’s right for a company to constantly question whether or not they’re getting their value out of you. So I think it’s only fair. But I felt that struggle. And I think the other thing that was hard for me about getting demoted down to seven was more that feeling that as I saw other people who used to be below me rise above me beyond that level, that was very difficult.

[16:52] I don’t begrudge them their success. So I’m not at all saying I’d rather go out there and make sure this person never succeeds. What I mean is more that I felt wistful, I guess is the right word, which is like, I was not crushed that someone else was doing better, but I did feel a little bit like I once could do that work. And part of me wonders if I could again.

[17:12] It’s like when Beowulf, at age 70, is asked to slay the dragon one last time. He gets out of his old house, and he slays the dragon one last time. Part of me wishes that I had that in me, that when I’m 70, I can be called upon one last time to do this thing. And I’m able to deliver at that level, but I know that maybe that’s not it for me. Right.

17:33 — What made it hard to sustain IC9 performance

Ryan:

[17:33] You mentioned that you used to be able to do it, and then you couldn’t. What changed that made it hard to perform at that level?

Philip:

[17:40] I think if I were to bucket it into a few categories, one is my environment changed. So as Facebook, the company grew, right? Senior ICs do a lot better, I think, in larger companies if they are domain experts. So you’re great at, let’s say, SQL optimization, right? And you’re helping SQL move on to SSD and you’re moving SQL into the cloud. That sort of IC does best in a large company. In a tiny company, a generalist does best because when I first started on video calling, I also negotiated the contracts with Skype with a third-party tester, with all sorts of things.

[18:18] So I’m negotiating contracts, I’m doing crazy things, but I’m also coding the thing, and then when the press release goes out, I’m talking to the press. So I’m literally meeting the press about the video calling feature, right? That is what a generalist excels at. And I could only do that because Facebook was small. By the time I came back to Facebook Seattle, and the Seattle office itself was 2,000-plus people, and the company was maybe, I don’t know, 30,000 people.

[18:40] There’s no way you would send me out to negotiate a contract with Microsoft. That would be ridiculous, right? And so for me as a generalist, my environment shifted to where specialists would survive better. And for me as a generalist, I was honestly just not as useful, right? For one whole six-month period, the team that I was on, the only mission for the ICs for that entire six months was to fix the bugs on this internal tool.

[19:02] So I spent six months fixing the bugs, which I’m happy to do, but I am not especially skilled at that. Right. And so I think one thing was my environment changed. I think the other thing that changed for me was I did tire a little bit of feeling like there was always so much pressure just to meet expectations, if that makes sense. So up until I would say IC6, I never felt the Eye of Sauron. Like I was never at any point in my career feeling like, oh, if I just fall a little below right now, maybe they’re going to can me.

[19:36] Right. But I think regularly at IC7 and beyond, once in a while I would feel like, oh, I feel like my own performance this half, I don’t know, things aren’t looking great, you know what I mean? And I think in a way it’s like when I was super ambitious, being like the slowest member of a team. But catching up and rising was exciting to me as I accomplished more in my career and I felt my happy places.

[20:03] I no longer liked the feeling of being the slowest on a team or feeling like I was potentially going to have a talking to at some point because I wasn’t performing to expectations. So I think that sort of pressure also was something that I no longer enjoyed in reality.

Ryan:

[20:20] That Eye of Sauron, though, was in your head rather than reality. Given that you got promoted from 7 to 8 and 8 to 9, right?

Philip:

[20:28] Yes. Maybe some of it is imposter syndrome, but I think a lot of it is actually just an honest look at myself and reality. So when I was an IC4 looking to go to IC5, right, there were plenty of IC5s where I felt like I could totally do that work. Just give me two years and I’ll be just as good.

[20:47] At IC7, I could see many IC7s where I’m like, honestly, if you put me on that guy’s team, I could not do that work. Right. I know I can’t.

[20:57] And so I think my realistic appraisal of my own abilities was more accurate to what they actually were.

Ryan:

[21:07] Right.

Philip:

[21:08] And also maybe some of it, if I riff on your theme a little bit, maybe some of it also is that as you get more and more senior, not only are the expectations higher, but the number of business roles where you are the perfect guy for the role actually is far, far less. When you’re an IC6, almost any team would welcome one. It’s like, great. Like, just pick up a keyboard and we’ll get going.

[21:35] But I think once you get to a certain level, it’s like, well, we need someone who’s good at marketing. And then this person has to also be somewhat technical, or the shapes become very specific.

[21:46] And I think that just realizing that my shape wasn’t right for many, many roles also made me realistically feel like maybe this isn’t the right long-term place for me.

Ryan:

[21:55] It sounds like over the course of your career, you worked an extraordinary amount. I mean, you mentioned last time we talked that you bring a sleeping bag to work. And I think early in your career it makes a lot of sense because you were so gung ho and you’re pursuing the promos, but then when you were at Facebook and you weren’t pursuing the promos, you’re just getting them because you were doing awesome work.

22:22 — What motivated him outside of promos

[22:22] What was your motivation to work so crazy hours at that time?

Philip:

[22:27] One of the most intense work periods of my life was shipping the first version of Facebook video calling. I had worked with Denise, with Chago, with maybe one or two others, with Vijay. That first version, when we went out, I think I went about six weeks down in Menlo Park, where I literally got up out of bed, went straight to work and worked all the way until I drove back to the apartment and went to sleep.

[22:55] I was eating junk food the whole day. It was like SunChips and whatever. But despite that, I lost ten pounds in those six weeks. It goes to show how intense brain-related work can be, but I had no idea there were levels. So obviously, a promotion was nowhere on my mind when I was doing this work. But I tell you, it was one of the most fun periods of my life because it felt so thrilling that I was directly impacting real users because Facebook was so tiny back then.

[23:25] You could see the users having errors right away. I was patching errors every day. It felt missional, right? It felt like this was the first time video calling was going to be easy for people without installing any software. WebRTC was relatively new back then. We still had to get some software with the first version out. And so I felt like this strong sense of mission, and being on a tiny team of three people also felt like, wow, I owe it to the other folks too, who are working equally hard to pull forward.

[23:55] So I think that was still in it for me, but no longer based on promotions as a thing, but more because I believed in what I was doing, and I felt that direct customer contact with people I could actually see getting positively impacted by the fixes.

Ryan:

[24:13] When you look back on a career of working so many hours, would you say that it’s worth it, and would you recommend it to others?

Philip:

[24:21] I think it’s become popular for successful people to tell people not to push as hard, and for wealthy people to tell people not to push as hard. And it’s understandable that people who aren’t as late in their career or aren’t as wealthy would say, well, it’s easy for you to say that, right? Because you’ve already gotten there. Like, I once had a guy say to me, “Well, it’s easy for you to say that because you’ve already been there, done that.”

[24:44] And I think at some level, yes. But I also think that there is sometimes wisdom that can only be gotten when you live a certain thing yourself. This is why when someone tells you money can’t buy happiness, nobody believes it, right? Everybody thinks there’ll be the one exception. And I think the thing is, you have to have lived a certain life before to really objectively be able to say whether it’s better or not.

[25:14] And I think for me, given my personality, the really much higher level roles that require broad impact and feel like a lot of pressure for me, just for my own personality over time, is not the right thing. But I would, at the same time, say, well, I don’t want to look a gift horse in the mouth. The freedom for me to, for instance, work on my own software right now, it only comes from having had a career where I got paid enough that I could save enough money that I can go two years writing my own software, right?

[25:46] And I don’t want to look a gift horse in the mouth and say, “Oh no, I totally shouldn’t have done that.” That’s not true at all. I think what it is for me is I would have appreciated, when I was younger, being more cognizant of the trade-offs that I was making. You know, like, hey, if I dig in really hard right now and I really work hard, then this will buy me the freedom when I’m 50 to work two years on my own software.

[26:11] I wish I knew that was the trade-off. Whereas I think at the time I was just blindly pushing forward, like, hey, I’m just ambitious. I want to do all this stuff.

26:21 — Is career advice useless

Ryan:

[26:21] And in your career and your life in general, you must have mentored so many people. And like you said, if you give someone advice and then they can’t really take it until they actually experience it, is all advice useless? Then what’s the point?

Philip:

[26:43] I think there is still a point, which is there’s a massive difference between you ignoring advice and you not knowing the advice was even there. And I think the difference is two things. One is when you have the advice in the back of your head but you’re ignoring it, when eventually some consequence comes about, it actually will reinforce for you why the advice was given and you’re much more likely to take more immediate action because it rings true, right?

[27:10] And so when someone tells you money won’t buy happiness and, let’s say, a brick of $2 million falls on your forehead, right? And then you go out and you buy something and you realize it’s not a happy thing. One of the things that I splurged on for myself when I felt like I have financial security is I bought a $50 pen, okay, because New York Magazine said this is the best pen out of the 100 they reviewed, and it was this Baron Fig pen out of machined aluminum or something.

[27:36] And I bought that pen, and after using it for a while, I realized this is not my favorite pen. There’s a Pilot G2 or whatever that’s much better than this, and it’s like a buck fifty, right? It took me buying that machined aluminum pen before I was like, actually, if you mill a pen exactly round, no matter what surface you put it on, it’s about to roll off, right? And it’s hard to grip onto because it’s slippery.

[28:01] It takes getting there. So I think part of the advice is when you finally do buy that pen and you’re disappointed by it, you realize, hey, people used to tell me that this thing might happen, right? So I think that recognition is helpful. I think the other thing, however, is even if you don’t take someone’s advice right away, I do think, at least for me, when I next face a decision where that advice might apply, it makes me think a little more hard about it. I may not take the advice, but I’ll at least think, several very smart people have told me this thing.

[28:35] Maybe there’s a reason they say that.

29:34 — Motivation after you’ve hit FIRE

Ryan:

[29:34] Obviously part of career and what motivates people at some point is the financial earnings. And I’m curious to explore the topic of the motivation after those more objective things because, for instance, there’s this subreddit and this movement on financial independence and all of that.

[30:11] And I remember when I used to look at that subreddit, there would be a recurring post of someone saying, “Hey, I finally did it. I finally hit my retirement number, and I’m depressed,” or “I don’t know what to do,” because they’ve been on this money-making hamster wheel for such a long time that their happiness was kind of tied to that. And so at some point in your career, you broke out of that needing to be on that wheel.

[30:40] What did you look to that gave you meaning and fulfillment in your day-to-day outside of needing to be in this capitalist machine?

Philip:

[30:50] I feel like, to your point about the FIRE movement, there are two types of personalities. There’s one type that, when retired, will be happy, and they will be happy for years. This is the type of person that is happy to sit on a beach, read a book, and if they are doing that two months from now, they are still happy. It’s like, oh, this is the best, right? There’s another type of personality, which is mine, which is the first week on the beach is amazing.

[31:15] And then once I’m there for two weeks, I’m like, what’s going on? What am I doing here? For me, four months on a beach feels like, quote unquote, a waste. And I know that that offends many people. For the type of personality for whom lifelong beach them is amazing, they will feel like what I’m saying is nonsensical. But I think there’s a type of personality that understands exactly what I’m saying.

[31:37] Which is like that sort of person feels like the rat in the cage that pushes the dopamine button and then dies pushing it because it can’t even bother to eat because it feels the pleasure is so great that it can’t eat. When I see that, I feel like that’s sad. That to me is sad. That is not dying in bliss. There’s a type of personality that says, “What more could you want? Like if you could feel a sensation that is more desirable than even food when you’re starving.”

[32:02] Like, wouldn’t that be the epitome of happiness? And in my mind, that is just a travesty. Like, to me, it feels like this rat could have been so much more, right? So that’s how I feel about myself. So I would say of the FIRE movement, for someone like me, the best parts of the FIRE movement, if I were to embrace it myself, which I never did, but if I were to embrace it, the best part would have been before I retired because it gave me such a strong sense of purpose.

[32:28] I am going to save up until I have $1.5 million. That’s the goal. And every two months I can remeasure how the investments are doing. Right? That is the excitement. The moment I reach the R in FIRE, then that’s actually probably the dangerous spot for me. So I think, in my particular case, for my personality, always having that sense of a goal is good. And that is what I’ve struggled with when I have been in periods of unemployment.

[32:55] I’ve really struggled with what, quote unquote, should I be doing?

Ryan:

[33:00] So then I guess the question is, you can think of getting promoted and all this stuff in engineering as this game that you’re playing, and you’ve got a goal, and you’re kind of going up, and you’re excited. Oh, I want to go to that next one. Oh, I want to go to the next one. I’m going to grow the skills. Do you think that you’d be happier if you got promoted slower and the game lasted your whole career? So let’s say whenever it is you actually want to retire, say, I don’t know, 65 or whatever the age is.

[33:33] And we could set up that game so that you are constantly searching for that next goal, and you get IC9 at 65, and you get a nice little hit of dopamine all along the way, and you’re constantly growing. Do you think you’d be happier in that case versus you speed-run everything and you get to IC9 in the first third of the game.

Philip:

[33:59] I feel like titrating it out would have been better for me. Maybe not all the way till 65, let’s say, right? But take from E3 to E9 is about six levels, right? If you work about 42 years in your career, that’s one level promo every seven years. When I imagine myself taking seven years to go from three to four, I’d feel like, oh man, I’d feel like I was so behind in the sense that it’s not a competition, but I would feel like, am I really progressing?

[34:26] Because seven years, you could get a PhD at Stanford in seven years. So I’m like, dude, what’s going on? Right. But the lemma or the corollary of what I’m saying then is let’s suppose you get from three to five or six within, let’s say, seven years, which is a leisurely, not superstar pace, but not terrible pace. You go from E3 to 6 in, let’s say, seven or eight years. Right. The remaining three levels, let’s say you would need about 12 years between each of them for the math to work.

[34:54] And when I think about 12 years, I also feel like, oh, that feels so long. I worked at Microsoft 12 years, and that was on six different teams.

[35:02] So on one hand, I feel like it would be better if it came sooner, but on the other hand, I do feel like you’d have to recognize if it came sooner that you might be 25 years in your career without a promotion. And for me, I think I would have to. If I were in my 20s and you told me that I would have to have shifted my intrinsic motivation to something beyond career levels. In my 20s, I didn’t have other intrinsic motivations, so that would have been disappointing for me.

[35:32] I’ll throw in one last thought, though. The median age of a Corvette owner in America is 64. And that’s a median, meaning half the people are above that. Right, right. I personally imagine by the time I’m 64, owning a Corvette would be not half as interesting as when I was 38, you know what I mean? And so, in a sense, I mean, is reaching E9 at 62, like, as good? Is that like getting a Corvette at 64?

[35:59] I don’t know. I feel like in a way maybe that progress is wasted on someone that’s that late in career. So I’m torn about it.

36:08 — Meaning and fulfillment

Ryan:

[36:08] You mentioned in between jobs or when you were, yeah, when you’re in between jobs, the motivation or the goals were harder. Did you ever discover meaning or fulfillment outside of an immediate goal? Do you have any advice on finding meaning in your work?

Philip:

[36:28] Yeah, very personality dependent. But for me, the thing I learned about myself is that I need to do more stuff with people. When I got out of work, a big part of it was the socialization. You show up, it’s like they mandatorily have to show up. Whereas when I throw a party, nobody mandatorily has to show up. So work is like mandatory socialization. But when I first quit Facebook and I took six months off, I thought this would be amazing.

[36:54] I’m gonna reach out to all sorts of long-lost former coworker friends for coffee and whatnot. But the problem is everybody else was busy working. So when I wrote them like, hey, can you grab a coffee, whatever, it’s like, well, I can’t, maybe next week. Right. And so what I figured out there was that, wow, I thought I would have all this socialization, but I didn’t. The best time being without work was I had about a six- or nine-month period where two other former coworkers of mine also were between jobs.

[37:21] And that was amazing. We went skiing three times a week on weekdays. Right. We did all sorts of stuff together. We ate dinner out. And I imagine that’s what I would like to think British aristocrats in the 1800s, like the same men that dug up the bones from the Jurassic period and that’s why it’s called the Jurassic era. Right? Those people, right? The gentleman scientists. Right.

[37:43] I would like to think that part of the secret to the happiness of the aristocracy is actually that there were other aristocrats also looking to do something together. It was fun because Mr. Darcy had no job, but you have no job either. So you and Mr. Darcy get together three times a week to whatever, play bocce ball. So I feel like that is the secret for me.

[38:05] And realizing that has made me feel like whether I’m working or not working, being in a situation where I can find regular socialization is probably key to me being happier.

38:17 — Top book recommendation

Ryan:

[38:17] Do you have any book recommendations? Something that you’ve read that gave you perspective on life that you recommend to someone who may be earlier in their career or are still figuring out how they want to plan things out?

Philip:

[38:29] Yes. I love the book Four Thousand Weeks. I’m not sure if you’ve read it.

Ryan:

[38:33] Haven’t. What’s it about?

Philip:

[38:34] Oh, highly recommended by Oliver. Oh man, I’m going to pull out the last name, but Four Thousand Weeks, his idea is that the average one of us probably has about 4,000 weeks. And you’ve probably seen the Tim Urban cartoon where he draws out a single box for every week of his whole life. Right. When you think about a life as 4,000 weeks, it actually feels a lot more precious and every week feels much more consequential.

[38:57] So reading that book really helped me take a broader look around. Decisions were often hard for me because my values weren’t clear. But what I would say to the average person, if they’re willing to hear the advice, would be something like, first, visualize today’s biggest goal for yourself in the next whatever many years. Maybe you want to retire by the time you’re 36, or whatever the FIRE movement people want, right?

[39:18] Visualize that goal. Then I would say, now pretend you’ve just reached it. What do you do next? If you have a good answer for that, then you’re fine. Then you’ll be just fine. I did not have an answer for that. And being that person, not having that ready answer really left me in a place where I was like, is it Michael Phelps or whoever? There’s so many athletes for whom, once you reach that career peak, they realize, wait, what’s after football or what’s after swimming?

[39:45] And the answer is nothing, because they’ve built no other skills in any other domain. And once they’re not a famous football player, it’s like, well, how many people really want to see them and for what reasons other than to ask them for money? And so I feel like many people have that big goal. I’m going to get in the NFL. I’m going to get in the NBA, right? But they don’t know what they’re going to do the day after.

[40:04] And so if I could give one piece of advice to people, it would be: think about the day after and what you’re going to do. And I think the book Four Thousand Weeks really helps a person think about that.

40:14 — What he would change

Ryan:

[40:14] And I guess, last question. If you could go all the way back to the beginning and do it over again, is there anything that you would change?

Philip:

[40:22] I think there were a few times in my career where I biased too much toward being maximally available for my employer and not available at all for friends or family. I think there are a few incidents, and if I could change things again, I would have played those periods of my life differently. Funny enough, one of them was not when I lost ten pounds working six weeks at Facebook, because my kids were very young back then, right?

[40:52] My kids were very young back then, right? Probably three and one or something. But what was great was I told my wife back then, hey, after we ship, it’s probably going to be nuts. And so what we did was we just moved the whole family down to California. My wife took the kids to the library every day. I could see them for 14 minutes before I went to sleep, right. And having family with me and just treating it more like, hey, everybody, we’re just going to go on a big trip.

[41:16] That actually made it all right. Whereas I think there were other times in my career where my wife was the primary one taking the kids to and from school. I had very little conversation with them. It felt like I was doing important things, quote, unquote, for the family.

Ryan:

[41:30] Right.

Philip:

[41:30] But at the same time, I wasn’t with the family. And so there are times like that where I do think there were a few periods where I would have played that differently.

Ryan:

[41:40] Everything in life, we have limited time, so everything in life, there’s trade-offs. If you did, let’s just say you went back to those times and you prioritized family, would that have made a material difference in your career success?

Philip:

[41:55] I think it might have. And I think the tradeoff is, in my case, definitely worth it. I say I think it might have because it’s very hard to tell. I’ll throw out examples where it’s hard to tell. How sometimes there’s the type of engineer who works super long hours, but you can tell that as they work longer and longer, they’re actually creating more and more regressions and they’re getting worse and worse.

[42:19] Right. For that sort of person, a break would actually improve their performance. So there’s no telling. Maybe sometimes taking a break would have made me perform even better. Right. So I don’t want to say that that’s definitely not true. But I also feel for the type of person who constantly tells other people, relax, work a 40-hour work week, you’ll do just as well and even better than other people.

[42:43] I don’t think that’s generally true. I think, at face value, it doesn’t seem like it could be true if two people were at the same skill level, but one just worked 10 hours more per week over a period of time. I think anybody would feel it was grossly unfair if that person wasn’t rewarded any differently. It would feel like, what? What sort of crazy company do you work for where these two people get compensated the identical amount over multiple years, but one guy’s working 40% more?

Ryan:

[43:11] Right.

Philip:

[43:11] It makes no sense. So I do suspect it would have impacted career, but I think also that I would have gladly taken that tradeoff.

Ryan:

[43:20] Awesome. Well, thank you so much for your time, Philip. I really appreciate it.

Philip:

[43:23] Yeah, thanks for having me again.

Last year, I started a podcast to practice speaking and share software engineering career stories that inspired me. Everything felt new and I was learning a lot. After work, I kept thinking about ways to make the podcast better.

I dreamed of working on it full time but it never made sense because I’d only ever lost money on it. Then late last year, there was a reorg that felt like a good opportunity to leave Meta early and try it out. So I decided to use six months of my savings to see if I could make it work.

At first, it was glorious. I interviewed people like Bjarne Stroustrup (Creator of C++) who I’d looked up to ever since I started learning C++ as my first programming language. It was a lot of fun studying for each interview and getting into video production. But doing everything myself had an obvious downside. If I stopped, everything stopped.

I put so much time into each episode that even though I was working more than ever, I could barely keep up with my goal of one episode per week. That’s because I personally reviewed every second of footage and did deep research on each guest before interviews.

Four months into my six-month runway, I still hadn’t made a dollar. I’d been reluctant to monetize since finding sponsors felt like time taken away from the fun parts of creating content. But as my bank account got closer to zero, I knew I couldn’t put it off much longer.

Then I got sick. I caught what felt like a strong flu that had me bedridden for a few days. Lying there, drifting in and out of consciousness, I kept wondering if I’d even be able to publish an episode that Monday. Because I couldn’t work suddenly everything felt fragile for the first time.

Thankfully, I had one episode already mostly finished so that got me through that week of sickness. And because of that week I finally started taking sponsors seriously despite my reluctance. I also found ways to make my recording process more efficient so I could do two episodes a week to get ahead although it was an insane grind.

With some luck and hard work, great sponsors like Cursor and then WorkOS signed on, which brought money in. I also cut my burn a lot by recording every episode myself. Aside from saving money the scrappiness has been a fun way to capture the essence of some of my guests. For instance, the interview with Bjarne was shot in his study against a wall of his own C++ books with two iPhones.

I earmarked 6 months of money and it’s been 9 months now. The podcast sustains itself and my other passion project (an ergonomic keyboard I wish existed) raised the funds we needed within a day of launching on Kickstarter. Since then, we hit our first milestone of real production hardware off the assembly line. If you want one, you can still sign up on Kickstarter.

My career decision didn’t make sense on paper then and it still doesn’t. For instance, I actually expect the keyboard project to lose me money in aggregate. But the goal with my podcast and keyboard wasn’t to make money. Otherwise I would’ve stayed at Meta.

I often think about how lucky I am to get to work on my passion projects. I just want to say thank you to everyone who has supported my work along the way. Without your support, the podcast would have died and the keyboard would have never seen the light of day.

What’s next?

I’m going to keep working on my passion projects as long as I continue to earn my keep:

1. The Peterman Pod - The podcast has grown so I hope I can leverage that to bring on better guests for you all. If you want to see how it’s going you can look at the Spotify podcast charts in tech. I usually struggle to stay in the top 50 but I’m going to keep pushing here! If you want to help out, I’d greatly appreciate if you dropped a rating for the podcast on Spotify.

2. Compose (my ergonomic keyboard) - I’ve been using the first sample off the assembly line as my main keyboard for the last two weeks. It’s a surreal feeling seeing the abstract become physical. It’s exactly what I wanted and my next goal is to bring it to production at the highest possible quality bar I can. We’re on track to ship early next year (follow along here if interested).

As long as the podcast covers itself and my living costs, I plan to keep pushing on these goals. I hope what I produce is good enough that you’ll continue to supporting it. And if you want to follow along you can also subscribe here.

Thanks for reading,
Ryan Peterman

I had Casey Muratori on who is a video game developer and programming creator also known for several talks (ex1, ex2) on the history of computing. In putting together those talks he dug deep into computing history. Enough where he had interesting stories and tidbits to share.

For instance, Dijkstra wrote about his depression and there were also several famous flame wars that happened between legends in the industry. They didn’t have social media back then so they wrote letters to each other calling each other out which we discussed.

Lastly, we talked about his career and the video game industry. I was curious to compare it with big tech and hear more about his career path. He’s a great story teller so I hope you enjoy the episode!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

01:08 - Digging into computer science history

04:08 - What shocked him

16:23 - Dijkstra was depressed

26:17 - The personal side of goto considered harmful

35:09 - The anatomy of a 35 year mistake

50:12 - Clean code horrible performance

58:33 - How to write high performance code

01:01:18 - Where bad code comes from

01:06:37 - Why design docs before code is a bad idea

01:09:20 - The only unbreakable law in software engineering

01:15:57 - How he got into programming

01:21:16 - Why he didnt work in big tech

01:30:44 - Should you work at a startup early on

01:34:52 - What video game engineering is like

01:39:57 - Why preventing recursion is reasonable

01:43:24 - Is vibe coding bad for the industry

01:50:17 - Technical reading recommendation

01:54:27 - Advice for his younger self

Transcript

01:08 — Digging into computer science history

Ryan:

[01:08] There’s this famous quote by Donald Knuth. The big part of it is, “Premature optimization is the root of all evil.” And I remember, I’ve heard that before, but I don’t think I know the full history behind it. And why is that significant?

Casey:

[01:26] So I guess we can split that into two parts. What’s the history behind it and why is this significant? The significant part is probably the easiest to answer because, for whatever accident of history, it’s something that people really remembered. It stuck. And so the reason that it ended up being significant is people keep repeating it, and they keep interpreting it or reinterpreting it. So the effects of that phrase are far beyond what anyone may have done with it in context at the time or what they meant or any of those things, or the history. The effects of it are still felt to this day.

[02:02] Some people, I think probably correctly, you might say, interpret the term with a fair bit of nuance and say, oh, well, it can mean a number of different things or it’s trying to capture something subtle or whatever. Other people are very blunt about it and just think, oh, it just means I don’t have to think about the performance of my code to the end of the project. “Premature” just means any consideration of performance is not worth it.

[02:28] Eventually, we’ll see where the code is slow and we’ll fix it or something. It’s a significant phrase for that reason, at least to me. You still hear it to this day, and it’s at least, depending on how you want to account for it, it’s at least something that’s 50 years old now. And so that’s an incredibly lasting impact for a rule of thumb, or however you want to look at it. So on the history side, this was really.

[02:57] When I decided to do a talk on this, I knew I wanted to do another computer history talk because I had given one before. This is at something called the Better Software Conference. There’s been two of them so far. At the first one, I did a history talk, and I wanted to do another history talk. And this was going to be like, I’m probably only going to do two of these, and this is the second one. I wanted to do it on the history of this phrase because when I started looking into the history of this phrase a while back, I found that there was just a lot of stuff there that I didn’t know.

[03:27] And this is true. I mean, I guess I would say every time I’ve ever looked at computer history, every time I go, I refer to it as dumpster diving. But it’s not like that makes it sound derogatory. But I think of that as kind of what I’m doing. But it’s not really like, it’s actually a very enjoyable experience to go back through history and try to pick through what happened. So to do this talk, I basically went and tried to do a pretty detailed analysis of how did this phrase end up being put in print?

[03:58] What were the worked examples at the time? What were they thinking about? Why might it have been said?

Ryan:

[04:02] What did you learn in doing all that research about these famous computer science phrases?

04:08 — What shocked him

Casey:

[04:08] The thing that shocks me both times, even though I’ve now done it twice, is the amount of stuff that you learn about what was going on at that time that you just had no idea about. It’s just mind boggling. And I would point out that this is for a talk. I’m not a historian, I don’t do this for a living. I’m not at a university somewhere doing computer history research. So what I think of as a pretty thorough read for the history that I did for the talk is actually somewhat shallow.

[04:39] If you had time and the resources, you could go access some of these people’s personal papers, make appointments to see things that are not really in the public record so much, and so on. So even just with publicly available things that you can get, the amount of stuff that I found was just really kind of intriguing to me. And so I’ll give kind of a brief overview of sort of what I thought was the story of this kind of phrase. In a way, I think there are kind of two.

[05:10] I guess I would say there are sort of two threads that are good to understand that come together. And this is what I tried to portray in the talk as well. The first thread is this idea of a thing, and we didn’t really do an intro to this podcast, but I’ll say it now. I’m a big fan of your show. When you said, do you want to be on the podcast? You didn’t have to tell me what the show was. I’ve already watched it.

[05:34] I love it. And one of the people you had on, for example, was Barbara Liskov. And in that interview, she actually refers to something called the software crisis, right? And I think you prompted her a question about this as well, right? So a lot of people don’t really know about the software crisis. They don’t know that that was a term. They don’t know. This is something that happened because it’s kind of ancient history now.

[05:58] It was in the sort of late 60s, early 70s. This was the thing. What this was is originally computer hardware, in a sense that you or I can’t really conceive of it in practice because it was so far before our time that basically computer hardware originally was very simplistic. And so the things that you were going to do with it could be described very easily. And really all you were trying to do when you programmed a computer was just translate a fairly straightforward definition of some computation into machine instructions.

[06:36] The kind of thing that we would think about today as hand optimizing assembly code was really just all computer programming was. It was just like, okay, we’re going to take this problem description and translate it in. But during the 60s, computing power was advancing to the point where people could consider doing much more significant things with it. They could run payroll systems, they could do analysis of data sets, and they would want to be able to be flexible and change the sorts of computations they were doing and all these other sorts of things.

[07:06] They were starting to have graphical displays. Ivan Sutherland’s Sketchpad is in the early 1960s. What they found was that at that time, programmers were not really ready to make that transition. They didn’t think about things the way we all now take for granted, where it’s like, oh, yeah, I built this library for loading JPEG images, and now when I want to load a JPEG, I just call load JPEG and it’s done.

[07:32] All of these things that we take for granted all had to be a cultural shift. The idea that there were going to be these abstractions and these ways of sort of breaking down a much more complex system into parts that we could manage, that actually was a transition that had to happen. And so the software crisis was kind of this period where people were starting to say, the methods that we’re using for programming will not scale to these larger problems that we want to do.

[07:59] We’ve got to figure out something to do about it. So that’s one thread of history that’s coming. Another thread of history that’s coming. It’s a little bit more specific to Donald Knuth, who was the first person to really put this into a worked example. He’s kind of who I would credit with the origin of this phrase, even if there are people who might debate that fact. And to me, it doesn’t really matter who said the phrase.

[08:23] The phrase lives on its own. So I wouldn’t even argue with someone if they wanted to sort of make other claims about it. But just in general, he was going, like, at Stanford at this time, he was sort of learning about the fact that you could do these profiles, like taking actual execution profiles, figuring out where time was spent in the execution of a program and using that to guide your decision-making about where you’re going to spend time developing the software.

[08:55] Again, something that even today, performance is maybe not as much of an emphasis as it maybe should be in software. But even today, with that in mind, most people understand the concept of an execution profile. They understand that you could go into Chrome and see a network profile of how that’s working. You could see a flame graph of where time is being spent, or all these sorts of things. Again, you have to remember, if you rewind the clock back far enough, these were all brand new concepts, right?

[09:24] A sampling profiler, a block-based profiler, a binary instrumentation profiler. All these sorts of things were not just tools that everyone assumed that they could just go have and had seen at some point. Some people may never have even realized that was a thing. So that’s another thread that’s happening. And those two things converge effectively in 1974, right? Roughly. To get us this statement, Knuth is very much into this idea of structured programming, which is sort of a proposed solution to the software crisis.

[10:02] Maybe a proposed solution is the wrong way to say it. It’s a certain set of ideas that are trying to be employed to improve the situation. Let’s say he’s very much into this. We can talk about what that is as sort of a separate tangent if we want to later. He’s very much into that. He’s thinking about that. He’s thinking about this idea that programmers can’t just be about writing all of this very tightly optimized assembly language code.

[10:31] And that’s all we’re going to spend all our time doing. We have to be thinking bigger picture. We have to be picking and choosing our battles. We have to make concessions to maintainability. If this particular routine is not really accounting for hardly any of our runtime, we should not be obfuscating it with all of these hand-unrolling the loops and all these things. Remember again, underlying all this, they don’t have massive optimizing compiler passes like we have with LLVM now.

[10:57] They don’t have all of this extra stuff. So if you wanted something unrolled, you were going to unroll it yourself. If you wanted some kind of loop, hoist a loop invariant out, you probably had to do that yourself. A lot of that stuff that we take for granted today, again, not in there. So that sort of. He’s very unstructured programming. He’s starting to see these execution time profiles. They do a thing at Stanford in 1970, actually he does it with some students where they take a look at FORTRAN programs and they instrument them to see where the time is being spent.

[11:26] Not in exactly the most rigorous way that you might imagine. That’s another thing from my talk that I kind of go into. But he’s sort of saying, look, we as programmers need to start taking the decision about what to optimize more seriously. And he kind of has a fairly nuanced take on it. If you actually read the section of his 1974 paper Structured Programming with go to Statements where kind of the first time this was really put to print that I know of.

[11:54] He does say it in an ACM Turing Lecture a little earlier, but he would have submitted the manuscript for this publication prior to the lecture. So it was the first time that I know of that he actually committed it to paper. It would have been there. But he may have said this a lot in lectures. He kind of obliquely refers to that in the Turing Lecture that maybe he had said this around town, so to speak.

[12:20] So where this was first uttered, I don’t think anyone knows. But the point being, when he says that phrase, it’s in this context of saying, look, we need to be very concerned about efficiency. We shouldn’t be leaving performance on the table when it matters, but at the same time, we need to know that it matters. If we don’t know that it matters, then we’re going to apply this optimization. That’s a premature optimization, and it has real cost.

[12:48] It’s going to make our maintenance and debugging of this program worse for all the same reasons that it would make it worse today. If we go into something and we start applying these optimizations to it that are above and beyond the kind of structural things that we might be doing to that code otherwise, that’s creating a cognitive burden that other people are now going to have to deal with, and you’re going to have to deal with in the future.

[13:10] So I don’t want to put too many words in Knuth’s mouth, certainly, but in general, that’s sort of the way that this comes together is those two things, this idea that we need to be doing things to solve the software crisis. How have a more structured approach to programming, care about maintainability and debugability, composability, abstraction, all that stuff. But also at the same time, we do care about optimization.

[13:33] So how do you dovetail those things? “Premature optimization is the root of all evil” is kind of like this phrase he uses, I would say, if I had to imagine his way of sort of reminding himself, think about all this before you make a decision. Right. That would be kind of my take on it. Right. And where it comes from. So hopefully, I don’t know, that’s very long, but it’s a very expansive question. So hopefully I’ve kind of wrangled most of the stuff into there.

Ryan:

[14:00] It sounds like this is really an engineering tradeoff, where the software crisis is about the maintainability and the complexity for people to actually write and handle their code, and then the tradeoff between performance and, I guess, code that is maintainable. And it sounds like this Knuth quote is, be mindful of where you pay that cost.

Casey:

[14:29] Yes. And it’s always important to understand the context in which this was said historically. So I want it to be a historical talk, because who your audience is is a large determiner of what the root of all evil is. If you’re talking to a bunch of people who don’t think about optimization at all, then you don’t really need to say this phrase to them. If you fast forward to today, when a lot of people don’t really take optimization into account at all during their programming, or very, very little, this phrase doesn’t make very much sense to someone who does care about performance, because it’s like why would you ever say that?

[15:08] It just seems like it encourages people to not be mindful of the performance of their program. But if you rewind to that time and you understand that, well, a lot of the programs, you know, they had the opposite problem. A lot of the programs at that time, what programming was, was coming up with all these crazy little assembly tricks to shave a cycle off here or there, right? And if you’re talking to an auditorium full of people who are really into that sort of thing, then it really can be the root of all evil, right?

[15:41] It’s like you guys are spending all your time on this, but we have this really big other problem. And that is not the right tradeoff, right? That is, you’ve swung, you know, like calling it tradeoffs is a great way to say it. You’ve swung the pendulum way too far in one of those directions at some point. And so to some degree, while I would highly dispute the description “root of all evil” today as a good thing to say to somebody, or that it leaves a good impression, when we rewind to that time period, I think it makes a lot more sense.

[16:12] Because when you look at what people were actually spending their time doing, where their priorities were, I think that maybe that wasn’t so much of an exaggeration. I mean, obviously it’s hyperbole, but it’s less of one.

16:23 — Dijkstra was depressed

Ryan:

[16:23] In your slides, there were so many quotes and snippets of really kind of digging into the true history. Was there anything you found that surprised you when you were doing the research?

Casey:

[16:33] I mean, constantly, absolutely constantly. And first of all, I’ll just say that there’s, as a meta point, I’ll give you a specific thing that surprised me that’s kind of funny. That’s more about a technical thing. But first I want to talk about a broader picture, which is one of the things that really hits home for me whenever I do these, is the personal aspects of it. These people were friends and competitors and all these sorts of things.

[17:08] And it’s all kind of lost to us in a way when we think about computing history in a sterile way. When I read up on what Edsger W. Dijkstra wrote, Dijkstra was the person who kind of kicked off structured programming. No, I’ll call it a revolution. That’s a bit too probably grandiose, but he kicked off that train of thought. He wrote a thing called Notes on Structured Programming. It was a manuscript or a monograph, I don’t remember what they called it.

[17:39] Got a typewritten thing. It looks exactly like a typewritten thing. Right. When he wrote that, he was very depressed, like he was having a lot of trouble in his life at that time. He had gone through this situation where they had done what people today now recognize as pioneering work in distributed computing. He and these other people at Eindhoven University of Technology.

[18:07] I apologize, I can’t say the proper name for it; it’s well beyond my pronunciation capabilities. But point being, he had done this really foundational work in distributed computing and published it, and people today now recognize it as that. It is undisputedly a massive contribution to distributed computing. He did it with a part-time team of people at the university, who—this wasn’t their job; it was a mathematics department they were in.

[18:34] And as a result of that, basically they sort of just got dissolved, like the Department of Mathematics. I guess he wasn’t really specific about it, but in his notes the Department of Mathematics was just like, they disbanded the team. It was like, this isn’t math or whatever, I don’t know, they just had a pessimistic view of it. And he was really depressed about that, and he wasn’t sure what he should do with his life and, what’s the deal here, right?

[18:57] And he was having this sort of, I don’t want to call it an existential crisis because I don’t want to again put words in his mouth. These are historical figures and, you know, I can only. That’s why I try to use quotes to try to show you like what they said. But that’s, it’s just so relatable when you go through the history this way. It’s not just some random guy who wrote some math down in a paper.

[19:17] It’s like people were really struggling with this, and some of the most important aspects of computer history come out of these amazing human stories. And I found that absolutely fascinating. So I’ll just put that out there as one of the biggest rewarding things about looking into this history, if you ever do it, is if you can go find the actual writings of the people, like things outside of just their technical papers.

[19:41] It’s just fascinating. And it’s so much more relatable and fascinating because you feel the story. It’s not just this abstract computer science thing that happened. So that’s one thing. But the other thing I was going to say is when you read through this stuff, I just go through piles of documents and I’m just reading them and seeing, does this fit into this story? Should it be part of what I’m telling, or is it extraneous?

[20:07] Is it something that is interesting, perhaps, but not actually part of it. And one thing that I found, when the VOD of this lecture or talk goes up, I’m going to include this in the notes because I thought it was so fun, didn’t make it into the talk. I found a thing, like a thing from Tony Hoare. So C. A. R. Hoare, who again is another massive figure in computer science. Hoare, Dijkstra, and Knuth are like the three amigos.

[20:38] And they all write to each other. They’re very important people in computer science history. So I found a thing by him that was like a thing he did not decide to pursue. It’s like this note where he’s talking about—he’s talking about this thing that he’s thinking of doing, and there’s just a handwritten thing on him from later on in his life, when he was, I guess, categorizing these documents, and he just writes down, like, I decided not to pursue this because I talked about it at this conference that I was at.

[21:10] And Peter Naur, who’s again another famous figure in computer science history, if you’ve ever looked at context-free grammars and parsing, you’ve probably heard Backus–Naur Form. He’s the Naur in Backus–Naur Form. If you’ve ever heard of the language ALGOL, he was a major figure in standardizing that and writing up the standard and all this stuff. Anyway, Hoare. Yeah, I proposed this thing, I went through and said it, and Peter Naur was like, making multipass compilers is easy.

[21:40] I just wrote a nine-pass one. So I decided not to pursue this. So what’s the thing? I read through the thing and maybe I’m just overreading it with the benefit of hindsight, but he pretty much describes static single-assignment form, like SSA, which is a very standard compiler technique developed in the ‘80s. But this note is from the ‘60s. So it’s like, in my head, I’m like, did Peter Naur accidentally set back compiler science by 20 years by telling Tony Hoare?

[22:18] Well, 15, let’s say, by telling Tony Hoare this is not important, when actually it would have been very, very important. You find stuff like that all the time where you’re like, whoa, what is this? I saw another one too. Just one more I’ll mention. I can’t remember now, I’m sorry again. Your brain kind of turns to mush when you try to dump this many documents into it for a talk. But there was a pretty interesting thing, I thought, where Margaret Hamilton, so the person who managed the Apollo Guidance Computer, she was one of the core programmers originally on the project and then was the manager of the whole OS, like the whole real-time software that ran the Apollo 11.

[23:03] Well, all the Apollo Guidance Computer stuff, right? Which I mean, most people today herald as a very, very significant real-time systems achievement in that era, right? Everyone pretty much agrees with that. She had to write a defense. I think it was in Communications of the ACM, maybe it was in Datamation. They say—apologize. I can’t remember the venue because it had been pointed out as a failure because people didn’t understand the context that the reason that the Apollo computer had to trip those alarms was because that had been used improperly.

[23:40] It was used in a configuration that wasn’t supposed to. And it actually, rather than crashing, went into backup modes and successfully landed. It worked. It actually was a triumph of fault-tolerant engineering. And she had to write a defense of this because people at the time were saying, “Oh, they screwed up. This is an example of why you wouldn’t want to do engineering this way, or don’t write the code this way.”

[24:03] And so again, stuff like that always makes me think, the more things change, the more they say the same. That’s exactly what would happen on Twitter now, right? Some very successful thing that people did, right? They would just get slandered and say that it was done wrong, and there would be a flame war, and then they’d have to come out and have a thing. So anyway, those are just some examples.

[24:23] But there’s so much great stuff in there. I highly recommend it to anyone who likes this kind of thing. You won’t be disappointed if you go dumpster diving, as they call it.

Ryan:

[24:32] When you said that you saw the human stories and that Dijkstra was depressed at that time, what did you see that made you realize that?

Casey:

[24:42] One of the nice things about Dijkstra is that he’s kind of a pretty straight shooter. And so I didn’t actually have to do any interpretation. He literally talks about being depressed. There’s a paper, not a paper, like a thing that he did that’s like a retrospective that’s handwritten by him later on in life. And he literally says, in this period I was very depressed because of these reasons.

[25:12] Now, he could be wrong about the source of his depression. Right. So I don’t want to claim that just because he said it, it’s necessarily true or something like that. But one of the amazing things, I think one of the really cool things about academics, especially that era, is they just produced a voluminous amount of material, and so we don’t have to guess that much. In the private sector, I think it’d be a lot harder, like if you wanted to know what people at maybe Lockheed or something were thinking or doing at that time.

[25:47] I imagine it’s much more difficult just because things are classified or they’re not academic, so they’re not necessarily going to write them all up. So a lot of the internal stuff when you write them, academics don’t really have that. They don’t have an incentive or a prohibition on writing up everything they do. So they don’t just have to have a public-facing statement of what they did or a public-facing paper of what they did.

[26:07] And then, oh, there’s this extra secret stuff. The academics don’t have that restriction. They’re sort of... They benefit from being as forthcoming as possible about what they’ve accomplished, usually.

26:17 — The personal side of goto considered harmful

Ryan:

[26:17] I saw in the slides that you looked at Go To Statement Considered Harmful. That email, do you have any sense of the personal or people side of that?

Casey:

[26:28] So you’re talking about the original Dijkstra letter to the editor. That’s like Edsger W. Dijkstra’s Go To Statement Considered Harmful. The complete story is actually relatively simple according to him. He was at a conference in Tennessee where he was talking to Brian Randell, who’s another computer science guy. He doesn’t quite get the same level of name recognition as a Knuth or something like that, but he has a lot of papers at that time.

[27:04] You can go find him. He’s not obscure. He’s not an obscure figure. I wouldn’t say to anyone who reads the history. You’ll see him come up. He’s talking to Brian Randell and some other people outside. This is exactly like the same thing that happens at modern conferences. There’s the talks and then there’s all the stuff that goes down at the bar. Right. It’s very much that. They’re outside, they’re talking.

[27:25] And according to him, he’s basically giving the same sort of example of a problem with the Goto that he gives in the paper. Right. This idea of enumeration, we can talk about that later. But sort of a side note, he’s sort of saying, like, this is kind of a problem with Goto. And one of the reasons that maybe it’s not such a good idea. And the people who were listening to him were like, Brian Randell and the others were like, you should publish that.

[27:56] That would be helpful because there’s these arguments going on about whether GOTO is good or bad. That was kind of happening at the time already, since around 1959 even, I think there’d kind of been a little bit of that, had been kind of growing, this idea that maybe Go To Statement Considered Harmful wasn’t the best idea as a way to structure your programs. And so he does. He goes back to Eindhoven University of Technology and he writes up this same thing he was saying, basically, and he sends it to Communications of the ACM for publication.

[28:29] Niklaus Wirth, who is the creator of Pascal, a very prominent figure, also was very heavily involved in ALGOL and all this sort of stuff. Language designer guy, he is the editor who is in charge of getting this thing published. I guess I’m not exactly sure how things work at Communications of the ACM. He doesn’t want to wait to have it published. He doesn’t want to take the time to go through the referee process or whatever.

[28:58] I don’t know at that time what the requirements were for publishing an article in Communications of the ACM, but I’m sure that it involved a lot of procedure. It wasn’t just like, oh, hey, I’m the creator of Pascal at that time. He wouldn’t have been the creator of Pascal yet, because Pascal comes later, I think. But either way, he’s like, hey, I’m this important guy. I’m just going to put this whatever I want.

[29:19] Communications. That’s not how it worked. And so he decides that in order to get it published more quickly, he’s just going to publish it as a letter to the editor. Because then there’s no anything goes there. As long as the editors are fine with the content. I assume it doesn’t have to be refereed, it doesn’t have to have any kind of review. It doesn’t have to be, et cetera, et cetera. So he turns it into a letter to the editor and he takes the name of the thing that Dijkstra sent, which was A Case against the GO TO Statement.

[29:47] That was what Dijkstra wrote at the top of the thing as the title. He changes it for letters to the editor to Go To Statement Considered Harmful. Right. So it wasn’t even Dijkstra’s plan to have it maybe be that confrontational. But that’s what happens now. This is not well received, to say the least. According to Knuth, again, I’m just trying to say who said what here. According to Knuth, Dijkstra said he got letters, angry threatening letters, in much the same way you would today.

[30:34] Got people who were very abusive, telling him off. I’m sure part of that is because by all accounts, Dijkstra himself was also somebody who liked to push people’s buttons. That’s well acknowledged. I think Alan Kay is probably the best source for this. He talks about this. He liked Dijkstra, and they apparently got along well. But he’s often said that Dijkstra was someone who kind of leaned into being sort of brash about stating things about programming and kind of relished that position.

[31:07] So it probably didn’t help that he was already sort of known a little bit in that way. But in general, that’s how it went down. And, like I said, that wasn’t the initial foray against Go To Statement Considered Harmful by any stretch of the imagination. But it just kind of maybe, you call it the straw that broke the camel’s back. It was like a flashpoint, might be the way to say it. And then the title, of course, that Niklaus Wirth picked is quite the doozy and kind of clickbaited everyone, as I call it, into that soap.

Ryan:

[31:43] It’s funny because, I mean, social media, it’s similar patterns. People have very explosive first lines, and then the comments are full of all this hate and stuff. In their case, I’m guessing this is all papers. So you submit a letter to that. It’s a physical thing, and people are reading maybe a newspaper or something. I don’t know.

Casey:

[32:05] Yeah, it’s like a periodical. It comes as a bound. I mean, I guess there’s. All the things around us here are hardbound, but it’s like usually with soft. It was a maybe a perfect binding kind of bound thing that has you open it up, table of contents and letter to editor. Right. And yeah, like you can go find. There are a few. If you go look at people’s personal papers, which, like I said, if I did this full time, I’m sure I could find out way more stuff than I did.

[32:34] Right. But some people have gone and looked at the personal papers, and occasionally some of them have been able to digitize some of those and put them online that we can look at. And you can find, for example, online right now, if you search for it, there’s a back-and-forth letters, personal letters between Edsger W. Dijkstra and a guy who is kind of into functional programming and promoting that. And you can look at the correspondence, and it’s kind of.

[33:02] It’s a little, it’s a little flame war. Like, really, like that’s what they did. They didn’t have the ability to do, like, pithy Twitter replies, so it was just on paper. And Knuth did something similar. It wasn’t really a flame because he had, at least when reading comes through, a tremendous amount of respect for the authors of the book Structured Programming, which is Dijkstra, Hoare, and Dahl.

[33:32] One of the things that he published was a series of open letters to them reviewing the book and talking about the things that he didn’t find compelling in it. Very respectful. So it wasn’t. That one wasn’t a flame war. But that’s what they had to do because they didn’t have social media. So Edsger W. Dijkstra wrote all these things called EWD with a number. It was his initials, basically, and then a number.

[34:00] And that’s like this serialized list of all the things he wrote. And he labels them this way. It’s not like some historian characterizes it after the fact. It’s like, oh, I’m doing. He’s like, I’m doing EWD 937 now or whatever. Right. It’s hilarious. But anyway, several of those have been put online that are not necessarily technical. For example, his trip reports. You can go read those and you can read about, oh, I went and stayed at, like, such and such’s house and we went to dinner or whatever, right.

[34:31] So you can find some nice personal anecdotes in even the publicly available stuff. But in terms of a real heart-to-heart conversation, I didn’t have access to anything like that that wouldn’t have just been in a paper, more or less, normally. So it’s a shame. One of the problems with this stuff is it’s so interesting, but it’s not a job to do. If somehow it was a job, I probably would almost take that job.

[34:58] Being the person who crawls through and tries to redocument this whole thing. But, no, computer historian, no one’s hiring, no one’s interested in paying for that.

35:09 — The anatomy of a 35 year mistake

Ryan:

[35:09] You have this other talk, and the title was just so catchy. It was “The Big Oops: Anatomy of a 35-Year Mistake.” What is that? 35-year mistake.

Casey:

[35:21] So this was a kind of funny thing that happened to me that I then did a historical lecture on. I had worked on systems in the past that were basically like editors. You have 3D graphics editors. You have to multi-select things and move them around. There’s a bunch of architecture things you have to learn to be able to write that kind of code and certain kinds of problems you have to solve. A very basic one that I would point out that hopefully most people can relate to would be if I have a bunch of things on the screen, some of which have a color.

[36:00] So maybe this is a drawing program and I’ve got some text and I’ve got some shapes and I’ve got some strokes, some hand-drawn stuff, whatever, and I want to be able to select a bunch of them, and I want the user interface to present to me which things I could edit on these shapes. So I want to be able to edit the color, and I want it to apply to all of them. Right. This is just a basic architecture problem that you have to solve if you’re going to write one of these programs and you want it to be any good.

[36:26] Now, oftentimes, you will see programs where the person didn’t solve this problem, and you can’t do that. It’s very frustrating, right? So a good program, someone has solved that architectural problem in some way. And I was watching, I just happened to be watching because sometimes I do like to watch old videos of computer science pioneer stuff. And I was watching a demo of Sketchpad. I’d seen it before, but I was watching a demo of Ivan Sutherland’s Sketchpad.

[36:53] And Sketchpad, for those who don’t know, is a groundbreaking computer graphics program. It’s done with a light pen, and it was done in the early 60s. And you could draw things like you do in a modern CAD program, and you could do stuff that even a lot of modern CAD programs don’t really offer or only offered recently. I think in the talk I said in 2007 was the first time that AutoCAD got some of these features.

[37:19] You could do stuff like say these two shapes, this line has to be perpendicular to that line, constrain it, and you could just do whatever you want with the drawing and it would resolve for making that happen. And these are very rare in programs even to this day. That’s just not a common operation you would see in a drawing package today. I was looking at this and I was like, how the heck did he solve this architectural problem?

[37:46] How did he do this stuff in the early 1960s in assembly language, with no editing tools, no debugging tools? I mean, this would have been like either punch cards or one step away from punch cards. It would have been hard to develop this stuff. And when I went back and I went through his thesis and I looked at the code, it’s actually documented how he did it. And I realized, like, oh crap, this is actually like an entity-component system.

[38:18] Basically what we would now consider sort of state of the art of real-time architecture for doing these kinds of operations, meaning cross-cutting, operating on this kind of property across many things at once that are all kind of different. And this was something that object-oriented programming — I’m editorializing now, a bunch of people will complain that I’m saying this, but this is just my opinion.

[38:47] Object-oriented programming and the pedagogy around it really struggled with that problem for a long time because they were teaching, despite people who will now claim otherwise. I document it very completely in the talk, so I don’t think they have any leg to stand on. But the pedagogy at the time was all about build a domain model. The domain model looks like your hierarchy. Basically, like I’ve got employees and employees, I’ve got contractors and I’ve got derived, like is this a full-time employee or a part-time employee?

[39:15] That was how they suggested these things should be implemented. That kind of architecture doesn’t work for these kinds of operations that I’m talking about. Entity-component systems do. And generally, that kind of rotated architecture, I might call it, does work for these. What I call the 35-year mistake is the fact that I very ironically, in my opinion, Sketchpad sort of showed in its architecture how you could solve this problem and how you could solve it in arguably an object-oriented way.

[39:52] I think if you squint at it, a person who does object-oriented programming could easily make an argument that you can do an object-oriented version of this. You don’t have to violate any particular principles to do it. It’s just not the hierarchy domain model way that people were conceptualizing it through a lot of the 80s and 90s, let’s say, and even unfortunately to this day. But I think a lot of object-oriented programs don’t do that anymore.

[40:17] Ironically, that was in Sketchpad. The DNA was there, and we could have had it right away because Ivan Sutherland figured it out. But weirdly enough, the whole idea of this sort of inheritance hierarchy with lots of encapsulation around it grew in part out of Sketchpad because Alan Kay looked at it and said the interesting part of this is the fact that you could take a shape and not know what it was and just have this draw circle call on it or something.

[40:49] That was the part they took away from it, which is much less interesting in my opinion and not that architecturally useful in most cases. So in kind of this amusing way, Sketchpad contained, if I’m editorializing, it contained what I consider to be a good architectural idea, but the takeaway from it was a bad architectural idea, is how I would say it. And saying bad architectural idea is a little bit strong because, as I say in the talk, I think there are times when you do want to think very high level.

[41:17] You might want to think about things in kind of the way that Smalltalk thinks about them. So I don’t want to say bad idea in the absolute sense, but bad in the way it ended up being applied, let’s say.

Ryan:

[41:29] Why does that class hierarchy not work for this problem?

Casey:

[41:33] It’s pretty easy to understand, actually. So when you think through an inheritance hierarchy that’s based on sort of what you see in the real world or what you’re trying to model. So you say, the typical example, and it’s brought up tons of times by people who wrote the OOP literature, like Bjarne Stroustrup, like the Smalltalk people, the idea is keeping it with a Sketchpad example, I’m going to have a shape.

[41:58] From the shape, I’m going to derive triangle or circle. And the encapsulation is around that thing. So a circle has a radius, but shapes don’t have radiuses. Shapes don’t necessarily know what that is, right? So it tends to get deferred down and the encapsulation boundary is drawn around that sort of derived class. That’s, like, the most derived version of whatever this thing is.

[42:25] The problem is that creates a lot of headaches when now something that wants to work across a lot of shapes needs to actually do something intelligent with modifying, say, the scale of something or wanting to change its color because it doesn’t really have a way to know what’s going on in these highly encapsulated things. So typically what you end up having to do in those situations is you then have to take this inheritance hierarchy and kind of, in a sense, throw away the benefits of it.

[42:57] You end up having to make at the top all of these accessor iterator things that allow you to probe into that lower class and say, tell me all of the colors that you might be using and a name for them. In a sense, what you end up having to do when you want the architecture to work is you have to rebuild the Sketchpad version on top of the inheritance hierarchy version, which doesn’t really do anything for you.

[43:24] And it’s not to say that there isn’t some benefit that you can derive from having derived is kind of a pun here, I guess, that you can derive from having this idea of saying this thing is like this other thing. Please give me some of the implementation of it. That’s not necessarily a bad thing in practice. The problem is when you teach people that this is how it’s going to work, like you just make this hierarchy and then your architecture is just supposed to work, it really ill-prepares them for the reality that that’s actually not going to solve most of the problems that you have are not going to be solved that way.

[43:56] And again, it just comes from this fact that typically when we’re working with computer programs, most of the time what we need to do is create cross-cutting operations that work with a lot of the data that’s inside these derived classes. That’s actually the thing that we want to do. And it’s really cumbersome and typically a bad fit for the problem space to put that into some virtual functions that are sitting at the top of this very sort of tall hierarchy.

[44:23] It’s usually much better to do. Again, even if you’re doing object-oriented programming, you don’t have to stop doing object-oriented programming. You just have to think about it differently. You have to think about what the objects are differently, where you’re drawing the encapsulation boundaries. It just helps to think about it differently and say, actually, the more important things to model are what are the things that stuff is built out of?

[44:44] How do I build a circle out of objects, right? What are those things? A radius property, a center property. Those maybe should be the objects that I’m thinking of as more first-class citizens. And this inheritance hierarchy stuff about what the objects are that I see on the screen, like triangle and circle, that’s a distraction. That’s not the proper way to model the problem. And again, I don’t think I would be pissing off any object-oriented programmers by saying that today because I think a lot of them use architectures that do think about objects in that sort of rotated sense and not in the domain model hierarchy sense.

[45:20] Not that there aren’t still people who are doing that. But it’s not the only way to go nowadays. It’s not the only way that’s promulgated.

Ryan:

[45:28] because I guess my immediate thought would have been in that case, the base class has the notion of a color or some shared thing, and we just operate. If you’re a shape, then we assume you have a color. But you’re saying refactoring and putting up in there is suboptimal and you want all these subclasses to have some handle to some radius property or something like that.

Casey:

[45:54] Is that what you just described is what tends to happen in systems that are architected this way? You end up with your derived class not really being very much of anything because in order to edit stuff, you had to migrate it all up to the top. And there was actually terms for this in the old days. I don’t still use, like, fat base classes, right? Or things like that. It just ends up your base class has every type of property that any derived class might ever have.

[46:18] You have get primary color, get secondary color, get tertiary color, right? Because something needed three different colors or whatever. And most things don’t use those colors and all these other sorts of things, right? There’s certainly nothing wrong with running a program that way. It’s just, again, why did you bother with the hierarchy? You’re not getting any actual encapsulation benefits from it because you just forced everything in the base class anyway.

[46:41] So why didn’t you just make that be your thing? Just make one class called Shape and be done in terms of the ECS style of implementation. I don’t necessarily want to advocate for it or not because I don’t actually personally use ECS or anything like that, but they are very common. Now the idea there is to just turn it on its side and say, look, typically what we want to do is do things like, okay, there’s stuff that has physics on it.

[47:09] I’m doing this thing, and I want to have physical simulation of entities. Well, the physics system is the thing that probably knows how that should be stored. So rather than having that be data in my derived class that’s encapsulated around the derived class, instead, why don’t I just have the physics system know what physics is, and then if you want to make something that participates in physics, you just have a handle for whatever this thing is, like a handle for my shape.

[47:36] That handle is valid in all the systems. So I can look up the physics properties of the shape and gather it when I want to actually do something with it. But generally speaking, the encapsulation stays around the system. So physics properties are defined by the physics system because, hey, that’s who knows how physics should work. And I just ask about my physics when I need to do something with it.

[47:59] And this kind of gets you out of that problem. And then now you can just compose things. Oh, I want to make something that has several physics elements in it. Fine. I can just have multiple physics handles if that’s what I need, or something like this. I can very flexibly merge these things together. I want something to not have physics. I just don’t ever insert the. I don’t ever ask the physics system to have a valid piece of data for this handle in it.

[48:21] And it won’t simulate any physics for it. Right. Whether that’s the world’s best architecture or not, I’m not going to argue for it or against it. It’s just a lot better than domain model hierarchies, that I will say, right?

Ryan:

[49:31] Earlier we talked about the tradeoff between, I guess, performance code and maintainable code. And I saw you had this one video. It said in quotes, “Clean Code, Horrible Performance.”

[50:03] I feel like this is on the same topic. What’s your take on that? Because you also put Clean Code in quotes. What does that mean?

50:12 — Clean code horrible performance

Casey:

[50:12] So it’s a fairly subtle topic, right? And that’s why the quotes are there. Because the first thing that you have to point out is that clean code is clean code. Object-oriented programming. A lot of these phrases, they mean different things to different people. And so if you’re going to say that this code is clean, it’s pretty hard to find two programmers who will agree on exactly whether it is or not.

[50:39] They all have different ideas about what is clean and what is not. The reason I put that in quotes is I was talking about a very specific thing, which is literally the book Clean Code. The thing where there’s, here are the things that we would recommend that you do in that particular case. What I was talking about is there’s a certain set of ideas that is advocated in Clean Code as these are the things you should do.

[51:04] And they are like you should have everything should be kind of, I guess I would say dynamic dispatch, or at least code shouldn’t know the types it’s operating on, right? Saying it’s dynamic dispatch is maybe it depends on the language whether that’s going to be true or not. But when I write code, I don’t know what types I have. It’s just, I don’t know. Some base classes is what I’m operating on, and they could be anything.

[51:28] That’s thing one. Thing two is functions should be very small. In fact, the numbers are kind of weird. They’re like four lines or five lines. When you go look at the actual things that are claimed in some of this literature, it’s really strange. You’re just like, gosh, that’s very small, right? And I go through some of those things and I say, look, if we were to actually follow these, we get into a really bad state because a lot of the languages that people are going to be using to implement this stuff, like C, for example, which even would be a fairly good case in a lot of cases.

[52:01] At least it’s a compiled language and so on. In a lot of cases, these things are kind of a recipe for disaster. If you’re handing out types where you can’t know the type at compile time, or you can’t know the type, or it’s going to be in a different module, so unless you have really aggressive link-time code generation, it’s not going to be likely that you could figure this out. And you’re saying all the functions should be very small.

[52:24] And of course they’re going to be virtual because they’re on these sort of types that you don’t know what they are. This creates a really toxic combination for the compiler. Normally you can have— I mean, you can have small functions if you want them only four lines long. If the compiler can know that, it can just inline that, right? If it can see clearly what you’re doing, it can just merge those things in. We don’t have a problem if they’re behind a virtual function.

[52:50] So it doesn’t know, it can’t guarantee that it is that type. It can’t do that. And so when you talk about all this stuff, what you’re giving up... People, I think, also because the video—I mean, the video was a very short video as part of a series—I think people sometimes get the wrong idea that I think that virtual function calls cost a lot. They do cost something, but depending on how you want to look at it, they actually don’t cost that much because it depends on whether it’s predicted correctly or not.

[53:19] But in general, the cost of a virtual function is less than you would think a lot of times. The actual reason that it slows things down is because the compiler cannot merge the code together. It can’t inline stuff and remove and reduce the waste. That’s the actual problem. So if you just want to call a virtual function, yeah, if it was a really, really hardcore optimization scenario, then you don’t want anything, probably calling a virtual function in general, because there is some cost to that.

[53:45] Just calling a function has cost. But that wasn’t the really bad part of it, right? So it’s that. Plus there’s an additional thing, which is that it can’t unroll and go wide on things. If the compiler can see everything you’re doing, it can use SIMD, it can widen loops to operate on multiple things at once. It can unroll those loops. There’s all these things it can do. If it’s got these virtual functions, it’s just like, that’s it.

[54:08] I don’t know. I can’t make decisions about that. I have no idea what this thing on the other end is doing. That was my point on that. And again, it’s not meant to be assailing the idea that your code should be easy to read or easy to maintain. It’s just more like these guidelines seem really bad. And also, I don’t think we need them for code to be maintainable. I don’t have trouble maintaining functions that are 30 lines long or 50 lines long.

[54:33] I don’t find that five is a magic number or something, or that it has to be really short. And also I find that it’s usually pretty easy to write code where I know what the types are, that those can be determined at compile time. I don’t think that results in code that’s particularly hard to read.

Ryan:

[54:48] When I was in college and very early, I remember people would recommend that book, “Oh, you should read Clean Code.” So my understanding is that you wouldn’t recommend that to people who are software engineers to read that. I guess the way I would categorize it is a mixed bag.

Casey:

[55:00] So I wouldn’t actually say that I disagree with all of the things in the book, though. I mean, some of the things are things that I definitely do myself. Like giving variables easy-to-understand names is something that I think is good advice, and that’s in that book. Right. And so kind of more, I wouldn’t necessarily say do or don’t read the book. What I would say is, like, I think there’s some things in this book that don’t.

[55:31] That aren’t addressed properly. Like, I don’t think you want to tell people these rules of thumb and not tell them about these other problems. That was exactly what I was pointing out there. And so usually it’s more that it’s like I find that oftentimes there is this tendency, I guess I’ll say, to pretend that we don’t have to talk about performance and we can just say, in fact, premature optimization is the root of all evil.

[56:01] Bringing it back to there, I feel like there’s this temptation and very prevalent practice of sort of taking that idea to mean we don’t have to talk about performance when we’re teaching people things at all. Or like when you write the book Clean Code, you don’t have to talk about performance at all. You can just include a thing that’s basically like, hey, there’s performance issues, but most of the time it’s not a problem or something like that, which is, or if you look at Refactoring, the book Refactoring, very popular, it literally says exactly that in like the OOP thing.

[56:34] It’s like there might be performance concerns, but they’re usually okay or something, right? And that is not true. I just think that’s fundamentally not true. I think these books should include detailed discussions of the actual performance problems that you are very likely to hit if you take some of their advice, because it’s not that it means you can’t do those things.

[56:57] But I’ll quote you back to you. It’s about trade-offs. There is always a trade-off that you’re making, and sometimes if you understand the trade-off, you will make it. You’ll say, I know this is going to cost. This may be a serious performance problem for us, but I think that’s okay. I think it’s not like our performance won’t suffer to the point where it’s a problem for the product. I understand what that is.

[57:23] There’s a huge difference between that and just going like, eh, we don’t worry about performance till the end. It’s completely different. Those are two different engineering approaches. And so what I try to do is encourage people to put that analysis back in, understand the performance trade-offs you’re making, understand how much it might cost in the future to make these fixes. And I don’t really do any AI stuff, but my sort of feeling is more so now than ever.

[57:53] I feel like that’s got to be pretty important because you’re instructing these AIs to do what they’re going to do. And I feel like it would be a bad idea not to know about performance trade-offs because, especially if an AI is going to be doing your bidding and structuring the code the way you want to structure it or doing whatever, it seems like a fairly straightforward part of the process to include performance stuff in those instructions.

[58:17] Right? That would be a natural thing that we would want to understand and do. So I feel like really I’ve been just trying to get that more into the conversation, and I feel like it’s as relevant now as it ever was and arguably maybe more so. I don’t know, but I could be wrong about that.

58:33 — How to write high performance code

Ryan:

[58:33] What are some things that are in your mind? They’re those high-value performance things to consider that don’t cost a whole lot to think about.

Casey:

[58:43] So to me, awareness is the number one thing, right? Understanding roughly the performance characteristics of the hardware that you’re working on, which includes things like if there’s a network, what does that look like? And so on. It’s really about awareness more than anything else. Because a little bit of awareness can go a very long way if you understand the basic concept that network latency versus network throughput are different things.

[59:15] You can make upfront decisions about structuring code such that you batch things properly and so on and so forth. If you don’t understand those things, you could get very far down a project only to realize that everything you designed and the way it works is all very serial and really just cannot be accelerated over a network at all. It’s never going to run reasonably or something like that.

[59:36] Right. And so I think the lowest hanging fruit is just to get some education in performance, get some education in how to think about the way a machine works and what makes it fast or slow, what it struggles with and what it doesn’t. And just to keep that in the back of your head, because at the end of the day, if you have that knowledge, I think you’re very unlikely to make the kinds of architectural decisions that will be hard to undo later.

[01:00:06] Right. And so that’s really the majority of it, I think. And that is by far the highest impact, lowest cost thing you can do is just do that training once, because once you have it, it’s with you forever. Once you understand how to think about performance, it can always be there. And at any time you can sort of have that alarm bell of like, “I don’t see...” You’re always kind of looking like, “I don’t see the path towards this running well,” then that’s your cue to stop.

[01:00:38] Maybe we need to rethink how we were making some of these decisions. As long as you can see that path, you can delay most optimization work. As long as you can see the path, like here is how we will optimize this, you’re in pretty good shape because if you’re making those trade-offs correctly, you’re not going to paint yourself into a corner where there’s nothing that you can do other than scrap and rewrite.

Ryan:

[01:01:05] You had this one video title. It said, “Where does bad code come from?” I guess, yeah. My question to you is: what’s the answer to that? Where does bad code come from?

01:01:18 — Where bad code comes from

Casey:

[01:01:18] Yeah, that’s a good question. My feeling on where bad code comes from is that, for everything that I’ve seen on projects in the past, the bad code all seems to come from roughly the same source. And that is not dealing with the actual thing that’s happening. Right. There’s a lot of ideas in computer science about sort of doing upfront design and making a lot of decisions without ever really implementing anything.

[01:01:54] And I have found that universally that leads to the worst kind of code. And the reason for that is, I hate to be pessimistic, and I hate to be pessimistic about my own ability, but I’ll just say, for me personally, I am not able to correctly hold all of the details for most complex software in my head at once. There’s just a lot of stuff going on at, like when the actual instructions hit the CPU, there’s a lot going on down there that’s very hard to keep all in your head.

[01:02:34] And so when you approach an upfront design, typically, unless the problem is very stupidly simple, right? When you approach something with upfront design and you think you’re going to get all of this architecture worked out ahead of time, you forget some important things. You make decisions without realizing, oh, wait, there’s this thing that has to happen there that means that this isn’t really the right way for these pieces of code to interoperate.

[01:03:03] Then you end up seeing these hilarious APIs or something where it’s like you’re just like, how did this end up being the way that you do this? I have to create all these objects and I have to connect them together with these things and I have to create this weird filter graph thing and then I have to call compile on it. But only you end up with these insane things. And you’re like, all I wanted to do was call this one thing that said, like low pass filter this buffer.

[01:03:26] It could have been one function call, right? It’s like, how did you get there? And the answer is because you weren’t actually dealing with the actual problem and looking at what the actual code looks like when you actually want to solve the problem in practice. And so my idea where bad code comes from is usually just that. It’s that. It’s this failure to engage with the actual reality of the situation.

[01:03:52] Maybe there are people out there. I certainly have never met any, but maybe there are people out there whose brains are so expansive that they can actually hold all that in there and they can therefore just do it upfront. But other than for various sort of constrained problem spaces, I’ve never seen that work. And there are some times when that’s the case with, if you’re just doing, I’m trying to do this particular mathematical operation, that might be a case where you can work it all out on paper because it’s very specific what it is.

[01:04:21] It takes these N inputs, produces this output. And I can work, right? But when you’re talking about architecture, like, hey, it’s a web browser, right? Some complicated thing, the details are all that matter to me, right? It’s like, it’s where all the complexity lies. And if you try to do the design without reckoning with them, it just leads to bad results in my experience.

Ryan:

[01:04:41] So how do you avoid writing bad code in that case?

Casey:

[01:04:45] I try to start with the actual solutions to the problems and work up from there. So one way to say it would be instead of top-down programming, bottom-up programming as much as possible. And top-down programming isn’t really the same as designing up front. But I’m just saying as a contrast there, try to start with the things that you know you need. It’s like, okay, if I’m building this thing, it’s gotta have a rasterizer.

[01:05:10] All right, I’m gonna start making a rasterizer. I’m gonna see what kinds of stuff that does and how I would like, what’s the most straightforward way to call this and use it. Okay, let’s make an API out of that, right? Build it out of steps where the abstraction comes from actual working code that gets abstracted rather than pushing the abstraction down from the top, where I say, this is how I will abstract the rasterizer.

[01:05:36] And now I go write the rasterizer and the thing that uses the rasterizer, only to find that that is not a very good way to use a rasterizer. So to me, starting with that and working upwards is the best way to ensure that you will get an architecture that is at least good for one thing. Now, if you want it to be good for multiple things, you probably need a couple different. I want a few different varied things that would use this rasterizer that I will kind of work on together, and I’ll make abstraction decisions that work across all three of them.

[01:06:07] That’s a good way to make a more reusable API that works for a lot of things. But I never want to just sit down and say, “How will I design an API for lots of people to use a rasterizer without actually writing any of it?” It’s like, no, no, no. And I definitely can’t do it. And I would question someone who says that they can. Unless one caveat: they’ve written a lot of them before, right? If you’ve written tons before, then you’ve sort of done the thing that I’m talking about already.

[01:06:33] And you might remember, oh, it’s this way, right?

01:06:37 — Why design docs before code is a bad idea

Ryan:

[01:06:37] I think there’s a lot of common advice, especially at these larger companies where there’s this process to write a design doc and put together everything in advance, present it before you write any code. And it sounds like you’re saying that that’s a terrible idea.

Casey:

[01:06:57] I think that’s an absolutely terrible idea. Now, that doesn’t mean that I wouldn’t be okay with that process with a slight modification.

[01:07:05] If what you’re doing during that time is writing test code in the way that I’m saying. So we’re going to write a little experimental rasterizer. We’re going to do those things. We’re going to start, and then our document that we’re producing is, here is what we have determined is a good API based on these experiments. I have no problem with that. That’s following my procedure pretty much to a T. And I don’t tend to produce documentation because I work on smaller teams.

[01:07:32] I don’t have to have a 1,000-person org know exactly what I’m doing there or whatever. So I wouldn’t produce upfront documentation normally in a case like that. But if you wanted to, that seems totally reasonable. Right. And that is communicating our research into how this should be structured out to a wider audience. But we still did the due diligence of determining that it really does work in practice.

[01:07:55] It’s not just our guess about what it will be.

Ryan:

[01:07:59] I see. Okay, so you’re saying kind of this pair design, pair prototype, just build as you go, but it’s just so you get a sense of the reality of the design.

Casey:

[01:08:10] Yeah. And I think I would be very comfortable with the team that wanted to work that way. If they’re like, look, we want to produce, we want to document this thing before we start developing. That’s just how we feel more comfortable with how we’re going to do it. Maybe it’s a very large org, maybe we have some very good reasons for that. Then I would say totally fine. It’s just, I want to hear if I’m going to be comfortable.

[01:08:31] I want to hear that that process is not, we’re just typing on paper. We are actually testing these API design decisions, and they come from looking at actual usage code that we have made and that we have implemented at least experimental versions of, so that we know they really do account for all the details that we’re likely to encounter in practice. That’s what I want to hear. Right. I don’t want to hear, we thought it through.

[01:08:57] I’m like, did you think it all the way through? Because I’ve seen a lot of times where people thought they did and they didn’t, including myself. That is not. That is not. I always think it all the way. So it’s like, no, this comes from a personal place of I forgot the thing. I forgot this important thing and I made a really stupid design, right?

Ryan:

[01:09:14] There’s another video you had. It was titled The Only Unbreakable Law.

Casey:

[01:09:19] Oh, yeah.

01:09:20 — The only unbreakable law in software engineering

Ryan:

[01:09:20] What is the only unbreakable law in software engineering?

Casey:

[01:09:24] So, yeah, that was a lecture I did where I was trying to think of, if I was going to say one thing about architecture to people, right? If I was going to say one thing about architecture, what could I say that isn’t probably wrong? Because you think about a lot of our ideas about architecture, it’s like even the stuff I just said to you, who knows what we’re going to be thinking 10 years from now.

[01:09:47] It’s like, they’re not really laws, they’re just observations that we’ve had that maybe this is a good way to do things, but it’s not really a law, right? So the only thing I’ve seen that feels like a real law to me is the thing I cover in this lecture, which is Conway’s Law. And this is a. It’s not a real law in the sense of like the laws of gravity or so, like, it’s not a physics law.

[01:10:14] Like a physicist would laugh at calling it a law. It’s probably not even a theory; it’s more like a hypothesis at this point, right? But in terms of things that I would place money on being validated as a law at some point, if we ever had the means to do so, this would be one of the only software engineering things that I think would qualify. And it is that if you would like to organize a series, like a set of people to work on something, or in the modern parlance, let’s say agents.

[01:10:56] So it could be. It doesn’t have to be human. It’s any system that has sort of its own internal processing, like a human brain does or like a computer does. If you need to partition a problem into a set of workers in this way, where the communication between those workers is slower than their own internal computation ability, which we would all agree is true about humans, it’s true about two computers running an AI model as well, right.

[01:11:25] The amount of time it takes to send information back and forth to them is significantly slower than what the GPU can be processing directly on its own, right? In systems that look like that, when you start to tackle a problem, in order to get the benefits of that parallelization, you will have to make decisions about who is working on what, at least some decision. For example, if we are making a car and you and I are the two people who are going to make the car, I’m going to design the body of the car, you’re going to design the wheels.

[01:11:54] Right. Just a decision someone could make. Once you’ve made that decision, you have now locked in the fact that the iteration on the design will be slower across that boundary than it is interior to either of the two parts. So, for example, your ability to improve the design of the wheels on their own and my ability to design the body of the car and improve that on its own will be much faster than our ability to design the interface between the wheels and the tire.

[01:12:32] Or it’s not even just the interface, the degree of harmony between the designs. So the degree to which your wheels complement my body design and my body design complements your wheels, that they all are considering the trade-offs together. Right. And Melvin Conway’s paper, which lays this out, this is a very early paper. It’s in the 60s at least. Was it in the 50s? It’s way back. When that lays this out, points out the consequence of this is that products or any.

[01:13:06] And when I say product, I mean anything that comes out of one of these design processes or development processes. Products will have a similar structure to the organization that produced them. You will be able to see in the product evidence of this because the degree to which things are able to harmonize is restricted across that boundary. So when you look at the object, it will have that boundary visible in some way.

[01:13:33] Right. It won’t be quite as good at the interface between these two things or in the way that they work together as the things are themselves to themselves. It gets sort of flattened, like one way. The rule is pithily stated is products look like the org chart, but that’s not exactly what it says. But that’s kind of a downstream consequence, and boy, do you ever see it in the real world.

Ryan:

[01:14:03] So, I’ve heard that in the context of these big tech companies, like, almost like it’s a bad thing to quote unquote ship your org chart, or basically the product you put out there has these inorganic, yes, things. So it sounds similar to what you’re saying.

Casey:

[01:14:24] Yeah, it’s. And I think part of the reason I think it is kind of an unbreakable law is I think it’s somewhat unavoidable. It’s more something that you just have to be aware of and mitigate to the degree that you can. Like, you just have to understand, look, that lower communication time, whether it’s humans or computers or whoever is doing this work, that lower communication bandwidth is whatever.

[01:14:54] That just means that where we draw these lines has consequences for what we ship. And so we really want to try, over time, to align those boundary drawings to places where it will have the least bad impact on the result of the product. And that’s true for org charts, like I said. I suspect it will also become true for AIs and things like that, where it’s like, you will want to partition these problems in ways that respect that line drawing, because that will be less good than the thing that can be wholly solved by one unit, whatever that unit is.

[01:15:36] And so to me, it’s a very helpful construct for thinking about things. It’s also a very good explanation for why you see something somewhere. You’re like, why doesn’t this just integrate this? It’s like, because there were two different teams. It’s like, I’m sorry, that’s just the answer. And it costs a lot more for those two teams to have integrated this. That’s not how we work. Right.

01:15:57 — How he got into programming

Ryan:

[01:15:57] I’d love to hear more about your career and how you got into programming.

Casey:

[01:16:04] I started programming when I was really little because my father worked at Digital Equipment Corporation, which is actually a very important company in that era. No longer exists. Right. They would be sort of like almost like a case study in how not adapting to a change in technology leads to your demise. They were one of the most important companies in the world for computing. If you ever heard of a PDP-11 or a VAX in computing history, that’s them.

[01:16:35] Right. They made these things that were foundational computers in computing history, gone today. Right. Part of them got absorbed by Intel, part of them got absorbed by Compaq, but they don’t exist. So he worked for that company. And so we always had computers in the home, and I learned to program when I was little, and that’s just sort of always what I wanted to do. I really enjoyed it.

[01:16:59] And so I ended up getting an internship at Microsoft when I was pretty young, and I met some people there. I came out to — I should say, I grew up on the East Coast, so nowhere near Microsoft. I met some people there. I ended up coming out to the West Coast really early on. This would be in, like, ’95. So it didn’t feel early at the time. It felt late in computer history. But nowadays, like, oh, wait, ’95.

[01:17:26] Oh, my God. Before everything was on the web, right? There was a web, though it was nascent. I ended up coming out and working sort of in the game industry, and that’s what I did ever since. And I’ve mostly always worked on game technology. I’m famously absolutely terrible at understanding game design. People who watch my stuff know this about me. I’m very, very bad at it.

[01:17:54] I’ve tried to make games a couple times and I just cannot do the design side. I’m awful at it. But I really enjoy the engine stuff, and I feel like I’m okay at it, and I’ve been able to contribute to projects. So in general, most of the time, if you’ve used code that was written by me, you probably used it in the context of a video game that was using technology that I wrote. And an example would be I worked at RAD Game Tools on a character animation system.

[01:18:23] I wrote the entire thing myself. That is used. Well, that’s not entirely true. I wrote the entire thing myself, except for the texture compressor, which Jeff Roberts wrote. There was this texture compressor that you could use as part of the pipeline for the exporting and stuff like that. It was a pretty cool project at the time. I’m really proud of it. The first version was awful because I was pretty new at the time.

[01:18:44] The second version, I thought we did a really nice job. And it was made at a time when people didn’t think you could do licensable game technology of that kind because it was too hard to integrate into things, like you couldn’t get the performance or whatever. And we did a lot of things that I think were pretty innovative at the time. And we were able to make something that was very successful. And it’s.

[01:19:04] I mean, we released the first version of that in ‘99. It’s still in use today, largely unchanged from the architecture that I guess was the second version I did in 2001 or something. There are a few changes to the architecture that people have made over time, but it’s largely unchanged. I found out recently Baldur’s Gate 3, which was a big game from Larian, came out. I had no idea. It turns out they use it.

[01:19:30] It’s in their engine or whatever. So I’m very proud of that product because I think it was in tons of games and was a very hard problem to solve. And I think we solved it pretty well. It’s largely irrelevant today. I would say it’s still in some people’s engines over time, but it’s not the kind of product you would make today because nowadays engines are monolithic and you license them as a whole. Typically, you wouldn’t be getting a character animation library.

[01:19:57] It’s going to be something that’s built into Unreal Engine or built into Unity. It’s not the kind of product you would probably consider making today. That was mostly, in terms of things that I’ve done that people might actually have experienced or used, like folks at home. If you’ve played games, you may have played something that I had a hand in at some point, but only the technology, not the design.

[01:20:20] I also worked a little bit on The Witness, which was a game by Jonathan Blow and team that I thought was absolutely fantastic. And I did some work on the walk system there that I was pretty proud of. I thought it came out pretty well. There’s some parts of it that are really janky. I don’t think I did a very good job of the actual implementation of it, but the design was pretty good, let’s put it that way.

Ryan:

[01:20:43] Early in your career. So you worked at Microsoft and then went to go.

Casey:

[01:20:48] I was only ever an intern. I never actually, I mean, I guess that’s technically working there, but I didn’t ever work there as an employee. Employee, right.

Ryan:

[01:20:55] As someone who’s writing code, I mean, there’s a lot of different paths, but there’s one path I imagine: you go and you work at one of these big tech companies and create their tech products, I guess. And then video gaming seems like another path. And I think there’s other paths as well, of course.

01:21:16 — Why he didnt work in big tech

[01:21:16] What drew you to going towards video gaming and not continuing down the Microsoft path or something like that?

Casey:

[01:21:25] I think that there’s a bunch of things I could say about that, but they’re probably all BS. The truth is probably that I’m probably more affected by the people around me than I would like to admit. I mean, I guess I don’t have a problem admitting it now, but at the time I probably wouldn’t have said that, right. I could envision an alternate past where I did stay at Microsoft and try to get a job there and work there instead of being just an intern and then going off and working at a different place.

[01:22:00] The reason that didn’t happen was because of the people who I worked with there when I was an intern. I fundamentally really like. Nowadays I fundamentally really love doing things like analyzing assembly code or looking at exactly how a microarchitecture is working and these sorts of things. If I had gone to Microsoft and had just happened to be under some people who were doing that kind of work and had taught me how to write device drivers in assembly language or something like that.

[01:22:33] I might still be there today, right? That’s not what happened. The capsule summary is the group that I was supposed to be in, the way that they did internships at that time was that a set of interns, say three or four of them, would be underneath a particular manager who was going to be managing those interns. So there were a couple of us who were supposed to be reporting to this guy whose name I won’t mention, just in case for some reason it’s ancient history.

[01:23:02] He probably wouldn’t care at this point, but we were supposed to be reporting to this particular person. And literally the week before we arrived, he has this massive flame-out with upper management. Leaves, just walks out of the building, and has not been heard from since. So we show up, and there was me, a guy named Rudy, a guy named Rajeev, and we’re just interns. We show up, we’re like, hey, how’s it going?

[01:23:39] And we report to this test guy, this SDET guy named Scott Latham, really nice guy. And we’re like, we’re supposed to be reporting to a program, like a software, or what’s going on? This is one of the guys in the test org. He’s like, yeah, that guy’s gone, he’s out of here. And me and this other guy, Bruce Johnson, are going to take care of the interns because, eh. Right. We don’t really know what you’re going to do.

[01:24:13] The first thing I think Bruce had me do was like an ANI cursor loader. There’s this format, I don’t know, ancient history now, but there’s this format for animated cursors on Windows. If you ever see the stupid little walking dinosaur or the, like, no one uses these anymore, I don’t think. But they were this thing that was in there. He had me write a parser for loading ANI files, right? Like it’s just meaningless stuff.

[01:24:36] So my experience there was pretty lame. I was like, this is kind of dumb. I don’t really want to work here. But it could have been totally different if I had been on some team that had really inspired me to learn the stuff that I didn’t know. I didn’t know assembly language at that time, really, at all. I think the only thing I’d ever written assembly language was a joystick polling routine for DOS because it was the only way you could poll the joystick in DOS.

[01:25:00] I think that’s really it, if I’m honest about it. I think most of it is that I think even if you’re a very brash youngster, which I was, and even if you think that you’re very independent, I think you definitely gravitate toward people who you see doing things you think are impressive or technologically interesting. And that is just not the experience I had at Microsoft. Now, there were some people who I like, the people I went out to go work with were people in other parts of Microsoft who were leaving Microsoft to do a startup company.

[01:25:34] And those were the people that I was really impressed with. Those are the people that I wanted to hang out with. So, if I just look at it in arrears, if those people had just been staying at Microsoft and doing something, maybe I would have gone.

[01:25:47] And I think that’s the truth of it, as best I can determine at this point anyway.

Ryan:

[01:25:51] So you moved across the country to go work with those people at a startup?

Casey:

[01:25:56] Yes.

Ryan:

[01:25:56] That feels pretty risky to do.

Casey:

[01:26:00] It was especially because at that time, a startup is not really what you think of as a startup today. Like, a startup was just some scrappy people in a crappy office doing stuff. Nowadays, you think startup, it’s like, well, we’ve got $10 million in VC funding and we have free sodas and whatever, like in the break room, and a masseuse comes in periodically or something like this.

[01:26:22] Right. I don’t know what the now version of a startup is, but it’s very different, right? So, yeah, it was pretty risky. And I don’t really know why I did it. It was mostly just because I hadn’t had really good experiences with education. I didn’t really want to do college, or I didn’t want to do any more education. I wanted to actually work, for whatever reason. And this seemed like a.

[01:26:52] But this was just the easiest way to do that. And I don’t really regret it, honestly. I’ve been able to learn most of the things that I would have needed to, if I was gonna go do a PhD or something. I’ve ended up doing work that is the sorts of stuff, like I’ve been lucky enough to be in positions where I could go spend a few months writing this particular linear least squares solver or something like that.

[01:27:19] The kinds of things you might have done as a thesis or something, or that walks on somebody done The Witness. Those sorts of things are the kinds of things you would have done had you decided to get a master’s degree or something like that. So I’m fortunate enough that I’ve kind of been able to have that part of the education because not everyone gets that opportunity. You may never get, if you don’t do a master’s thesis or you don’t do a PhD thesis, you may never really get the chance to really do deep work on one problem and learn a lot about it, read a lot of papers, maybe make some novel contribution in some very small way usually.

[01:27:59] Right. And so I was just lucky enough to do that. So I don’t really regret not doing something like that, but I think had I not had those opportunities subsequently, I could see being regretful about that because that is something that I do enjoy doing. And if I’d never had the chance, I would have been sad.

Ryan:

[01:28:18] So you went and you traveled to this startup because there’s no funding, it sounds like.

Casey:

[01:28:25] So, yeah.

Ryan:

[01:28:26] What, you? It’s just a group of guys. Was there pay or...

Casey:

[01:28:30] It’s just not really. No, it was. It was pretty rough, and it didn’t last very long. Right. I ended up going to work at an actual game company shortly after that called Gas Powered Games. And then shortly after that I started working at RAD Game Tools, which I stayed at for quite some time and where I did that character animation system and stuff. So it was pretty quick into not doing that, but it was still a pretty educational experience for me.

[01:28:53] And also what I will say is at the time, I worked with a guy named Chris Hecker, who I have to give basically complete credit for teaching me basically about reading technical papers. Before that time, I just thought math was kind of stupid and an annoying thing you had to do in class. Right. And I definitely didn’t know anything about reading a SIGGRAPH proceedings, really.

[01:29:26] And I may have been aware. I mean, I was aware of SIGGRAPH. I knew what it was. But I don’t think if you’d handed me that binder, I would have known what that was or what to do with it. I think the biggest takeaway that I got from that, other than startups are hard and maybe don’t do them unless you have a lot of people and a lot of funding and aren’t really that much on the line, maybe.

[01:29:51] But the biggest takeaway that I got from that that was positive was just a much deeper appreciation for math, a much deeper appreciation for research, how to read it. That’s where I learned to use CiteSeer, which would be kind of the precursor to Google Scholar or whatever. Crawling references and all that stuff. In a lot of ways you could say if I hadn’t had that experience, I bet I wouldn’t have given the two talks that we’ve talked about for most of the interview.

[01:30:17] Because what are those talks? They’re me crawling every reference. They’re just me going back and back and back and looking at everything that I can find. And that’s something that if no one ever conveys to you the importance of reading, the scholarship and being aware of what’s being done, and also teaches you how to read a tech paper and how to parse through it, I don’t know that you get that.

[01:30:42] I don’t know that you get that.

01:30:44 — Should you work at a startup early on

Ryan:

[01:30:44] I remember early in my career, I think there’s this common path of these big companies, and then there’s this thought of, oh, me and a couple buddies, let’s go build something. Now, with your experience looking back, if someone out there is young and thinking about starting, would you say go that common path or would you say take the chance?

Casey:

[01:31:10] It’s a really tough question. And I think the advice is that you have to think about what it is that you want to do every day. So in my mind, the things I regret are the times when I’ve had to do things or chosen to do things that I wasn’t really that happy doing every day. Right? And so I think you just have to optimize for the experience you want to have. Because a startup might work out, it might not.

[01:31:45] It’s always a risk, right? You may go to the big company and it may be cool. There may be interesting things there, or there might not be. You don’t really know. You’re making a kind of blind decision. And so I think you kind of have to optimize for what do you want your day to day to be? What do you want the experience to be? And you want to keep a running talent, you want to be aware of it.

[01:32:12] If you make a decision and six months in, you are not liking what you’re doing every day, then you need to get out of that, right? That’s my opinion. So I don’t know. I think most people probably, if they sit down and actually clear their mind and aren’t engaging in too motivated a reasoning just for themselves, go, what do I envision working at the startup will be like? What will I actually be doing every day?

[01:32:40] Am I gonna like that? Is this gonna be thrilling? Trying to make this thing work and being kind of on the edge, and do I want the kind of war stories of the things we had to do to pull off the demo or whatever? Right. If all that sounds exciting to you and you wanna have that experience, then you should do that thing. And I would say, really, I really mean that.

[01:33:05] I don’t even think you should take into account, even, like, let’s say, the startup’s gonna fail. If you want to have that experience, then you need to do it, right? It’s just like anything else. It’s like going and backpacking across Europe or playing guitar at a nightclub. It’s like, you may know that these things are not profitable. Is that the experience you want to have?

[01:33:26] Are you going to look back on that six months or a year or five years or whatever, the amount of time you’re thinking of committing to it? Are you going to look back and say, I’m glad I did that, or are you gonna be like, that was time that I would have rather spent some other way? Right. And so I think most people can probably, if they’re honest with themselves, at least make a pretty good guess.

[01:33:45] And that guess, if they’re honest with themselves, is gonna be better than any advice I’m gonna give them. My guess about what you should do is gonna be worse than yours. So you should just make that determination. Because another way to look at it is, you know, the big company side, maybe you just wanna have some security. Maybe when you’re starting out, I mean, I’ll just give some examples.

[01:34:04] Maybe you want to spend a lot of time dating. You want to find a partner, and you want to have a relationship, and you want to have a family. Maybe that’s more important to you. Maybe the startup, yeah, it might be fun. Maybe it would be more money if it worked out or whatever. But maybe the stability is actually going to be something that you would really benefit from because the sorts of things that you imagine being fulfilling in your life are not all around what you’re going to be doing in computing.

[01:34:34] I think you can have some guess about those things if you just let yourself have some space to think about it and don’t engage in too much motivated reasoning about it. And I think that would be the best way to make a decision, if you’re going to make one. That’s my feeling about it. Anyway.

01:34:52 — What video game engineering is like

Ryan:

[01:34:52] We talked a lot about video game engineering, and I have no idea what goes into video games. If you were to just boil it down to the big pieces that you need for a video game, what are those software components?

Casey:

[01:35:07] So the biggest thing that’s different about a video game is that the sort of original mental model that you’re taught in programming, which is the standard I O, is not how it works, right? So the biggest mental shift is just like, oh. The way that a video game or a simulation of any kind works is I need to have some world state.

[01:35:37] And I’m constantly updating that world state on a regular interval. Everything is always happening. There’s no “I wait for input and then I do something,” right? Everything is always going because it is real time. The time is going forward. So the components tend to be built around this idea, and it depends on what level of sophistication you end up getting into. But in general, you need a way of storing that world state.

[01:36:03] So some kind of. We usually call these entities, like the things that make up a world.

[01:36:08] So some way of modeling what is in the world. Where are things in the world, what is their state, what are they doing right now? So you need something that does that, something that is in charge of advancing that state. This is a mixture of several things. It could involve physical simulation, it could involve AI, not necessarily large language model like the modern notion of AI, but pathfinding, making a decision between whether I should attack the player or not, that sort of AI.

[01:36:42] So we have the world. Some way of showing the world state, some way of advancing the world state, like an update step that may involve lots of things like that. Then some way of presenting the world state. So a renderer. Right. And this is something that typically has, I guess I would say it’s traditionally been a very important part of a game because the visuals are often something that is a selling point for games.

[01:37:12] People produce trailers, certainly in the AAA space. We’re trying to show you how cool the new lighting looks and the whatever. So that is a pretty big component of games. Oftentimes you go look at an indie pixel art game, it might be much smaller because that’s a much smaller part of the problem. Now that’s generally what the shape looks like. There’s a lot of little pieces there. Typically nowadays we would have some way of asset streaming. The renderer needs to have things like textures loaded, models loaded, things like that.

[01:37:45] We need world data, physics, collision models, these sorts of things. They might be too big to fit in memory, or we don’t want to spend a lot of load time to load them up front. We want to stream them in as they’re necessary. So there’s typically this thing that’s sitting there constantly grabbing things off of disk, caching things, pulling them in and out of a cache that’s being used by the renderer, by the physics, and so on.

[01:38:04] So that’s another common component that’s new, didn’t used to be there. There’s going to be an audio and music system. Obviously, that’s in charge of when sounds are triggered in the world, ambient sound effects that are happening in the world, music that’s playing, continuity. Again, all of that’s interacting with the world state to know which ones of those things are happening. The update step, which will be triggering things in that sound system.

[01:38:28] And of course, the asset streaming to load what sounds are being played or load the music. So we typically have that. And then I’m trying to think, I’m trying not to leave out any major components. In a modern context, there’s often networking. So we want to have a way for multiple of these game clients to communicate with a server. So typically what that means is that world, that state of the world might be provisional. It might be sort of a predicted model of the world that’s not the real model of the world.

[01:39:01] The simulator is actually running. The authoritative simulator is actually running on a server somewhere. And I am merely communicating with it to find out what the world state is. And then, because I don’t want to wait, I don’t want the latency of going all the way around, I am predicting the motion of things forward in time based on the last information I have. So that’s another kind of way that things tie in.

[01:39:27] If you want to start doing things like competitive multiplayer and all these sorts of things. Right.

Ryan:

[01:39:31] That makes a lot of sense because I used to play video games, and then these MMO online games, when I start to lag, everyone continues forward.

Casey:

[01:39:43] Yes.

Ryan:

[01:39:44] And then my Internet catches up, and then everyone jumps to where they’re actually supposed to be. Okay, that makes a lot of sense. I pulled some of your top tweets. I thought that might be interesting to discuss.

Casey:

[01:39:57] I’m sorry.

01:39:57 — Why preventing recursion is reasonable

Ryan:

[01:39:57] So someone said, NASA does not allow recursion in their code. How crazy is that? And then you said, not even slightly crazy, and it went really viral. Can you explain why that’s not even slightly crazy?

Casey:

[01:40:12] When you’re writing functions in a procedural programming language like we have, and that NASA is probably using, you are able to use the program stack for storage. I mean, that’s what it’s there for. It’s what local variables are. I call a function, I get some storage space on the stack. The compiler did that for me. It also saves the return address when I make a function call. That program stack is keeping track of where in my code I was, so that when the thing that I called is finished, I get back there, not some other point.

[01:40:50] Neither of those two things are things you couldn’t implement yourself. They’re both things you could do. You could break the thing up into pieces. You could have ways of remembering what they were, like a state machine. You can have your own stack that you put data on and access it. Right? So the only thing recursion really does is it allows you to leverage the fact that someone already wrote that code for you and maybe more convenient to use because it’s built into the language.

[01:41:18] Now, there are some things, if you really want to get super technical about it, there are some things that happen at a CPU level when functions are called, but we can put those aside for now if you want to talk about them after we wrote the code. So the reason that I don’t think it’s crazy to go, we’re not going to use recursion to implement an algorithm, is because if you’re doing that, you’re kind of just YOLO swagging that there’s room on the stack for whatever it was that you were doing, right?

[01:41:44] And you can’t even really check unless you’re going to do some kind of weird thing. We could sort of do a thing where we go like, okay, let’s try to determine how many more iterations, how many more recursion depths we have before we hit the end of our stack. We can do those calculations, but it’s like, eh. And also if the compiler changed something about the layout, it wouldn’t be true anymore, and so on and so forth.

[01:42:07] So it’s like, so if I’m NASA and I’m like, hey, I don’t want my astronauts to crash into the moon, it seems much more logical to say, don’t use recursion. Just figure out whatever this thing was you’re going to do, turn it into a loop, keep a stack, and make a state machine for it. We can reason about that much more clearly. We know exactly how far it’s going to take. It doesn’t matter what compiler, it’s going to work the same way every time, and it will know the bounds.

[01:42:31] Precisely.

[01:42:33] Very sensible to me.

[01:42:35] And again, you assume at NASA that they’re not doing it for their health. They’re doing it because they have hard constraints on the problem domain where someone’s life is at risk, or at a minimum, many millions of dollars in equipment is at risk. If you screw up, if your stack falls, if you get something where you’d recurse too many times and hit the end of the stack, that is not just a, oh, I rebooted the computer or restarted the software.

[01:43:08] So I don’t know. Hopefully that makes sense.

Ryan:

[01:43:11] Andrej Karpathy had this famous tweet that kind of coined the phrase vibe coding.

Casey:

[01:43:16] Yes.

Ryan:

[01:43:17] And then you said, if you thought software was bad today, buckle up, because it’s about to get a whole lot worse.

Casey:

[01:43:23] Yes.

01:43:24 — Is vibe coding bad for the industry

Ryan:

[01:43:24] It’s been about a year and a half since that tweet came out. The tweet came out in February of 2025. Would you say that that was an accurate prediction?

Casey:

[01:43:35] To be clear, I think the whole lot worse part is predicated on something that may not happen. And that is that the idea that we just kind of type some stuff into a computer and ship it to prod, right? Basically like, hey, could you make me a thing and then publish it, becomes a common way of doing things, right? For example, also done by people who maybe don’t have a computer science background. I think it’s fair to say, and that I wouldn’t be being sort of overly dismissive of AI at this point, to say that a person who is well trained in computer science using an AI to make code right now can make substantially better code than someone who doesn’t know anything about computer science, who is just given Fable and types some stuff in.

[01:44:27] The difference is rather dramatic, I would say, from everything that I’ve seen. So part of my concern that I was trying to express in that tweet was like, if the idea is like, we’re just going to type stuff in and we’re not going to really be checking the code, someone who knows computer science is not really going to be looking at it. Worst-case scenario, it’s literally just like some random person in marketing somewhere who has no idea what programming is, just types of stuff in and crosses their fingers.

[01:44:57] Right. I think we’re in for a world of hurt right now. It’s a race, so it’s hard to say because it’s basically a race of how good can you make the AI versus how much adoption does it get? It’s a curve. If you can make the AI good enough that the people who are adopting it at a particular rate are always using an AI that’s good enough for what they’re adopting it for, we wouldn’t expect software to get significantly worse.

[01:45:24] If those curves go the other way, we’re in a lot of trouble. Right. So I feel like right now we’re almost kind of teetering on this knife’s edge. It’s really, to me, it feels like a footrace of improving AI so it can be more autonomous and make better decisions without you needing to make them for it, versus the capability level of people who are using it and the degree to which they’re paying attention to its output.

[01:45:49] It’s like these two curves that are just, what’s going to happen? I don’t have a prediction. I don’t know where we’ll be in a year. Obviously, for all of our sake, I’m hoping that the AI curve wins because I agree. I understand certainly the perspective of people who maybe just don’t like AI and don’t want there to be AI. I can understand wanting it to fail. I understand that.

[01:46:21] Right. And I’m no fan of AI myself, so it’s not like I’m going to criticize someone for taking that position, but at the end of the day, if you’re talking about something that tons of people are using, you’re going to kind of want it to be good. I think at this point, given the level of adoption of AI, I really don’t think it would be great if it stopped getting any better right now.

[01:46:46] Like, if this was as good as it was going to get, I think that might be bad. Certainly six months ago, I think that was true, and I think it’s probably still true today. So I think ideally, if you want software to not be terrible, you have to kind of still be hoping that six months from now the AIs are again significantly better than they were. Right. Like, that is the only way out of the current situation, as I see it.

[01:47:15] Right. I don’t know if that’s fair, but that’s my sort of feeling on that.

Ryan:

[01:47:21] One of your other top tweets, it was Shopify put out this internal memo and you just replied, Slopify.

Casey:

[01:47:30] Yes.

Ryan:

[01:47:30] So I guess it’s because in this tweet it’s leadership pushing the adoption curve, maybe harder than the capabilities of the AI in this case.

Casey:

[01:47:39] Yeah. Although I also just like the pun. One of the things that I think is most unfortunate about the AI adoption, as I’ve seen it, is just the, because people think that it’s going to be this major. I guess if I had to categorize the way it appears that companies are reasoning about it, they’re assuming that if they don’t get in early it will be a big disaster for them, right? Like there’s a tremendous.

[01:48:07] They don’t just think, “Oh, well, we can just wait until the AI does what we need it to do and then start using it.” They’re like, “No, we have to do it now. Even before we know whether it can really do the thing that we want it to do or whether we know whether the outcomes are good, everyone has to do it right now. Let’s do this, right?” And I understand why they want, why they’re going about it that way, because they think that that’s critical, right?

[01:48:27] They obviously believe that’s very important. And to me, that’s just kind of terrifying because, as with any technology, the sane way to do it is to measure its capabilities, see how well it is able to solve problems that you have, see if it solves them faster than the way that you were doing it, and put it into a workflow at such a time as you’ve determined that it is a net positive. That’s just the same; that’s what you would do with any technology.

[01:48:57] And you’d probably have your team of people whose job it is to assess this thing, and they’re out there YOLO swagging it. They’ve got 3,000 agents working on this cluster, talking to each other and doing God knows what, right? So there’s going to be that, and someone’s going to do that. But that should not be every org. You wouldn’t just be like, everyone needs to use a ton of tokens, right? So yeah, I do have concerns about that.

[01:49:24] I don’t think that the way AI adoption was done was the best way for quality in software. But I would temper that statement with just the obvious fact that we were not exactly a five nines industry to start out with. Software quality was really pretty low rolling into the AI era. So I always try to just also caveat most of the things that I have to say that might be critical of a particular thing happening with AI with just the fact that, look, it wasn’t particularly great beforehand either.

[01:50:01] A lot of this software was pretty low quality, and so you can’t. Some AI things may make things worse, but it’s not like software was amazing and the AI showed up and ruined everything. That is a completely ridiculous narrative. That is not true at all.

01:50:17 — Technical reading recommendation

Ryan:

[01:50:17] Do you have any top technical book recommendations for engineers that might be listening?

Casey:

[01:50:25] No. I would probably use this opportunity to try to pitch reading technical papers. I think something that really the industry could use more of is people being more aware of what’s happening, both the historical papers, but also just current papers. It’s daunting at first, to be sure. If you don’t tend to read technical papers in your field, you will probably find it confusing. You won’t know where to find them, you won’t know how to approach them.

[01:51:00] It will seem to take too long to read them because you don’t know how to skim them properly and determine whether it’s worth your time to investigate a particular section of a paper and all that stuff. But if you’re willing to spend a few months just, at night I look at a paper, or on my lunch break I look at a paper, if you’re willing to spend a few months just doing that, you will get your bearings and you will start to know where the good papers are in your field.

[01:51:25] You’ll know how to find them, you’ll know where they tend to be published. You’ll be able to read them much more effectively, you’ll be able to know how to spend your time on them. And I think in all but probably a few small fields that probably exist somewhere that maybe people don’t tend to write many papers in or something like that, it’s tremendously valuable, and I think it’s so valuable that I read papers in disciplines I don’t even do.

[01:51:50] And I find it extremely rewarding. I read security research papers all the time. I don’t even work in a field where there are security research implications. Games don’t really do much of that. They tend to be run very sandboxed, and they don’t. Sometimes there are. But they’re not that kind of thing. They’re not like a web server authentication protocol or something like this. And I just find it incredibly rewarding because there’s just so much good stuff out there that you can learn.

[01:52:18] So I would say that would be it. Instead of a book rec, I would say find a paper, try reading a paper.

Ryan:

[01:52:24] How do I go and find that first paper or someplace to get started?

Casey:

[01:52:29] That will be valuable for most people who are watching because they might be generalists or working in web dev or in just a general tech org at a big tech company or something like that. I would say pull up the proceedings of USENIX, look through it for a paper that sounds interesting to you and try reading that paper. Or oftentimes there’s awards. I think USENIX has them where it’s like best paper of the conference.

[01:53:00] Try reading the best paper of the conference, see what you think, because that’s a collection of papers that’s usually about operating system stuff and systems design stuff. So it’s going to be something that most people can relate to. It’s not going to be really esoteric. If you were to open up the proceedings of SIGGRAPH, for example, it’d be like, oh, neural networks for cloth simulation or something, and you’re like, okay, this is not.

[01:53:28] I can’t relate to this because I don’t do graphics or whatever. Right. So USENIX might be a good place to start. But in general, yeah, if you had another option would be to go to scholar.google.com, which is their search that just specializes in papers, and type in a topic description that you find interesting. So if you wanted to learn, maybe you were very interested in consensus algorithm Paxos or something, and I don’t know what that is, or it came up at work and I haven’t really ever looked at it.

[01:54:02] You can just type that in, Paxos, and they’ll just be a list of papers, and they’ll say a thing like cited by. You can see how many citations they have. That’s usually how influential that paper was, to a certain extent. So those are some ways you could get started and find something that might interest you. It won’t be for everyone. You may bounce off it, but that’d be my recommendation. It’s something to try. You might find it interesting.

01:54:27 — Advice for his younger self

Ryan:

[01:54:27] And then, yeah, last question for you is if you could go back to the beginning of your career, when you just entered the industry, and give yourself some advice, what would you say?

Casey:

[01:54:38] I think the advice I would have given to myself was to get into low-level programming earlier. I didn’t really learn how to properly analyze and even really write assembly language code until probably 2010 or 2015 or something. I mean, it’s recent because I’m pretty old, and it’s like the last 10 years or so. Right. And I feel like I always wanted to know how to do it and just never seemed to.

[01:55:21] And the advice I would have given to myself was, just go down the hall. What I was interested in, go down the hall and be like, grab somebody. Show me. How the heck do you write this? Just show it to me. I think one of the problems is a lot of people, especially when they’re young, they are afraid of appearing like they don’t know things. And I think that can be a real impediment to learning.

[01:55:48] I’m sure it was for me. And I probably just didn’t want to literally say, “I don’t understand any of this stuff. Can you explain it to me?”

Ryan:

[01:55:55] To me?

Casey:

[01:55:58] And I think that’s one of the most useful things you can do. I don’t understand this. Please explain it to me. It’s very useful, and most people will be very happy to do that, if they’re not a dick. Most people will be like, oh, sure. Now, they might not be good at explaining it. There are plenty of engineers who are really good at something and suck at telling you how they do what they do. So you won’t always get a great explanation, but sometimes you will.

[01:56:26] Sometimes you’ll find the type of person who can explain very clearly how it is they do what they do. So if you just keep asking, you’ll get the good explanation. Nowadays, I wouldn’t really need to give myself exactly that advice because the Internet has so much great information on it. I could have taught myself that did not exist at the time.

Ryan:

[01:56:46] Awesome. Well, thank you so much for your time, Casey. I really appreciate it.

Casey:

[01:56:49] Thank you so much for having me. I love the show. It was an honor to be invited on, so thank you very much.

In this conversation, I asked Thariq Shihipar who is an engineer on Anthropic’s Claude Code team how Anthropic makes the most out of the models for engineering and how the industry will change soon.

For instance, we discussed:

• How Anthropic maintains their code given so much more code is landing now

• What has worked in preventing AI-written breakages

• How internal software engineering practices have changed (e.g. onboarding, glue work, etc)

• How engineers within the company typically leverage the models

• What percent of Anthropic’s work is fully autonomous

Hope the conversation is helpful for giving you some insight in how the models are and will change software engineering more in the near future.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:29 - Onboarding at Anthropic

02:53 - Internal capabilities vs external perception

06:16 - Model vs Harness

08:55 - What percent of Anthropics changes are fully autonomous

14:51 - Computer use

17:42 - How to make the most out of your compute

20:45 - Loop engineering

22:47 - Where the industry will go soon

26:02 - Which model do Anthropic engineers use

27:38 - Is learning a particular model worth it

30:56 - Prompting tips for todays models

35:04 - How to get the models to do tasteful work

39:00 - How much of writing is done by AI at Anthropic

45:36 - Code ownership and maintenance at Anthropic

52:04 - How Anthropic prevents breakages

55:24 - Visibility and sharing your work

58:42 - Luck surface area example

01:00:57 - Should people still learn to code

01:07:42 - Advice for his younger self

Transcript

00:29 — Onboarding at Anthropic

Ryan:

[00:29] My goal with this conversation is to ask you as much as I can about how you can get the most out of the models specifically for software engineering, so that people in the industry can learn from the best practices where Anthropic‘s having success. And so to start the conversation off, I’d like to ask you, let’s say I was coming from a company that’s maybe less AI-pilled, and I was onboarding onto your team.

[01:01] What are the most impactful things that you tell me to start doing to successfully onboard?

Thariq:

[01:08] I think the number one tip we have for both people inside and outside Anthropic is that if you treat Claude like a thought partner and give it the context that you need, then you can usually figure out the next steps. And so I think that starting with, okay, can Claude do it? If not, why not? And using that as the starting place, I think is really important. And I think just always thinking about, okay, reflecting on, can you move up a higher abstraction level?

[01:42] Can you set up a system? Can you build the system that builds a system instead of just building the product itself?

Ryan:

[01:52] I remember when we used to onboard people, you would get assigned an onboarding buddy, someone who really knows the code base. And you can ask all of your trivial setup questions too. It sounds like Claude fills in a lot of those gaps. And in practice, is it 100% you don’t need an onboarding buddy and you can just ask the model for everything?

Thariq:

[02:14] You do need an onboarding buddy, but more from a social and cultural perspective than a technical perspective. I think, from a technical perspective, you can basically just work with Claude and, if you’re good at it, you can get what you need to onboard. But I think just having the context of how to work with the team, and also how to get buy-in on what you’re building, or understand how the team works together, or just even have a friend to work with, is really important.

[02:46] So, yeah, we still have onboarding buddies, but it’s not nearly as much technical lift as it used to be.

02:53 — Internal capabilities vs external perception

Ryan:

[02:53] There’s a big difference between the external perception of the AI capabilities and the internal Anthropic usage. Because I’ll talk to friends and say, yeah, what Boris is saying is the reality. And so my question is, why is there such a big difference between that internal perception and that external perception?

Thariq:

[03:15] I think we have a good track record when we make these claims. You’re like, oh, it turns out to be true on a large enough timescale. I think a lot of engineers are not really in the IDE anymore. The code being written is like, I talked to large enterprise customers where they haven’t typed a line of code themselves in six months. We think of it part of our jobs to figure out how to work at a higher abstraction level.

[03:45] And if I spend a day trying to figure out how to get Claude to do this autonomously and I fail, that’s fine, maybe even good. Because now I can be like, oh, hey, Claude is not good at this. How do we make it better? But I think if you’re working an average job, your job is to produce the output. And I think automation always has a cost because it’s an investment. And if it works, then great, you’ll make a return on your investment over time.

[04:14] But if it doesn’t, now you’ve wasted all this time. And so I think the nice thing about the models is that generally the chance of the investment working out is higher and higher because the models are getting smarter and smarter. But you still have to take that leap as an individual. Your boss is not going to be super happy with you if you’re like, you know, if you’ve been working on your harness setup the entire time and not shipping code.

[04:40] But yeah, I think it’s mostly just culture and thinking of it as our job to sort of live in the future. And then we try and build it into the product and our harness as well so that you don’t have to do as much manual step. Yeah.

Ryan:

[04:53] Are there examples that come to mind when you think of things you don’t see people doing at Anthropic that are really making a big difference and you’d kind of recommend?

Thariq:

[05:06] Using Claude Code for knowledge work I think is really valuable. The way a technical person does knowledge work, I think, is very different than the way a non-technical person does knowledge work these days because you can get the models to do it. And so I think increasingly, if you can figure out, like, hey, this is a task, the task is made up of code-like things, how do I tell the model the code steps to take in order to do it right?

[05:36] You can do a lot more, right. So I think I do a lot of accounting with Claude Code on the personal side, using scripts and Python instead of Excel. I do video editing using FFmpeg and these libraries to render visuals and things like that. And so I think most knowledge work is reducible to code and coding agents, if you think about it well.

[06:07] And I think that that’s one big difference that I see, other people doing less of.

06:16 — Model vs Harness

Ryan:

[06:16] I think we talked a little bit about the model and the harness, and I want to ask you, what’s the relationship between the model and the harness in terms of getting the best end results? Obviously the model is important, so how important is the harness, and are there any examples you could share?

Thariq:

[06:36] Yeah, I mean, the harness is super important. I think that sometimes there’s this idea that the harness doesn’t matter because the models will get better and better. And if the model just does everything perfectly, then why do you need a harness at all? I think that in practice, what we see is the models get better and better, and so the harness needs to become more and more complicated to allow the model to do more things.

[07:04] An example of this is Auto mode. And so Auto mode is a classifier that runs after every task that you normally have to ask a permission prompt for Claude. And back when we were on Claude Opus 4 or even Claude Opus 4.5, maybe it was not so bad to hit Enter on the permission prompts because the turns would only last a few minutes anyway. Now Claude can run for hours, and so you really need that ability for it to do work safely.

[07:38] Stick to your instructions. And Auto mode is really complicated software. Sandboxing is really complicated software. And then you also think about things like, okay, Claude can do so much more work. Now, how does it represent the work that it’s done? It’s worked for eight hours and you want to know what’s done in eight hours. This is what we use Artifacts for. And Artifacts themselves are a form of prompting, because how does Claude represent that in a useful way?

[08:06] There’s a lot of different ways that it could represent that information. And so I think roughly what we see is the harness. Harness engineering is definitely this mix of science and art. I think it’s very unintuitive in a lot of different ways, but I think it has just big abilities to unlock new parts of model behavior. And I just see the harnesses get more and more complicated, and it’s kind of harder and harder to actually vibe code to your own, which is a little bit unintuitive to me because of how good the models have gotten.

[08:45] But yeah, things like Auto mode and workflows and things like that, which are actually quite complicated pieces of software, become really load-bearing.

08:55 — What percent of Anthropics changes are fully autonomous

Ryan:

[08:55] I think as LLMs have advanced, more and more of the human part can be taken out of the loop. At Anthropic, what percent of your or your team’s changes are fully autonomously made versus actually pairing with a model? People were doing more of that around a year ago.

Thariq:

[09:18] I think it’s very dependent on what you consider autonomously made or what team or what function you’re working on as well. For example, a designer might give you a Figma file, and then you pass the Figma file to Claude Code. Claude Code is great at using the Figma MCP, but the designers put a lot of work in there. I think roughly our goal is to sort of get Claude being able to do all of the glue work that ties everything together, right?

[09:55] So, okay, you’ve got a Figma file. Do I really need to rewrite that in React or something? Probably not.

[10:00] I think that work has been done once, right? And so the way I think about it is, what’s the unique work that I need to do every day, right? And the more I’m doing that unique work, the better. And I think there’s just a ton of demand for unique work and thinking. And the more I’m doing something I’ve done before, I’m like, okay, can Claude do this?

[10:24] Or if I’m just translating what someone else has done, I’m like, oh, can Claude do this as well? It’s really blurring the lines of what does it mean? Even if Claude has fully generated his PR, you’ve probably made a lot of decisions and added a lot of context along the way.

Ryan:

[10:42] How close are we to a world where someone just says, “Hey, Claude, here’s the ticket. Just don’t tell me until you’re done”?

Thariq:

[10:50] Yeah, so I mean, it depends on how good the ticket is. If someone has perfectly written out essentially a software spec for this ticket, then yeah, actually Claude can probably do that, right? But I think that to start, let’s say that we get a GitHub issue. Is this worth fixing? Oftentimes issues are also feature requests or something, or there might be multiple things happening that maybe you combine together in a different way.

[11:18] And so I think that a lot of that work is, okay, what’s the vision for the product? Where do we want to go?

[11:27] How do we make sure what we’re building is cohesive? And so I think for a specific spec, a specific enough spec, Claude can do it. In practice, people haven’t figured out what they really want and haven’t figured out the unknowns or the shape of the problem and things like that. And maybe the way you would have done it before is you start writing the code and you’re like, oh, what am I supposed to do now?

[11:55] Or you figure it out that way. Now I think you need new ways of figuring out what you don’t know yet. And I think you can still chat to Claude, really. But I think that’s the hard part. And I think definitely a failure mode is like, you tag Claude, tag. And you’re like, hey, please do this one sentence or less description, no previous context or memory. And then it does it. And you’re like, oh, no, I don’t like it.

[12:22] And then you’re like, just iterating forever on that, right? Versus figuring out what you actually want, really quickly.

Ryan:

[12:30] When I was working at Meta, the ambiguity of the task really ranges, oftentimes proportional to people’s—I mean, levels aren’t everything in software engineering, but roughly, senior engineers kind of take that ambiguous business need and convert it into something that’s a lot more concrete. And then people who are maybe newer in their careers kind of do the implementation work, and intern projects were kind of almost line by line specified.

[13:02] If I was still working at Meta and I had an intern, I was like, just kind of give the intern back. Give Claude my intern’s work back, and it would kind of do it. What kind of work does an intern do then at Anthropic, if Claude can kind of handle it? What we see in practice is that there are just so many new types of work that no one has ever done before, right?

Thariq:

[13:55] And I think that we all have to figure that out. And so, for example, how do you do an eval against these new coding behaviors, right? How do you make sure that Claude‘s performance across millions and millions of users doing all sorts of tasks? Sometimes these tasks might have tradeoffs, you know. So I think there’s a lot of new work to be done, especially on the research side of things.

[13:19] And I think that it’s harder and harder to write those specs, but there’s also less and less experience that is relevant, you know what I mean? And so I think that, yes, having some experience means that you can sort of, you know, you know how to get work done and you know how to learn. But I think you also get those skills out of college. And now I think as an intern trying to figure out, okay, what are the things that people have not done before?

[14:25] And doing that, I think, is really exciting. And I think that there’s, yeah, I think internships are less “write the React code,” you know what I mean? And there’s so many new problems to solve. We need people to solve them. It’s helpful if you have a fresh set of eyes on it. But it is definitely more proactive and opportunistic, maybe than before, where it was maybe more of like a pipeline.

14:51 — Computer use

Ryan:

[14:51] We talked a little bit about knowledge work, and that makes me think of computer use and browser use. And I wanted to ask you, how far away is that from being widely adopted in the industry and impactful? Maybe you can talk about how Anthropic uses it, since it feels like you’re always far ahead.

Thariq:

[15:11] I think computer and browser use, the models have gotten a lot better. Opus 5, I think, is a really good computer use model. But there are these weird edge cases where, for example, it can’t type a password on my behalf because my passwords are in 1Password or something, and it can’t access that. And so it gets stuck. I think there are still those edge cases, which are kind of UX edge cases. And then I think also, obviously, computer use is also the more and more people turn APIs and MCPs into new ways to use Claude. I think that can also take a lot of the use cases that you’re using computers for.

[15:51] And so going back to, oh yeah, knowledge work, everything is code. I think there are some things where there’s no API, there is no way to execute in code other than just opening up your browser. But I think increasingly there are more and more ways. And I think, yeah, Claude Code is a great example of we’ve just sort of tried to roll up all these things into APIs that it can use. And so it feels like it can do a lot of work on your behalf, even though it’s not literally running a virtual computer and clicking things.

Ryan:

[16:24] I have noticed that whenever I use any kind of computer use tooling, it feels painfully slow. I look at the cursor, and it’s sitting there for 10 seconds, moves over, goes there for 10 seconds. Where is all that latency coming from? Do you have a sense?

Thariq:

[16:41] I think it’s hard to make a small model that’s really, really good at it. I think just because there’s a lot of knowledge that you need to have about this task and how these things work together and stuff. And so you want a smart model, and smart models take a little bit longer time. I think a lot of people thought we’d get here sooner, but I think it’s just been a harder task than we expected.

[17:03] I think one thing someone’s told me about computers before is that it’s a state machine where you don’t control the entire state. If you are on the DoorDash website or something, you want to add something to the cart, and you add it incorrectly. Now you have this new flow to undo it. Now you need to go click, and now you need to go delete it, and you can make a mistake along that side as well.

[17:25] Whereas in code, you can sort of undo, Git, whatever. You control all of the state. But for computer use, each action is, if not irreversible, it’s much harder to reverse than others.

17:42 — How to make the most out of your compute

Ryan:

[17:42] At Anthropic, I get the sense that employees have a lot of budget in terms of the compute to speed up whatever it is they need to do. And so if we were to spur the imagination of people who use the models to make them more productive, assuming they had infinite compute, what type of workflows would you start telling someone to do if they had infinite compute?

Thariq:

[18:10] I think this difference is slightly more exaggerated than you think. I think that, for example, I use my Max subscription on the weekends, and I have almost never hit a five-hour limit. I think the models are really smart, and I think that a lot of times when we’re spending a lot of compute, we’re just trying to find capabilities or we’re trying a bunch of different things, and it’s more about us figuring out model possibilities than getting a lot of work done.

[18:43] When we’re testing for math, for example, we’re trying to understand how smart the model is. And that is useful to us, that’s useful output to work. And it can also sometimes solve the Riemann Hypothesis or something, or not make progress, you know what I mean? People can replicate what we do at home just by thinking at a higher level of abstraction. For example, I’m trying to get Claude to draft feedback for you.

[19:07] And so I want the funnel for, like, Claude has drafted some feedback to the user, has submitted feedback, to be really good, right? And so I monitor that funnel. And then I asked Claude. I had some ideas, but then I was also like, oh, what if I ask Claude to try and improve the funnel? And it’d be like, here are some ideas, can you come up with some as well? Let’s figure it out. All of those things you can kind of do yourself right now.

[19:33] If you’re like, okay, when I’m making a feature, let me annotate it with events. Let me make sure that Claude has access to those events. Let me run a loop in the morning every day to check what events have fired and what changes were made. Maybe even let me proactively suggest some ideas. This can all happen, I think, within a fairly reasonable amount of compute, actually. What I see more often is people running into limits where they’ve actually done the opposite.

[20:04] They’ve started with a small mid-scope task. It’s like, oh, hey, refactor this function in this way, and then Claude does it, and maybe it has some follow-on effects because refactoring this means you have to do some other work too. And that’s not exactly correct, or you’re iterating there, and it’s like you’ve just spent a lot of time. Whereas if you had sort of stepped up a level, told Claude your goals, then figure out, okay, what are the details, do some exploration, maybe write out the schema, and then work with it, then let it run.

[20:41] You could probably get the same output.

20:45 — Loop engineering

Ryan:

[20:45] I remember it was going kind of viral, this idea of creating loops. And I mean that does feel like a pretty expensive sort of thing to set up if you’re just asking it to keep hammering away. Maybe first could you define this loop engineering thing, and then I’m curious, how often do you use it, and would you hit limits if you were on a Max subscription doing that kind of stuff?

Thariq:

[21:10] Yeah. Okay, so loop engineering, roughly, it’s like instead of prompting Claude directly, you’re setting up a system that prompts Claude. You don’t have to think of it, if you use Claude Code, a lot of this comes naturally. You just ask it, like, hey, every day do this thing. And that will, that’s a loop. You can definitely do that sort of work right now. But I think if you’re trying to set up, let’s say, like 10 loops or something that are triaging your feedback and implementing and things like that, we do that sort of work, but we also spend a lot of time making sure our skills and things like that are useful and are good at triaging, that we can have, we’re good at verification and so that we can, like, make sure that the changes land, you know, and then I think at that level, you know, what it means is like, now we have someone monitoring issues that we just could never have kept on top of before, right?

[22:16] And it just increases our software development velocity, and it’s worth a lot of value to us. And so, yeah, I think that, if you’re kind of at the scale of like, okay, you want it to essentially be autonomously running, doing a software engineering job for certain cases, I think it can do that if you set up the verification well, if you set up your skills well, if you give it the right data sources.

[22:38] But it is a lot of work, right? And I think that you have to make sure that that work is valuable to you in the same way that if you hire someone, you have to make sure that work is valuable.

22:47 — Where the industry will go soon

Ryan:

[22:47] We’ve talked a little bit about Anthropic being kind of just ahead because that’s the job of the company, on adopting AI. Is there something that you feel is kind of the next big shift that maybe Anthropic‘s already felt that you feel is going to diffuse into the industry, and if so, what might that be?

Thariq:

[23:06] Yeah, I think there are a few different ones. Obviously, Claude Code is the way we do a lot of our work right now. I think the way I think about it is that Claude Code is really good at the implementation of code, and Claude Code is for the rest of the software development lifecycle, so getting feedback, doing code review, babysitting, building CI/CD incidents, all of these other things. Claude Code is really good at at a high level.

[23:38] Turning every part of your software development lifecycle into kind of like a routine or a loop using Claude Code or something like that, I think is probably where things are headed. I think generative interfaces are still to come, and I think that Artifacts and, yeah, basically Artifacts, I think, are going to be an increasingly large way of how you interact and read with Claude.

[24:06] And so I think that I use Artifacts for almost everything. And so I think that we’re going to see that also become big. And I think that also ties into Claude Code. Right? So, like, let’s say that you are on your phone and Claude Code has done a bunch of work for you. It creates a report. The report is readable on your phone because it’s made the, like, the Artifact look really great.

Ryan:

[24:28] Could you explain artifacts a little bit, or kind of what are they and how do people use them?

Thariq:

[24:34] Artifacts are basically Claude can upload, essentially a web app for you to use. And I think that you can use it in a really wide range of capabilities. They can now, for example, call your MCP. So you can make an artifact, for example, to read your inbox and display it or sort it or tag it in one way. You can also use an artifact to show you a plan for coding. And that might show diagrams and file snippets and code and schemas.

[25:09] And so it shows you sort of, it’s like an interactive display for the job you’re doing right now. And as Claude does more and more jobs, we’re realizing that just text in, text out is probably not useful for everything, right? And Claude is better and better at creating essentially the exact interface for you at the right time. I think that there’s a lot more to do there. And I think it’s another one of those things where you have to think about, like, oh, could I be interacting with Claude in a different way?

[25:44] Could I interact with it through an artifact? Could I use it to learn more or to understand it better or stay in the loop or improve some of my own knowledge work or something? Yeah, I think it’s pretty exciting. We’re still kind of early to it.

26:02 — Which model do Anthropic engineers use

Ryan:

[26:02] Does the daily driver model vary among engineers, or do people typically just pick the most intelligent one that’s available at Anthropic?

Thariq:

[26:11] I do think similarly with models. If you use the smart models and you use them well and you give them tasks where they are well shaped and you’ve spent some time setting up a good verification harness and things like that, you can get a lot out of them. I don’t think it’s like choosing which model at the right time. I think it’s like, oh, how do you get the most out of the frontier models? Because I think technology works the way it does, right?

[26:37] Everything gets more abundant, more available. And so I think we’re in this current weird spot where we don’t quite have enough compute for everyone to have Fable at 100% of the rate limits. But I don’t think this is a durable skill to build, figuring out, like, oh, when do you use Fable and when do you use Sonnet? I think it’s unintuitive there. But I think in practice, if you’re today, what I would do is I use Fable for planning, for brainstorming, for finding unknowns, for coming up with a detailed spec, and I’d use Claude Opus 5 to implement it, and I would probably use Claude Opus 5 with workflows using a verification aid like Schema or Harness that’s built with Fable.

[27:21] So I’d use Fable for those high-leverage tasks and, yeah, Claude Opus 5 for execution and implementation. But yeah, I think increasingly, probably next year, I think you’re just not going to be thinking that much about which model.

27:38 — Is learning a particular model worth it

Ryan:

[27:38] You mentioned that skill of prompting, and I’ve heard some people say it’s not too durable of a skill because it’s really specific to a model. These models, they almost have their own unique, I guess, spiky intelligence. So if you knew everything that was very specific to, let’s say, today’s Fable, and you’re a master of today’s Fable, maybe you don’t need to know any of that stuff a year from now.

[28:08] And Fable 3 or 4 or 5 or whatever comes out. Let’s say you were talking to a software engineer who’s looking for career advice, and they’re thinking, hey, should I really become a master of engineering?

Thariq:

[28:23] My prompt, I do want to say prompting is a little bit more than just a prompt you put in. It’s also, you know, you might have made a skill or you might have added some data or something. It’s not just a prompt you write, but it’s like everything you’ve done before that builds up into your context. Sometimes people see us write small prompts and they’re like, oh, what does that mean?

[28:44] But we just spent so much time on the harness and the verification and the skills. So I think it will be really valuable to just get better at prompting. I think, to what you’re saying about each model is different, you’re right. I think each model is kind of its own kind of almost organic digital thing. And so there are quirks you have to learn, and you do have to unlearn them. We recently wrote about how we removed 80% of the system prompt from Claude Code.

[29:18] One of the learnings we had was we needed to remove examples from the tool descriptions. This used to be the only way you could get good output from the models was through tools or through examples. You’d have to be like, hey, this is the right tool. Use this here. Here’s an example of writing a file well, and here’s an example of not doing it well. Now, we found that examples are mostly negative, I think, unless you really see Claude doing something you don’t like because it’s just quite imaginative.

[29:52] It’s good at sticking to your intention and working with you. And so we removed a lot of examples. So in that case, yes, you do have to sort of adapt, but the skill you’re building is the skill to adapt. You learned how to use Fable, and now you know a lot about Fable, but you also know how to learn. You learned how to work with a model, and so Claude Opus 4.5 comes out. You need to learn how to use it again as well, but you’ll be much faster because you’re better at learning.

[30:22] You’re better at working with Fable 5. And I think, for me, I think the first model I worked with was GPT-2. And I remember it was so hard to get a JSON output out of GPT-2. If you could just get it to choose one of the categories that you gave it, that would be incredible. And so I think that building that skill—GPT-2 is such a different model than Fable 5—but I feel like the time I spent doing that has helped me be better at prompting Fable 5.

30:56 — Prompting tips for todays models

Ryan:

[30:56] Is there any tribal knowledge or quirky tips in today’s models where you’d say someone should know that to get more when they prompt? I actually need to counter one.

Thariq:

[31:03] I think that people have been saying where it’s like, oh, just believe in yourself or something. I know that Jared’s post about the Riemann Hypothesis. He was just like, keep going, just believe in yourself. I think in this case it was mostly just Jared saying, it’s okay to use Claude Code to solve this problem, and I’m giving you permission to do it. And I think that that’s not exactly the same as I believe in you.

[31:33] You know what I mean? It’s really just letting the model use compute. So I think that is something I like to tell the models right now is like, okay, hey, I think this is a hard problem. Use subagents, use workflows if you need it, right? So I always tell it to use its own judgment, but I’m giving you permission to do this stuff. I think that you have to remember that the models by default do what maybe the average user wants, which is they want it to respond and start doing work as fast as possible.

[32:11] Roughly complete the task but not spend a crazy amount of compute on it. I think that you have to sort of, if you want the model to do it differently, you have to nudge it slightly, right? So you might have to be like, okay, hey, I don’t want you to do any work yet. I want you to brainstorm. I want you to think with me, right? And if you prompt it that way, it will start doing that if you want it to spend a lot of compute.

[32:36] If you’re like, hey. Sometimes I’ll say, yeah, hey, I think this is a hard problem. Feel free to use workflows. If I’m running overnight, I might just be like, hey, I’m going to sleep. Set a /goal or something and then let it run. So yeah, I think there is just giving it permission to do the thing you want.

Ryan:

[32:57] When you recently removed so much of the system prompt, how did you prove that the end result was better?

Thariq:

[33:06] We have a bunch of user metrics, just like how much do people like the output of Claude? Sometimes you get that survey and you see it. We run evals against our internal eval and external evals to see how it performs at these different tasks. But I think it is hard sometimes. You don’t realize that if Claude is telling the user, if it does all its work and then it’s like, hey, maybe you should go to sleep.

[33:35] There’s no eval for Claude telling you to go to sleep. You know what I mean? And now we have to catch this new behavior. So it is hard. I think we spent a lot of time basically just removing lines in system prompt, running evals, seeing how it works, seeing how people reported it internally, and then adjusting. But it was a full-time job for several people over long periods of time. And so I don’t think I necessarily recommend everyone do this.

[34:03] I think that’s kind of why we wrote that post about what we learned from adjusting the system prompt. And we think that’s pretty general. So hopefully you don’t have to now go through this crazy iteration process.

35:04 — How to get the models to do tasteful work

Ryan:

[35:04] I think a lot of people, when they use Claude Code, they get excellent results when it’s kind of getting very objective work done.

[35:13] But when it’s prompting models to do beautiful or tasteful work, it’s not always. It’s pretty much more hit and miss. And so, how do you best instill a very particular style you’re going for, or particular taste in the model’s outputs when it’s a much more subjective domain, maybe like front end?

Thariq:

[35:35] The way you do it is sort of like you stay in the loop. I think you give it references, and I think the more references you give it with data, the better. So it’s better to give an HTML file than a screenshot. It’s better to give a Figma file than a raster image or something. Because now if Claude wants to know the border radius of this thing, it’s like, oh, what’s the Figma component? Border radius?

[36:00] And let me just copy it over. I think giving it a bunch of references, ideally in code, is a really good way of getting it to stick to this. I think if not, you can then ask it to. If you don’t have, let’s say you’re not a designer, there’s probably step one is being like, okay, I’m not a designer. There’s a lot I don’t know about design, and there’s a lot I don’t know about iteration. I don’t even know what good looks like.

[36:29] And I think this is part of the art of working with the designers. They will just know what good looks like, and they’ll be like, this isn’t good enough in this way. And they prompt it. And that, I think, is also a skill that will keep getting valuable and even more valuable over time: what is good output, what is worth doing? I think, for example, with the Riemann Hypothesis, Jared prompted it, but he had no idea if it was correct.

[36:56] Until Lev, who is one of the world’s best mathematicians, was like, okay, is this correct? And he worked with it, and he asked it tons of follow-up questions, and we could not follow that at all. We had no idea what he was saying, but he was really intrigued. I think more and more, being that high-taste user and knowing a lot about a problem in a domain space is how you get good outputs. That’s how you solve these problems.

[37:27] Otherwise, maybe Claude did solve physics or something, but you just wouldn’t know it. You don’t know enough about it. And so I think when you’re talking about design, the first thing you do is how do you become more tasteful with design? And so you can ask Claude that as well. You can be like, hey, I’m not a designer, I want to be better at design. I don’t even have the language first. Maybe let’s find some reference sites.

[37:50] And then maybe you pull some reference sites, and then you’re like, this is what I like, or this is what I don’t like. And then you sort of build up those references, and you give Claude Code, and now maybe you tell it, hey, let’s do some exploration. This is sort of my taste. And then it’ll do a few different mockups. I like to do these mockups all in HTML because it’s all self-contained, easy to edit.

[38:13] And then once you have that reference, now it’s a reference. So now you can make a new session and be like, hey, this is a mockup of a design. I want to start implementing this, and it will have all of it in code, and you can start getting there. But I think that the really hard part is just knowing when something is good enough versus when can you push harder. And you see this with a lot of the math proofs too.

[38:41] When Terence Tao is like, okay, enough with the half-complete theorems, just do the full theorem. And so I think it sounds simple, but it takes a lot of domain knowledge and expertise to get to the point to be like, okay, it seems like you’re smart enough to have done that. Now do this.

39:00 — How much of writing is done by AI at Anthropic

Ryan:

[39:00] When I was a software engineer, there was a lot of, I guess it was like glue writing work kind of where you finish some work and you write a launch post, or you are part of some work stream and you got to post an update every two to four weeks. Or maybe you have a direction doc or design doc and all this writing around the software that you actually write. And curious your thoughts on if that’s changed at all at Anthropic, how much of that is written by LLMs and how much of that is human written?

Thariq:

[39:39] Still, my rule of thumb is if I would be happy to show someone the prompt, I would send them the output, right? And so a lot of times the prompt is just collecting context. Context is the most common one. For example, before every one-on-one with my manager, I asked Claude to read every Slack message and GitHub message or PR and compile a report of what I did. That’s context that my manager doesn’t have because they haven’t been literally reading every PR or something.

[40:15] And so I don’t feel bad if my manager could also run this command, but it doesn’t have my context. And I don’t feel bad with them knowing that this is the prompt I used to generate this command. I think likewise, if you’re sharing updates or something like that, you might want to prove that you’ve read it. I think this is important. And sometimes little edits are ways of proving that you have also understood this work.

[40:45] And so if it’s just like a data readout, maybe you’re sanity-checking the numbers make sense and these are all the numbers you intended to include. And as part of that, maybe you format it differently or you add a little sentence on your behalf, but I think ultimately it’s a data readout. Everyone knows the prompt you wrote is like, hey, generate a readout on this feature based on this, and you’re fine, right?

[41:10] But I think if you’re pitching a new concept or a new idea, and your prompt was like, help me come up with a new concept for this product, right? People probably at least want to know that you’ve believed in it, right? And so even if you think Claude‘s idea is incredible and just verbatim, you wouldn’t change anything. What I would say is, I’d be like, hey, Claude generated this.

[41:34] But I think it’s great, you know, like I did 100 different generations. And I think this was really good. And here is something, you know, that I want to send you, right? And so I think that it’s good to be upfront about it, I think, right? Because I do think what people don’t like is when they feel like they’ve been misled a little bit. Like, oh, we thought you were doing this work, but, you know, it’s really Claude.

[42:01] Right. And I think that writing sometimes can have a lot of... There are some parts of writing where individual words matter, funnily. Tweets are, I think, an example of this, where the individual tweet matters more and more. You can’t use Claude to do that because it’s like every word has some thought that you’ve put into it and some intention that you’ve put into it. So yeah, a pitch or an essay or something like that.

[42:29] We do a lot of internal essays at Anthropic, being like, hey, this is why I think we should do this. And that’s generally all human written. It’s very looked down upon, I think, to have Claude write your essay for you, you know what I mean? Because every word is something that you are intentional about.

Ryan:

[42:48] This sounds like the proportion of the writing. That’s all that boring rote writing, like the data readouts, the one-on-one updates, the work stream updates, that’s increasingly becoming AI but always reviewed by a human. And then the novel thoughts, novel direction, is still very human written and feels like it should remain that way, even if the models were a little bit better too.

Thariq:

[43:16] Yeah, I think it’s like if your writing is also a way of thinking, and so maybe if you need to think about the data stream or data readout more than maybe you need to summarize it. And so, but I think especially gathering context is one of those things where no one will ever hold it against you, kind of. Right. Like, oh, you know, you did a bunch of research and Claude did this.

[43:41] But yeah, like I don’t want to ask my agent to do the same research. Like, you know, it’s a shortcut, but just acknowledging it is good.

Ryan:

[43:48] Someone else I was talking to, they had this thought that it would be valuable to have almost like a Git blame, but it’s like a prompt blame because it would be nice to reverse look up what was the prompt that generated this change, to kind of debug things. Do you have any sort of meta version control on the prompts that generated the software, or is it still very vanilla Git history?

Thariq:

[44:17] Yeah, that is a little bit tough because, again, what goes into a prompt is not just the prompt, but also context and skills and things like that. So maybe a prompt might seem basic, but isn’t. I think it’s kind of hard to judge, but I do, going back to when I’m giving a PR, I don’t think a PR at this point is any different than an artifact or something. Claude is doing basically all the code writing.

[44:44] So if I send someone a PR, I usually also attach an artifact of every prompt I sent to Claude, including failed approaches and things like that, so that they can see, okay, I’ve considered a lot of other things. And if I haven’t, if this is just a one-shot, I just tell people, I’m like, hey, this is the one-shot example. This is the prompt I used. And I think that’s usually impressive and interesting to them as well because they’re like, oh, it’s cool that Claude could one-shot this.

[45:18] But the worst is when you get, like, I’m just trying to avoid cases where I send in this 10,000-line PR and they’re like, how much have you read this? Or how much do you work with Claude on it? And if I’m doing a large PR, I am going to show my work.

45:36 — Code ownership and maintenance at Anthropic

Ryan:

[45:36] as much as possible on maintaining code, because AI can generate such high volumes of code at this point. Do you have any tips on what’s worked well at Anthropic for code ownership and maintenance?

Thariq:

[45:52] I do think you have to revisit what is important with code maintenance. I think that there are some things where naming used to be really important because it was how you as a team thought about this abstraction and feature. But I think naming is becoming less and less important. A lot of stylistic things in code are becoming less and less important. And I think that this is not the same to me as maintenance.

[46:19] I think that you might want to sit down and be like, okay, what things really matter now? What don’t? What opinions do we have that don’t matter? That’s one. And then I think on the second, on the maintenance side, is having good scaffolding. So I think that it’s like having a good verification harness, having a good sort of skills. We use the simplify skill a lot. I think that sometimes even from a model perspective, it might do a lot of work.

[46:51] And then even just giving it permission to be like, “Hey, I think this is the right idea. Let’s simplify.” It gives it that permission to do it. But you actually don’t want a model to, by default, do work and then simplify because maybe it’s not correct. You don’t want it to simplify work. That’s not correct. It’s like you’re wasting tokens. And so I think this is also how humans think. You’re like, you think generatively, you try and approach, and then maybe you simplify and abstract a little.

[47:23] So I think there’s some work inside your own code base or setting up those skills and that process for those practices where you’re not just submitting the first take, but you’ve simplified it and tried it. And then having a really good verification harness where you feel like you’re catching it. You have a good belief that Claude is testing every part of it. When you submit a PR to Claude Code, you get a recording back of it using the feature and testing it as an example.

[47:56] And you can just get really, really creative with different ways to test stuff. I think you should basically have on the order of, I’d say more like 100 times more testing code than you’ve ever had before. You know what I mean? So you should have fixtures for everything. You can just pull production code and create fixtures and mockups on the fly for databases. You can have Storybook for front end and things like that.

[48:22] And you can have all these different ways of testing and verifying your code. And that, I think, is really valuable for maintainability. It’s like just having all these ways of verifying it. And then, of course, there’s just the human element of where do you want your codebase to go? If you know that’s the case, probably you start thinking about how you’d replay, and undo and redo becomes really important, just that sort of stuff.

[48:52] But if it’s single-player only, that actually matters a little bit less. The average user is not going to undo 100 times or something. And so many single-player applications’ undo stop working pretty quickly after four or five times, just because it’s not that important. But in multiplayer, the ability to compose different things together is really, really important, or compose different operations together is really important.

[49:19] That’s just an example where, if you know the direction of your codebase, there are things you care about and you want the models to know, and you can include that in your skills. You can also just. That’s sort of what maintainability means to me, is having a vision for what your codebase is good at, where you’re going, keeping it in line. I do think the models are getting better and better and better.

[49:39] And almost every code base probably, I think, will have this moment where you’re like, do you just ask the model to rewrite all of it? Because now you’re like, oh, I can do it in the most performant language, I can mix and match. There’s not a reason that every software in the world shouldn’t run in WebAssembly in the browser. You know what I mean? There’s not a reason why I don’t know your Xbox game can’t run in your browser.

[50:09] Actually, the consoles are much weaker than your average MacBook right now. But it’s just the code base. But we could. And so I think probably over the next year or two, everyone’s going to need to think about that. And so I don’t think you want to spend too much time worrying about maintainability in this way. That might not matter anymore. I’m not saying maintainability doesn’t matter.

[50:37] You just have to update your mental model of what does it mean for code to be maintainable.

Ryan:

[50:43] I was talking to this friend who was saying that he leaves tons and tons of tech debt lying around because the next iteration, why waste time fixing that now? In the next iteration of Fable, it’s going to one-shot all this tech debt and refactor this for me. So kind of funny.

Thariq:

[51:05] Yeah, I don’t think that’s completely incorrect. It depends on the circumstance, right? I think this is also just a classic thing in startups where you’re like, even in normal human engineering, you always have this problem of like, hey, do I refactor? Do I do tech debt or do I deliver more customer value? Would refactoring help me deliver more customer value right now? I do think that, generally, you should think on your projects on shorter timescales, so you’re like, okay, how do I deliver value over the next month or two?

[51:36] And if the project you’re talking about is delivering value over six months or 12 months, then maybe wait for the next model a little bit and just deliver value on the short timescale. Make sure it’s really good. And if the models are not quite good enough, they might get there soon. It depends very much on the specific case.

[51:59] Right? But I’m not saying this is true of everything, but just something you should keep in mind.

52:04 — How Anthropic prevents breakages

Ryan:

[52:04] I’ve talked to some friends who work at big tech companies like Google, Facebook, those types of places. And then they, as they’ve become more and more AI-pilled, one thing that people have noticed is there’s a lot more incidents or sevs in their usage, and it’s natural in those organizations because they read the code less and there’s more code flying out. What countermeasures have worked really well for Anthropic to prevent breakages, given that the code velocity is so much higher?

Thariq:

[52:38] Yeah, I think this is something that is a byproduct of moving faster sometimes, and we have to figure it out. I don’t think our uptime is exactly where we want it to be either. But also, as a company, we’re almost six years old, I think, around. So it’s like no company has grown this fast before. And a lot of that is because we’ve been able to create more products faster than ever before.

[53:04] And so you can use Claude to make your uptime better. And I think the way we think about this is just really good. What’s the dream testing environment? The dream deployment environment? Can you take requests and replay them across mock databases and fixtures? Across everything. Can you Chaos Monkey everything?

Ryan:

[53:26] In my personal workflows, I have so many more custom random tools and scripts that just make everything faster. And just curious, on your team at Anthropic, for instance, does everyone have a set of miscellaneous tools that help them get random things done?

Thariq:

[53:48] Yeah, everyone does for sure. I think part of this is the job. I think that sometimes what we try and do is we play around with harnesses. Sometimes some people on the team build their own harnesses for a little bit to figure out, oh, is this useful or not? And then they figure out if it works and if not, they integrate it. I think that’s part of the job in some ways. I think other examples of sort of misc stuff people will do.

[54:18] A lot of people will have unique Claude Code setups. I think Claude Code is one of these things where, you know, you can have it like I have it scheduled, my calendar advice, right? And so if someone wants to schedule something with me, I’m just like, hey, you can just tag Claude here in this channel and I’ll accept whatever it puts on my calendar. You know what I mean? So I think there’s some stuff like that.

[54:41] I know a lot of people use it for email. I think that I’ve seen some people do interesting multi-closing, sort of tmuxing-like setups. What’s the ideal scenario for you to display 50 different Claude Codes, and what’s the best way for you to figure out what’s going on at any one time? I think there’s a lot of different ways, and we’re trying to make Claude Code more hackable as well so that more people can even make their own version of Claude.

[55:18] Code more different, and everyone might have their own little twist on it.

55:24 — Visibility and sharing your work

Ryan:

[55:24] Your role at Anthropic is really interesting because of the external visibility that you have. And I think a lot of people, when they give career advice, visibility is a good thing, but they don’t have this level of external visibility. So do you recommend to software engineers that they should be posting on Twitter and X? And if so, what advice would you give in that sense?

Thariq:

[55:49] Generally, the thing I say to people is that you should share your work externally as much as you can. Especially, I think, within certain companies. You might not be able to, but maybe you have side projects or something like that. I think just before I joined Anthropic, what I did was I spent a bunch of time working with different companies, building stuff, and writing about it and talking about it.

[56:13] And this was really valuable because it increased my surface area of luck. And so I think that the bar is much lower than you think. Basically, whenever someone asks me for advice, I’m like, okay, I’ll sit them down. I’ll be like, I know statistically I tell this advice to a lot of people, and almost no one does it. And everyone who’s done it is either in a job that they’re pretty excited about or running their own company.

[56:45] And there are reasons why you’re not going to want to do it, but this is it. I just can tell you one: I don’t care about your resume. Don’t do that. You have to choose an interesting project to work on. You have to work really hard on it. You have to lock in, and then you have to ship it and write about it. You have to do it. You can’t. There’s going to be so many reasons why you don’t want to.

[57:06] It’s like not good enough yet. Or like you haven’t, like you think the writeup is not very interesting or something, but you have to do it and you can’t get discouraged. Maybe the first one might not work, but you have to do it again. And maybe Twitter is not the right place. Maybe it’s Reddit, maybe there’s a specific Reddit or Hacker News or something like that. Part of what you’re trying to do is you’re just trying to find people who like what you’re doing, right?

[57:29] But I think that people in general want to really, you know, we consume more content than ever, right? And you know this, right? I think that people want really high-quality content. High-quality content, as you know, is a lot of work. And so I think going back to what we said before about would you show someone the prompt? You did, right? I think a lot of times people are like, oh, what’s the shortcut?

[57:55] “Oh, should I just ask Claude to manage my Twitter account? And is that how I grow?” And I’m like, no. Like, you should not do that.

[58:03] You have to sort of engage authentically. You have to post, do good work, and talk about it. And I think build up networks and things like that. But I think that as long as that’s one of your goals and you try hard at it, I haven’t seen anyone not succeed at it, but it is really hard. It’s kind of like saying, oh, I want to go to the gym every day, or I want to lose weight or something.

[58:26] There are simple things that you can do that take a lot of discipline and are easy to get discouraged with. But they’re worth doing if you do it. And I think posting, or more specifically writing about your work, is really, really valuable.

58:42 — Luck surface area example

Ryan:

[58:42] You mentioned LLM surface area. Do you have an example that kind of illustrates the value of expanding your LLM surface area?

Thariq:

[58:52] Yeah. I mean, okay, how did I get my job at Anthropic? I did a fellowship with a company called Goodfire where I did some applied research. And so they’re an interpretability AI company. And I was trying to figure out how do I use interpretability to make better products? And so I learned about their research, and I felt I want to work on a project, and it was really important for me to share it.

[59:21] And so, when I agreed to work with them, I was like, that’s my goal: I want to share what I’m building. I think that’s good for you as well, because Goodfire is a startup, and people want people to learn about them. And so this is something I’m going to do. So I built this interpretability visualization, and I shared it. This was my first big post on Twitter, but it was only 500 likes or something.

[59:42] Now, you know, that’s not very much to me, but it’s like, back then it was like a huge post, and several people saw it, and some of them DMed me about it. And then I got an intro into a role here. And so I think that I spent a month on that project in particular, so it wasn’t crazy. And, yeah, it just showed people that I could do interesting work.

[01:00:17] And I got paid for it too, so it wasn’t like I was doing it for free. And there’s plenty of examples of, I think people are happy to do that sort of thing for you, if you sort of show that kind of initiative. But yeah, you have to. It is like, you really have to do interesting and novel work and work hard and be proud of your work as well. There’s not a shortcut to that, I think.

[01:00:43] But if you do, I think everyone is always looking for interesting work and wants to support you and wants to hire you or, yeah, give you money, like, lots of good things.

01:00:57 — Should people still learn to code

Ryan:

[01:00:57] I see this tagline going out a lot with some of the stuff that Anthropic‘s been maybe, like, I think it was Boris went on some podcasts, and the tagline was, “Coding is largely solved.” Should people still learn to code if coding is largely solved?

Thariq:

[01:01:14] I think being technical is really, really important. Knowing how computers work, how computer programs work, how languages work, what are the hard things? And what’s a backend service, what’s a cache, what is memory allocation? All of these things are actually kind of really important to learn. I do think it’s hard to motivate yourself sometimes to do it the same way that doing math by hand was not that motivating to me, but some people just love math and did it.

[01:01:49] I think that that’s probably something that people have to figure out, but I think it is really worth it. Being technical is really, really important. We talked about at the start, or earlier, where the only way you can tell you’ve solved the Riemann Hypothesis or made progress or whatever is if you’re a great mathematician. And in the same way, the only way you can tell if you’ve built great software is if you’re a great software engineer.

[01:02:19] I think that how do you do that is hard. But we’ve talked about some of this stuff before, just staying in the loop, reflecting on your process and getting better. And you can use Claude to learn as well and sort of explain things to you. So treating it like a thought partner, but learning truly. I think Karpathy says learning should feel like effort. And I think that’s one of the hard things is a lot of times, even if you ask Claude to explain something to you, you might just nod along and you’re like, oh, yeah, I learned it.

[01:02:52] But you didn’t really, because you didn’t put any effort in. So I think it is really technical. You should learn. It’s hard to learn. And sometimes what school forces you to do is learn that. I don’t know, truly. I’m not learning programming from scratch, so I don’t know exactly how to do it. Now, I think if there are better ways, I would still type out and build programs and run them and learn them, you know what I mean?

[01:03:20] There might be better ways that are more Claude-informed as well. But I think it’s really important. I think when Boris says coding is solved, I think it just means we don’t get stuck in the same ways that we used to before. I think coding used to be this very high-variability thing where you’re like, oh, could this bug take a day or could it take two weeks? You have no idea sometimes. And I think on the whole, coding used to be in real terms something that was very rare for something to go well.

[01:03:56] Very few people in the entire world could write software, and they were very, very rare. And even if you got them all together, there were so many other reasons why it wouldn’t work. And coding was one of the rarest things in the world where the chance of a software project going well was, on absolute terms, very low. And if you were hiring someone to make software for you for something that’s not a huge product, like if you’re hiring someone to make software for your car dealership, you are almost certainly not going to get the software you wanted.

[01:04:31] You’re going to get essentially scammed, you know what I mean? Not because anyone was trying to scam you. It was just like, software is really, really hard and it could only be spent on the most important scalable things in the world. And now that coding is solved, I think what we mean is that you can use coding to do all these other things that we’ve not done before. But that’s not to say that that’s not a lot of work still.

[01:04:56] It’s just not this incredibly rare, difficult thing that mostly just doesn’t work, and you have to spend, like, eight hours a day locked in to do well.

Ryan:

[01:05:07] It’s really insane. That shows the difference in expectation is when I used the right software. I would be shocked if it worked on the first try. I was like, whoa, wait, why is this working? And you expect to kind of bash your head against the wall a little bit and then it works, even if it’s just like you missed a semicolon or something like that. And now I almost have the flip expectation where when it doesn’t work, I’m like, wait, what, why, why did Claude.

[01:05:34] What happened here? Usually I expect it to work almost the opposite, like on the first try.

Thariq:

[01:05:41] It’s crazy immediately. Yeah, I think humans get really used to abundance, right? There was this article someone shared recently about going through a modern apartment and talking about all the wonderful things that we have now that people could not have imagined before. Something that can play music on demand that’s suited for your mood. Before, you’d have to hire a musician to go write incredible music, right?

[01:06:09] But I’d say, on the whole, probably more people are getting paid to make music now than ever before, right? And I think that music is reaching more people than ever before. And I think probably the same thing will happen with software, will happen with math, will happen with all of these things where, when you get abundance, people are like, great, I want more abundance.

[01:06:30] I want my software and everything, you know. Like, I want my music everywhere, you know.

Ryan:

[01:06:34] So, yeah, one potential other data point from this conversation saying that maybe people should still be technical or learn how to code is, I think earlier in the conversation we talked about automating knowledge work, and you mentioned that people who are technical had kind of a leg up because they kind of understood how to coordinate Claude to do a variety of things, like you’re calling FFmpeg to automate some video editing.

[01:07:01] And I don’t think someone who is not technical would have that thought. So it does seem like even in this case where models are doing a lot, there’s still so much value in

Thariq:

[01:07:12] Being technical, knowing how computers work, in the same way that probably the most technical CEOs are, like, the best CEOs are technical, like Zuckerberg, Elon, but they probably haven’t written a line of code truly in a long time. But they understand how systems work, they understand constraints and things like that. And that’s really, really important. And so even if all that work has changed, I think being technical is really, really important.

01:07:42 — Advice for his younger self

Ryan:

[01:07:42] And then last question for you is, if you could go back to when you just entered the industry and give yourself some advice, knowing what you know now, what would you say?

Thariq:

[01:07:52] They’re like kind of like two wolves, sort of. I think you have to believe in yourself. I think this is really important. And I think that at least when I joined the industry, it was rarer to believe in people when they were kind of younger. I think that was the whole point of Y Combinator or something was believing in young people early on to do really great things.

[01:08:15] And so I think that, you know, even going back to the internship discussion we had earlier, right, I think that thinking of yourself not as someone who’s being trained to do something, but someone who can do something incredible right away, I think is really important. And I think I wish I had done bigger, bolder things that I’d written and shared about.

[01:08:38] I think there were lots of ideas where I was like, wow. I think I had thought I had done original work that I wish maybe I’d even shared in some form, but maybe not in a form that survived the Internet, you know, and it wasn’t a goal of mine. And so I wish I’d sort of been bolder and done and shared some of this work. But at the same time, you also.

[01:09:03] There is a lot to learn from people. And I think that when you’re young, you tend to fall. Either you’re not bold enough or you’re too bold and you don’t figure out what people have done before and figure out why this is not working, right?

[01:09:29] And there’s this balance. And I think everyone has different failure modes, but I think I probably didn’t take enough advantage of mentors and people who had learned a lot. And I think I probably had to relearn a bunch of things as a result. So there’s probably not universal good advice, but just things to think about as you’re entering.

Ryan:

[01:09:53] Awesome. Well, thanks so much for your time, Thariq. Really appreciate it.

Thariq:

[01:09:56] Yeah, of course. Thanks, Ryan Peterman. It was fun.

This made me curious about Martin Odersky’s (the creator of Scala) thoughts comparing different languages. His deep domain expertise made his responses comparing Rust, Zig, Python and Scala interesting.

He also had a lot to say about how AI will impact programming language ecosystems in the future. For instance, he talked about some research he was working on to strengthen the static guarantees programming languages give to provide more safeguards for LLMs.

Hope you enjoy the conversation!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:44 - Why care about functional programming

06:35 - Why should people learn Scala

09:26 - Rust vs Scala

12:42 - Rust vs Zig

15:45 - Scala vs Python

18:31 - The programming languages that influenced him

22:16 - How running on the JVM works

26:33 - Why writing a compiler is hard

29:19 - Why Twitter adopted Scala early on

31:00 - How he believes AI will impact programming languages

43:40 - Will there be less engineers in ten years

44:34 - Top programming languages to learn to grow

46:18 - Top technical book recommendation

46:51 - Why he chose academia instead of industry

48:28 - Reflecting on Scala

55:42 - Advice for his younger self

Transcript

00:44 — Why care about functional programming

Ryan:

[00:44] What is functional programming? And why should an imperative programmer care about the functional way of programming?

Martin:

[00:52] So functional programming is programming with values, so you don’t have state that changes, like mutable variables that change or arrays that change. You have values and you have functions, and the functions transform these values into other values. So it’s a very restricted form of programming. And most real functional programming languages are impure in the sense that, yes, of course, at some point you have to touch state and change things and write to standard out and things like that.

[01:24] But the idea is to do that sort of very late, so to have the largest part of your program represented as values and functions that transform values. And the benefit you get from that is essentially much better predictability and fewer bugs, because these side effects to, let’s say, a global variable or a field in some object graph or things like that, they can really trip you up. They can essentially, they’re an undocumented effect of your function, so it’s not reflected anywhere typically.

[01:57] But maybe you have a comment if things are good. And these things are very hard to keep in your head and generally reason about. So the advice from functional programming is essentially to keep these things to the bare minimum and possibly to nothing if your function maps into these things. The other reason why functional programming is nice is that it’s very directly linked to mathematics. So in mathematics you have theories of, let’s say, polynomials or strings or lists or things like that.

[02:33] And in none of these theories will you find the concept of mutation; that just doesn’t exist. So you can take a polynomial and you can transform it into a new polynomial, but you can’t change a coefficient at 0.3 at the third coefficient and pretend it’s the same polynomial. It’s not in mathematics, right? It’s clearly something different. So functional programming, you could say, follows quite closely the way mathematics sees things.

Ryan:

[02:58] What would you say to someone that doesn’t do functional programming because it’s not convenient?

Martin:

[03:04] I guess two things. One is it’s a learning curve. So initially your brain is wired to do imperative programming from when you were very young. I imagine most people learned an imperative language first, and then it’s hard to see how you would express things differently. But if you persist in that a little bit, and it doesn’t really take much, then you will essentially reap the benefits very quickly, that you say, well, actually my program got a lot clearer.

[03:36] I can understand it better. I don’t really have to track some steps, go step by step through my program with a debugger or things like that to figure out what it does. Typically I don’t need a debugger when I write functional code. That’s really not necessary. The other thing is to essentially know when to stop. So there is a strand of functional programming called pure function programming, which tries to express as much as possible in pure functions and to delay the side effects and wrap them up in monads or whatnot.

[04:15] And that can get very inconvenient very quickly. So my answer to that would be, it really depends. And in most cases, it’s completely okay to have your side effects as long as these are well documented and you use them. So basically, use these things in moderation. I would say functional programming is great for 95% of your program, and if you need some side effect, some imperative feature, for the last 5%, that’s also okay.

Ryan:

[04:45] Is there any quantitative measure of the, I guess, the correctness benefits that functional programming gives you over imperative?

Martin:

[04:56] I think there are some studies. It’s not quite clear how significant they are. I think people criticize them a lot. The studies tend to say that a language like Scala would have fewer bugs than a language like C/C++. But I don’t really want to insist on that because these studies are very hard to do, and the methodology is very hard to get right. I believe the effects become more important in large programs than in small ones.

[05:28] For small ones, you can do anything, really. You can write a loop, you can write a recursive function. It doesn’t really matter. And it’s very much a matter of taste which one you prefer. But in a large system, I believe static types have certainly proven their worth, even if we don’t really have a conclusive study that shows it. I mean, I can point you to a study, and if you’re a dynamic typing enthusiast, then you will point to another that essentially claims the opposite.

[05:59] So it’s very, very hard to do empirical software engineering on that scale. And so I’m afraid I can’t really give a good answer. I just have a feeling that mostly functional statically typed languages is sort of a sweet spot for getting programs right. Maybe the other thing is when you really need to get them absolutely right, like with proofs and things like that. If you do Rocq or Lean or any of these things, these are all functional languages.

[06:29] So people wouldn’t even attempt to do something like C/C++ here.

06:35 — Why should people learn Scala

Ryan:

[06:35] When you think about Scala in the environment of all programming languages, what sets Scala apart? Or maybe put it another way, why should someone learn Scala in 2026?

Martin:

[06:47] Well, Scala is the only functional language that is also a very capable object-oriented language. In fact, it was born by the idea that we can actually make a fusion of the two in a way which is not side by side, but which really combines the features in a nice synthesis. So that was what Scala was about. That’s what I wanted to show, and that’s been largely successful. So you can write really beautiful programs in this combination.

[07:19] Object-oriented programming comes in when you talk about components and modules and essentially encapsulation, these sort of things where functional programming typically doesn’t really have a very strong story. I mean, there are languages like Standard ML or OCaml that do have very capable module systems, but other functional languages don’t. And people, when they think of functional programming, they don’t really think much about components and interfaces and these sort of things, which are things that I believe also matter very much.

Ryan:

[07:50] Could you give an example? Maybe an object-oriented thing that you could do in Scala, but you couldn’t do in Haskell, which is pure functional.

Martin:

[08:00] It’s sort of ingrained in the whole fabric of the thing that everything is essentially objects, what you do. So one thing that you get is what I think Simon Peyton Jones called the power of the dot, that you say it’s super convenient. You have an object and then you do dot, and then you have the environment that immediately tells you what are the methods and fields of that object, that you can use them.

[08:24] So it focuses your mind. Whereas in functional programming, it’s typically you have a sea of functions that can be applied to arguments, and you have to figure out what they are.

Ryan:

[08:34] When you think about the systems programming languages like Rust, Zig, Go, C/C++, in your opinion, which one would you say is kind of the best one? And then maybe we can compare it to Scala.

Martin:

[08:46] In this day and age, systems programming languages need to be memory safe, guaranteed memory safe. So that would already exclude quite a few of them, but it would leave Rust and Go, I think. And Rust and Go are at different levels. Go is really not a sort of nuts-and-bolts systems programming language. This is more a language in which you would write, let’s say, an application server or some middleware or some cloud infrastructure, or things like that.

[09:13] It’s not something you would use for embedded, say, which you would use Rust for. So I think in the domain, both of them are probably the ones that are the leading ones that I would take most seriously.

09:26 — Rust vs Scala

Ryan:

[09:26] And then when you compare Rust or Go with Scala, what are the pros and cons of the different language designs? What’s something that Rust does better than Scala? Something Scala does better than Rust.

Martin:

[09:40] So Rust is closer to the metal, you have better performance guarantees. I guess the fact that Scala is a garbage-collected language means that you always have some pauses. I mean, garbage collectors have become quite, quite capable. I mean, they’re brilliant and the pauses are really very, very small. But it’s a fact that you do need a big chunk of memory to run fast, and I guess Rust could run in much smaller memory.

[10:08] So I believe that’s better for embedded systems and things like that. I believe right now Rust is actually overused because a lot of people push Rust for things higher up in the stack where your garbage collector is fine. But essentially, you still want to write code without, and that is for me a bit an exercise in, I don’t know, just intellectual that I can do it.

[10:37] I don’t really think there’s a big sense in it to write memory management for a garbage collector. You should absolutely use one because it makes a lot of things simpler. So yes, of course, if given enough brains, I can write code around it, and I can do that. But why should you? I mean, it can be much simpler. So that was for Rust, for Go. Go is sort of a language that lags behind. I mean, it was intentionally designed to be very, very small and essentially to be the standards of the ‘90s.

[11:15] So now they have gotten generics, which is a big step. So I believe that sort of is a step forward for that. But it’s still a fairly limited language. What you can do, which has an advantage that essentially it forces a very uniform style because there’s not much different things you can do. And there’s probably a culture fostered to do things in a certain way, which makes it easier to essentially read one another’s programs and essentially jump in a new code base and things like that.

[11:47] So I think that would be my main advantage of Go that I see there.

Ryan:

[11:51] Is it possible to turn off the garbage collector in Scala?

Martin:

[11:55] Not in production. So we have some research that would let you use essentially your own memory allocators and things like that, the way let’s say Zig does it. The problem with that is always that you can leak references into memory that you reclaim, and then all hell breaks loose. Essentially, your pointers, you point to memory that’s undefined. But in Scala we now have a very good way to actually track these references, so we can actually prevent that statically by the type system, that this will never happen, and you can still have your own allocator.

[12:36] That said, we haven’t really shipped that in production yet. So right now I would say you use the garbage collector. Scala.

12:42 — Rust vs Zig

Ryan:

[12:42] Yeah, I see a lot on the Internet, people comparing Rust and Zig, or kind of a fierce debate on which one is better. When you think about Rust versus Zig, what are the merits of the two compared to each other?

Martin:

[12:58] So what I can see is Zig has a really nifty compile-time construct, essentially inlining, where the compiler does smart inlining, and that is quite clean and quite powerful. And Rust has macros, but I think they’re more clunky than the Zig version. In Scala, we have something quite close to Zig. We also have essentially a thing that’s based on inlining and optimizations by the compiler. But we have a restriction, which I believe Zig doesn’t have, and that is that there cannot be additional type errors after inlining.

[13:41] So the thing is, you inline, and then the question is: Is the inline program guaranteed correct, so type-correct, or might you have type errors? The typical example where you might have type errors is C++ templates. In fact, that’s quite scary in C++ that you can expand a template, and then you get very, very complex type errors and very, very hard-to-debug things. So Zig, I believe, its inlining mechanism is much saner.

Ryan:

[14:10] When you say inlining, can you explain the concept?

Martin:

[14:13] Inlining just means that in Scala we can write `inline` in front of a function, and that means that the compiler will, before it starts code generating, during the time when it looks at the type code, which are trees, take the function body. When it sees a function call to that function, it will take the call and replace it by the body, and then it will do some optimizations. It can say, okay, so here we have essentially an application to, let’s say, a value which is a lambda, but I know where the lambda points to, so let me forward the call right to the function.

[14:54] And with that you can already do quite a bit of essentially optimizations, which are guaranteed because the inliner must inline. That’s not a thing. An optimizer has essentially discretion whether they want to inline things or not, and so you can never rely on that. But an inliner, which is essentially a compile-time based on the typer, must inline, so you can rely on it, and constexpr in Zig and C is essentially very similar.

Ryan:

[15:25] Okay, so it’s a way to get rid of the function call, or the overhead of a function call, and tell the compiler you can do more because it’s all, I guess, inline.

Martin:

[15:37] Yeah, you reveal the implementation, and that means the compiler can do something with that.

15:45 — Scala vs Python

Ryan:

[15:45] When you think about all the dynamically typed languages, which one stands out as one that you think is kind of the best among them?

Martin:

[15:53] Python is ubiquitous, and it has a nice syntax. A lot of Python programs look like they’re very easy to read, so that’s definitely an advantage. And the other one would probably be something like Scheme, which is sort of very grounded in computer science theory and lambda calculus and things like that. So both of them are sort of interesting in their own way. But of course Python is 100 times more popular.

Ryan:

[16:23] If you compare Scala to Python, for instance, I guess what are the trade-offs that the two languages take?

Martin:

[16:30] I think the gap is closing because Python now actually has an optional type syntax and a number of type checkers that check that syntax. And Python is getting some of the features that Scala had since the beginning, like pattern matching is in one of the recent Pythons. So I think actually the gap is closing not just between Python and Scala, but between a lot of programming languages in general. They’re sort of all drifting to a standard set of features, which mostly come from functional programming.

[17:01] Actually, pattern matching, for instance, strong type systems, generics, polymorphism, all these things came from closures, all these things came from functional programming. And so the gap is closing in that sense. Python is, I think the main advantage of Scala over Python is that it has a strong type system that is always on, and that gives you essentially guarantees that certain bad states can’t happen.

[17:34] So really you can rely on it. Whereas I think the Python type system, well, it’s just syntax. It has a number of type checkers, but in general you have fewer guarantees. And I believe it’s also the ecosystem and culture that doesn’t value types as much in Python. So I think that’s probably the main difference syntactically. The two languages, I think with Scala 3, are actually also quite close.

[17:59] So Scala 3 looks a lot like Python in that sense. You could say, well, you can see it as a language that has strong types and runs on different runtimes than Python. Or I should say the other thing with Python, which is really great, is that Python is a fantastic glue language because I can essentially have very, very efficient linkages to high-performance C libraries, pandas or NumPy or things like that.

18:31 — The programming languages that influenced him

Ryan:

[18:31] You mentioned that a lot of the programming languages, they’re kind of drifting or kind of being inspired by the other ones and adopting new features. In the design of Scala, is there a programming language that you admire most and influences Scala the most?

Martin:

[18:48] Historically, Scala was essentially, you could say it was a blend of Java, OCaml, and Standard ML, which is close, an ML-like language, and Haskell. So I’m by trade an imperative programmer. PhD is from Niklaus Wirth. I know Pascal, Modula. That was sort of my first generation of languages, and I like them a lot. And then I became sort of a converted functional programmer. So I looked very closely at ML, OCaml, Haskell, and these things.

[19:23] And then Scala came about. There was a predecessor language called Pizza, and I was working on that with Phil Wadler, who’s one of the original Haskell designers. And the idea was to have essentially an accessible functional language on a very widespread platform, which was the JVM at that point. And in order to prepare for that, I wrote a Java compiler. So that’s how I learned a lot about Java and what Java was.

[19:53] And in the end I had to say, well, it’s actually quite useful. I was quite dismissive at first, but afterward I found it actually quite useful. I mean, this was very early Java, this was Java, even pre-1.0. So now Java is, of course, even more useful, but also a lot bigger than what it was at the time. So when we came up with Scala, which was sort of the second iteration after Pizza, Pizza was the language I did with Phil Wadler.

[20:24] The ideas came mostly from Java, OCaml for the modules and the component model, and Haskell a lot for the standard libraries. So if you look at the function names in the Scala standard library, then there’s sort of a mixture of OCaml and Haskell, you could say, but you recognize a lot coming from both of these languages.

Ryan:

[20:48] If I recall correctly, Java had some sort of licensing with it, or it was owned by a company. How were you able to build on top of Java? Or did you have to pay for licenses, or how’d that ecosystem work?

Martin:

[21:05] The language standard was open source. There was a lot of experimentation with Java at the time. I think the only thing that Sun, that was the company at the time, they’re very particular about, is that if you did something that was using Java and had Java in it, you had to call it Java, and you couldn’t have a different name. So that’s why initially, for instance, Microsoft clashed with them, and then Microsoft went away and designed C#, which was sort of a.

[21:40] Java, some steroids. They threw in a bit more than what Java had. At the time, I think the nastiness came, Sun was actually quite an open company. So at the time, we were not worried about that. So that was in the time frame from 1998 to 2004, 2005, something like that. And at the time, there was no issue. I think the issue came later when Sun was acquired by Oracle and Google forked Scala on Android.

[22:11] Java on Android, and that’s when the fight started, but that was much later.

22:16 — How running on the JVM works

Ryan:

[22:16] So when you say that Scala was using the JVM or built on top of it, like concretely in the tech stack, what does it mean that Scala uses the JVM? Like, how does Java source code eventually execute on a machine?

Martin:

[22:32] So the JVM is essentially defined by its bytecode. The bytecode is essentially an intermediate format which you can translate your program into. And then the bytecode is run first by an interpreter and then essentially by an optimized compiler, just in time. Compiler JIT. So that’s called JIT. They do that. And so if you know how to output bytecode, and that’s not very hard, then you can run on the JVM.

[23:06] So that’s essentially the idea. The harder part then is interop, that you say, okay, I run on the JVM. I have to make sense of all these Java libraries out there. So I have to somehow map a Java concept into a Scala concept so that the compiler can understand what it is and I can document what it is for Scala programmers that maybe don’t understand much Java. So that is sort of work that sort of goes more into the details.

[23:35] That said, I mean, that’s not the only Scala platform, so it was born on the JVM, but now it also exists on JavaScript and Node.js, on WASM and on Scala Native. So it’s really a multi-platform language.

Ryan:

[25:05] Let’s say I write a Scala program. I have the source code, I have to compile it, and then I have some Java bytecode, and then I call the JVM and I pass in this bytecode, and it just works.

Martin:

[25:19] Yeah, exactly.

Ryan:

[25:21] What would the advantage be of compiling Scala to Java bytecode instead of doing something like C/C++ where you compile it all the way to machine code from source?

Martin:

[25:33] We have that too. So Scala Native compiles directly using LLVM to native code. The advantages of compiling to bytecode is essentially, again, the interop can use all the Java libraries, then the garbage collectors. So the JVM has actually very good garbage collectors, high-performance ones, and the runtime loading. So what I can do on the JVM is I can compile, let’s say, a one-line thing into a little Java bytecode, and I can immediately load that bytecode and execute that.

[26:13] And that makes it very easy, for instance, to have a REPL, because that’s how a REPL would work, a read-eval-print loop. So I would just generate a snippet of Scala code to bytecode, load it into the running JVM process, and it gets executed. And that’s much harder if you go to binaries; basically, binaries don’t really have a concept for that.

26:33 — Why writing a compiler is hard

Ryan:

[26:33] You mentioned that you wrote a compiler for Java before Scala, and I’ve heard that compilers are notoriously hard to build. Can you explain the hard parts and why they’re hard?

Martin:

[26:46] Compilers are very intricate because I think there are a lot of requirements on a compiler. So you have languages which are already complex artifacts. Then you have a thing called type inference, so you have a type system, but essentially you want the compiler to infer a lot of types that make sense. Because you as a programmer think, well, the compiler should know that, and it should, but actually for the compiler to do that is quite hard.

[27:21] And then, of course, you also demand that it would generate very efficient code for your program, because again, the compiler should know that, right? So there are a lot of demands on that. Plus, there’s a demand that it should be very, very fast. And to square all these demands requires quite a bit of work, basically. There are also things that make it easier for compilers because they’re fundamentally deterministic programs.

[27:47] So essentially, you run a compiler on a source, and you always get the same output, so it means they’re easier to debug. You can just replay things and repeat things. Whereas if I would have some cloud service or distributed application that has other nightmares, right? Every run is different, and how do you even figure out what goes wrong?

Ryan:

[28:07] So when you wrote that compiler, I think Espresso for Java, how long did it take to write that by hand?

Martin:

[28:16] At the time, it took me about three months, I think. Not full time, maybe half time. Three months, half time, something like that. But that was a very simple compiler. So that’s the other thing with compilers: they typically start simple, and when you’re at the 10-year mark or 20-year mark, then there’s lots and lots of essentially other requirements to a compiler that make them more complex.

Ryan:

[28:37] Were there libraries that you could rely on to kind of piece together components of it, or did you have to write everything from scratch?

Martin:

[28:47] There was a library to generate bytecode, I think. I think I used that in that version. Yeah, I did, yeah. So there was a library, essentially a high-level library, to just assemble bytecode and put them into the right format and things like that. But that was essentially it. The rest I wrote by hand.

Ryan:

[29:07] That’s crazy because, well, I mean, these days a lot of people, even more so now, we’re thinking less about using AI and more about kind of writing the code. So that’s pretty impressive.

29:19 — Why Twitter adopted Scala early on

[29:19] I saw one of the big, I guess, moments for Scala was that Twitter adopted it, and I wanted to know the story behind that. How did they choose such an obscure language at that time?

Martin:

[29:30] It was very obscure at the time, that’s true. So I believe the story was Twitter originally was written in Ruby, and it wasn’t very reliable because I believe it’s again a problem with garbage collector and memory management and things like that. And it was a small company at the time, so 25 people, including the ops people, and essentially the board and VC investors said you can’t go on like this, being unreliable like that.

[30:03] You should do Java, because Java was sort of the solid choice at the time. But some of the engineers at Twitter, they wanted essentially something more fancy as a programming language. And there are some people who knew OCaml and liked OCaml, but of course OCaml didn’t run on the JVM. And then they found Scala and said, well, Scala is actually quite a lot like OCaml and we can tell our investors that we do Java because it’s not a lie, we do JVM bytecode.

[30:33] And that’s essentially what it comes down to. So that’s why they picked it. And they were quite the first. But once they picked it, sort of the floodgates opened because at that time they were a very interesting company and a lot of people admired them. So a lot of people followed and did the same thing. Mostly they came from dynamic languages, so Twitter came from Ruby, others came from PHP or JavaScript, things like that.

31:00 — How he believes AI will impact programming languages

Ryan:

[31:00] I mentioned a little bit that AI is kind of generating a lot of code, and I wanted to ask you what you thought maybe the future of programming languages might look like if you speculated or drew it out further into the future. If AI is generating more of the code, how do you think that might affect the programming language ecosystem?

Martin:

[31:22] Yeah, I think right now we’re sort of in an existential crisis, right? So we have AI generating the code, but humans being asked impossible tasks, like to review all these mountains of code and things like that, which will never work. And at the same time, AI has also gotten extremely good at exploiting vulnerabilities in code, like we all heard of Fable and things like that, that you can’t use it anymore because it’s too dangerous. It will exploit things.

[31:53] So we are at a moment where it’s essentially very dangerous that we lose control as humans of what actually happens here. And that’s a challenge that I think programming languages can help meet. And probably definitely not only programming languages, that’s not a silver bullet, but they definitely can help things. So I think one of the things is that the focus, if the code is AI-generated, then the focus has to go elsewhere.

[32:26] And I think the focus will go to the interfaces and to the types. So I expect types will become a lot stronger and more precise than what we had. Because types are essentially the handle that we can make a contract between the human and the AI that the human can understand and that’s concise enough to be reviewed and that essentially the AI can keep to. We have to level our game quite a lot because right now, I mean, let’s face it, type systems are mostly recommendations. They’re mostly things that mostly hold, but not always. There are no guarantees because you can always have a cast or value, you use some dirty memory or.

[33:13] I mean there are a number of techniques to undermine the type systems, and we have to close all these holes from the beginning because once there is a hole, somebody can exploit it. So I think strong types, strong high-level types, will help. And then I think the other part is generally the programmer has to think much more about what the requirements are and what are essentially the high-level specifications and be able to leave the code to be generated by somebody else in confidence.

[33:50] And I think we’re not quite there yet, but we have some ideas about how we could get there. So one technique that I believe we can use, and it has been around for a long time, but maybe its time has come now, is capabilities. Capabilities essentially were used in operating systems to give very fine-grained permissions to entities, users, programs, and things like that. And I believe that can be used also for agents and agentic AI to say, well, once we have agents, we have to give agents very precise and fine-grained capabilities for what they can do, and that lets us essentially be confident about what they will not be able to do.

[34:34] They will not be able to leak my API keys or my email or do other things. So I think that’s an important part. And the existing languages are not there yet. I think Scala is halfway there. At least it’s there in essentially stuff we’re working on, which we have in the lab and we have released as an experimental feature. So I’m quite excited about that. The first thing that you have to do is definitely be memory safe.

[35:08] So a language that essentially is not memory safe, that lets you essentially access undefined memory, is immediately out because you can’t guarantee anything. So that’s. In that sense, it’s good that there is a drive to use, let’s say, Rust as a memory-safe language that was even promoted by the American government, I believe. So that’s definitely a very useful drive. But I think you need a lot more, because you need much.

[35:36] Rust talks essentially mostly or only about memory. You need to talk about a lot more things than memory. You need about essentially read permissions, write permissions, access to secrets, all these things that go beyond that. And you could say, okay, Martin, you’re totally unrealistic because all our software is written in C/C++ and we will not be able to rewrite that. But I believe AIs can help there, right?

[36:09] So AIs are great in rewriting software. So if we know what to rewrite, too, I think we might be able to get there.

Ryan:

[36:17] You mentioned some of those experimental features in Scala that might have some sort of safety guarantees or signal capabilities. Can you explain what that might look like, or maybe give an example?

Martin:

[36:30] So a simple example would be, let’s say somebody gives me a file and I have access to the file, let’s say a log file or something like that. I have access to a file for a limited time, and then I need to close it. So typically I have an operation that essentially somebody passes a file to me, to an operation that my program provides, and the program does something with a file, and then the environment will close it.

[36:59] But how do we make sure that I don’t hold on to the file after I gave it back to the environment, or after I pretended I’m finished with it? Because, hey, I have a file, I could have stored it in a variable, I could have stored it on the side, I could have gone back to it and done something with it. So capabilities help me prevent that because essentially I can say, okay, so this file is a capability.

[37:23] And then I can further say, well, this capability can be used only in a limited scope, and the type system will make sure that the capability doesn’t escape. And the way we do that is that if a type refers to capabilities. So if I have a thing that I say, I give you back a lambda or a stream and it holds onto the file. So the stream holds onto the file in secret. In our language, that won’t be a secret anymore because the type has to declare that the thing I return does hold on to the file.

[37:56] The file is a capability, and I can’t essentially hide capabilities I have access to in my type. I have to declare them. And that gives me essentially this control that then I can also enforce, to say, well, at this point you’re not allowed to have any capability because the type that I enforce you to have is a type that doesn’t hold capabilities. And that way I enforce with the type system something which previously hasn’t really been enforceable for memory safety.

[38:26] It’s essentially the same thing with arenas, that I have an area where I allocate memory and then I want to get rid of it. I have to make sure I don’t have pointers pointing into it. And that’s exactly the same situation, and let’s say for accessing secrets again. So it’s a very common pattern that I say in certain situations I want to make sure that you don’t have, or that you only have a set of defined capabilities that I give you, and nothing else.

Ryan:

[38:57] You mentioned memory safety is an absolute table stakes. What are the programming languages that you think of that are not memory safe? I know there’s C/C++, but what are the other ones?

Martin:

[39:08] The big ones are C. I don’t know about. I think Zig or Nim or other low-level systems languages are not memory safe. So that was sort of in Rust, the big achievement, that you can be a low-level systems language and be memory safe. Nobody sort of thought that was possible before Rust came. So that’s why I would think, I don’t want to say anything wrong, but I would think that essentially most other low-level systems languages would not be memory safe.

[39:40] But you really need more than memory safety. You really need capability safety, that you say, when I essentially hang on to something, I can’t sort of forget capabilities to say I hang on to something and I just conveniently forget that I have access to that. And I can’t forge capabilities to say, well, if I need a capability, I just make one up. These two things need to be prevented. And that goes beyond memory safety.

[40:07] But memory safety without memory safety, essentially you have nothing because you can fake everything.

Ryan:

[40:12] A lot of programming language design and how we write code in the past is writing the source code so that it’s nice for humans to read. But if humans are no longer interacting with the code, what kind of things come to mind that we might not care as much about but are good for machines to read?

Martin:

[40:34] For instance, the first thing is maybe sometimes you want to read it, but you probably wouldn’t have written it. So easy to write is definitely not a big criterion anymore. Easy to read to some degree, yes, but that means you don’t need any of these sort of syntactic hacks, like to write plus plus in C or things like that. That’s easy to write, right? But I don’t, I mean I’m sure we will still have that, but it doesn’t really matter anymore.

[41:03] I mean, whether I write an assignment in long form or with X, whatever. So I think these things won’t matter much less. The things that matter much more are, that continue to matter, and are essentially high-level ways to constrain and specify what my program should do. So constrain what it should not do, that’s one of the things. And also specify what it should do. And I mean some people say a golden age for formal verification because we can be very precise in our specifications, and our AI can actually not just furnish the program, but also the proof that the program actually meets the specification.

[41:48] And I think that’s true. That’s really very exciting in a lot of areas. But in the large, the problem is you often don’t really have the formal specification, or it’s just as hard to write a formal specification than to write a program, or sometimes even harder. So that means that we will still live in a world where we specify things by natural language, by prompt to the agent, and the agent then will do the code.

[42:16] But I imagine that also that will be a lot more formal in a way. So in a sense right now the prompts, I mean, it’s fantastic what they can do with the prompts, but then we throw away the prompt or it’s hidden in the chat history with the agent. So that’s really a shame. So I really should have the prompts as first-class values in my program, that I can say, well, essentially that’s what the program is about, and if I change the prompt, then the AI will know essentially what the incremental change was and change the program incrementally, these sort of things.

[42:51] That’s another thing that I think we’ll see in future programming languages for agentic programming.

Ryan:

[42:57] Maybe some kind of meta information about the program, almost like a Git blame, but like a prompt, I guess, blame of what generated that part of the code.

Martin:

[43:11] You should be able to keep that around and come back to it. Yeah. Also because you might want to change, right? You might want to say, well, now it’s exactly the same, but I want to change this little detail. But I don’t want the LLM nondeterministically to generate a new program because that way it might get a lot of other things wrong that I reviewed already. So there really should then be an incremental small change to the code, and that means I need to keep the prompt as a part of my program.

43:40 — Will there be less engineers in ten years

Ryan:

[43:40] Ten years from now, do you think there will be more software engineers than today or less?

Martin:

[43:46] I think there will be less. And it will be a higher profession that essentially has higher standards. So it will be harder to become one. You will need to know quite a lot of logic and math to be competent at essentially keeping AI on the right track and things like that. It’s sort of, I can say, sort of like a control engineer for a factory where you don’t understand many things initially. It means that there must be more—you must be higher skilled than a factory worker of 50 years ago or something like that.

[44:27] And I think the same will happen for software, where you will need fewer but more qualified people.

44:34 — Top programming languages to learn to grow

Ryan:

[44:34] One thing that a lot of people recommend is to become better at programming: you should learn multiple languages. And I wanted to know, aside from Scala, what are the top programming languages you would recommend people learn to expand their mind?

Martin:

[44:49] So definitely a systems language. I think to know how hardware works and how software links with hardware, I would learn a systems language. I’m sort of torn between C and Rust there because C has going for it that it’s very simple and very close to the metal. In Rust, you have to learn a lot of abstractions, but on the other hand, it is memory safe. So I would say probably initially C, to figure out what these things are.

[45:17] And then if you decide to become a systems programmer as a career, then you should switch to Rust. I guess that would be one thing. The other thing would be something more with a verification, improving background because that will be a lot more, will become a lot more important. So I would actually do a course in Lean or Rocq, one of these languages, to say we. We should be able to use AI or to.

[45:48] To have to develop first an intuition what it means for a program to be correct, because I guess for most people have only a very, very fuzzy intuition for these things. And learning one of these languages would sharpen the mind. Yeah, so I think those. And then, of course, Scala too as a language that essentially sits right in the middle where fairly provable, strong types, high expressivity, these sort of things.

46:18 — Top technical book recommendation

Ryan:

[46:18] When you think of a top technical book that you might recommend to people, does anything come to mind?

Martin:

[46:23] I got a lot out of Structure and Interpretation of Computer Programs. That was a book from the 90s. It was an intro text at MIT at the time, or 80s even, I think. And in fact, the courses I taught on Coursera and at EPFL are based quite a lot. Well, to some degree they’re based on that material. So, of course, not the same language and strong types instead of dynamically typed.

46:51 — Why he chose academia instead of industry

Ryan:

[46:51] But still, when you look back on your career, why did you choose to work in academia instead of industry?

Martin:

[46:57] When I came to the end of my studies, I was asked to do a research project, and the project I picked, or the professor then asked me to modulate that a little bit. In the end, I found it super interesting to say I work on something that I don’t know whether it has a solution or not. So it might be that. The question is yes, it might be. The question is no, we have to do research, and that’s sort of how it started.

[47:24] And then I believe the main advantage of being in academia is really the long term and being independent. So in the long term, I mean, in industry, I’m sure there are many periods, including now, where I could be paid 10 times what I’m being paid at university if I joined Google or any of the other companies in Silicon Valley. But then times also change, and sometimes essentially what you do is no longer relevant, and then it’s very easy to get fired. And then you say, no big deal, I can do something else.

[48:00] But at a university you have essentially long-term tenure to do exactly what you want. So no manager, you can define your own research agenda. Of course you have to get some money. That is hard. You have to get grants and things like that. You have to convince students that what you do is the right thing. But that’s also very rewarding, working with students. So I think in the end I’m very happy that I took the career I took.

48:28 — Reflecting on Scala

Ryan:

[48:28] What about looking back on Scala? You have so much experience there. What are some things that went well or things that didn’t go well, and maybe some learnings you could share?

Martin:

[48:39] Scala was initially this experiment that we could combine object-oriented and functional programming. And technically that experiment was a big success. In terms of the ecosystem, it had a lot of challenges. I don’t know whether there was A Brief, Incomplete, and Mostly Wrong History of Programming Languages by James Iry, which is quite hilarious. And there’s a Scala entry there that says I discovered Reese’s Peanut Butter Cups.

[49:07] And I had an idea to essentially have a language where you put in both object-oriented and functional, and then it ends with these pieces of both communities. And they promptly declared jihad. And at the beginning, it was very funny. But in retrospect, that’s to a large degree what happened. I mean, there were a lot of fights and cultural things like that, and it was a challenge. And I don’t know, in retrospect, I think it might have been more prudent to be more careful introducing functional features because that sort of was.

[49:51] We went in essentially quite complete. So essentially you can port most Haskell programs to Scala, maybe that you find them a bit less attractive looking, but you can do it. And that brought in essentially different cultures. And it caused a big clash of cultures. So, for instance, in Go, Go was a lot maligned because they didn’t even have generics. Right. And it’s true, it was a ridiculous language, but by not having it initially you sort of form a culture that when you add it, nothing much will go wrong.

[50:30] And people want to over-abstract or things like that. And by essentially going full hog into it with Scala from the start, we were not protected against that. And people did reach abstraction peaks and over-abstract it and things like that, and they still do it to this very day. So essentially having fancy abstractions is great, but you have to use them responsibly. And then it sort of clashes with the natural urge to just try out all these fancy things and do something that in the end maybe neither you nor nobody else understands very well.

[51:05] And it could have just been a simple map or things like that. But yeah, why do I use that when it can be complicated?

Ryan:

[51:13] Why would that upset someone?

Martin:

[51:15] Because of the library ecosystem. I think that the libraries are important because they sort of set the agenda, how you express your programs. And in particular the libraries that come from the Haskell side, they’re essentially monadic frameworks, and they require you to express your whole program as a monad, which is a concept that works well in functional programming. I have my reservations. I wouldn’t actually do that in my Scala programs.

[51:48] But by having prominent libraries out there, it’s quite normative that people feel like being a Scala programmer, they’re required to program this way. And then, of course, there are opinion leaders and conferences and all these things that tell you how you should be writing your programs. But I would say I think most of the Scala community is actually very, very level-headed, and I think most of the advice is great.

[52:18] But then, yeah, it’s still a challenge because it’s just too easy to. Mostly it’s not really the opinion leaders in the community, but let’s say it’s your boss. You have a small team in a company, your boss came from Haskell and says, “Hey, this is great. We do exactly like Haskell, the whole thing.” And then two years later the boss’s boss says, “No, nobody can understand this code. This code in the project is cancelled.”

[52:46] So these things happened in the industry. I’m not saying that all projects are like that, not at all. I mean, there are lots of really great success stories of Scala, but that’s essentially a challenge in terms of techniques. I think, in the end, I wish we had been a bit less dependent on the JVM in the sense that we took a lot from Java that intuitively makes sense but, in the end, and was very important for interop, but in the end could have been done better.

[53:25] So for instance, in Java, being an object-oriented language, you have universal methods like toString and equals and hashCode, and they’re defined for everything. And languages like Rust or Haskell, they’re no more discriminating. They have a thing called type classes where, essentially, at compile time, you tell exactly where you have equality and hashCode and these things, and it’s a bit more tedious to set these things up, but in the end it’s also safer.

[53:55] So I wish we had that, and we couldn’t because we sort of adapted Java‘s notion of what an object is, and it already came with all these things, which is sort of very convenient, but in the end caused friction.

Ryan:

[54:10] If I went back to you at that time, when you were starting it, and I said, what do you think is going to happen 20 years from now? What would you have said?

Martin:

[54:17] I would probably have said that while it was a footnote in memory, because, I mean, let’s face it, you do a thing and initially we had maybe five users or something like that outside our group, something like that. Right. And you don’t really expect that it would change a lot. And so no, I think it was quite by surprise that this actually happened. And I think the reason why it happened was that at the time Scala was a good bridge between dynamic languages that are slow and sometimes they crash.

[55:02] And solid languages, statically typed languages like Java, which were at the time quite cumbersome to write code in and there was a lot of ceremony and things like that. And Scala had inferred types, so you had types but you didn’t see them much. So it felt like a dynamic language, but it had also the solidity of essentially a good platform, and I think that’s what made it. And we’ve been copied a lot by a lot of other languages that put in these features then five or ten years later or things like that.

[55:33] But at the time, it was sort of Scala that was the first one that had it, and that’s sort of why it happened. But I wouldn’t have foreseen that by

55:42 — Advice for his younger self

Ryan:

[55:42] No means looking back on your career, when you just graduated college and kind of started your career, knowing what you know today, what advice would you give your younger self?

Martin:

[55:55] I think to take risks, be adventurous, pay it out. So essentially don’t follow the mainstream. If you take a fancy to do something wild and crazy technically, take the time to do it and do it. But I mean, yeah, so that’s what I would. Of course, you still need to sort of stay on track somewhat, but I don’t want to exaggerate that either. But yeah, so basically be a bit nonconformist.

Ryan:

[56:28] Awesome. Well, thank you so much for your time, Professor. I really appreciate it.

Martin:

[56:32] Thank you, Ryan.

He also had a lot to say about the Chinese robotics ecosystem. I asked him questions about that and about competitors such as “what if Anthropic and OpenAI started their own robotics labs?”

We went over a bunch of questions about predictions on future timelines. I asked him what a concrete roadmap might look like so we could get a sense of how deployment will happen.

Hope this episode is helpful in learning where we are today and where we will be when it comes to humanoid robotics.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:37 - Where are we today

04:20 - Most surprising capabilities so far

07:03 - The most inspiring real world robotics

08:36 - If OpenAI or Anthropic got into robotics

10:22 - Chinese robotics

13:15 - Will one lab breakout from the rest

16:59 - Thoughts on a concrete roadmap

21:03 - Generalization and demonstrating it

26:04 - Types of data and which is best for robotics

34:34 - Why humanoid robotics differs from Waymo

37:10 - If humanoid robotics failed here is why

39:55 - Are there hot take modeling architectures in robotics

42:05 - Thoughts on AI safety in robotics

46:44 - Top robotics research paper recommendation

49:35 - Why is Boston Dynamics less top of mind

53:47 - Advice for his younger self

Transcript

00:37 — Where are we today

Ryan:

[00:37] LLMs have caused unprecedented impact and investment in that area. Physical AI and humanoid robots could potentially be even bigger. And so I wanted to ask you today about where are we today with humanoid robotics, and how do you foresee this technology actually being deployed into the world?

Sergey:

[01:01] I guess with machine learning, what we’ve learned over the last few years, or the last decade rather, is that it works when you do it at scale. And this is very obvious now, but it wasn’t always obvious. But there’s a caveat, which is you have to scale the right thing. And initially when people started working on models for language, for example, the dominant design was LSTMs. Some people remember what those are.

[01:29] They were kind of okay; they were a lot better than what came before that, but they didn’t really scale as well. And then the big thing with transformers was not that transformers were somehow particularly mathematically elegant or anything like that. It’s just that they scaled better. So they were easier to train on very large amounts of data with lots of parameters. So the technology proceeds in phases.

[01:48] First you figure out what you can scale, basically what is the scalable technology. And then you pour on a lot more of kind of an industrial-scale effort and adding lots of data, adding to model size. And that’s when kind of the magic happens. So when we’re doing kind of more fundamental technology development, the key is to understand what are those scalable levers. So figure out the design, figure out roughly the mixtures, and that by itself does something pretty cool.

[02:14] But that’s not the thing that actually changes the world. It’s like when you start pulling that lever that things actually change. So with LLMs, when the first GPT models came out with GPT-2, it did some stuff, but it was sort of like a parlor trick, so you could get it to synthesize a story about unicorns in Peru or something. And it was coherent English, but it wasn’t a thing that would solve lots of real-world problems.

[02:39] But the folks that worked on this kind of recognized that, hey, there’s something kind of magical that happens because as you add more data and you make the model bigger, this stuff gets more coherent and more effective. So they could see that if we do a lot more of that, then it’ll become a lot more powerful. So to come back to your question, what I would say about robotics is that it’s not in the GPT-4 to GPT-5 stage, where it’s an industrial-scale effort to kind of make the model bigger and get more capability out of it.

[03:10] It’s in that stage where we’re establishing the fundamental technologies. And because of that, what one should expect to see right now is not necessarily that each month the model gets bigger and more powerful by some predictable kind of scaling curve. It’s that the scaling properties themselves are evolving as we develop the right technologies. So to bring this back to something closer to reality.

[03:36] I’m very happy with the demos that we’re doing here at Physical Intelligence. And I think that a lot of the results that other people are coming out with are really cool. But these are, to put them in context, we should not expect these to be the things that are actually illustrating the power of scale. We should expect them to be developing the fundamental technologies that will be scaled up after that.

[03:55] So where I think we’re at now is that we’re actually kind of getting all those puzzle pieces in place. And I think it’s actually very close. I think a lot of the puzzle pieces are falling in place, but it’s not like. What makes it so hard to prognosticate about where the technology is going to go is that it’s not yet at that predictable scaling stage. It’s at the stage where we’re figuring out the puzzle pieces, which I think is really exciting.

[04:15] But it means that it’s also very hard to foresee sort of what the coefficients on that will be.

04:20 — Most surprising capabilities so far

Ryan:

[04:20] What are the most astonishing emergent capabilities you’ve seen so far?

Sergey:

[04:25] That is the thing that is the most fun. And certainly we’ve seen a lot more of that happening as we progress. In the very beginning, it was kind of little things, but they were kind of magical because in robotics, basically prior to 2024, the stuff never happened. So the little things that happen, and this was maybe at this point about two years back, we would see things like, okay, we train our policy for folding laundry and it takes individual shirts out of the hamper and tries to fold them.

[04:55] And then one very vivid memory I have in late 2024 is we were watching one of the evals, and it takes out two shirts at the same time. And I’m watching this, I’m like, okay, it’s done for. There’s no way you can possibly do this. And then it puts the two shirts on the table, disentangles them, puts one of them back, and then starts folding the other one. It’s like, wow, okay. In retrospect, you can do some detective work and figure out where it got that from, some piece of training data.

[05:22] But that was one of those moments where I don’t think anybody watching that eval thought that the robot was going to do this. It’s like a little thing. It’s exhibiting the common sense you expect people to have. But actually, the thing that I find more interesting recently is some of the mistakes, because one of the things that’s pretty remarkable about LLMs is that once they got good enough, even the mistakes kind of made sense in the sense that they weren’t like crazy mistakes where just outputs, like, zzz all the time.

[05:50] But their mistakes are sort of semantically sensible. We had an evaluation last year for π0.5 where the robot was cleaning up a kitchen, and it’s told, like, put away all the utensils. There are some spoons, spatulas, et cetera. And it tries to open the drawer where it thinks the silverware goes, and it can’t really get the drawer open, so it slides over and opens the oven, which is right next to it, and then starts putting this stuff in the oven.

[06:16] It’s like, you can sort of imagine that if you ask a child to clean stuff up and put it away, they might decide to do that because, okay, it’s like a container, and you can put stuff there, and nobody sees it. Another experiment we had is washing all the plates. So it would pick up the plates, wash them with a sponge, and put them on the drying rack. And this was an experiment on memory, because it has to keep track of everything that it’s doing and has a scratch pad of memory where it’s writing down, hey, I had three plates.

[06:40] I cleaned the gray one, I cleaned the green one. And then it drops one of them on the floor and drives the base over so you can’t see. And I was like, okay, I’ve cleaned the gray plate. It’s done. So, I mean, obviously these are not the things that we want to see. But it’s kind of interesting that some of the mistakes, they’re almost like what you would associate with a child trying to do the task.

[07:00] So now it just needs to grow up.

07:03 — The most inspiring real world robotics

Ryan:

[07:03] You mentioned the advancements. They’re kind of happening all over the industry. And I know there are a lot of people building humanoid robots. There’s Figure AI, there’s Tesla, and there’s many other competitors, and you have the expertise of what is hard and what isn’t. When you look at the competitors, has there been any advancement or achievement where you think, oh, that’s really admirable and that’s impressive?

Sergey:

[07:29] I actually think that one of the most inspiring things to me in the industry is to see the kind of takeoff that autonomous driving systems have had. Because one of the criticisms that is sometimes leveled against robotics researchers is, it’s like nuclear fusion. It’s the technology of the future, but it’s always in the future. But that’s what people said about autonomous driving, too. And now we’re in San Francisco.

[07:53] You can go outside and you can take a Waymo, and it will actually take you to your destination. And there was no driver sitting there. So, without getting too much into the technical details, I think what’s really inspiring about that is just this case in point that, yes, you can actually have one of these technologies of the future, and it actually does land. And I think it’s not an accident that it’s landing now in the mid-2020s, because a lot of the puzzle pieces for large-scale ML are getting to the level where we can put them together with actual physical systems.

[08:24] And there’s a lot of differences between driving and robotic manipulation, of course. But I think that the illustration that, yeah, we can actually land learning-based technologies in the real physical world, I think that’s really inspiring.

08:36 — If OpenAI or Anthropic got into robotics

Ryan:

[08:36] If OpenAI or Anthropic started investing more heavily into robotics, how do you think that would impact the industry? Do you think competitors would be worried about that?

Sergey:

[08:49] Robotics is an area where, to be fair, the ecosystem hasn’t been as healthy as it has in other areas of machine learning. And what I mean by that is that computer vision and NLP are things that sort of lend themselves naturally to a machine-learning-based ecosystem, because there’s freely available data. People kind of have a general acceptance that they’re going to be using learning. There aren’t concerns as severe concerns about safety, at least physical safety.

[09:20] Right. You know, people rightfully are concerned about AI safety, but it’s not the same as like a physical device causing some physical harm. And because of that, I think it’s a bit easier to spin up a very serious large-scale ML effort in those areas. Robotics is not like that. Robotics traditionally is not a discipline that really embraces sharing of data, for example. So I think that the more activity there is around learning and robotics, the more I think it’ll shift people’s thinking toward this kind of future where we accept that robots will be controlled by learned models, not by hand-designed controllers, that there will be data, that data will need to be shared because there’s no way that somebody can build out a true foundation model in a single vertical and basically kind of shift the entire thinking around robotics to look more like how we think about vision and NLP as opposed to traditional factory automation.

[10:12] So I think in that sense, much as I’m proud of the work that we’re doing at Physical Intelligence, I think it’ll take more than one company to kind of shift everyone’s thinking in that direction.

10:22 — Chinese robotics

Ryan:

[10:22] As a bystander, I see on Twitter these really impressive demonstrations of Chinese robotics. It almost feels like they’re ahead in some sense, but I don’t have that deep domain expertise. So I was curious about your thoughts on what you think of China’s robotics, and are they further along?

Sergey:

[10:45] I think that one thing that is very useful and constructive for us to do, those of us that work on these things in the United States and in Europe, is to ask what is the lesson to learn. And to me, one lesson is that it’s important to have a healthy ecosystem. And ecosystem means that there should be obviously good researchers, good engineers working on these things. There should be healthy open source.

[11:18] But it also means that the different industries that contribute to robotics need to individually be very healthy. And those industries are not just the computer science, ML, and model building stuff. It’s also supply chains, manufacturing hardware, R&D, these are all very important things. And aspects of those things are things that the United States does quite well. Other aspects of them are things where the United States has sort of let things go a little bit.

[11:52] And I think that what we should do is we should look at what’s going on in the world, look at some of the excellent results that Chinese labs are doing, that labs in other countries are doing, and we should take away that lesson that we should strive to build a healthier ecosystem. And that means investing in all the different facets that contribute to this. So I’m not much of a business person, I’m not much of an investment person, so I can’t claim to know how to do this, but I think that it’s important to sort of fully embrace that this is a holistic thing and not something where we can do just one piece of it and outsource everything else.

[12:25] Basically.

Ryan:

[12:27] Of all the pieces of the ecosystem, are there parts of it? As a robotics researcher in the US, if it was better, that would have the biggest impact on the advancement of robotics.

Sergey:

[12:39] Yeah, I think certainly availability of reliable, low-cost hardware is a big deal. And right now, I mean, certainly for hardware used for robotics research, a lot of that does come from China. And it’s good, it’s relatively inexpensive, it’s of high quality, and meets the standards that people generally need. But it would be awfully nice to be able to source all that domestically as well. And I don’t think there’s anything impossible about that.

[13:07] I think it’s just a matter of embracing the fact that that entire ecosystem needs to be supported rather than just one piece of it.

13:15 — Will one lab breakout from the rest

Ryan:

[13:15] You can imagine that the lab that is first to get to scale will be the first to break out. There may be this exponential growth effect where once you deploy, deployment helps you grow faster, and growing faster helps you deploy, and this flywheel. And so do you believe that that will happen in this industry, where one lab, whether in the US or China, will hit some breakout point and they’ll kind of jump everyone else?

Sergey:

[13:47] There is a lot of truth to that. I think that there’s an important detail to keep in mind. The detail is that you kind of have to scale the right thing. So I think that basically the statement that the way that I would phrase this is having an effective positive feedback loop where more deployed robots translates to more model capability. That’s kind of the key, and that makes total sense. The trick is that there are lots of ways that it can be done wrong.

[14:23] So I’ll tell you a few obvious ones. One obvious one is let’s say that I’m a car company and I have a robotic arm that is welding cars, and it’s there on the assembly line, and it welds cars every day, and it gets a million welds every month, and so on. If I just use that as my data flywheel, I’m unlikely to get something more capable than a robot that welds cars. So since the robot is already there and it’s already welding cars, presumably the marginal improvement for that is not all.

[14:54] That valuable. So that’s an example of how you kind of have to scale the right thing, because data is not quite as fungible. It’s not like electricity or oil. You can’t just buy more of it. It has to be heterogeneous. So I think that basically it’s right, but you have to scale the right thing with the right technology and the right kind of source of diverse learning, like data is more like an education program for your robot than it is a fungible commodity.

Ryan:

[15:19] If you think about that data flywheel and, I guess, putting out the proper platform that would generate data that matters, that would then improve that platform, when do you foresee this kind of happening in the world?

Sergey:

[15:34] I think, on the technology side, things are advancing very rapidly toward that. And I think that maybe a particular balancing act to strike that would significantly determine that timeline is how much structure somebody’s willing to admit. So on the one extreme, you could imagine jumping straight to fully unstructured deployment domains like home robots. And that could be really exciting because then you have a lot of diversity right off the bat, but the bar is a lot higher to be effective enough in that domain to be safe enough.

[16:04] Safety is a much bigger issue there because it’s around people in their home. On the other extreme, you could imagine much more structured tasks, maybe not quite the welding robot, but sort of like maybe the robot down the hall that does something more unstructured. And that could be a much easier domain in the sense that there’s much less safety concerns because it might be around trained humans, the task might be more predictable, and so on, but the marginal value of each bit of data you get in that domain is lower because there’s less variety.

[16:36] So it’s like you could take off earlier, but with a smaller slope, or later, but with a larger slope. And you kind of have to calibrate that. But my sense is that whichever end of that extreme we’re talking about, it’s in the single-digit years rather than the double-digit years at this point. So it could be that the more structured ones might be happening now or next year. The less structured ones might be a few more years out, but probably not like a decade.

16:59 — Thoughts on a concrete roadmap

Ryan:

[16:59] A lot of people talk about timelines, and it’s kind of more nebulous. And I’m wondering if you were to put down, I guess, somewhat of a roadmap, but not so concrete, but just milestones toward that north star of a robot in my home doing.

Sergey:

[17:16] Yeah, that’s a really good question. So maybe to preface this answer, I think that there’s one thing that is very important to say about robotics that is very easy to miss from the hype cycle and the demos that people put out, which is that the hard thing in robotics was always generalization. But when somebody shows a demonstration of their system, the demonstration alone usually doesn’t make it clear what level of generalization is being shown.

[17:48] The highly acrobatic robot demos, for example, are really exciting to look at. But typically, if it’s something that is a little bit more staged, sometimes literally on stage, if it’s a show that is obviously rehearsed, and that’s okay, because it’s literally just a show, but it’s not the same as doing a task every time reliably in any home. And the generalization piece often doesn’t look that impressive when viewed in isolation, because generalization is sort of a property of many trials, not of one trial.

[18:20] So you might see the robot doing something fairly mundane and unimpressive. But what’s exciting about it is that it’s doing it with an object that it’s never seen before in an environment that has never been tested before. And that is actually harder than doing an acrobatic backflip that it’s practiced millions of times. So with that said, my answer to your question is that the roadmap is all about both achieving better generalization and kind of that second-order effect of having a mechanism to get more generalization as you generalize.

[18:53] So one of the steps on that roadmap is to have a very concrete demonstration of a robotic system that gets better with autonomous experience that is collected in a setting that it wasn’t originally trained for. So I do whatever I do in the backend in the lab and whatever. I get my model, I get my adaptation algorithm, I put it in a new setting. Maybe it’s a home, maybe it’s a factory, whatever it is, something where it’s doing something real, and it does okay.

[19:24] But then over time, it gets better and better. And it gets better and better to the point where it reaches sort of practically relevant levels of robustness without sort of capping out at like 50%. I think that would be a major milestone, because now that says, okay, if this is truly an automated process, it’s improving, it’s getting better, even as it’s collecting useful experience. Now, I can take it and I can put it in lots of different domains, collect useful experience, do something that people actually want, and it’ll improve the model.

[19:51] So that, I think, is a really major step on that road. I think another really major step is to demonstrate a very concrete and practically useful way to transfer knowledge, to transfer common sense, to achieve robustness. So that’s like kind of the other scenario we don’t get to practice. If you’re driving your car on the road and you see a fire truck and you see a bunch of traffic cones, even if you’ve never been in that situation before, your common sense tells you, like, hey, I should slow down.

[20:20] Maybe I don’t know how to react optimally, but I shouldn’t just barrel on through the cones and upset the firefighters and so on. So that’s common sense. And if you can apply that common sense to effectively recover from unexpected situations, like when the robot put the spatula in the oven, it should probably open it up, take it out. It knows that this is not the thing you do semantically.

[20:40] That, I think, is another important step because that tells us that we can use common sense to fix mistakes.

Ryan:

[20:46] I could imagine a more narrowly scoped robot. Let’s say it’s a humanoid robot. That’s one step in assembly line, in manufacturing. And my understanding, you’re less interested in that because that’s not really a step toward that general intelligence.

21:03 — Generalization and demonstrating it

Sergey:

[21:03] What I would say, it’s not that I’m less interested in it, it’s that I think that the real world has these leaky abstractions that make that kind of stuff a lot more complex than it seems. Let me try to explain this with an analogy. So in the ‘90s, when people really started working kind of full steam autonomous driving, there was this idea that we could avoid a lot of the hard problems by kind of instrumenting the environment a little bit.

[21:31] Like, we’ll have magnetic sensors along the highway and so on, and cars will have a little sensor on them and a little transmitter so they can tell where each of the cars are. Kind of like the way you do it with aircraft, basically. And then people thought, well, we don’t really need fancy AI. We’ll just have these sensors and it’ll just work. And that just basically didn’t go anywhere because the real world has so many messy exceptions and special cases that even if 99% of the time, the magnetic sensors and all that stuff just allow the car to drive the 1%, when someone steps in the middle of the road or there’s a piece of trash or whatever, it just messes everything.

[22:05] Up. So the thing that actually worked was when Waymo said, hey, we’re going to not try to avoid the hard problem. We’re going to actually try to deploy our cars not in the middle of nowhere, but in San Francisco, very messy, and let’s just deal with it head-on. And that allowed that community to make progress. And I think robotic manipulation is going to be the same way, that past the fully structured world of the factory, if you want to go even a little bit outside of that, even if 99% of the time it’s all pretty straightforward, that 1% when something weird happens means that you really need the full scope of the problem basically to be addressed.

Ryan:

[22:41] This kind of reminds me, I remember Figure AI had this demo where they live-streamed the robot sorting packages. When you watch that demo, does it demonstrate generalization in your opinion?

Sergey:

[22:54] Yeah, I think it does. And by the way, this is something that I find very encouraging is that, like I mentioned, it’s hard to show generalization in a video, and it’s clear that lots of people are thinking about that and are thinking about how do you present something that somebody can watch and take in kind of at a glance what generalization is. I think you can see a lot of creative steps towards that.

[23:16] Live demos, these kind of really long time lapses. I think it’s a great idea, and I think that’s a really nice way to move towards elevating the importance of generalization in people’s consciousness. When we were working on the π*0.6 project, the RL project that we did late last year, we wanted to do some longer horizon experiments. In some cases it’s obvious. We had our robot assembling boxes at Dandelion Chocolate Factory.

[23:46] So they’re like, it’s an actual chocolate factory, so they need the boxes. So we ran it for several days. But we had this coffee task, which was the robot using an espresso machine to make espresso. So what we did is we ran it for 13 hours making espresso drinks. And we are, we try to be very, I guess, environmentally conscious about this. So we didn’t want to throw out the coffee.

[24:05] So after 13 hours, everyone in the office was a little wiry because someone has to drink the coffee. But it ran for 13 hours, and it was pretty cool. It screwed up a few times. It’ll spill all the coffee grounds, and then it needs to go and get a cloth and wipe it down, but it does it and nothing exploded. Thirteen hours went by. Probably the most negative consequence was loss of sleep from too much caffeination.

Ryan:

[24:29] But when it spills the coffee grounds and cleans it up, it did that by itself.

Sergey:

[24:34] Well, so the way that that experiment was done is that there is a high-level prompting. So roughly the prompt is updated maybe every five minutes or so in between semantically coherent tasks. So you tell it, like, make espresso, clean up the machine, et cetera. So those steps, the actual clean up the machine, was commanded by a person. In principle, we could automate that. In fact, one of the things we’re spending a lot of effort now on is improving our high-level policy that does those commands.

[24:59] But for that experiment, every five minutes, somebody basically updates what it’s being asked to do, the way we intended. It was like the commands would be like, if you go to an actual coffee shop, you say, “Oh, I want a latte, I want an espresso.” That was supposed to be the prompt. Except then you also have to tell it, “I want you to clean it up before you do the next one.”

26:04 — Types of data and which is best for robotics

Ryan:

[26:04] It sounds like on the way to generalizing data is a very important part of that.

[26:10] And I was reading there are different types of data. There’s simulated data you could collect, like physical interactive data. And I want to hear your take on what’s the best data to get, what’s the worst, and what are the pros and cons.

Sergey:

[26:25] This is, by the way, a question that is, I guess, quite. There’s a lot of discussion in the robotics community about this question. And some people have very opposite opinions on it. My own take on this is that a lot of different data sources are easier for the model to internalize if it can ground them in a thorough physical understanding of the world. So let me try to explain what I mean with a few examples.

[26:53] If you want to learn to fly an airplane, you will probably use a simulator, at least during part of your training. But the simulator makes a lot of sense to you, because when you start using the simulator, you have a lot of world knowledge that you can use to ground what’s going on. You know that when you are using the flight simulator to learn how to fly the airplane, you’re not just playing a video game.

[27:15] You’re trying to acquire knowledge that you will then use with a real airplane. And you understand that there’s sort of an abstraction there. Same thing if you’re playing a really cartoony Atari game or something. You know that all the symbols on the screen, you can sort of connect them to things that you’ve experienced in your life, and you can make an analogy there. So a lot of that, even though it kind of seems like these simulated environments reflect aspects of the real world, to us, they make a lot of sense because we kind of bring to bear a lot of our own prior experience, and we fill in the blanks that the simulation has.

[27:52] And also, if you want to use data yourself as a person of somebody else doing something, if you watch someone, let’s say, cooking a meal, even though you don’t experience every movement they’re experiencing, you have a lot of that knowledge that you bring to bear. And you’re like, okay, I see they’re picking up the salt shaker. I’ve put salt on things before, so I kind of roughly know what’s going on there.

[28:13] And I can file it away at this level of abstraction of add salt without having to figure out all their muscle movements. So my point with this is that once you have that understanding of how you do things physically with your own body and how you experience the physical world now, all these other sources of knowledge can be connected up to it, because that foundation you get from your experience helps you ground everything.

[28:34] So where I’m going with this is that if we have a robotic foundation model that is trained on lots of real embodied data, that provides that grounding, and it might actually be much better able to absorb other sources of knowledge. And this is actually a little bit upside down relative to how some people think about it, because it’s very tempting looking at the success of Internet data for LLMs to say, well, maybe we should do the opposite.

[28:56] Maybe we should start with YouTube videos and then put robot data on top of that. But I think it’s actually the other way around, and I even have a little bit of evidence for this. So my colleague Suraj Nair, together with Simar from Georgia Tech, they had a project together a while back where they took our robot foundation model and they added human video data. But they didn’t start with human video data.

[29:22] They actually started with a model trained on robot data and then added video data on top of it. And what they did is they looked at the representations inside the model. Basically, how does the model represent human experience versus robot experience? And they found that if you use a small model with a small amount of robot data, predictably the human experience and the robot experience are fully separated, meaning that the feature representations are different.

[29:42] But if you train on lots of robot data from lots of different robots, then the features are grouped much more by what task is being done rather than by whether it’s a human or a robot. And when we looked at the feature plots, it was just mind-boggling because literally when you crank up the amount of robot data to 100%, they just line up perfectly. You do this t-SNE embedding, you see the shapes of the embeddings, and it’s just all task identity and minimal sensitivity to embodiment.

[30:10] And to me, that’s kind of mind-blowing because the base model wasn’t trained on any human data at all. But once you start adding human data, it represents it exactly the same way. And I think that’s really exciting. And I think that to me is one of the strongest indicators that if you have that good foundation of robot experience, you can put everything else on top of it. It’s actually better at absorbing that.

Ryan:

[30:29] Is it important that that base model has data that was collected using that specific set of motors, specific set of joints?

Sergey:

[30:39] So far we’ve obviously put a lot of effort into cross-embodiment models that can handle many different robot types. But generally, you do need data of the robot you’re going to be deploying on to get good performance. So kind of the metric of generalization there is not can you zero-shot a new robot, but it’s mostly can you get away with less experience from the new robot and transfer skills from other robots?

[31:02] Okay, so that’s the current state of things. Now there is a little bit of a surprisingly positive read on that, which is even though you need data from these robots, the amount of special stuff that the model is doing is kind of minimal. When we started doing all this, I had a big long list of all the cool research I wanted to do to better accommodate different morphologies. Can you factorize the model’s representation in some way so that there’s a six degree freedom arm head and a seven degree head and a gripper head, et cetera?

[31:32] We didn’t do any of that. The model just outputs a big vector of numbers. If the robot has fewer degrees of freedom than the number it outputs, it just zero-pads it. There’s just nothing fancy, and that’s it. And then it just trains on all the robots and outputs the correct actions based on what is seen through the camera. But now, to your point about whether you can handle new robots.

[31:55] So far, the thing that we focused on, and I think this is showing some promise, is being able to transfer skills between robots. And this is actually where the particular choices in how the model works seem to matter. For example, you can have a model that does some intermediate thinking, and that thinking can be done in different modalities. So you can think in text, and thinking in text is really good for transferring high-level behavioral structure.

[32:27] So that’s basically how you understand that, hey, if I want to clean the kitchen and put away the silverware, first open the drawer. That’s kind of a semantic inference. And you can transfer that very well because obviously that’s largely agnostic to any embodiment or anything like that. But even lower level things can be transferred if you use the right representation. So one experiment we did is we had a thinking stage that is expressed in images, where you basically dream up an image of the next milestone in the task.

[32:55] And with that, we can actually get a robot, the UR5 robot, to fold a T-shirt, even though we didn’t have any T-shirt folding data on the UR5. Because while getting the arm motions correct is very hard, because the robot basically requires very different joint angles to do the task, cooking up an image of what it looks like for it to fold a shirt is not that hard because you’ve seen the robot arm in all sorts of different poses, you’ve seen the shirt in all different stages of being folded and unfolded, roughly where it should hold it.

[33:21] So getting a good generative model to cook up that image is pretty straightforward. And once you have the image, then, from that backing out the correct actions is easy too, because you can just look at the synthesized arm angle and just back out what the angle should be. So it’s not changing the problem, but it’s just introducing this intermediate step that makes it easier to solve. Just like if you’re solving a math problem, if you figure out the right intermediate step, kind of the answer is obvious from that intermediate step.

[33:47] And I think that’s really exciting because now that shows that this level of generalization across robots, and I’m sure other generalization too, can be facilitated with thinking, just like in large language models, but with a twist that you have to think in the right modality.

Ryan:

[34:00] Interesting. So it outputs a, I guess that image is what its video sensor is seeing, and it’s like the next step.

Sergey:

[34:09] Yeah, you can almost think of it like image editing. You can do the same thing with video. You can do it with video prediction. But the key is to imagine what it would look like to progress on this task. That seems like a very human thing to do.

[34:22] Some things you plan semantically and some things you plan spatially. If you’re doing rock climbing, you’re probably not thinking like, “Hey, left arm to rock, 37 centimeters to the left.” You’re probably more imagining your arm reaching for the rock.

34:34 — Why humanoid robotics differs from Waymo

Ryan:

[34:34] Earlier in the conversation, you mentioned that Waymo was very inspiring, and their kind of path to productionization is proof that you can do real-world generalized robotics. And if I recall correctly, when I was a lot younger, it was kind of this early promise of, “This is going to happen,” and then in reality, it took a lot longer. So I guess my question is, in the case of humanoid robotics, what would make you say single-digit years, it’s coming, versus a long tail and policy challenges as well?

Sergey:

[35:17] I think one big difference between how robotic foundation models address the problem and how more traditional engineered systems address the problem is that the stack is really thin. So it’s not easy to train a foundation model. Obviously you need to get the right data. There’s a lot of work that goes into curating, labeling, all that other kind of stuff. But the actual software that runs on the robot is very, very simple.

[35:42] So you might have some kind of thinking or reasoning stage. You might have the model produce actions; it needs to be fast enough. But if you think about it in terms of raw lines of code, it’s much, much lower than a more traditional AV stack. And partly that’s because modern autonomous vehicles, the work on that started a lot earlier with very different technologies and evolved over time. Partly it’s also because the problem is more safety-critical.

[36:13] Like, yes, you don’t want a robotic manipulator to drop a fragile object, but at the end of the day, that’s a lot less bad than having a car hit somebody. So that is not to say that the safety challenges with robots are not real. They’re very real and it’s very important to tackle them. In fact, it’s probably one of the harder ends of the problem. But they are not as much of a hard stop to practical deployments because you can come up with tasks and environments and domains and also physical hardware where those problems are a lot less severe.

[36:47] So I think that combination, radically simpler software stack, plus less drastic software challenges, actually make it a lot easier. And because, to your earlier point, there is this kind of flywheel effect, that there is a positive feedback loop, that starting to get things out in the world, even under some constraints, will actually facilitate getting them out more and more.

37:10 — If humanoid robotics failed here is why

Ryan:

[37:10] I think a lot of people are familiar with this idea of postmortem, looking back on why something failed. But in this case, I’m curious, what would you say to a pre-mortem in the sense of if humanoid robotics did not succeed in single-digit years, what do you think would be the most likely reason why humanoid robotics failed?

Sergey:

[37:34] Ultimately, for these things to be truly useful, they do need to reach a level of reliability and robustness and generalization that is higher than what we typically expect from LLMs, for example, or generative AI for images and video. Because typically these tools, they are very much human-interactive tools. You get an LLM to do something, and it doesn’t do quite what you want, so you sort of revise your prompt, and you basically iterate with it.

[38:01] And that’s why even the earlier LLM tools, like the first version of ChatGPT, even though they were much more primitive than what we have now, they were still already useful because somebody could just keep hammering at it until it basically solves their problem. Just like if you’re using a search engine, you type something in the search engine, you don’t get quite what you want, you revise your query and then you get what you want.

[38:20] Whereas with a robot, the full value of it is unlocked when it’s actually doing the thing autonomously. So to have somebody constantly iterate for every single task is almost antithetical to the benefit that you’re getting. So I think a lot of the risk has to do with how easy is it to get that level of reliability and robustness. And that’s again where some of the demos might be a little bit misleading, because if someone shows a demo of their robot doing something cool, I mean, obviously if everything is presented in a forthright way, that could still be a very good indicator of progress.

[38:52] But it doesn’t make it obvious how far or how close it is to reaching that practically relevant level of robustness. So I’m personally a big believer in using techniques like reinforcement learning that can actually benefit from autonomous experience to kind of fine-tune those last few percentage points to make it go from 95 to actually 100%. But that’s really important, and it’s not yet a solved problem.

Ryan:

[39:18] If it did take longer than expected, it’s because the bar is higher.

Sergey:

[39:23] Because the bar is higher. And in particular, those last few, kind of the last inch, so to speak, is something that requires not just really good models, but also new innovations in technology. I mean, I don’t think that I’m not the kind of person that would say, oh, we should throw out everything that we know about foundation models to start over. I don’t think it’s that at all. I think that roughly the puzzle pieces that we have are actually very good puzzle pieces.

[39:46] But still, we should acknowledge that right now, the methods and the models need more work to cross that level of robustness.

39:55 — Are there hot take modeling architectures in robotics

Ryan:

[39:55] In LLMs, it feels like everyone is doing kind of the same thing, but different flavors in the robotics industry. Is everyone doing kind of the same thing? Are there any hot take architectures that are different direction?

Sergey:

[40:09] I actually think that there’s a lot more heterogeneity than it might seem. One big dividing line that I think is maybe not as obvious from just looking at the results is the distinction between fully embracing the foundation model ethos, so to speak, versus focusing on specific vertical areas. And I think this is hard to tease out sometimes because obviously everyone’s going to say, “Oh, I’m doing the thing that LLMs did,” because that’s the cool thing.

[40:40] But the foundation model ethos fundamentally is something like this: if you have a particular problem you want to solve, it is better to train a more general model that can use data from a breadth of problems. And if you do it right, it’ll actually be better at the specialized problem you want to solve than a narrow specialist. So again, to come back to the LLM analogy, if you want to do machine translation, don’t build a machine translation system.

[41:05] Build a language model that understands all language tasks and throw it at machine translation. And in robotics, I think that is actually very deeply uncomfortable to people. Because if someone is actually working on an application, they’re doing warehouse automation. It is very awkward to think, oh, if I want to do warehouse automation, let me collect data of putting away silverware in kitchens.

[41:27] It just sounds bizarre. But that is the foundation model lesson: if you have enough breadth, if you collect data from a wide range of different tasks, then you will acquire those generalizable skills. And if your model is built correctly, it will repurpose those skills for whatever situation it encounters. So I think it is actually true that even if you want to build a warehousing robot, you are better off collecting a breadth of data and will be better at handling all the weird edge cases you might encounter, even in that warehouse domain.

[41:55] But this is not something that’s easy for people to accept because it’s just so antithetical to the principle of building kind of a traditional, vertically integrated robotic system.

42:05 — Thoughts on AI safety in robotics

Ryan:

[42:05] I noticed this new, interesting phenomenon with these AI companies, which is if they’re wildly successful, it creates this, I guess, worry or new set of things. So, for instance, when Anthropic had a very powerful model, then the government comes in and there’s these worries about safety and risk and all that. And I’m curious how you think about that. Like, if Physical Intelligence this year had a phenomenal, incredibly capable, generalized model, how do you think about those kinds of topics that might come up?

Sergey:

[42:48] Working on AI safety is not a new thing. My colleague at UC Berkeley, Stuart Russell, was talking about this stuff over a decade ago, and lots of people spent a lot of time working on it. It’s just that the trouble is when the technology moves so fast, the important problems are not just a function of the core principles. It’s also a function of how society reacts to it, what kind of tools are adopted, and so on.

[43:11] And I think that’s very, very hard to anticipate. So I don’t have a very satisfying answer here. In terms of how we are approaching it, our philosophy around all this stuff is basically one of empirical experimentation. Let’s get stuff out there. Let’s see what happens in the real world. Let’s see what goes right and what goes wrong, so that we have as much of a preview for what the technology can do, what are its weaknesses, what are its strengths, and so on.

[43:42] But at the end of the day, you kind of have to just keep your eyes open, see what happens, and adjust as you go. It’s very hard to anticipate. And I think your question, though, is very spot on. Even though I don’t have a great answer for you because, yeah, if we’re having this much concern and issues with AI systems that are basically limited to using computers, we’re presumably going to have strictly more concerns and issues with AI systems that can do everything in the physical world that we can do.

[44:14] Right. So the issues are real. It’s just you kind of have to see what happens and then adjust.

Ryan:

[44:19] And that’s kind of in the scary path, but in the happy path. If everything goes well and we have incredibly capable models and robots, in 10 years, is the North Star, that’s the end of human labor.

Sergey:

[44:37] I believe it’s a mistake to think of robots as mechanical people. Computers at some level are kind of like mechanical brains. But when personal computers really took off in the ‘90s, early 2000s, et cetera, it’s not like the first thing that happened is that people replaced their brains with computers. Rather, what we saw is actually a proliferation of very different kinds of computers. We saw kind of ubiquitous computing.

[45:03] So you would have a computer on your desk, but you might also have one in your pocket. You might have one in your refrigerator and in your car. Because computing became so accessible, you could have a little bit of computing in everything. And I don’t think that’s what the people that first started thinking about this stuff in the 40s and 50s would have imagined. They would have imagined room-sized computers whose job is to control the policy of an entire country or something, rather than a little bit of computer in everybody’s refrigerator.

[45:32] So I think by analogy, we might imagine there might be a little bit of Physical AI in everything, and it might just be lots of everyday things that you have to do yourself. Now you can get a little bit of help with it. I think the other example that’s worth thinking about is modern coding agents. So I think that this is something where, of course, the jury is still out as to what the end game of coding agents is.

[45:57] But certainly from the experience of software engineers today, it kind of seems like it’s fair to say that most would consider coding agents to be more empowering than somehow causing them to panic. I mean, obviously some people might panic, but in general, at least from the software engineers that I’ve talked to and from my own experience, it’s more empowering to be able to amplify how much work you can do with AI tools.

[46:28] So I think from that, and that maybe is a pretty direct analogy, because that is straight-up an example of an actual real job where AI has entered into it and has actually provided more leverage to the people doing that job. So I think that’s another example that we can look to. But the truth is that I think it remains to be seen.

46:44 — Top robotics research paper recommendation

Ryan:

[46:44] So in LLMs, there are a few seminal papers that, if you’ve read those papers, you kind of get a sense of the lineage of the breakthroughs that mattered in understanding where we are today in the robotics industry. Are there a set of top papers that you really think kind of show the breakthroughs that people should know about if they’re curious about the state of the art in terms of humanoid robotics?

Sergey:

[47:11] One thing I would point out, and this is partly a shameless plug, because I am a coauthor on that paper, though candidly, 99.9% of the work on this was done by Tony, who was the lead author, is the original ACT paper, the ALOHA paper. It’s an interesting example because in some ways the ideas weren’t really that new, but they were illustrated in a really nice way. And the idea was that, hey, if you set up the right kind of low-cost robot setup, in his case it was based on these robot arms from Trossen Robotics that are, they’re like $7,000 hobbyist arms.

[47:48] He set them up in a bimanual setup with a leader-follower teleoperation device. And he showed that actually if you do it right, without really any particularly fancy tricks, you could easily collect teleoperation data of extremely dexterous tasks that people had previously thought would require very sophisticated hardware and all sorts of really expensive stuff, and then set up a fairly straightforward transformer-based model, and it could actually do a lot of those tasks.

[48:13] And it’s kind of like an interesting thing because usually in academic research we put a big premium on do you have some sophisticated new mathematical thing or some sophisticated technical insight. And in that paper, which I think at this point has been hugely influential, the insight is really just, yeah, just put together the right pieces and have a little bit more faith in what a simple robot could do, so to speak, equipped with a good intent learning system.

[48:39] And he showed things like replacing batteries in a remote control. He even got a mannequin foot, and he showed that he could put a shoe on it for an assistive task, sort of. Some people need help getting their shoes on, so that’s good. But what people found, I think, so interesting about that paper is just how far you could get with relatively simple building blocks. And at this point, he open-sourced the code for it.

[49:06] And the ACT code has been used by lots of people. Sort of like if someone wants a very basic starter kit for robotic learning, that’s usually what they grab. And I think it’s worth for somebody who wants to get into the field to go through that paper and really understand what’s going on there. Because even though in some ways it’s not that sophisticated, I think it provides a bit of calibration on what matters.

[49:31] The details matter, but the details don’t have to be complicated.

49:35 — Why is Boston Dynamics less top of mind

Ryan:

[49:35] Before all this large-model robotics kind of wave, prior to that, Boston Dynamics had these really impressive demonstrations and tons of mind share. I guess I wasn’t even in the field, but I think, wow, they’re really doing incredible robotics. And then in the last, I don’t know how many years, I don’t really hear about them much anymore. Is there some shift in the industry that made that so, or is that something you could explain?

Sergey:

[50:12] So the way I would explain it is this: robotics at some level is about building complex systems. So even though it’s very tempting to say, oh, there’s different areas of AI, there’s LLMs and vision and robotics, one of those is not like the others because for robots you actually need all the parts, everything from how you wire up the robot, what the power source is, what does the actuator look like, all the way to how does it do high-level planning to determine what tasks to do next.

[50:46] And even though we could look at these things and say all of these different videos and different companies and different demos, they’re all robotics, they’re really different parts of the stack. A lot of what the classic Boston Dynamics results show is very sophisticated hardware, very carefully designed hardware with a traditional control approach, with very smart controls engineers setting everything up, but with comparatively less emphasis on the kind of decision-making aspect.

[51:20] And I think that at a particular point in time that actually made a lot of sense. Because if we can’t build the physical body, it doesn’t matter what kind of decision-making system is running on it. But to our earlier discussion about generalization, at this point we’re at a stage in the development of these things that even though we can do more on hardware, in many ways it’s good enough. And the big challenge is how to have the decision-making loop that actually works and that reacts intelligently to everything in the environment.

[51:52] And the place where I would draw the dividing line between those is decision-making loop doesn’t mean symbolic decisions. It could mean low-level decisions. The question is, do you need to take the rest of the environment into account, or are you just dealing with a robot? So if you want to do a backflip on flat ground, you most have to deal with a robot. But if you want to pick up a coffee cup off of a table, even though that’s maybe in some ways simpler than doing a backflip, you really have to understand what’s going on in the rest of the world rather than just your own body.

[52:20] And that dividing line, I think the way that technology has panned out, I think it’s fair to say that that is the dividing line between AI and controls. Controls is when you have to control the robot body. AI is when you have to take into account what goes on outside of the robot. And I think that that’s why you see this divide, because I think a lot of the demos where you mostly needed to deal with the robot itself and not the rest of the world, really good controls, could allow you to admit a very good solution there.

[52:51] And another thing I would say here is, okay, if there’s a lot of controls work that goes into doing some particular skill, well, there is actually something to learn from that. Because if you can hand-design a controller that performs a sophisticated behavior, very likely you can also learn that controller. So just that proof of existence that the thing is possible, and not only possible, but also simple enough that a person could build it.

[53:15] Because remember, people are, at the end of the day, even with code these days, the kind of complexity that people can handle is not as high as the kind of complexity the AI can handle. So if a person can hand design something to do a backflip or do some acrobatics, that’s a really great proof of existence that there exists some relatively parsimonious control law for doing that skill. And parsimonious does mean generalizable.

[53:36] So if it’s simple enough for a person to design, probably there’s something fairly general in there. And if you can learn it and automate it without having to have the human controls engineers in the loop, that’s good news.

53:47 — Advice for his younger self

Ryan:

[53:47] And then last question for you is, if you could go back to when you just entered the industry and give yourself some advice, knowing everything you know now, what would you say?

Sergey:

[53:57] One thing that I’ve learned over the last few years, which I think is a little different than my original mindset, is that addressing robotics effectively requires using very broad prior knowledge. And I think there’s this idea that a lot of people in robotic learning have, which I think I shared initially, that since people learn things from scratch, maybe robots should learn things from scratch too.

[54:26] So, for example, in some of our early work on large-scale robotic learning at Google, we had this, what we call the ARM Farm project. We set up a bunch of robot arms in a conference room, actually, because we didn’t have a proper lab. It was a conference room. And we had them all grasping objects. And the idea was, well, if they grasp millions of objects, they’ll learn very general grasping strategies.

[54:51] And it basically worked. They could learn to grasp objects, but it was very hard to take it further than that to the next level. Now I can pick up anything, but so what? It didn’t serve as a very good stepping stone for more complex skills. And I think part of that was that we were approaching this from a very blank slate. Let’s start from zero and see if, knowing nothing in advance, the robot could start picking up behaviors.

[55:12] But I think that it’s much, much more practical to get all this to work if you can combine robot experience with knowledge that you can pull in from other sources. For example, I was very skeptical initially about the utility of language. And I think scientifically this is defensible, which is that, hey, animals can do some pretty impressive things. Monkeys can do really cool stuff. But monkeys, as far as I know, can’t speak, at least not very eloquently.

[55:39] So maybe our robots should also be able to do stuff. And they don’t necessarily need to understand language. But I think the subtlety there is what’s important is not language, it’s prior knowledge that you can put in as a scaffold on your learning process. And you can pull in that knowledge in all sorts of ways. Humans don’t necessarily pull it in entirely through language. Humans and monkeys certainly don’t.

[56:01] They do it from observation, from observing other people, other creatures, and so on. So there’s lots of sources of prior knowledge, but the point is that you got to get that prior knowledge in there. Otherwise, you’re actually faced with a harder problem than what humans and animals have to solve. Because if a person had to figure out how to assemble IKEA furniture, but they’ve never actually encountered any article of furniture in their entire life, okay, that would be pretty difficult because they don’t even know what the point of this is or what the end game looks like.

[56:28] So, yeah, prior knowledge is important. And while I’m still a big fan of learning things through experience, I think that my advice to myself would have been, take prior knowledge more seriously.

Ryan:

[56:38] Awesome. Well, thank you so much for your time, Sergey. I really appreciate it.

Sergey:

[56:41] Yeah, thank you for your questions.

I had a lot of questions about why they chose Go (vs Rust) and if they used LLMs in the rewrite. Turns out they used LLMs much less than expected in the rewrite. He explained why in the conversation.

Anders has strong takes on how AI will impact software engineering so I made sure to run all the famous takes I’ve seen on Twitter to see what he thought like:

• Will AI write all the code in ~1-2 years?

• Will AI replace junior engineers in a few years?

• Will you still need to use an IDE by the end of the year?

And also I asked him why his opinion seemed to be so different from the more AI-pilled companies like the labs. Hope you enjoy the episode, full transcript below as usual if you want to skim.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:48 - Why write a compiler in JavaScript

07:29 - Why rewrite the compiler in Go

14:49 - LLMs for large migrations

20:12 - Why Javascript is so popular

26:32 - Why ever use Javascript on the backend

32:59 - What it takes to build a programming language

37:06 - Will there be fewer languages in 10 years

42:57 - Hands on engineering vs delegation

49:14 - Why fast tooling matters more now

51:16 - AI software engineering predictions

58:52 - The most technically challenging work

01:02:04 - Top book recommendation

01:03:50 - Advice for his younger self

Transcript

00:48 — Why write a compiler in JavaScript

Ryan:

[00:48] The big thing that we’re going to talk about here is obviously TypeScript 7 with the native rewrite. And the first thing that I think of when I see this was I didn’t even realize that the compiler was written in JavaScript to begin with because I don’t usually think of compilers being written in high-level dynamic languages.

Anders:

[01:09] Yeah, no.

Ryan:

[01:11] So why was TypeScript written originally, the compiler written in JavaScript?

Anders:

[01:17] No, it’s a good question. And honestly, if you had told me before the TypeScript project started that, “Anders, you’re going to be writing compilers in JavaScript,” I’d be like, “No, no, I’m not.” But I mean, the original prototypes for TypeScript, the Strada project, as it was called in the very early days, were actually written in C because it was like an adaptation of the parser, the JavaScript parser that we had in Internet Explorer and whatever.

[01:49] And then we’ve moved to JavaScript, but we wrote it sort of C# style. But why did we go with JavaScript? Well, I mean, if you can self-host in the ecosystem that you want to be a part of, then that is just dramatically better than putting yourself outside the ecosystem and trying to target that ecosystem. Do you know what I mean? Because by writing it in TypeScript, we were also daily users of TypeScript and daily users of the tooling that we were building.

[02:21] And whenever something didn’t work right, we knew it immediately. And whenever something didn’t perform right, we knew it, and so in the early years, it was a huge boon, I think. And then, of course, JavaScript runs everywhere, right? And that meant automatically our compiler could run on every platform, anywhere, even in the browser. Had we gone with a native code solution at that time, it wouldn’t have been possible to run it in the browser.

[02:49] Now we have WebAssembly or WASM, but that didn’t exist at the time. Right. So it was a meaningful choice. And honestly, at that time also, people didn’t really realize how fast JavaScript had gotten. I mean, it used to be very slow, and then Google did all of their excellent work with V8 and got it to within 2 or 3x of native code, which is pretty darn impressive. And it was like full well possible to write compilers in JavaScript, and you could even get them performant because often it’s the algorithms that determine how performant you are.

[03:33] It isn’t necessarily the runtime environment. Right. I mean, it’s a combo. But yeah.

Ryan:

[03:38] Is there anything unique about the TypeScript compiler? I think of a compiler, I think of Clang or one of those ones that is used for maybe C or those static languages. What’s unique about the TypeScript compiler when it was written in JavaScript compared to these native compilers?

Anders:

[04:00] I think there are a couple of things that are pretty unique about TypeScript‘s compiler. First of all, it doesn’t target machine code, it targets JavaScript, and some people call that a transpiler. And in a sense, the compilation phase is mostly about removing the type annotations and turning your TypeScript back into JavaScript. Right now, in the early days, also an important part of the compilation process was to downlevel your JavaScript, meaning all of the runtime environments at the time were not evergreen.

[04:36] And sometimes people were lagging multiple years behind on which level of the standard was implemented. And for example, when classes got standardized, most JavaScript runtimes didn’t implement classes, but it turns out that you can downlevel to constructor functions, transform the code. And so part of what we did was this transformation, downlevel transpiling of the code. But then, of course, the type checking is the big thing that we do.

[05:06] And the type checker in TypeScript is also quite unlike any other type checker in other compilers. Typically, type checkers exist in compilers to guide the code generator because you want to know: are we dealing with a float or an int or a string here so we can generate the correct machine instructions for that data type, et cetera, et cetera. That’s not the case in TypeScript. In fact, since we erased the types, the types have no impact whatsoever on the runtime behavior of the code.

[05:40] They purely exist for tooling sake and for the developer’s sake and to guide things like statement completion and refactoring and code navigation, which is a whole different thing. Also, they don’t necessarily have to be there. And so TypeScript has a gradual type system. You can sort of have half of your code have types and the other half is just anys that we don’t check. Now very few languages have anything like that.

[06:13] So it’s a very different compiler in that sense and a very different language in that sense. That actually made it fascinating to work on because we were solving problems that no one had solved before.

Ryan:

[06:25] I know a lot of compilers, they take the higher-level code and they typically apply optimizations as well. Maybe they unroll loops or they get rid of duplicate instructions, simplify things. Does anything like that happen in the TypeScript to Java compilation process?

Anders:

[06:44] Very little. Like I said, when we do the downleveling, there are some transformations that go on that are complex. But it is less and less the thing that’s important about TypeScript. In fact, a lot of people use TypeScript only for the type checker, and then they use some bundler like esbuild or SWC or whatever to package their app, erase the types, do whatever needs to be done in order to make it runnable in the browser.

[07:15] And so we’re not really there to optimize your code for runtime. We’re there to make you more productive as a developer or make AI more productive as a developer.

07:29 — Why rewrite the compiler in Go

Ryan:

[07:29] So with the native rewrite of this originally fully JavaScript compiler, what was the problem you were trying to solve with the rewrite, and why did you end up rewriting it in native code?

Anders:

[07:43] Well, the problem we were trying to solve is real simple: performance and scalability. JavaScript was never really optimized for compute-intensive workloads like compilers, right? JavaScript is more about creating UI that runs in a browser. It was originally intended for just maybe 100 lines of code, but now, of course, it’s gotten to be a lot more. But it’s not a place that you would optimize for the kind of workload that we are.

[08:16] So in JavaScript, first of all, you pay a 2 to 3x perf penalty compared to native code. I mean, it depends on the workload, but if you’re doing compute, that’s about where it’s at. And then secondly, in JavaScript there are a lot of restrictions around use of concurrency. JavaScript was always engineered, in fact, to be a single-threaded language. That’s why we have callbacks and async and whatever.

[08:44] It’s because you can’t spin up threads, and that’s a good thing. Mostly because concurrency in a language with mutable data is very, very hard, because you can have races and deadlocks and all of this good stuff, right? That’s why functional programming languages are easier with concurrency, because all the data is immutable, and it’s much easier to reason about. So JavaScript doesn’t give you access to concurrency other than web workers.

[09:15] But web workers can’t share data between each other other than by remoting it. So you can have one web worker compute something, but if it wants to give it to some other web worker, it has to turn it into JSON, or it can’t just hand it objects. And that means you can’t have one worker compute some data structure and then have someone else use it. In other words, you can’t have shared memory concurrency.

[09:41] And really that’s what we wanted in order to gain all of the perf that we were leaving on the table by not utilizing multicore CPUs that everyone has today, right? Because Moore’s Law has stopped giving us faster CPUs, it’s giving us more CPUs, and we got to find ways to use them in our compute-intensive workloads, or else we’re leaving money on the table. And so we were leaving money on the table in multiple ways, right?

[10:08] And so native code, and that was why we looked for a language that would get us out of both of those binds. It had to be native and it had to have access to shared memory. Concurrency.

Ryan:

[10:21] I saw for the language choice you went with Go. And when I think of all the systems languages, the ones that are often hot are maybe Rust or Zig, why did you choose Go for the native rewrite?

Anders:

[10:35] I think the decision process was actually pretty structured. The first decision we made was we’re not going to rewrite, we’re going to port. Because only by porting can we preserve the semantics and the algorithms and the exact behavior of our existing compiler, which everyone depends on for backwards compatibility. Now, we could have cleaned the slate and started completely from scratch, but we would have come up with a different language in the sense that it would give you different errors or behave differently in certain situations where it has to make choices between multiple possibilities and what have you.

[11:15] So we wanted to port that meant our code makes certain assumptions. Our code, for example, assumes the existence of garbage collection. It assumes the existence of first-class treatment of functions. You can have functions within functions, and you can close over outer state and so forth. As we evaluated all of these, Go was the one that checked the most boxes. It gives us very robust and mature native code generation on all major platforms.

[11:53] It has garbage collection and it has excellent access to shared memory, concurrency. And those were the high-order bits that we wanted to check. And every other language had something that kind of worked against those objectives. So for this particular workload, Go was the right choice for us. And it’s worked out well.

Ryan:

[12:16] If you think about Rust, what didn’t it have that if it had it, you would have picked it?

Anders:

[12:22] I mean, I think there are two things. It doesn’t have garbage collection. It’s done manually, or it’s done through the borrow checker. But the borrow checker doesn’t allow circular data structures. And our compiler is chock full of circular data structures. We have trees with parent pointers, we have types that are recursive, we have symbols that refer. I mean, it’s everywhere. And like I said, if we had chosen to rewrite, we could have probably solved all of that.

[12:54] But it wouldn’t have been just porting the code. It would also have been solving a whole bunch of new problems that we had bought ourselves by going that route. We tried, and it just wasn’t feasible. And so we were just trying to optimize for doing as little work as possible to get us to the payout. And honestly, Rust is no better when it comes to the quality of the generated code or the concurrency gains that we could have gotten out of it.

[13:27] Go is just great. I mean, so we got all the bennies for less work by going that route.

Ryan:

[13:35] I know some languages, when you say they’re garbage collected, there’s something in the language itself that is doing garbage collection. But there’s also independent libraries that can provide garbage collection, right?

Anders:

[13:52] There is, but it often comes with a whole bunch of restrictions, and it doesn’t necessarily come with the safety guarantees that we were looking for. I mean, Go is type-safe and memory-safe, meaning that you don’t get to just have stray pointers or whatever. With Rust, you can do ref counting or you can do all sorts of different strategies, but there’s always that little bit of unsafe where you have to do this in order to make it all work.

[14:26] Where if garbage collection is engineered into the language, it really is a separate concern that is you don’t have to do anything special. I mean, of course, you have to not hold on to data that you no longer need and whatever. But that’s true of ref counting as well, right? But it is inherent in the language.

14:49 — LLMs for large migrations

Ryan:

[14:49] When you ported it from JavaScript to Go, I’m curious how much LLMs were used in that process, because I know famously there’s some major projects that have been doing rewrites of their entire codebase. I know there’s this JavaScript project called Bun that rewrote everything from Zig into Rust, so it seems like a pretty useful tactic. And I’m curious if you leveraged that in this process.

Anders:

[15:16] Not a whole lot, but it also has to do with timing. We started this project two years ago, and two years ago, LLMs were nowhere near as good as they are now. I mean, that’s how crazy fast it’s all moved, right? So what we did, though, is we certainly had a bunch of tools that aided us in the port. I’d say the prototypes we wrote, the scanner and the parser we wrote manually. And at that point we could convince ourselves, wow, we can actually get 10x out of this.

[15:51] Now what do we do with the rest of this code base? What we did was we wrote a tool that syntactically translates TypeScript into Go, this code that comes out of it. It has no syntax errors in it, but it doesn’t compile either because it’s full of... It uses types as if they were TypeScript, which they’re not in Go. And so all of that had to be refactored. We had to redo all the data structures or whatever, but we got the same code base out of it, and then we could sort of bang on that, and then in a more localized fashion, maybe use AI occasionally to help us do the transformation.

[16:29] So it was sort of manual and automated and a little bit of AI. Now, if we were to start the project today, would we do it differently? Possibly. Although I will say, if we just let AI loose on what is it, like half a million lines of code that we have in the old compiler, or somewhere between half a million and a million, and asked it to translate it all, well, I don’t know that that would absolve us from then having to go in and carefully examining every line that came out of it to make sure that there were no hallucinations.

[17:04] Right. Unless you have 100% perfect test coverage, you probably still got to go check all of that. Now, I think a better approach, quite honestly, would be to enlist AI to write a program that helps you translate from TypeScript to Go, because at that point you can park the stochasticness in that program and then you can get deterministic behavior whenever you run the program, which means you get the same transformation every time you run it.

[17:35] That’s always the thing about AI that people forget: it’s not deterministic. So you can’t really trust that it’s going to do the same thing twice. We might have done it that way, but AI was not ready to do it at the time. Now, that doesn’t mean that we don’t use AI now down the line. We use AI a lot in our internal processes around the compiler, as everyone does, right? Help it to write tests and to move pull requests and what have you.

[18:05] And whenever an issue is logged, first thing we do is put Copilot on and see if it can fix it for us, right? I mean, so, yeah, in that approach.

Ryan:

[18:13] where you use the LLM to generate tooling and then the tooling is deterministic, but you’d still have to validate that thing.

Anders:

[18:23] Yes, but that’s a much smaller surface area that you have to validate, right? And honestly, I’ve seen that even with friends. We did some trip together, and there was some accounting of it. Well, he paid for the hotel rooms and we paid for this and whatever, and we needed to sort it all out, right? So, okay, well, here’s what all the costs were, and here are the pieces, and have AI fix it for us, right?

[18:46] Or like tell who owes who what. And it very authoritatively came up with the wrong answer, right? Because it just forgot about some of the settlements, right? But if we had asked it to write a spreadsheet, which is really just a program, right, then we would have gotten the right answer because it’s very good at writing programs. So it’s kind of funny how sometimes you don’t ask AI for the answer, you ask it for a program that computes the answer.

Ryan:

[19:17] What are the potential benefits that you left on the table by doing a port instead of a full rewrite?

Anders:

[19:23] To be honest, I don’t think there are any, and I don’t think we would consider a rewrite. We were quite happy. We’re quite happy with the way this codebase works. I don’t think we’re leaving any money on the table currently. And as I said earlier, rewrites are toxic often for ecosystems, because they sacrifice compatibility, because you never rewrite and you never get back to exactly what you had before, right?

[19:54] Oh, but in the name of making it better or prettier or whatever, we change this and that and the other, right? And then while all the users get to suffer through that, right? So backwards compatibility is super important if you want to keep your ecosystem happy. And we do want that.

20:12 — Why Javascript is so popular

Ryan:

[20:12] In studying for this interview, I just keep reading about JavaScript and the strange semantics of the language. And I think throughout my career too, people have typically not been super satisfied or happy with JavaScript for some reason or another. My question is, why is it so popular despite that?

Anders:

[20:36] First of all, I don’t think JavaScript is as bad a language as some people make it out to be. I will say in the three, what, three, four weeks that Brendan Eich had to create this language back in the mid-90s, he did a lot of things right, and thank God that he had been educated on functional programming and got first-class functions done, right? Where you can have functions within functions and the inner functions can access the outer function state and you can pass functions around as first-class values.

[21:09] That is super powerful. JavaScript actually got that very right. Now there are some quirks in the language too. All of the automatic conversions and all of the bizarre differences between double equals and triple equals just drive everyone mad. But that’s exactly what type checkers are happy to do. They can ferret out all the little differences because they understand all the deep semantics of the language that no one seems to be able to keep in their mind.

[21:39] So I think that’s part of why TypeScript has become so popular, right? It can actually truly bring out the best parts of JavaScript and leave the bad stuff behind. And of course you can’t. The thing about JavaScript is it is the cross-platform language, like even Java, that was engineered and intended to be the way to write cross-platform applications. It’s not really cross-platform.

[22:06] It doesn’t run in the browser, I mean, it doesn’t run everywhere, right? JavaScript runs everywhere. So there are a lot of reasons why you should like JavaScript. And with TypeScript, I think we’ve managed to sort of capture all the badness and park it.

Ryan:

[22:27] I saw there were some projects. I don’t know if you’re familiar with Dart or CoffeeScript, and it seems like these were some efforts to replace JavaScript or improve it, but they’re not popular today. So I’m curious what happened.

Anders:

[22:44] I mean, I think CoffeeScript was mostly a different syntax for JavaScript, so it doesn’t really change the semantics, and it didn’t provide any additional tooling or whatever. And Dart was also, in a sense, about fixing JavaScript. Right, but if you can fix something by fixing it instead of trying to replace it with something else, then you’re doing the ecosystem a much bigger favor, I think.

[23:16] Right. And that’s what we set out to do with TypeScript. We weren’t trying to change JavaScript; we were trying to improve JavaScript. And I think that’s ultimately why we succeeded.

Ryan:

[23:28] I mean, in this new age where it’s very feasible that maybe AI could rewrite code bases, I imagine people will start to go toward the desired languages rather than the ones that are the incumbent languages. And I’m curious if you think that JavaScript might become less used in the future.

Anders:

[23:51] See, I don’t think so. What I’ve observed is that AI is best at the languages it’s seen the most of in its training set. AI gets trained on all the code that exists in the world, which means there’s an awful lot of JavaScript, an awful lot of TypeScript, an awful lot of Python, and therefore AI is good at JavaScript and TypeScript and Python. It is less good at my favorite little language that I just invented.

[24:22] In fact, there’s none of it in the training set, which means you have to sacrifice God knows how many tokens in the prompt to teach AI the language before you can even ask it a question about the language. Do you know what I mean? So in that sense, I think incumbent languages are actually, if anything, going to flourish because of AI. And we’re sort of seeing that right now with TypeScript too. Right.

[24:47] There’s a noticeable knee in the curve of TypeScript adoption that coincides with the advent of AI. I do think the incumbent languages are actually, if anything, getting stronger.

Ryan:

[24:58] What percent of all JavaScript is written in TypeScript?

Anders:

[25:04] Well, so in the last year, TypeScript became the number one used language on GitHub. So there is JavaScript more than JavaScript. So more than 50% on GitHub at least is written in TypeScript. So we’re actually larger now than the language that we set out to improve.

Ryan:

[25:28] Wow.

Anders:

[25:29] Yeah. And larger than Python.

Ryan:

[25:31] If you were to just draw that out in the future, do you think that eventually TypeScript would become the default and almost 100% of all JavaScript would be typed?

Anders:

[25:41] Well, certainly. I mean, if you’re having AI write it, I almost challenge you to find a tool that writes JavaScript. They all write TypeScript because it helps AI write better code, because the type annotations guide the LLM toward writing, or to write, making fewer mistakes, and the ability for us to statically validate the code before you run it. I mean, that’s the distinction, right? The only way you can validate JavaScript is by running it, which means you have to set up a runtime environment, which might not be possible for AI to do because AI lives in a sandbox, but AI can run through tools, the compiler, and check the code that it just generated and be told, oh, you made a mistake.

[26:27] Oh, well, let me fix it then before I even tell anyone that I made the mistake. Right?

26:32 — Why ever use Javascript on the backend

Ryan:

[26:32] After learning about this 10x improvement and performance from rewriting in native, it makes me wonder why anyone would use JavaScript on the back end. Why not just always use native languages on the back end?

Anders:

[26:48] Well, it depends on your problem, I think, because the thing that overlooks is what kind of thing am I going to write on the back end? There are an awful lot of very, very good web server frameworks, for example, that use TypeScript or JavaScript, right? So if there are frameworks in your ecosystem that get you to a solution quicker than if you had to write that because your native language wasn’t really intended to target that particular community.

[27:21] So I think it very much depends on what your problem is affinitized with. And often performance of your code isn’t the bottleneck. I mean, look at Python, right? It’s used to basically script all of the LLM training in the world, right? I mean, a lot of that code is ultra time critical, but that’s written in native code, right? And then you use Python as the orchestration language, and in a sense, in a web server, TypeScript is just an orchestrator of talking to a database and doing this and that. And the things that ultimately control the performance of applications like that aren’t necessarily whether that inner for loop is running as native code or not.

[28:12] Which actually it is because of the JIT anyway, right? I mean, so measure first and then make decisions, right? Because you always get surprised when you measure, when you talk about how much faster it was to.

Ryan:

[28:24] One of my immediate thoughts is, why wasn’t it done sooner?

Anders:

[28:33] At the time we started TypeScript, I don’t know that we had ever envisioned that people would be writing projects that are the size of the projects that people are now writing in TypeScript, right? Visual Studio Code is like 2.3 million lines of code. I mean, we have in-house projects that are over 10 million lines of code, which is insanity. We would have just at the time gone, well, that’s clearly no one’s ever going to do that, right?

[29:01] But that was a decade ago, more than a decade ago, right? We started in 2012 with the TypeScript project, and the world looked very different. And so gradually, people have started writing larger and larger and larger projects, right? And at the same time, our compiler has gotten smarter and smarter. We’ve added all sorts of cool features like union types and discriminated unions and control flow analysis and blah, blah, blah.

[29:26] And all of these things make our type checking even better. But it also makes it go a little slower every time we add a new feature, right? In fact, our TypeScript 6 runs only about 50% of the speed of TypeScript 1.5, for example. But TypeScript 1.5 also did a whole lot less. So projects have gotten bigger and the compiler does more. All of which detract from your effective output. And as I mentioned, Moore’s Law also, unfortunately, stopped delivering faster CPUs, and JavaScript keeps you from taking advantage of the additional cores.

[30:02] And it’s not clear that we could have foreseen all of that, right? But it’s just the way it panned out, right?

Ryan:

[30:10] OpenAI, Anthropic, Cursor, and Vercel all use this product to make their lives better. And the problem it solves is when you’re building SaaS or an AI product and you want to sell to other companies, there’s all these requirements you need to meet. There’s SSO, there’s SCIM, there’s RBAC, there’s audit logs. These are all things that take time to integrate but aren’t the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code.

[30:40] So let’s say you have a new SaaS product and you want to sell to other companies. WorkOS will solve all of these critical feature gaps for you. You can check them out at workos.com to learn more and get started. And I appreciate them for supporting my work and sponsoring this podcast. Jira by Atlassian isn’t just for tracking work anymore. Now you can pick your favorite AI agent to assign tasks to, and they’ll get access to the rich context that’s already in Jira.

[31:07] When the agent is done, it surfaces a pull request. That way you can get more done with your favorite agents, all in one place. Learn more at jira.dev. That’s J I R A. D E V. Appreciate them for sponsoring the podcast. And back to the show. I first became a software engineer and I went to start working at Facebook. At the time they had this popular framework called Flow, which was doing type inference on top of JavaScript.

[31:37] It was this thing that would take a long time, and then I’d never hear about it these days. So it sounds like TypeScript won, if there was a competition to type in.

Anders:

[31:46] There was a bit of it, yeah. In the early days, I think the thing that worked for us was actually the fact that we were self-hosted, which made it a lot easier for the community to contribute to the project. Flow was written, as I recall, in OCaml. And so in order to contribute to Flow, you had to go learn a whole different way of programming in a different language. Right. And Flow also did not focus all that much on IDE-based tooling, which we knew full well going in.

[32:22] We’re writing a compiler, but we’re not writing a compiler in order to generate machine code. We’re writing it to make better tooling. That was why we wrote it right there, hand in hand with our compiler. We had a language service. It was deeply integrated into Visual Studio, Visual Studio Code, all sorts of other editors through an open protocol, and that’s where the problem that needed solving was.

[32:47] I mean, it’s nice to have a type checker, but boy, you want that. You also want statement completion. You want red squigglies, you want it interactive, right?

32:59 — What it takes to build a programming language

Ryan:

[32:59] So I know in your career you’ve, you’ve worked on multiple programming languages. What does it take to build a programming language?

Anders:

[33:07] Well, first I’ll say that the world needs another programming language. Like it needs another hole in the head. I mean, it’s like you kind of got to be a certain kind of person to even embark on it to begin with, right? It’s a super fascinating area of computer science and it’s one that’s been around ever since the beginning of computers. Now every compiler, every language has a whole bunch of things you need to understand, like parsers and scanners and lexers and code generators and whatever, right?

[33:43] But that’s sort of the mechanics of implementing the language and then there’s the design of the language, sort of the art of making it feel right, whatever, right? And I think you sort of have to master both. And then you also got to appreciate that like every new language is actually only 10% new. And then it’s 90% the same drudgery that every other language has to go do. And so be prepared for a lot of work that maybe isn’t as interesting, you know, and then finally maybe I’ll say that, you know, like, never forget there that you stand on the shoulders of giants.

[34:24] I mean, in order to make a great programming language, you got to understand a bunch of other programming languages first and understand all the, all the distinctions between the different styles of programming like procedural and object oriented or functional or what have you. And then last but not least, it’s like it’s a long game. I mean, it is probably a longer game than anything else. I mean, like every language project I’ve worked on, I’ve worked on each of them for at least 10 years and shipped multiple versions.

[34:58] And it’s really never until version three that it truly starts to get okay, do you know what I mean? And it just takes an incredible amount of devotion to that. So you gotta really not be the type that tires of a problem quickly and then moves along that you’re not meant to do language design. And you see that too when you talk to language designers in the industry. They’ve been doing it for a long time.

Ryan:

[35:23] You mentioned those two parts. There’s the objective pieces that you need to implement and then there’s the art of the design and making the language, I guess, ergonomic for developers. When you think of that second part, that art, and you look at other programming languages, are there any that you admire outside of the ones that you’ve worked on?

Anders:

[35:45] Of course, learning and fully appreciating the beauty of functional programming has been very educational. I mean, because it really is a different way of thinking about programming, a way of thinking of programming that’s much closer to math than it is to machines. And I think there’s a lot of incredible goodness that has come from that. And honestly, Even in building TypeScript project, large portions of the TypeScript compiler are written in a highly functional style and work on immutable data structures that are then.

[36:25] Now, because of shared memory, concurrency can be shared between different threads or processes that don’t mutate the data and therefore they can share one data structure that’s incredibly powerful. But mastering this, like writing islands of pure functional programming inside an imperative program and putting it together with concurrence, I mean, it’s complex, but I think functional programming has brought a lot to the world.

[36:55] I know object oriented programming as well, but I wouldn’t single out any particular language. Every one language you come in contact with, you learn something.

37:06 — Will there be fewer languages in 10 years

Ryan:

[37:06] You mentioned the world doesn’t really need more programming languages. And if you think 10 years from now, do you think there will be less programming languages than there are today?

Anders:

[37:19] It’s hard to say. But like I said, AI tends to favor the incumbents. Right? And I do think, and I think this has been true even before AI, the bar keeps going up for what it takes to successfully implement a programming language and create an ecosystem around it. I mean, it used to be, oh, you just need a compiler. Well, you also kind of need tooling now. I mean, you need a language service, you need debuggers, you need profilers, you need frameworks and libraries, you need code generators that can target all sorts of.

[37:59] I mean, it’s like it just keeps getting harder and harder to get all the way there.

Ryan:

[38:08] When you think about all those pieces, really, they’re all for the people. I mean, the IDE and the types. I mean, the computer looks at that too, but it’s so that we can read source. Maybe one day the LLMs will generate machine code directly.

Anders:

[38:28] I wonder. I think LLMs are better at what they do when they don’t have to repeat themselves a lot. I think, like when a program is expressed in text, it is closest to its sort of ultimate condensed meaning and representation. Right. If you translate it into machine code, there’s an awful lot of noise in that machine code. Like all of the instructions, like, half of the instructions are memory addresses that have absolutely no bearing on what’s going on here.

[39:09] So half of all the data is noise already. Right. And then whichever register you pick, well, that doesn’t matter either in the code generator. And honestly, you could change your mind at any point in time. So teasing the truth out of that noise is a lot harder than if you just have a program where the variable is called I and whatever. And by the way, that you can relate to the written instruction that the user just gave you.

[39:34] I mean, keep in mind that, like, AI are, they’re just emulators of humans in a sense. Right? I mean, it’s like neural networks. Right. There’s a reason we have programming languages because we’re terrible at writing machine code straight off out of our head. Right? AI is not that different from us, so the same would probably be true there.

Ryan:

[39:56] When you look back on working on C and Typescript and these language projects, they were long journeys and I think, yeah, one thing people might want to know is what did you Learn through those journeys that if you knew at the beginning of when you embarked on working on them, you might have been better off.

Anders:

[40:19] Gosh, well, each journey is different. I mean like the first project I worked on, Turbo Pascal, I think

Ryan:

[40:30] that

Anders:

[40:30] project started back in the old days when it was 8bit micros and 64k of memory and one person could do everything themselves and have ultimate control of everything. And so I was very much a one man shop. But that quickly was not scalable. Right. And capacities of machines. We went from 64 to 640k and then kaboom, the lid went off. Right. And you could have as much memory as you wanted. And so not one person couldn’t do it.

[40:59] And I had to learn to become a team player. Right. And that, that was a big journey for me. I mean to learn to let go. Right. If you’re a perfectionist, that could be hard, but that’s one thing that I would say I learned there.

Ryan:

[41:14] Well, another way to word this question is, you know, what’s the most common mistake that you see people make when they embark on building a programming language?

Anders:

[41:24] Well, I think people tend to over index on one idea that they have that they think, oh, wouldn’t it be cool if my language could do blah. And then they under index on all of the mundane stuff that every programming language has to do and then it ends up doing that one thing they love, maybe better, but then it does everything else not as good. And the net is a detractor. Right. And so it’s so hard to convey how many things you have to do that really doesn’t have anything to do with the problem you’re trying to solve per se.

[42:03] When you’re implementing programming languages, when you

Ryan:

[42:06] were working on C, do you keep tabs on the other languages and what they’re doing better, what you could do better with C?

Anders:

[42:15] Yeah, no, you got to keep yourself informed because like I said, we all stand on the shoulders of giants. No programming language was ever created in perfect isolation. Everyone learns from everyone and then someone comes up with a good idea and then you see it adopted elsewhere. We’ve adopted many ideas from functional programming in C, for example. Then other languages have adopted some of the good ideas we had in C, like Async now is in JavaScript and in some of the other programming languages out there.

[42:46] And that was pioneered in C. You know, it’s, it’s, we all learn from each other and that’s how the industry moves forward. Really.

42:57 — Hands on engineering vs delegation

Ryan:

[42:57] You mentioned the, I guess, learning to let go. I think that’s something that a lot of people, as their career advances, they start with, you know, individual contributor work and then later they start delegating things. How did you learn that? Or what was the. Is there like a, maybe a story or particular project where you let go and you develop that skill?

Anders:

[43:21] Well, it’s almost like I got a counter story to the letting go there because in the C Sharp project, my main function was not implementing the C compiler, it was being the language designer and writing the spec and designing all the new language features. Before that, when I, when I had worked on Turbo Pascal, I was, I was doing a bunch of active coding, you know, on, on the thing itself, right? But then I sort of let go of that, but I let go of it too much and I sort of drifted up into the stratosphere and became more of an architecture astronaut, do you know what I mean?

[43:59] And I wasn’t getting my hands dirty. I was writing stuff in the framework and in the libraries, but it wasn’t, it didn’t quite. These are not like the deep, really super hard problems to solve. And I didn’t really know it at the time, but I was gradually getting less happy with the work that I was doing. I still enjoyed, but there was something missing. And so when this typescript opportunity came along, I decided to jump in and actually actively participating writing compiler.

[44:30] And it brought so much happiness to my life. I finally realized I’m just a happy coder. I mean, I like the spec stuff too, but coding is like, man, that’s what gets me up in the morning, make coffee and write some code. You know, that’s when I’m in my happy space.

Ryan:

[44:48] You know, when people are at these really, really high levels, they kind of have this expectation of a certain level of impact. And so how do you continue to write code as such a high level engineer?

Anders:

[45:02] Well, the specific code I’m writing isn’t necessarily having all that impact, but it’s the fact that I also do the architectural guidance as part of a group of people in a project, there’s plenty of work for everyone to go around, but you stay involved in a corner of the project because then you see what happens in the code. When you’re checking in your code, you go, what was, what was that over there?

[45:31] Let me just, what’s happening over here? Or you realize, oh, we need to refactor this. This is not feeling right anymore. But if you let go of that, you can’t really talk about the thing that people use day to day. You can talk about the Syntax of the thing that people use day to day, but you can’t talk about that thing. So both are important, I think, and I’m happy that I get to do both.

Ryan:

[45:57] Now, I know a lot of companies have this idea of engineering archetypes or the way that high level engineers get some work done. And you mentioned architect, for instance. A lot of companies have different words for architect. I’m not sure if you’re saying it’s just your working style or are you saying that all high level engineers should be hands on at some level?

Anders:

[46:22] No, I’m not saying that because I don’t think it’s like I made a conscious choice to remain an independent contributor as opposed to become a manager. I mean, I have plenty of opportunities, but that is not where I do my best work. Right. So I think you have to decide for yourself what is it that motivates you, makes you happy, keeps you doing this for a lifetime. Do you know what I mean? And you only get one run at it in life here.

[46:54] And if you’re going to do your best work, do the thing that makes you the most happy. I think that’s what I learned along the way, that coding is part of that, a big part of that.

Ryan:

[47:10] So then when you were working on C, but before Typescript, how did you know something was missing?

Anders:

[47:16] I just knew something. I don’t know how. I mean, I just wasn’t feeling as fulfilled with only doing the design part. Right. I missed the coding and whenever I had a chance to write a little bit of code, I would feel a lot happier. And I go, that’s kind of interesting. Do you know what I mean? But now I got to go write some more specs.

Ryan:

[47:41] So then was Typescript something you kind of went towards because you wanted to write more code?

Anders:

[47:46] Well, I went towards it for many reasons. I mean, it wasn’t specifically that to begin with. I just found the problem fascinating. Right? I mean, because the way TypeScript came about was actually indirectly through C. Because the Outlook. com team, I think it was, approached the C group and asked whether we would pretty please productize something called Script Sharp. Script Sharp was this thing that took C and transpiled it into JavaScript so you could run it in a browser.

[48:19] I’m like, what? Why would you want to do that? Why don’t you just write the job? Well, because that way we can get great tooling, then we can use Visual Studio and we can have projects and we can have type checking and we can have code refactoring and navigation and we can write interfaces and people can understand how this all works. And I’m like, wow, is JavaScript really that busted? And you’re saying, like, the way you want to fix that problem is by abandoning JavaScript, treating it as an instruction language.

[48:51] Right. And then having a code generator targeted. I’m like, couldn’t we fix JavaScript? Wouldn’t that be better? Do you know what I mean? And that’s how TypeScript kind of got off the ground, Right? It was like, gosh, there’s something here that’s really broken that needs to be fixed. Right. When it comes to JavaScript tooling, and that’s what we set out to do.

49:14 — Why fast tooling matters more now

Ryan:

[49:14] One thing I thought would be interesting is in one of the talks that you gave, you said that you believe that the speed of your tooling is more important now because of AI, And I want to hear thoughts on why is that the case.

Anders:

[49:30] Well, more and more, our workflows now are dominated by agents that are, like, running away in the background. I mean, like, writing code for you. And they make mistakes just like we do. But you can have as many of them as you want. So there are like, many, many more little workers in the ecosystem writing much more code. Right. And that whole workflow is like, LLMs already have performance challenging.

[50:00] And if you add, like, if you’re writing code in a big project and you have to type, check it, and it takes two minutes every time the LLM writes something. Do you know what I mean? That’s horrible. Right? So making that go faster is a big benefit.

Ryan:

[50:14] Yeah, absolutely. I guess. Because it’s hammering away.

Anders:

[50:17] Yeah, Because, I mean, well, we all know LLMs, they like to use GREP and whatever. Right? But then they’re also smart enough now to realize that if you’re trying to change this property called version, and like every other object has a version property, you can’t just grep for version and then go rename it to something else because, like, you’re breaking all these other interfaces that have a version in them, right?

[50:45] So you got to do semantic search, and the only thing that can do semantic search is a compiler. And so you got to use the compiler through, typically through lsp, through language Services, or through our command line tool. That would give you the equivalent. Right. And so more and more AI is doing that. And that means, you know, compilers run at. You may not even see that they’re running, but they’re running and they’re doing work on your behalf.

[51:15] Yeah.

51:16 — AI software engineering predictions

Ryan:

[51:16] When you talk about AI, it’s very realistic and grounded in the software engineering. And so I thought it might be interesting to run some common AI takes that I hear from the Internet and get your sense of how accurate is this? What are your thoughts on when or if it’ll be true? Okay, so the first one that I’ve heard this was more common at the end of last year, is that AI is going to write 90 plus percent of the code within a year.

[51:49] Curious what you think on that.

Anders:

[51:51] Well, for certain classes of apps that might be like all of I coded apps are writing 100% of the code. Right. And there’s an awful lot of that being written. Are they going to write 90% of the high quality code on the Internet? I don’t know about that. So the thing is like 90% of what the volume of written code is just going like that right now. Right. Because AI writes so much code. So in a sense that’s a self fulfilling prophecy.

[52:22] Right. But when it comes to the super high quality code that no one has ever written before, it’s not clear to me that AI is going to write 90% of that.

Ryan:

[52:35] So when you think about cases that AI is not writing all the code, maybe some examples of the super high quality stuff, what is that?

Anders:

[52:44] Well, I mean it’s algorithms that no one has ever seen before, for example, or particular solutions. Like, I mean, I know that AI could not write our compiler, the Typescript compiler. It just can’t. I mean we’ve tried it can’t do it. And I’m not asking it to either. I mean I’m not expecting it to either. But our compiler is also not a typical piece of code. That’s why it’s bad at writing it, because it’s seen none of it in the training set.

[53:16] Well, I’ve seen some compilers, but not like this one, not with these concepts, not with done the way that we’re doing it. Right. And so it’s just not a good fit there. AI, we can’t forget that AI is at heart a big stochastic machine that has memorized the entire Internet. Right. And has an ability to extrapolate somewhat over what it’s memorized. Right. But if it hasn’t seen it before, it’s not necessarily going to be all that good at doing it.

[53:49] It’s getting better. I mean, I’m not saying it’s not impressive, it’s wildly impressive what it can do, but I just think there’s a long way still to it’s doing all of it. And I don’t know that we ever get there. I hope we don’t. Because then what’s the point of humans anymore then? I mean, it’s.

Ryan:

[54:09] What I see this take often too is you won’t need to use an IDE within the year or you don’t need to read the code anymore.

Anders:

[54:19] Well, good luck to you. I mean, if you’re going to hand AI the keys, I mean, then all bets are off, right? I mean, the minute AI you can’t convince AI to fix this issue or this new feature that you want built, what are you going to do? I mean, if you don’t understand what’s below? Right. That’s one problem. The other problem is, let’s say a user comes to you and goes, your app just stole my bank account.

[54:46] Well, it’s going to sue you. They’re going to sue you. Not the AI. I mean, it’s like at the end of the day, someone has to take responsibility for what AI is doing. And if you’re giving it the keys, well, it’s on you. But I don’t know, I personally would not feel comfortable. I wouldn’t be able to go to sleep at night, I mean, if I didn’t understand what it is that I am vouching for.

Ryan:

[55:13] Why is there such a big difference between this opinion and what I see from maybe people who work at Anthropic?

Anders:

[55:22] Well, the difference is, all I’m saying here is not that AI can’t do amazing things. It does, it can. It does that every day. But people love these, like, take it all the way to 100%. Right. And that’s where I get off the bus a little bit. Right. I think, oh, yeah, okay, fine, we can get higher and higher percentage. But there still has to be someone understanding what’s going on and how it’s relevant to our business problem and how it relates to what our organization is doing.

[55:53] And like, I mean, there’s so many other things that have to be connected that it’s. I think it’s wrong to just view it as AI did it all and we were completely unnecessary, you know?

Ryan:

[56:04] Yeah. The next one I was going to ask you was, you know, three years from now, will AI replace junior software engineers or what junior software engineers do today?

Anders:

[56:13] Well, if it does, then how do we ever get senior software engineers? Right? I mean, it’s just like, I don’t think so. Well, I’m not. Unless you also believe that you will be able to do your business three years later than that without any senior software engineers.

Ryan:

[56:30] Right.

Anders:

[56:30] Because where are they going to come from you got to train them, I mean. But to me, I think maybe one thing that to some extent has happened is that for certain classes of programmers, the pyramid has narrowed at the bottom. There are fewer people coming in, and we are wanting them to advance higher up faster so that they can get to this more supervisory role. I think the craft of being a software engineer is definitely changing from your typing in lines of code to you’re having agents type in lines of code and you are reviewing the work of the agents.

[57:14] So you do more reviewing, less typing. Some people love that and really are fantastic at that workflow. But it’s a change in nature of what the job looks like as a programmer and this tool that you now have in a toolbox is having that impact. But it is but a tool and there are still programmers involved in the process that I firmly believe.

Ryan:

[57:42] It sounds like you enjoy typing out the code. Would you be less happy if five years from now, for 40, 50 years I have enjoyed typing out code?

Anders:

[57:48] I’m actually. And so I will continue to type certain parts of the code, but there are other parts of the code that I don’t particularly care to type. I don’t care to type in tests and follow all the rigor of the particular testing framework. Heck no. If I can farm that out to AI happy me, I do think reviewing has always been harder for me. It’s harder for me to spend time on reviewing other people’s code than it is writing the code.

[58:24] But I also think that over time we can make that process of reviewing code much more ergonomic than it is today. Right. I mean, often today you just get, here’s like a list of the files that were changed and here are the deltas. You figure it out. Right? I mean, AI could help us more there by explaining what the changes are and whatever. And so I think we’re going to get better at this. It’s going to get more interesting, but it will change the nature of, of the craft.

58:52 — The most technically challenging work

Ryan:

[58:52] You said that you’ve been writing code for 40, maybe 50 years. What is the hardest piece of code you’ve ever written? Or what’s the most technically challenging thing you’ve ever done?

Anders:

[59:06] There are so many things that in their time were challenging. I mean, this last project we worked on, we knew that the easy part was getting the native code that’s just like just move it to this other language. But then taming this beast called shared memory concurrency and getting the compiler to use as many CPUs as there are available on your box that is not a simple problem to solve in a compiler because we’re all taught to write sequential stuff, right?

[59:48] I mean, first you do this, then you this. But how do you do all of this at the same time and then share the data structures afterwards without anyone like accidentally modifying the other guy’s data structure? And you know, how do you, in the cases where you have to do that, how do you then synchronize it and avoid deadlocks and race conditions and whatever, Right? This, it was tricky. There were some good technical problems that we licked that I think we can be proud of, you know.

Ryan:

[01:00:13] But what about when hardware was more constrained earlier in your career? Is there any wacky thing you had to do to kind of, you know, make it work?

Anders:

[01:00:23] Oh, totally. I mean, when I started, it was a. Like being a programmer was a very, very different thing, right. I mean, I started out with, with 8 bit micros that had Microsoft Basic in ROM, right? And then the BASIC interpreter and you could buy these books and type in these Star wars games or whatever. They were all text, you know, there’s just scrolling and telling you there’s Klingons over in that quadrant, you know, and K4, you got whatever, right.

[01:00:55] But I got fascinated with understanding how it was all put together and quickly learned how to write assembly code. And Turbo Pascal, the first product I worked on was all written in Z80 assembly code. The compiler, the editor, the runtime library, everything was assembly and writing structured. A compiler in assembly code is like that. A lot of fiddling. And you were counting like, okay, I think we need to squeeze this into this EEPROM.

[01:01:30] And then there’s only 12k and I’m 20 bytes over budget here. Oh, but I can make this jump, this long jump instead. I could jump to this short jump and then jumps to that jump and then I could save one. That’s one bite saved. Okay. You know, moving right along and you would just like sitting there fiddling, you know, it was a craft. It was like woodworking almost. I mean, it was just so different from what we do now, right?

[01:01:57] Everything is now it’s bottomless pits of capacity and bottomless pits of expectation from users.

01:02:04 — Top book recommendation

Ryan:

[01:02:04] Right. Is there a top technical book recommendation you have for software engineers?

Anders:

[01:02:09] I usually recommend the same, but the one book that was like the IT book for me when I was younger, and it’s called Algorithms plus Data Structures Equals Programs by Niklaus Wirth, the inventor of Pascal and then later Modular and Oberon and whatever. And it’s a book that is light on math and Symbolism and rich in instructive examples and good explanations about how data structures work. I mean, that’s how I learned about hash tables, right?

[01:02:43] I mean, like, when you’re self taught, you don’t know about hash tables, you sort of know about linked lists, right? And fine. So in the original version of Turbo Pascal, all the symbol tables were just, well, they were just linked lists, you know, or whatever. And then of course, as you had many local variables, well, you’re going exponential in search time. And then I read about these hash tables and like, wow, what you mean I can just do this?

[01:03:11] And then it’s basically like linear lookup time and implemented and the compile went twice as fast. Right? Like, holy cow, that was useful reading. Do you know what I mean? So I was always like the engineer, I mean, understanding how to do error recovery. He explains that in how you construct a simple compiler. And then like, you know, and it was, for me, a great book. And now it’s actually like, I mean, it’s just a big PDF, you can download it out there.

[01:03:46] It’s out of print since 40, 30 years. Yeah.

01:03:50 — Advice for his younger self

Ryan:

[01:03:50] Last question for you is, with all the experience that you have now, if you go back to yourself when you just entered the industry and give yourself some advice, what would you say?

Anders:

[01:04:01] Well, a couple of things. Maybe like we talked about being a team player, you know, I would have probably tried to educate myself a bit more about that to begin with. I think also one thing in retrospect is like, don’t let people tell you that it can’t be done. When they tell you it can’t be done, it’s because they can’t do it. That doesn’t mean that you couldn’t possibly do it. Do you know what I mean?

[01:04:29] So, so don’t let that discourage you.

Ryan:

[01:04:31] Is there a project where you. Someone said you couldn’t do it and then you did it and that’s how you.

Anders:

[01:04:38] Well, I think the first thing I worked on, like Turbo Pascal, people were telling me, whenever we told them, here’s what we have, they said, that can’t be done. That’s like, nah, you guys are beautiful. That’s like not possible, you know? Well, it was and I didn’t know that it wasn’t possible.

Ryan:

[01:04:55] Right, awesome. Well, thank you for your time. I really appreciate it. Anders.

Anders:

[01:04:58] You’re welcome. No, this is a lot of fun.

More recently, frontier labs like OpenAI have been generating massive candidate proofs to unsolved problems in frontier math (e.g. OpenAI recently released these 10 advances). Lean plays a critical role in formally verifying these proofs.

I wanted to learn more about Lean so I talked with the creator, Leonardo de Moura recently. He’s also a key scientist at AWS for their neurosymbolic AI initiatives, bringing Lean and formal verification together to prove agentic AI systems correct. He explained how Lean works and why LLMs plus Lean will fundamentally change how we write software and do math. Hope you enjoy this episode!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:28 - How formal verification works

05:21 - A new way of writing software

13:15 - Proof assistants vs programming languages

21:06 - How Lean has assisted in mathematical breakthroughs

32:03 - When is it worth formalizing software

33:29 - How Lean will impact handwritten math

38:55 - The Z3 theorem prover project he started

45:44 - The most technically challenging work of his career

51:10 - Lean vs its competitors

01:00:37 - The future of Lean

01:04:10 - Technical book recommendations

01:06:15 - Advice for his younger self

Transcript

00:28 — How formal verification works

Ryan:

[00:28] There’s this famous Dijkstra quote I wanted to start the conversation with. It’s that program testing can be used to show the presence of bugs, but never to show their absence. And my understanding is that Lean and formalizing proofs can be used to show the absence of bugs. And so in your words, what is Lean and how do people use it to show bugs can’t occur in programs?

Leo:

[00:59] Lean is a programming language. You can write code, but you can also write proofs. You can reason about your code. You can write state properties about your code and prove them. Lean gives you machine-checkable proofs. You can check your proofs and get absolute assurance they are correct. You have many checkers, independent checkers, but you should view Lean as a platform. You can write code, you can write properties about your code, and you can prove them.

Ryan:

[01:30] So could you give a concrete example? Because when I think of a proof, I think of what I learned in math. But then how do you couple that with the software that we write?

Leo:

[01:42] Yeah, it’s a great question. It’s not that different from proof. Lean is actually very popular for math, but for software verification, there are two very different use cases. You can reason about Lean programs. Lean is a programming language. You can write programs in Lean itself. Then a Lean program is not that different from a definition you have in math. The techniques are very similar. But if you want to verify programs written in a different programming language, there are basically two different approaches.

[02:20] One of them, they translate, called shallow embedding. They translate for Rust. This happens today. We have a tool called Aeneas that maps Rust into Lean, and you can verify the Lean translation. There’s another technique called deep embedding, where you have the semantics. You write a semantics of the programming language of C in. And now you have a data structure that represents a C program, and you can state properties about it, almost like your programs become Lean objects that you can reason about.

Ryan:

[02:58] To make it really concrete, to give someone a sense of, here’s this thing I want to prove about a simple C program. Maybe no buffer overrun or something like that. What’s the step by step where we could use Lean to prove that?

Leo:

[03:13] Yeah, yeah. Let’s get an array. You’re trying to access an array in C. You want to make sure the index is in bounds. You’re not accessing elements that your array, for example, has 10 elements. You’re not trying to access element 11, right? Basically, you can write that. You can write something that says the value of i at this point in your program is going to be greater than or equal to 0 and less than 10.

[03:44] You can write that as a mathematical statement. Another way to view it is that if you can express in math what you care about in your program, you can verify using Lean. That’s another way to view it.

Ryan:

[04:02] So I have my C source files, and then somehow there’s an equivalent Lean proof that’s almost like metadata on top of the C program.

Leo:

[04:11] Yes.

Ryan:

[04:12] And that’s a line-by-line proof. And Lean will go and check.

Leo:

[04:16] Exactly. People will build automation for automating the process. They’re going to use techniques like Hoare triples, that says like we have a precondition, some mathematical facts that should be true before executing that statement, the statement and what is true after. Right. And they will have a lot of automation to process makes your proof modular. Right. I mean, complexity is a challenge in software verification.

[04:48] Handling the complexity is a big deal. And all these frameworks for verifying programs, they are trying to manage the complexity, make your proofs modular, even if AI. Now AI can prove things automatically for us, but they have to be modular, the proofs, if you want them to scale.

Ryan:

[05:08] And what you’re saying sounds similar to software, where you have to write it cleanly. It needs to be easy to edit and reason about. So it’s almost like a second software layer on top of the software.

05:21 — A new way of writing software

Leo:

[05:21] Yes, yes, you can view it this way. You can also flip it and imagine a future where you’re writing what you want mathematically, precisely, and AI synthesizing the code and a proof that the code that was synthesized meets your specification. Right.

Ryan:

[05:42] Oh, interesting. So you could start by writing what you want to be true and then ask the AI, please.

[05:50] And AI is going to just go and hammer at it until the Lean proof says you’re good.

Leo:

[05:55] Yes. It feels like science fiction. Six months ago, I would say this is science fiction. But for example, now a colleague of mine, Kim Morrison, a few weeks ago, she started a project I thought was, six months ago, I would say it’s not possible at all. She said, we have zlib, this compression library written in C. She says she creates a very complicated prompt for AI saying I want you to translate to Lean.

[06:28] Ensure the Lean version passes the test suites for zlib. Then I want you to prove that if you compress data and you decompress, you get the original data back. It’s a really strong property and, believe it or not, after one week, she succeeded doing the whole thing, and now it’s just asking to optimize the code. But you cannot break the proofs. You have to keep still proved all the properties you care about.

[07:02] I mean compressing and decompressing, getting the data back is a really important property for a compression engine. Right? Yeah, this is rich now. I mean, surreal.

Ryan:

[07:16] I mean, it’s crazy. And I hear in the industry, a lot of people use a really comprehensive test suite coupled with AI to do some really amazing rewrites because they have some more confidence that the rewrite is accurate and the AI can check itself. And it sounds like a specification is even better than a comprehensive test suite.

Leo:

[07:45] Yes, because your quote from Dijkstra captures it perfectly, right? With a test suite, you can show the presence of bugs, but not their absence. It’s almost like with a good test suite, you may say, well, probably there are no bugs here, but you may have a really corner case that’s not covered by your test suite. But with a proof, you’re covering all possible cases. So property-based testing is really popular now.

[08:19] People are writing properties. They want to ensure they are true, but they are checking with testing. But now we can prove them. And you say, look, there’s no point testing anymore.

Ryan:

[08:32] It seems like having a well-written specification is a superset of a test suite. But in terms of the human labor required to create a reasonable test suite versus a reasonable specification, how much more work is it to come up with a great specification? It varies a lot by the program.

Leo:

[09:04] In many cases, it’s not uncommon for someone to start developing a piece of software, and they don’t know exactly what the spec is. But properties are usually vaguely in your mind. Another thing that I tell people to keep in mind is that an inefficient program can be viewed as a specification. Usually, writing an inefficient program is way easier than writing the super efficient one that has many clever tricks.

[09:35] You can write a very, this is what I want, in a very naive way. And you ask the AI, look, generate the efficient version and optimize and prove that equivalence to my inefficient one. There are many scenarios. I mean, I will not say this. Specifications are always easy to come up with. But properties, usually the developers have good ideas about properties they care about. An inefficient program is a spec, right?

[10:08] You can view it as a specification, and the technology form of verification complements testing, right? I think your quote from Dijkstra captures...

Ryan:

[10:19] Perfectly, and I think I saw this on Twitter because Jane Street was more heavily investing in formal verification, and I read their post, and they talked about this. I think it was seL4 or some software that was entirely formally verified.

Leo:

[10:37] Yes.

Ryan:

[10:38] And the main drawback to why it wasn’t. You know how much more time would it take writing a program versus verifying it?

Leo:

[10:48] Your example, seL4, is a great example. This was a major milestone. It’s a microkernel they verified manually before AI. This project was done before AI was a big deal, and the cost is super expensive, right? At AWS, we have been using formal verification for decades, but only for the super-safe, critical components because it’s expensive. Until now, right? With AI, it changes the game.

[11:21] You have to come up with a spec. But this is not the most painful part. The most painful part is developing the proofs manually. If you have tools before AI and maintain the proofs as you change the code, it’s messing you up. I’ve seen people complaining that, “Oh, I changed the program. Right now I have a bunch of failures in my test suites, and I have to patch them one by one.” Imagine with proofs, it’s the same process.

[11:50] You have to fix the proofs. Sometimes you don’t remember anymore why. What’s the story behind this proof? It’s a lot. But AI is extremely good at proving, writing formal proofs, maintaining formal proofs. For example, yesterday I was changing something. I want to modify some proofs for technical reasons. I didn’t even know what the proofs were about. Someone else wrote. Then I said, look, I want you to—I asked AI to rewrite these proofs without using this feature because I’m going to change it.

[12:31] I don’t want to break the libraries instantly. It came up with the new proofs for me. I mean, it’s really good. And this is crucial for making formal verification mainstream because otherwise maintaining the proofs was almost like if your program took X amount of time to do the formal verification in the past, it would take 10x. That would be normal. But imagine if your program is changing. That’s something that’s really common now.

[13:05] You have to keep maintaining the proofs too. It’s a lot of work. But AI eliminates this pain for us.

13:15 — Proof assistants vs programming languages

Ryan:

[13:15] You mentioned that Lean is a proof assistant, and then you also said it’s a programming language. Is that typical for proof assistants to be both a programming language and a proof assistant?

Leo:

[13:30] Some of them, especially the ones that are based on dependent type theory, they are like Rocq and Lean — programming languages and proof assistants, right? You can write definitions like when you’re defining concepts in math. But some of these definitions can be programs, and you have types, you have structures. It’s a programming language, but it’s in the family of what’s called functional programming languages.

[14:01] I mean, is it a specific kind of programming language for people that are familiar with programming languages like Haskell? Lean is close to Haskell, but with the support for proofs. That’s a way to view Lean.

Ryan:

[14:16] Are there major use cases where people use it as a programming language but not as a proof assistant?

Leo:

[14:21] Well, the first big use case is Lean is implemented in Lean. We have many of our tooling implemented in Lean. Like the documentation authoring system called Verso is implemented in Lean. The build system that’s called Lake, like Lean make, is implemented in Lean. At AWS, we have a compiler for AI accelerators. It’s half a million lines of Lean and using Lean as a programming language. They’re proving some properties about the program using Lean.

[14:54] But the main goal is to use Lean as a programming language. In this project, the proofs are like a bonus that you can get the proofs and find problems in the design.

Ryan:

[15:06] I think most people are familiar with programming languages and the toolchains they have. But what are all the major components that you would need for a proof assistant?

Leo:

[15:19] It is not that different. I mean, if you’re used to modern programming languages like Rust, the tooling, for example, Lake is our Cargo, right? I mean, you’re going to open Visual Studio Code the same way. And I want to get all the IntelliSense. One big difference is that we have something called the Infoview in Lean. Your screen usually is going to be split in two. You have your file on the right-hand side, you have the Infoview that tells you information about your proofs, about your code.

[15:55] It’s giving you constant feedback about your development. That’s basically the main difference. But the tooling, VS Code, everything works the same way.

Ryan:

[16:06] I mean, it seems like the programming language is the fundamental layer, and then there’s some additional layer on top that keeps track of that stuff.

Leo:

[16:14] Good question. In Lean you have definitions that show your program, but you have theorem statements. You’re going to say, for example, factorial is always greater than or equal to zero, or something like that. Or if you add two even numbers, you get an even number. You can write statements like that, and immediately you can write actually a program that’s the proof. But most people don’t do that. They go into something called tactic mode.