ACM ByteCast - Russ Cox - Episode 78

Episode Date: December 2, 2025

In this episode of ACM ByteCast, Bruke Kifle hosts Russ Cox, Distinguished Engineer at Google. Previously, he was the Go language technical lead at Google, where he led the development of Go for more than a decade, with a particular focus on improving the security and reliability of using software dependencies. With Jeff Dean, he created Google Code Search, which let developers grep the world's public source code. He also worked for many years on the Plan 9 operating system from Bell Labs and holds degrees from Harvard and MIT. Russ is a member of the ACM Queue Editorial Board. In the interview, Russ details his journey from the Commodore 64 to Bell Labs, where he met Rob Pike (a co-designer of Go) and contributed to Plan 9 working alongside other legendary figures. Russ shares lessons learned while working on Google Code Search (a highly complex C++ program) and how that informed his later approach to the development and evolution of Go. They delve into the role of Go in the AI era and the future of computing. Russ also discusses the open-source community and collaboration around Go, touches on mentorship and leadership, and offers advice for aspiring builders.

This is ACM Bycast, a podcast series from the Association for Computing Machinery, the world's largest education and scientific computing society. We talk to researchers, practitioners, and innovators who are at the intersection of computing research and practice. They share their experiences, the lessons they've learned, and their own visions for the future of computing. I am your host, Brooke Kifle. In a world where software powers nearly everything we touch, the tools we use to build it have never mattered more. Few innovations have reshaped modern computing as profoundly as the GoP programming language, a language built for simplicity, speed, and scale.

Our guest today is Russ Cox. Russ is a distinguished engineer at Google. He led the development of Go for more than a decade, with a particular focus on improving the security and reliability of using software dependencies. Before that, he created Google Code Search, which led developers gripped the world. world's public source code. He also worked for many years on the Plan 9 operating system from Bell Labs and holds degrees from Harvard and MIT. Today, he works on understanding and improving the coding abilities of AI models. We'll explore his journey through some of the computing's most influential institutions and what it takes to build technology that lasts and how programming

itself might evolve in the age of AI. Russ, welcome to ACM Bycest. Thank you. It's great to be here. You know, you've had such a fascinating journey from your academic roots to your early work at Bell Labs and eventually leading the development of Google at Google. I'd love to understand some of your key inflection points that inspired your interests in computing and ultimately led you into the field and your work at Bell Labs. Yeah, so I grew up in the 80s, and so it was just a personal computer was just starting then, and my father worked at speech processing in Bell Labs, And he bought me a Commodore 64 when I was very young. It might have been something like third grade.

And I loved just typing in programs from magazines. We had a description to Run Magazine and just watching them run and trying to figure out what they did and why they were. And that sort of started from there. And then when I was in just starting high school, I think, I went to school with the son of John Bentley who wrote the Programming Pearls books and the CACM column Programming Pearls. And he worked at Bell Labs in the Computer Science Department.

and I knew him through his son, and pretty much everyone at Bell Labs then had a home computer with some kind of connection back to the labs. But in the CS department that John was in, it was also very common to make accounts for the researchers' kids. And so his son had an account, and I said, wow, how did you get that? And the next thing I knew his dad had made me an account so that I could use my dad's connection, but then get to the CS department's machines. And I spent hours just poking around, reading code, trying things. It was like the first real multi-user Unix machine that I'd used. And it was, you know, I could go read all the source code for the things we were working on. And it was just really amazing. And then after my

sophomore year of high school, John got me a summer job at Bell Labs. And, you know, looking back, it was a bit of a strange summer. The task he gave me was to write a program to summarize department expenditures. And I was working with the secretaries in the department. And I decided, since, you know, I knew Windows better than I knew Unix, that the right way to do this was to write some Microsoft Excel basic scripts inside Excel and let you do the summarization that way. And, you know, in retrospect, it was sort of fascinating for me to walk into the Department of Creative Unix and say, here, use this Windows software.

But, you know, the sort of technical chops wasn't really the point, right? John had really just engineered a reason for me to be there to get in the door to meet people and just sort of experience it all. And, you know, every day at 11.30, I had lunch with people like John and Brian Kernahan and Marinda Cherry and Doug McElroy, these like giants. And really, it was just amazing. I was in the right place at the right time and it was just a fascinating place to be. Wow, what a journey. So you said this was high school? Yeah, this was high school. This was the sort of mid to late 90s. Oh, wow. So this was quite an early start. And so how did you, once landing at Bell Labs,

how did you come to work on Plan 9 and what was that experience like? Yeah, so I was sort of stuck in a room where they had an extra desk. It was a room that was mostly, it was like four desks and it was mostly just one person who ran an OCR lab focused on optical character recognition. But every desk had this little odd-looking terminal off to the side that I wasn't using, but I looked around and passed around and eventually learned that it was for connecting to the Plan 9 system that the lab was working on. And Plan 9 was the network successor to Unix that the Unix people like Ken Thompson and Dennis

Richie and Rob Pike had moved on to trying to build in the 90s. And I asked around and eventually I got this CD, you know, handburned CD from Dennis Richie that was a plan on install CD that I could run at home. And I never quite left Bell Labs after that summer. They made an arrangement for me to be a part-time contractor working on a cable modem experiment. Back then, cable modems were just starting out. And to install a cable modem at someone's house, you actually had to get someone from the cable company to come out and run diagnostics on the actual cable and figure out the places along the line where, you know, the two different cables had been spliced together not quite well enough to carry data and then, you'll fix them. And even then you could only get

downstream. The upstream was all over modems over phone lines. And so I wrote some of the software that, you know, managed the motifs that all our upstream traffic was going back to. And so that was kind of fun. But it was, again, just sort of a reason to be there. And then I kept hanging out there. It was sort of on my way home from school. And so many afternoons, I would just go chat with people for half an hour on my way home. And I kept that connection through the end of high school and into college. And then in college, one summer, Rob Pike invited me to come back for a standard internship

to work on Plan 9 itself. And we did some graphics work. We put Porter Duff Alpha compositing into the Plan 9 graphics libraries. And then the following summer in 2000, I wrote the software, for the first open source release, and in 2002, I did the software for the second open source release, which is the one that's still running now. And so, looking back, you know, it's really kind of incredible. They let just let this high school kid show up and hang out.

You know, it was just a much less formal time. There were even times when I needed to go into the building and, like, my badge should expire and I haven't bothered to renew it yet. And I would just hold it up anyway and walk past the guard and maybe cover the date with my hand that they were fixing anyway. You could just walk in, and I was supposed to be there, so it wasn't like I was breaking there or anything, but it was just a different, more carefree time computing in the world. But the amazing thing about Bell Labs to me and the Plan 9 experience especially was

this sort of emphasis on building really simple things. You know, the people there was a small group, they were doing ambitious things, and really the best way to get those done was to start with simple things and build simple things that really were solid and work. and they also really cared about simplicity and clarity and writing. I was there for the summer of 99, and that was the summer that John Bentley was working on the second edition of Programming Pearls, and Rob Pike and Brian Cunningham were working on their book, The Practice of Programming, and I got to read and comment on drafts of both

and watch that whole process. It was just being there was really just kind of a masterclass in both programming and also just writing. Wow, that's quite remarkable. And I think, like you said, times have certainly changed. But I think it's a true testament, of course, to those who believed in you, but also your capabilities to be given so many responsibilities. We think about summer internships these days, and very rarely do you have the chance to contribute

so meaningfully to projects that shape the field. And so I think it very much speaks to your contributions as well. But that's quite interesting. I'm curious how from there you eventually found yourself at Google and how some of these core principles, we'll get into that later, but how some of these core principles are on simplicity informed how you thought about software and design. But I would love to learn a bit more about your journey since transitioning from undergrad and, you know, your academic chapter to then Google and what ultimately drew you to the Go project. Yeah. So my my path to Google from undergrad,

it went through grad school at MIT. And I'd been in this sort of Bell Labs bubble of the sort clean, simple programs. And I didn't really understand that I was in a bubble. It was just the way the world work. And then I started grad school at MIT, and that was my first exposure to sort of the complexities and horrors, really, of modern C++. And I was just incredibly taken back. The group I was in MIT was fantastic. I was working with fantastic people. And, you know, their C++ was actually very good by industry standards, but it just seems so complex. And to their credit, they were really limited by the tools they had available. This was the early 2000s. They were running FreeBSD, there were some Linux machines. At that point, you couldn't rely on the

operating system to do multi-threading correctly, which we took for granted in Plan 9, but Linux and FreeBSD still had this single big lock around the kernel. You just, you couldn't do threads reliably. And so if you wanted to do lots of concurrent network I.O, everything was async and callbacks. It was just shocking to me. It was just wow. And so like by the end of that year, I was the first year, I was pretty convinced that there was a big opportunity to do something better. And I actually wrote a bit of a rant talking about wanting to do something better that I discovered on the Internet a couple of years ago just, I'd completely forgotten about it. But one of the professors I shared it with had sort of included in a directory full of papers

that he had maybe accidentally posted to the Internet. And I stumbled across it and reread it and said, oh, okay. So I was thinking about that in like 2002. But the group I was in was doing some other things, and I ended up working on those things. In 2006, Rob Pike had moved on to Google, and he'd been bugging me to come be an intern there. And so I did that. It wasn't with Rob. He was away that summer. But that was the summer that I built Code Search. And that was a lot of fun. It was a big C++ plus program again. The C++ plus at Google was just as complex, maybe slightly higher quality than the stuff at MIT, but still just

solid, complex, you know, you understand why it's all there, but just felt really much more difficult than it needed to be. So that was my experience of, you know, C++ plus at Google and went back to grad school. And then when I was finishing up two years later in the spring of 2008, Rob and Robert Grissimer and Ken Thompson were just starting to work on Go full time. And when I was talking to different companies, they told me about Go and invited me to join them. And, you know, We were all in complete agreement that modern C++ plus, which was way more complex than needed to be. And I just jumped at the chance to go work with them.

I mean, honestly, like, I would have paid for the chance to go work with them. And instead, Google paid me. So, like, it was like a win-win for me. And it was obvious to us that you could do better, right? Because we had all been in places that did better. And it's not a knock on Google in any way, right? It's just, that was the way the industry was. And they were doing the best they could with the stuff they had.

I mean, efficiency really matters when you're running these systems at scale. And Plan 9 was not an efficient system. It was a research system. We really didn't care if it ran half the speed of a Linux system running on the same machines as far as I-O and network bandwidth or things like that. That wasn't the point. But we did have a much better development environment. And so Rob and Ken and I had all used Plan 9.

We knew better was possible. Robert had come from Module 3 in Small Talk, and he also knew that better was possible. And we wanted to bring the simplicity of those environments to the sort of complex world of Google in a way that Google could actually still use it, right? That sort of didn't have those kind of inefficiencies of Plan 9 or, you know, I don't know the reasons that Modula 3 and Smalltalk didn't take off. That wasn't my thing. But it just felt like it's some way we have seen better paths elsewhere and like let's

try to get development of Google onto a better path too. Okay, that's super interesting. So, of course, it started off as an early experiment to make programming more productive, but it seems like it was underlined by this idea of simplicity, which was informed by experiences working on other systems across Bell Labs, across other institutions. So as you think back to the core problem that you and the early team were really looking to solve, was it around simplicity? Was it around productivity? What were some of the key guiding principles that, really drove the development of Go? Yeah, it was all of those things. I think mainly we had all written large C++ programs at Google. I mean, Robin and Robert had been working there for years at that point. And I think Ken had not

maybe written the same level of C++ code at Google that Rob and Robert did. I had done the internship. And so we just never wanted to write that kind of code again. It just, enough was enough. And we knew that there was a better way. And we were pretty sure that we could bring it to engineers of Google. And mainly because Rob and Robert had had some major successes at Google building systems before, they had the kind of like credibility and runway from upper management to just,

okay, take two years and figure this out. And so the problem we wanted to solve was we wanted to build the system that would let us be happy writing programs at Google. Yeah. So solving a problem for yourself, which inevitably, you know, trickles down through the rest of the organization. And as you were scaling this project, was there a moment when you realized it was taking a life of its own beyond what was originally imagined? Yeah, I mean, there were so many moments. You know, I had worked on Plan 9 with Rob, and Plan 9 did not have many users. And so we were not used to success. We really weren't even dreaming of success. We really just wanted something that, you know, maybe some people at Google would use. Yeah. But we knew we had

to open source it. So we always had that plan. But, you know, when we were doing the open source release, Rob reminded me later that I said to him something along the lines of, well, you know, if we're all doing something different in a month, I hope that people take at least some of the ideas and use that for whatever comes next. Yeah. Like, we really were not assuming success in any way. But there really were these moments where we realized, oh, wait, there's something here. And there's been like a succession of them.

One early one was the first time that someone at Google who was using Go to build something, where we didn't know the person, we didn't know about the project. They just showed up in our office and said, hey, I can use some help on this. And it turned out they were building a MySQL load balancer that was on the critical path for all of YouTube, including the homepage. And they found Go, and they were just using it without us knowing. And, you know, that person actually told me later that they never would have written this particular program, which became the test, which is a very commonly used MySQL load

balancer now in the industry. They never would have started this project if it hadn't been for Go. because his other choices were C++ plus and Python. YouTube was all Python at the time. And Python was too slow, and he said he never would have gotten working in C++. So that was sort of one of the points where we were like, oh, you know, there's something here. And then another public one was the first big go conference in 2014. You know, they announced this conference.

We had nothing to do with it. We said we would go. And when we got there, there were 700 people in a room to talk about this thing that we created. That was really eye-opening. We were like, wow, we did that. And then just a couple months ago, the most recent sort of one of these things where you go, oh, wow, was when the TypeScript team announced that they were rewriting the TypeScript compiler and Go. Because you have Anders Halsberg, who's a giant of the computer world, or the compiler world, right? He created Turbo Pascal and Delphi and C-sharp and TypeScript. And for him to decide to move to

our programming environment for developing his language, that was pretty amazing to us. And they came and talked to us about it. After they announced it, we arranged a call where they came and presented what they were doing. And it was just so much fun to watch such amazing programmers using Go in exactly the way that we intended and just doing surprising, incredible things. You know, I mean, I think that must be the most gratifying feeling ever, right? not only seeing the community and the contribution, but also how this is being used in ways far more

than you had originally even imagined. And so I think that has to be as a builder and as a developer, that has to be one of the most satisfying parts of the job. I want to touch a bit on sort of the community and ecosystem piece, which you kind of touched on. Of course, the open source community goes open source community has been one of the most collaborative in the world. I'm curious through that experience, what you've learned about managing and sort of maintaining an open community building trust, but ultimately balancing progress with long-term stability. Yeah. I mean, building that community was a lot of work. In the early days, you know, we would go give talks to Bay Area companies because we're all in the Bay Area at the time. And, you know,

you go and give a talk to 10 or 20 people or Rob gave a talk to the Stanford Computer Science Department to maybe 30, 40 people. And you just took what you could. Robert was telling me last week that in the early days, he would go and have lunch with two or three people at another company and talk to them about Go. And that's sort of initial seeding of knowledge about Go was really important. And then we hired a developer relations engineer named Andrew Duran, and his full-time job for a couple of years was traveling around the world, bootstrapping Go Meetups. He was, you know, the first talk at a new Go meetup for many, many different meetups and

talking at conferences, not Go conferences necessarily, just. and it was a huge amount of work, but it ceded that sort of initial set of users and user communities. And that really set the tone for everything that came forward after that. And you had asked about stability and progress. And progress, yeah. So those are interesting too. Like, I think that progress can come in many forms, right? And there's kind of an unstable form of progress and a stable form. And we tried as hard as we could to find the stable forms. And usually that was by doing less than people were asking for, but still enabling them to solve their problem. So like, you know, one example would be testing system

integration. So there's a go test command. It prints the outputs of running your unit test. And one of the things people ask for inevitably is, well, can you print the same XML that J unit does so that we can use the testing system we use for our Java program? And, you know, we don't want to do that. We don't want to learn the ins and outs of that XML format. We're not experts. We're not going to be the ones who notice when it goes stale, all that sort of stuff. So what we do instead is, you know, in that case, we defined a very basic JSON, sort of machine readable JSON form that we'll print instead. And then we'll say, okay, well, you know, here's the definition of the JSON form.

We promise to keep this working. And then you can write a converter from, you know, JSON to the XML that you need. Now you can solve your problem instead of needing us to solve your problem. And so we did try to look as much as possible for solutions like that where we can do one stable thing and then let people build their own progress on top of that. ACM Bycast is available on Apple Podcasts, Google Podcasts, Podbean, Spotify, Stitcher, and Tunein. If you're enjoying this episode, please subscribe and leave us a review on your favorite platform. I think, as you said, the community has been so vibrant and fostering and nurturing that sense

of collaboration and shared ownership has been key, of course, to the success, but also the widespread adoption. I'd love to turn a bit about what you're working on these days, which I think if folks are following some of the recent progress with the innovations that we're seeing in software and AI, we're seeing a lot of productivity tools, support tools, low code, no code tools, but also coding assistance, right? And so as you mentioned some of your work in understanding and improving the coding abilities of AI models, I think that resonates to a lot of modern day software engineers. And so as you think about how the programming world

is changing rapidly with AI now, not just being a support system, but actually writing and reasoning about code, what do you see as the role of human programmers evolving in this new era? And as you think about the future of programming languages, what is the implication on how we actually design code and programming languages?

Wow, that's a big question. I am not one of the people who believes that this is, you know, a ridiculous new, unseen thing. I like to read a lot of the sort of early documents and histories of the field, and I really think that AI is on the same kind of evolutionary path that we've been on since the early days of computers. You know, one story that I believe is in George Dyson's book, Turin's Cathedral, is about the IAS machine that was built Princeton 1940s. And you programmed it by literally like connecting wires up in a way that encoded your program into the wires. And it might take you a day to load the program and then actually much less time to run it on the machine. And so that loading was like a lot of overhead.

And at some point, they realized that they could move up a level and wire up an interpreter and then have the program just be data that was fed into the machine. And they never had to rewire the machine again. And, you know, that ran a little slower, but you removed all this rewiring time. And so on balance, actually, using the machine was much faster. And then this sort of pattern repeats, right? Like in the 50s, we had Fortran, which stood for formula translation. And the big deal was like, you got to write AX squared plus BX plus C, and the compiler wrote the machine instructions for you. And so we've been making these kinds of advances for like 80 years now. And we keep moving up levels of abstractions and letting the machine take over work that we used to do ourselves.

And it's, you know, a lot of the time work that seemed fundamental and important and, like, maybe even personally satisfying to do it well. But then we hand those concerns off and we find newer and bigger things to focus on. Every time that our capabilities grow, that we, like, unload some of the work that we have to do onto the machine, our ambitions grow too, right? We're still spending as much time writing programs now as we were decades ago, and there's many more people writing programs now because it's so much more accessible. And I think AI is going to fit into that same kind of pattern where it's going to offload some things

that right now we have historically thought of as only a person could do this. And we're going to discover that actually machine can do that part just as well. And now you don't have to think about it. We're not there yet today at all. But we'll probably get there for certain kinds of things. And then, you know, we'll just focus on the next thing up the stack. And we'll focus on, oh, wow, if I have this capability, now what can I do? Right. I mean, we have these machines that are just so much more powerful that they were when I was a kid even, or not to mention, you know, that's our IIS machine. And so we have to find things to do with them. And we do, because we keep building on top of what's come before. And I think AI is going to be another one of

these things that we can build on top of and we can do even more amazing things with. So I do think it will change. If you think about the 80s when I was a kid, we had Turbo C and these little 8-bit games, right? And you look at the world today, I think you would say that the world is fundamentally different than it was in the 80s. But at the same time, there's a continuum that, you know, I live through that got us from there to now. And I think the same thing will happen with AI, right? There's this continuum that we're

going through, and it will look fundamentally different in a couple decades, but that was going to be true no matter what. If you think about just the pre-internet era and then the internet, right, like that today looks fundamentally different than it did trying to find people or find information in the 90s. And so, you know, AI is definitely going to change things, but I don't think it will be like a sudden shock kind of thing, right? I think that we will adapt and we'll find newer things to want to do. And there's still going to be a huge role for programmers and programming languages and having to decide what it is that we're going to do with these machines. And as you see some of these trends in programming, what's maybe one or two things that you find exciting or equally on

the flip side? What's maybe one or two things that you find worrisome? Yeah. So, you know, on the exciting side, I think that not having to do a lot of the grunt work that we have to do these days, that's exciting. I have a life and a family that I didn't have when I was in my 20s, and I can't spend as much time writing code. And if the AI can write code and I can still get as much done, then great. Or if the I can write code and I can just spend my time thinking about what I want to do, that's great. The ability to move up a level or something like that, we're not there yet, I don't think. But I'm excited about the idea. And another thing I'm excited about is that I really like, the AI seem pretty good at debugging right now, about just

thinking, right? We do saw the IMO math contest gold medals from Open AI and Google. And they're actually really good at reasoning. And so one game that I play recently is that if I'm programming and I have a test that's failing and I just can't see what the problem is, before I start debugging it myself, I feed the source files and a sort of explanation of the test failure into Gemini. And I say, hey, like, what's wrong here? What am I doing wrong? And it'll, you know, sit and think for three, five minutes. And while it's doing that, then I try to figure it out too. And, you know, whenever it pings that it's done, I take a look. And sometimes it's completely off base. And sometimes it figured out the thing I just figured out. And sometimes it comes

back and says, oh, it's this. And you think, oh, wow, that would have taken me another happen hour. And so, you know, it doesn't really cost me any time to run this thing in parallel. And sometimes it really speeds me up. So, you know, that's sort of a nice way to experiment and understand what they can do and what they can't. So I think there's a lot of promise there. At the same time, the sort of worrisome side, I feel like we're seeing a lot of people not thinking too much about the results that come out. And I think there's a whole variety of problems with that. The one that's maybe most relevant to go is that when we were doing the original design, we would write out the spec, which came first, and that was really important

to us, and then we would write the program to implement the spec. And when you're writing the spec, just having to write down what the meaning is forces you to keep it simple. But then when you go to implement it, if it's not simple to implement, then you also realize, oh, wait, there's something I still don't understand about this. And then you go back and and now you say, oh, okay, so in this case, I need to change this to this, so it'll be even simpler. So the implementation will be easy and simple, because if the implementation is simple, then it's usually more understandable, too. And so there's this feedback loop between the design and the implementation back to design, back to the implementation. And if you lose that, right,

if you can just hand something off and no matter what you hand off, it'll get implemented, then your designs end up worse because you didn't get that feedback to implement. improve them. And I've seen that in complete non-AI context with just people. Once the team got big enough and I would do some designs of things and then I would hand it to someone else to implement. If they didn't come back to me right away, sometimes you'd find out six months later when you look at some aspect of the code that you had in review and you go, oh, wow, that's really complicated. We should have not done that. We could have changed the design to eliminate all of this. But, you know, they were just, the design was sort of sacrosanct to

them. And they just made it work. And so I think that it's easy with the AIs to fall into that same kind of trap, or you've got something that eventually will be very good at implementing things, no matter what, no matter how hard it is. And you need some way to reestablish that feedback loop so that you can still get the simple designs coming out to you. As you're speaking, I was kind of interested what the implication of, you know, AI becoming more capable of writing and understanding code will be on the future of actual programming languages. I think back to the story of what motivated the early project of Goh was how do we bring the principles of simplicity and adaptability to this new paradigm of how we actually write software

built on some of the things that we've learned in our time about labs and previous organizations. And so having helped shape one of the most influential languages of the past decade, I'm curious what you think tomorrow's programming languages will need most to actually stay the test of time, and whether that's programming languages designed for human development or programming languages that are catered towards AI as the core user. So curious to get your thoughts on that. Yeah, it's a big question. I don't think anyone has any answers at this point.

One thing I want to say about Go is that simplicity and clarity and generality, those are all timeless and language independent things. And yeah, we were certainly aiming for those, but the goal of the language wasn't those first, right? Like the original goal of the language is really to come to grips with the sort of rise of multi-core network systems and how to program that. And that was a big challenge in the late 90s and early 2000s. And that was what Go was built to address. And then the world, we were ahead of the curve on having that problem. And the world sort of caught up with cloud and things like that. Now, pretty much everyone is writing those kinds of programs. And so Go is still very relevant. And so those kinds of shifts in

the demands on a language are what necessitate new languages. And being able to design a language specifically for those lets you restore the simplicity and the clarity and the generality that you might have lost in the earlier languages being applied to this new thing. And so, And so AI at some point is probably going to present another kind of big challenge the way that multi-core network systems were 20 years ago. But I haven't seen the big challenge yet, right? Like, there's probably room for a new language, specifically for training models, right? Like, Python is actually working remarkably well because it's so adaptable, but it's easy

to believe that you could probably do better with a custom language for that. But the whole world is not to be training models. I mean, we think there's maybe three-ish million Go developers. I don't think there's three-ish million people who need to write model training code. But there's some might be a room for a language there. I don't know what the next big thing that's going to the AI sort of evolution is going to affect that is going to create a new space here. I do think that we're going to have code for a long time. I just, I don't see code going away. I think we might move up a slightly higher level, but I think the reliability of deterministic code means that for the foreseeable future, we might have AI helping us to write the code, but the code itself, like English is not

going to become the programming language or against, you know, reinterpret it every time it runs by some AI that reads the English and then decides what to do at that moment, because it's just not reliable, right? There's too much ambiguity there. And then people talk about, well, what about a really precise form of English that the AI could use instead? And when it comes down to it, you're describing a programming language. And we've been working for decades on how precise can we be versus how informal can we be, where we're leaving out unnecessary details, but getting all the important things into the text of what we want the computer to do. And I don't see that model changing, I think it's still going to be very important to have programming languages that

people can read and people can look at and understand this is what's going to happen when the program runs. So the mistake happens. If the computer is misbehaving, you can look at and say, oh, I see why given these instructions, that's actually not the right thing to do. Or given these instructions, it really shouldn't have done that. Maybe there's a bug in the interpreter or the compiler or the hardware. Those are all, I think, fundamental interface points that are not going to go away.

So software is here to stay, nonetheless. Yeah, software is definitely. I'd love to turn me into the last section around your experience around leadership and collaboration. You've, of course, guided countless contributors through the open source community, but also members of your team,

similar to the early folks that took you under their wing. I'm sure you've taken many more under your wing as well. So what in your view has made for a great leader or mentor and those that you've looked up to, but also a great collaborator? Wow. So I think those are different things. On the collaborator side, open source is really kind of a fascinating method of program development. It's somewhat different from being in a company or on a team at a university or anything like that because anyone can show up and anyone can leave. And there's not a clear decider for disagreements, things like that.

Whereas, you know, if you're on a team, right, there's usually like one person, the professor or the company CEO or someone who ultimately can decide any problem that, you know, you have with someone else. Whereas an open source, you can't. And so open source really is not so much about programming, although obviously we're all writing programs and you have to be able to write and deep up programs. You're not going to get very far. But the biggest thing about open source is communication. You have to be, it's a social endeavor. You have to be able to work well with people, to write clearly, to talk about what you're going to do before you do it, to convince others that your approach is the right one,

to give constructive feedback without making people feel terrible, to listen to users and really hear what they're saying. All of that is arguably more important than the programming, and that is where projects see or fail. And so being a good contributor, I think, really is about working well with others and communicating well with others. And then you also asked about mentors and leaders. And I think that that's a different skill.

It's equally important. But the skill for mentors and leading is really identifying what's just beyond someone's reach right now as far as their abilities to do something. And getting them a project that's at that level so they can. grow up to that next level. And that means not doing everything yourself. It means recognizing when, oh, okay, I can let them struggle with that and figure that out, even though, you know, I could show up and just fix it. It'll be better in the long run, right, for them to develop that skill. And then ultimately, the most important final sort of exam for leaders is to step aside, right,

and say, okay, I don't even need to be here anymore. You can leave this now. And that's hard. You know, I just stepped aside from Go about a year ago, now. And I've been to go for 17 years. I've been the lead of Go for at least a decade, sort of unclear exactly when I took over. It was a gradual thing. One day I was the lead. But at least a decade. And it can be fun to do something you're good at, right? It feels safe. It feels comfortable. But projects need new ideas and new perspectives. And originally Go, Rob Pike inviting me to join Go. And at some point that didn't quite register with me at the time, like he handed it off and I was in charge all of a sudden.

And I did a more formal handoff to Austin Clements last year. This is good. This is all about making sure that projects, you know, outlive a particular person and also that you get the sort of new perspectives and ideas that they need. So all those sort of soft skills are way, way, way more important than the programming. The programming is table stakes, but once you're up at a certain level of I can get a program, I can write a program, I can debug a program, all the other sort of human skills. are more important. I think there's definitely a lot of lessons to be taken from your personal journey

and I think just hearing you call out as a leader the importance of, you know, one, as a mentor, empowering and pushing those to reach just slightly above their, what they believe to be their capabilities is what pushes folks to constantly evolve. But I think this core idea of learning when to step aside and welcome new ideas and new perspectives, I think, is a very powerful piece. So I think a lot to be drawn in different aspects or different industries or different roles. I'd love to maybe try to get some insight from you on what you see as some of the next frontier or next open areas that excite you in your respective area around software design, around program languages, around AI, but also just broadly for the future of computing,

what keeps you up at night? What are some of the things that you think are going to be the big problems of the next maybe five years. I'd love to say the next decade, but I think we all don't know where things are going. So five years alone might be a stretch. Yeah, I mean, I try not to be kept up at night. I think mostly my kids keep me up at night. If people at work tell me that, you know, some technical problem is keeping them up at night, I really strongly encourage them to disconnect. I think that's really important. But I get what you mean. And I think that we are going have to struggle with exactly how AI gets used. There's already a lot of talk about replacing people instead of making people more effective and able to do new things. And so, you know,

I think that's clearly a healthier way to approach this. And it's up to us as technologists to make that clear. There's also questions around AI and how people learn new skills, right? So if AI can handle the work that college grads do for the first two or three years that they're out of college in a job, and then they don't get those experiences, right? How did they become the people who are more senior? Because making those, like I was talking about with the mentorship, being growing and struggling, and that's how you learn what to do next. And so it is important that we don't use AI to just eliminate. all the starting jobs because if people can't start, they can't grow to be the next generation of leaders. So we are going to have to figure that out. But again, I think AI can also just play

a very positive role of making us better at things. And someone just starting out now has more abilities than they did when they were, you know, someone starting out 10 years ago. And there's still things for them to learn around all the sort of social aspects of coding. And also AI can write code and it can be bad code and spend time debugging it and that's a learning experience. So I do think there are positive ways to approach all of this and I think it's mainly up to us to advocate for the positive ways and try to advocate against dystopian ways that sometimes are in the news. And I think we have a lot of folks with all this podcast who are potentially interested in pursuing a career in computing or in the early

stages of their career. And I think there's a lot of inspiration to be drawn from your journey in really building something that is impactful and truly less. And so what advice would you give to aspiring computing professionals, builders who want to create something that last and is really rooted in some of the core principles that have driven your personal career? It's a great question. I think the one thing is to just really take the time to understand the problem that you're trying to solve and how best to solve it. I think a lot of the time, it's easy to just take the first thing that works and move on. And a lot of the things that I've done have come from looking at it again and feeling like, oh, actually, I don't think I

understand this quite well enough yet. I should try this again, or I should dig into is something that's bothering me about this solution, and then discover, oh, actually, like, there's an important detail I missed, and this could be simpler or this doesn't need this level of complexity. And so paying attention to those kind of doubts about whether it's right and developing that sense, I think is really important. Another thing is just finding an environment where you're excited to work on something, because if you're excited to do something and you wake up in the morning, you wake up in the morning,

and wanting to continue doing it, you're just going to get so much more done than if you're just doing it because you have to put in eight hours and then go do something else. And so we're in a field where we're really lucky that jobs exist where we can really go after

those kinds of things. Like I said before, I would have paid for the chance to go hang out with Rob Pike and Ken Thompson for a few years at the beginning of my Google career. I mean, Ken was my office mate for the two years that I lived in California, and it was just fantastic. And so you can't necessarily get that lucky.

But finding something that you're excited to go do every day, I really loved getting up every morning and working on Go, especially in the early days, where, you know, it felt like a blank slate, and we were solving real problems and really making a difference and really felt like we were making quick progress. And that was really a great time. towards the end of go, I was spending more of my time on administrative things. And that was important too, right? That kind of leadership is really a service job. It's really important to have good people doing it and that it gets done well. But it wasn't the same kind of like

I'm really excited to get out of bed in the morning and go do those things. And so, you know, it is important to go find the things that really, really motivate you. And it doesn't have to be as general as programming either. I was talking to a college student the other day about this kind of question, and he said he was really enthusiastic about the environment. He was a computer science major, and I said, great, like, there's lots of ways that technology can help us address or answer environmental questions, right? Like, find a way to mix those two so that, you know, you can take the thing you're really excited about and then add a computing bent to it. And computing touches literally everything now. And so whatever you're excited about,

bring those skills and have at it. I think that's beautiful. So really take the time to understand the problem and find an environment that excites you. Ultimately, if you find something you're passionate about, you'll never work a day in your life is what they commonly say. So Russ, thank you so much for joining us. I think we're excited by all your contributions, but also your leadership. And I think we'll find great inspiration and many folks in the career path and contributions that you've had. So thank you so much for joining us on BICAST. Thanks very much. This is fun. Cheers. ACM Bytecast is a production of the Association for Computing Machinery's Practitioner Board.

To learn more about ACM and its activities, visit acm.org. For more information about this and other episodes, please visit our website at learning.acm.org.org. B-Y-T-E-C-A-S-T. That's learning.acm.org slash bikecast.