Brian Kernighan was one of my most consistently requested guests and so I was excited to have him on the podcast.
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
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.
