Boris Cherny is the Creator of Claude Code but few people know his full career story. I interviewed him about everything he learned growing at Meta and for insights from his time building Claude Code at Anthropic.
Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.
Timestamps
00:09:43 - Early side projects and book rec
00:17:05 - Being under leveled
00:18:55 - Staff (IC6) promo story
00:25:19 - Proximity to leadership learnings
00:29:36 - Scoping out work for 100s of engs
00:35:31 - Senior Staff (IC7) promo story
00:44:39 - How to find side projects
00:50:45 - Principal (IC8) promo story
00:54:20 - Building credibility in a new org
01:10:05 - Why Claude Code succeeded
01:15:56 - Claude Code use outside of code
01:17:22 - What he thinks of competition
01:22:57 - Advice for his younger self
Transcript
00:00:59 — Starting at FB
Ryan:
[00:00:59] I wanted to start at the beginning of your story with you getting promoted to senior engineer at Meta. What’s the story behind the projects that got you promoted, and where were you at the time?
Boris:
[00:01:11] If I remember right, the project was Chats in Groups. And this was a project to bring Messenger and Facebook a little bit closer together.
[00:01:18] The first few projects that I worked on at Meta were about Messenger and Facebook. The first one was Zuck had this idea about syncing Messenger chats and Facebook groups. There were a few of these projects just trying to bring Messenger and Facebook closer together.
[00:01:36] The motivation was this feeling that the public space social product was disappearing and that things were moving more into chat and these more casual real-time spaces. We tried a few versions of the product, and Chats and Groups is the one that worked.
[00:01:52] I think it was number three or number four at the time. I was in the Facebook Groups org at the time, working a lot with Messenger, which was organizationally very distant. This was an idea that Steve, who was a PM at the time, had. I picked up on that and was like, yeah, hell yeah. Let’s do this. I started hacking on it. Pretty soon there were signs of life, so I asked for more engineers, and three engineers joined
[00:02:28] We got some data science support and design support. It started on web, then we also moved to mobile a little bit. We proved out this idea that you can have chats inside of Facebook Groups and that this kind of product can work. There was a lot of stuff that didn’t work at all about it.
[00:02:49] It was a super janky experience by modern product standards. Back in the day, everyone was building on web, and all sorts of bugs were totally okay. Nowadays, the visual and quality standards are a lot higher. The product grew, and we were such a small team that everyone had to do everything.
[00:03:08] I remember we didn’t have a user researcher, so I would go to the cafeteria during lunch. We would have a new feature, and we would show the cafeteria workers the feature and ask them if they could figure out how to open a chat. Sometimes they would find it, sometimes they wouldn’t.
[00:03:23] This was an observational user research study. You could see how people in a particular situation could do a task without prompting them too much. You could see where they struggled and what they got. I taught the team how to do this, and soon we would all go to the cafeteria at lunch and start asking cafeteria workers, as representative users, if this made sense or not.
Ryan:
[00:03:48] It’s interesting how the early Facebook culture that you were operating in let engineers do so much outside of just the code.
[00:03:58] For instance, you were doing UXR (user research). I remember in your story you did some design as well and you were coaching people to do design. I think that’s a pretty interesting, unique thing in Facebook’s culture.
Boris:
[00:04:11] I think this is so important. To this day, on the Claude team, which is the team that I’m on right now, we really prioritize generalists.
[00:04:20] I love working with generalists. If you’re an engineer that codes but can also do product work, design, and have product sense, you want to talk to your users. I love this kind of engineer to work with. This is how we recruit for all functions now. Our product managers code, our data scientists code, and our user researchers code a little bit.
[00:04:41] I just love these generalists. This is really how I grew up. From the beginning, when I was running my first startup at 18, I had to do everything. Up until Facebook, I worked at smaller companies where you had to do everything. At big companies, you get forced into a particular swim lane, but it is just sort of official because engineering is a very narrow skill set. The thing you’re doing is building product or building infrastructure, and there’s so much more that goes into doing that end to end besides just writing code. It was really cool being at a place that uniquely rewarded that at that time.
[00:05:19] I think at the end of that half, I got promoted, and then I think that half after every single one of the engineers got promoted too.
Ryan:
[00:05:25] In those early products, there was this concept of latent demand that you mentioned a few times, which was the impetus for a lot of those product directions.
[00:05:38] Can you explain latent demand?
Boris:
[00:05:40] Latent demand is the single most important principle in product. If you look at Facebook’s successful products, every single one has an element of latent demand. For example, Marketplace came from the observation that if you looked at Facebook Groups at the time, 40% of the posts were buying and selling stuff.
[00:06:00] Facebook Groups were not designed for commerce, but that’s what people were using them for. You design this product in a way that can be hacked and abused by users a little bit. Then you look at the data, see how they’re abusing it, and build a product around it.
[00:06:16] There were Facebook Groups and then buy-sell groups. That exceeded because people already wanted to buy and sell and do commerce on Facebook Groups. Marketplace was next. It was just a natural extension of the same intent that people had. Facebook Dating was pretty similar.
[00:06:32] The observation was something like 60% of profile views were people of the opposite gender that were not friends with each other. This traditional creeping on each other was evidence that this would work.
[00:06:48] The principle in product is you can never get people to do something they do not yet do. You can find the intent they have and steer it to let them better capitalize on that intent and do what they want more easily.
Ryan:
[00:07:06] At this part of your story, you mentioned that you worked across orgs because you were bridging the gaps between Messenger and a lot of the Groups engineering work. You said that there were some clear cultural differences and that was difficult. Do you have any advice for working across very different culture orgs?
Boris:
[00:07:29] Oh my god, difficult is such an understatement. It was a nightmare. For Facebook at the time, we wanted to ship awesome products as fast as we could. Messenger was all about reliability and performance. That’s all they cared about. It was just polar opposite values.
[00:07:45] This isn’t just cultural; it’s not just an engineer-to-engineer thing. The engineers on that team were suspicious of us because we would affect their performance metrics. Their org was set up to ship slowly without regressing the metrics, while we were set up to ship quickly.
[00:08:01] The goals were totally different. They had SLA uptimes, and for us, it was just about daily active users and engagement. These cultural values go super deep. It’s not just something people talk about; you can see this in org design, goal design, and every part of everything.
[00:08:22] One of the reasons that project failed, and eventually evolved into something successful, was because of this difference in values. If you want companies with really different values to succeed and work together, you have to find some kind of shared goal or shared interest, shared belief, or hypothesis that they want to test together that would be interesting for both of them if it worked.
[00:08:54] The Chats and Groups thing was really cool for Facebook, but it’s not that cool for Messenger for a lot of reasons.
Ryan:
[00:09:02] So knowing what you know now, how would you change things?
Boris:
[00:09:08] I probably would’ve gone to Zuck and just been like, if you’re really serious about this thing, we should move Messenger into the Facebook org.
[00:09:15] And I think this has since happened. Messenger was in the org, then it moved out, and then it moved in, then it moved out. It’s a big company; this happens. But I think fundamentally for this kind of thing to succeed, the common manager can’t be like Chris Cox.
[00:09:32] It has to be a little bit lower down. You can structure the orgs to be a little bit more cooperative.
Ryan:
[00:09:37] At this point in your career, I saw there were a bunch of really interesting side projects that you had, and I’m kind of curious what the butterfly effect of those kinds of projects is.
[00:09:53] For instance, even before you got to Meta, you worked on UCS, the state management framework for React. I’m curious how that impacted your career, if at all.
Boris:
[00:10:06] Yeah, for me, side quests are so important. When I hire engineers, this is definitely something I look for. I want people with side quests, like cool weekend projects.
[00:10:16] Even someone that’s really into making kombucha. You want people that are generally curious and interested in stuff outside of their main work. These are well-rounded people. These are the kinds of people I enjoy working with. A lot of my growth came from working on these side projects.
[00:10:36] Something like Undux, honestly working from React state management is unnecessarily complicated. At the time, the state of the art was Flux and then there was this other thing called Redux, and I just couldn’t wrap my head around Redux. I consider myself an average engineer.
[00:10:55] I build product; I’m not one of these incredible systems engineers. For me, Redux at the time had concepts like reducers and a very complicated flow to just update a little state. I just couldn’t wrap my head around it.
[00:11:10] So I built a simpler thing that seemed to work. I was volunteering at a nonprofit at the time, and they started using it, and their engineers liked it. When I joined Facebook, I saw a lot of frustration around Redux usage because there was an internal group for people that used Redux, and there were all these questions where people were asking the same questions I did.
[00:11:32] When you as an engineer or as a product person run into a problem, sometimes it’s just you; often it’s other people too. I think it’s important to build the spidey sense for when this problem might be shared by others. This was a problem that definitely was shared by others, and I could see this in support posts.
[00:11:50] I launched Undux internally. It’s fine; it’s not that great of a product, but at least it’s better than Redux. At Facebook, I didn’t know how to get adoption, so I posted about it. A few people started to use it.
[00:12:07] I remember Jeff Case on the notifications team was a big early adopter, and we spent some late nights debugging some gnarly notification-related bugs due to it. I wanted to get more adoption, so I wrote a little script and scraped the group of people reporting issues and tallied them by team.
[00:12:28] I reached out over chat to the tech lead and the manager for every team and scheduled a tech talk just for that team. Overall, I did maybe 20, 30, 40 tech talks over the course of a few weeks. I remember biking around the Meta campus doing these talks, and it was so fun because people were so engaged and excited that someone cared about solving this problem.
[00:12:54] At some point, Undux was the most popular state management framework at Facebook. Then it got quickly replaced by Recoil and more modern alternatives. Nowadays, it’s Relay and things like that.
Ryan:
[00:13:07] Does that kind of side project appear in your performance review or help you in some way?
Boris:
[00:13:13] I think it was in my performance review. By Meta standards, it’s kind of a cherry on top. It wasn’t really something that gets you to the next level in itself. I had a lot of other side quests around that time too. At some point, I got really into TypeScript.
[00:13:27] This was at the previous company I was at. We were using it. There weren’t a lot of good resources, so I started writing a book about it because someone should do this. It’s crazy; it doesn’t exist. This language is just magnificent. It has really good design with ideas that no other language had at the time.
[00:13:44] Things like conditional types, literal types for everything, map types. They are just absolutely insane. Even the gnarliest Haskeller is going to be impressed by this kind of language feature, but no one was writing about this stuff.
[00:14:08] I got super into it and wrote this book, and it just sort of ate up a year of my life. I would not recommend it, but it was really fun to go deep on it. I also started the world’s biggest TypeScript meetup at the time in San Francisco.
[00:14:23] That was a really cool chance to meet Ryan Dahl, who created Node.js, and all these famous JavaScript celebrities. It made me realize all these people are just people; everyone builds cool stuff. Some of it’s cool, some of it’s cool at a particular time, but it’s all just people, and anyone can do this stuff.
Ryan:
[00:14:45] Did you end up using TypeScript or that technical depth later in your time at Meta or maybe even in Anthropic?
Boris:
[00:14:52] Yeah, it’s funny; I actually used to not care about languages. At some point, maybe 10 years ago, I used to ride a motorcycle and got in a pretty bad accident.
[00:15:02] I broke both my arms. I had two slings on.
Ryan:
[00:15:06] Oh my God. How’d you code?
Boris:
[00:15:08] That was the hard part. I couldn’t code for a month, and my hands still kind of hurt. I couldn’t write JavaScript, which is what I used to write at the time.
[00:15:18] I had to branch out and learn other languages because they literally used fewer keystrokes. I started with CoffeeScript because it had fewer parentheses. I don’t think that language even exists; no one uses it nowadays. That’s also how I got into Haskell and functional programming.
[00:15:34] You can do the same thing with fewer keystrokes, and that was literally the motivation at the time. I was working at a hedge fund before Facebook, and I had a coworker, Rick, who was really into Scala. I really didn’t understand Scala, but he got me into it and the functional programming side of the house.
[00:15:52] The one technical book I would recommend to everyone that has had the greatest impact on me as an engineer is called Functional Programming in Scala. You’re probably never going to use Scala day-to-day, but the way it teaches you to think about coding problems is a change from the way most people code, either practically or in school. It’s incredible.
[00:16:21] It’s going to completely change the way you code. For me, Scala was like Haskell and CoffeeScript, these few theoretical languages. That was a first step, then Scala, and then TypeScript. This changed the way I think because now I think in types when I code. The thing that matters in your code the most is the type signatures.
[00:16:43] This is more important than the code itself. Getting this right leads to very clean code. Even at Facebook, where I was writing mostly Flow and Hack, and later on Instagram, Python, it was very helpful. Here at Anthropic, I mostly write TypeScript and Python, so it’s quite relevant.
[00:17:00] The bigger lesson is just thinking in types.
00:17:05 — Being under leveled
Ryan:
[00:17:05] At this point in your career, you mentioned that you came in under leveled as a mid-level engineer, even though you had a lot of experience. You said in hindsight you were lucky to be under leveled. I’m curious about the thinking behind that.
Boris:
[00:17:21] At a big company, there are all these expectations in terms of project impact and people impact. The specific criteria are different across companies.
[00:17:41] A lot of it is about either project impact or checking a bunch of boxes, and all this takes a lot of time. Coming in under leveled gave me the space to explore and just build cool stuff for the sake of building cool stuff.
Ryan:
[00:18:00] Definitely. I wonder if it also helps with building momentum. If you came in as a mid-level or E4 and then you were crushing it, everyone would say Boris is amazing. This is crazy. As opposed to if you came in at your expected level and did okay. There can be an effect when you come in and really wow everyone; you have such a strong first impression. I think that can be helpful for building a good reputation that gives you more credibility, more projects, and stuff like that in the future.
Boris:
[00:18:40] Yeah, I think that’s totally true. This is probably good advice for any company. A lot of times engineers switch jobs and they really push, like, I want to go to a different company and I want a level plus one or whatever. There are a lot of downsides to that.
00:18:55 — Staff (IC6) promo story
Ryan:
[00:18:55] Going on to the thing that got you promoted to staff or E6 at Meta, I’m curious about the story behind where you were at the time and what got you promoted into more of that leadership position.
Boris:
[00:19:06] What was happening was chats in groups were launched, and there was a team working on this. I had done a lot of JavaScript before I joined, but at Facebook, I had never actually written JavaScript because it was all PHP. I really just wanted to write JavaScript. We had this web interface for Facebook groups in particular. A lot of people use web as opposed to mobile because, for example, being a group admin is just easier to do on a big computer with a keyboard.
[00:19:43] At the time, the site was really janky. It was a static site, all PHP, with little bits of JavaScript injected in different places. There were all sorts of inconsistent states and problems that came out of it. It didn’t feel like a good UX.
[00:19:57] I wanted to rewrite it in JavaScript, but I got a lot of pushback from the org at the time. The big reason was that the infra just wasn’t really ready for it. Luckily, at the same time, Comet was starting, which was the rewrite of facebook.com on desktop.
[00:20:18] There were a bunch of core people working on this, and I really wanted to be involved. I reached out and asked how I could help, offering Facebook groups as the guinea pig for it. I didn’t ask anyone; I just did it. Later, I went to my leadership in Facebook groups and said, “Hey, Comet’s coming.
[00:20:37] It’s going to be a bunch of work, or we can get ahead of it, set the standard for everyone, and build relationships with these other teams.” I still got pushback, like, “Hey, you can’t put 20 engineers on this.” After a bunch of reviews and haggling for engineers, we got about 12 engineers because it was a pretty big migration.
[00:20:54] It was going to take about a year. Groups is the single biggest product surface in all of Facebook, which is kind of surprising. The migration worked, and something fun about it, besides building relationships and friendships with this infra team, was that we got to influence the direction of Comet.
[00:21:16] For an infra project, a product team often cannot influence the direction; they’re more seen as a customer of it. But here, because we helped build it, we created a lot of the abstractions that were then used by other teams also building on Comet. For example, a particular one I remember was relay mutations. You send API requests and need some sort of consistency. There was a bug where, let’s say there’s a button, and every time you press it, you send a POST request. Each time you press the button, it toggles the state of that button for a nice UX.
[00:21:57] What you want is for the state to toggle as soon as you press the button, which means you need an optimistic update. When the network request comes back, you also need to update the local cache to ensure consistency. If you’re mashing that button, the responses can come in out of order, and you might end up with a different state than what was in the UI.
[00:22:16] I wrote a system to queue up mutations, so it was consistency at the cost of reliability. This was the right trade-off at the time, and everyone ended up using it. This is how I met Joseph and a bunch of the relay team working on the data stores. It was really fun. Whenever I work with engineers, I love when people go a layer deeper and try to figure out what’s going on. Just because you’re a product engineer doesn’t mean you can’t build infra. Just because you’re an infra engineer doesn’t mean you can’t talk to users. Just be curious about these other parts of the stack.
Ryan:
[00:22:53] Definitely. In your agency and getting ahead of Comet or this big JavaScript rewrite, you mentioned in your writing that getting ahead of that actually gave you a lot more control and dibs on opportunities. When you talk about opportunities, is this what you’re referring to, like building these fundamental pieces of product infra that are impactful for everyone taking on the new platform?
Boris:
[00:23:19] Yeah, that’s an example of it. A different kind of example is that Comet was a lot higher quality than the thing that came before because it’s a single-page web app, so it feels a lot more polished. But we hadn’t yet figured out what exactly quality means on the product side. I wrote a bunch of notes trying to define that and did a bunch of talks to teach people on other teams what we’ve learned about quality, setting up the conversation about that.
Ryan:
[00:23:48] You mentioned a big headcount ask for the migration to Comet. I’d be curious what that would look like today with new tools like Claude Code, Codex, etc. Knowing what you know now about Claude Code, if you were in charge of scoping that same job, how many engineers do you think it would take to do that 12-engineer job?
Boris:
[00:24:16] To move Facebook groups, it started with 12 engineers, but I think at the end it was maybe 20 or 30 engineers for about two years. It turned out to be a pretty big project. Nowadays, it would be maybe five engineers for six months, something like that.
Ryan:
[00:24:34] So a fourth of the time and less than a third of the engineers as well.
Boris:
[00:24:42] Yeah, because everyone would have a bunch of Claudes running in parallel. You’d let it cook for a couple of hours, and then it would come back with a PR. You’d give it Puppeteer or something so it could see the UI and adjust. I think that’s pretty much all it would be. Nowadays, the world we’re in is so different from a coding point of view because the models are moving so quickly. If you ask me this question in three months or six months, my answer will be totally different. In six months, the answer might be that this is actually one engineer. It’s just moving so quickly now. It’s really hard to do these estimates or predict how they’re going to change in the future.
00:25:19 — Proximity to leadership learnings
Ryan:
[00:25:19] At this point in your career, you mentioned something, maybe it was tongue in cheek, that this was when you learned to always present three options in VP reviews. Since 80% of the time they’ll just pick the middle option. What’s the thinking behind that?
Boris:
[00:25:40] This is very much tongue in cheek, but maybe this is actually kind of true at Meta at the time. Decision-makers that are far away from the work want to know that you did the due diligence of finding the right options and trade-offs and that you did the work, but they also want to contribute somehow to the decision. The middle option is kind of the easy way to do that. It’s a little tongue in cheek because not all leaders are like this. A lot of leaders will do the work themselves; they trust their teams more or less. There are so many different ways to operate. At the time, I remember we had a pretty non-technical leader, and this was kind of the way to help her make decisions.
Ryan:
[00:26:23] At this point in your career, you had the most proximity to senior management. You said you were reporting to a senior director at some point, and you were involved in a lot of huge scoping conversations. I’m curious about the downstream effects of reporting to someone so senior like that.
Boris:
[00:26:41] Yeah, I think it kind of depends on the engineer and the company. So for example, now I’m at Anthropic, and I think at Anthropic it doesn’t matter which level you report to. Some of the most senior people at the company report to line managers.
[00:26:57] A lot of the line managers are like ex-CTOs and things like this. So it actually doesn’t matter. I think this is kind of like a Meta-specific cultural observation. I think there are sort of two things going on. One is, at Meta, you needed to find scope.
[00:27:20] Some of this you can find yourself, and then some of it your manager helps you find, or your tech leader, the people you surround yourself with. The PSC process is famously grueling at Meta, and you just have to constantly talk about your impact. Scope is the biggest contributor to that.
[00:27:36] If you have enough scope and you execute it well, that’s impact. That’s the formula. I think the other part was at Meta, no one had titles. Even the most senior engineers had the title of software engineer, which I really love. Bell Labs had this with member of technical staff, and this is true at Anthropic too, but we actually go even further here.
[00:27:58] Everyone’s title is member of technical staff. It doesn’t even matter if you’re an engineer, PM, or designer; it’s all the same title. I actually really love it because back to this point of working outside your lane and doing things that should be done, regardless of what you are personally expected to do.
[00:28:19] I think this kind of culture just sets that up.
Ryan:
[00:28:22] I see a lot of the benefits of the no titles. I could also see a case where, and maybe this is only true for big companies, where you reach out to someone across the company and say, “Hey, I’d like to do this collaboration,” and if your title said director or whatever, it kind of is a shortcut for them to understand how seriously to take you or how to interact with you.
[00:28:48] If you’re a designer or some other role. Now Anthropic has gotten a bit bigger at this point. Do you see any of that? People probably all know you, so maybe you don’t see as much.
Boris:
[00:28:59] Yeah, I think this is definitely the downside. I think the upside outweighs it, which is you have to earn it.
[00:29:06] I think this is true regardless of what company you’re at; you gotta earn it. Just because you did a cool thing before doesn’t mean you deserve respect. Well, everyone deserves respect; it doesn’t mean you deserve authority at a new company in a new setting.
[00:29:22] Even for people coming in with manager titles, you kind of have to earn it. In some ways, having a manager title makes it a little bit harder to earn this kind of trust. As an IC, you gotta do it either way. I think just the lack of titles makes it a little easier.
00:29:36 — Scoping out work for 100s of engs
Ryan:
[00:29:36] At this point in your career, you were becoming more of a tech lead or uber tech lead, and I think you had a few stories where you scoped out work for hundreds of engineers. How do you do that? If there’s so much to scope and you’re one person, how do you go about doing such massive scoping requests for leadership?
Boris:
[00:30:01] Yeah, this was a totally insane time. I worked a lot with Tina Suchman, who’s now at Microsoft, but she was my manager at the time.
[00:30:08] And then Ife, who was my manager after. There was a lot more investment going into Facebook Groups at the time. I think the org was maybe 150 or 200 people when I joined, and by the time I left for Instagram, I think it was like 600 or 800 people. There was this feeling from Zuck that the Facebook app should be all about communities, and he just wanted us to go faster to make that a reality.
[00:30:35] As an executive, your biggest way to do that is to put the right people in charge of decisions and then give them resources. In the case of Meta, it’s just engineers. You don’t need GPUs for this; you need engineers to do stuff. We pitched this project to Zuck called Communities as the New Organizations.
[00:30:55] That was the internal name. He granted a bunch of headcount to go towards this, and we just had to figure out what these people would do. For him, if the thing is important, you gotta put a bunch of people on it. In hindsight, what I would’ve done differently is put way fewer people on it because what matters is solving people’s problems and building awesome products.
[00:31:17] This actually has to be bottoms up, and you want to slowly dial this up as you find product-market fit for new product lines. You can’t just do it all at once. We just had to scope out all this stuff. There were weeks where I had to do a scoping doc for like, “Okay, we’re gonna put 30 engineers on this. Here are three technical options. We’re gonna pick this one. Next project, we’re gonna put 20 engineers on this. Here are three options. We’re gonna pick this one.” Just doing this over and over again to have some sort of confidence that this thing isn’t totally crazy.
[00:31:48] We did some baseline technical scoping, roughly matching the number of engineers to the project. There were some pretty fun things. I remember we were trying to merge Facebook Groups and Pages at some point, like in the data model side. This was a very gnarly migration.
[00:32:04] To fully do it, this would take many years and probably hundreds of engineers because you have to do it across the data model, product layer, integrity systems, and ad systems. At the time, Yosef Carver had just joined; I think he came from either Profile or Events, a different org that joined forces with Groups to make this happen.
[00:32:27] He was working on it but struggling with a decision at the time. I think he was even more senior than I was, but he just wasn’t making the decision on the data model. I took a bunch of people and said, “All right, all the tech leads across the entire org, we’re gonna spend the next three hours on this day, and we’re gonna do this essentially like a game where we get to do architecture.”
[00:32:40] I split everyone up into two teams. I think it was like blue team and green team, or I forget what they were. We gave everyone this problem of how to merge these data models. Here are the requirements. Everyone had three hours on a whiteboard to come up with a design. What was cool is that going into it, we had no idea how we would do this because it seemed too crazy of a problem. But coming out of it, we had two designs that were 80% the same.
[00:33:14] It was really obvious what we could execute on, and the 20% differences were very obvious where the risk was. We could front-load a little bit of that risk with some technical spikes, but we could also start execution right away because we knew exactly what we had to do.
Ryan:
[00:33:29] Yeah, that was really interesting when I saw that it was like a technical design competition with all the senior engineers, and you just put people in separate rooms to come up with. I’ve never heard anything like that. When you proposed that idea for this design competition within the org, were people excited about it or was it kind of a crazy idea?
Boris:
[00:33:51] Yeah, it was sort of crazy. With this sort of thing, you just have to do it. I just told everyone, “Hey, we’re doing this,” and then I put it on everyone’s calendar. It just seemed fun; as an engineer, you would want to do it. But sometimes you need consensus, and sometimes you just have to act.
[00:34:08] In this case, because the path wasn’t clear, it was important to act, but at the same time, I didn’t know how to proceed, so we had to get everyone together to build consensus. As a leader, you’re kind of always juggling these two things.
Ryan:
[00:34:20] After that experience, just being given hundreds of engineers and scoping things out, do you have any tips for someone who’s a tech lead who needs to do quick scoping? Anything that worked well for you?
Boris:
[00:34:34] I think the biggest thing I’ve seen is people taking too long and getting too into the weeds. There’s always an infinite number of details. Just start with a high level. Most technical scoping you can do within 30 minutes, very roughly.
[00:34:48] If you don’t know the systems, nowadays, you would just use code, run in the codebase, and ask it, “What are all the systems involved?” It can actually do this for you. This is another totally insane change. When I was doing this stuff, I never would’ve expected that AI could do this for me now.
[00:35:05] But now it does. In the past, I think that would’ve been my biggest advice: just time box it. Spend maybe 30 minutes, maybe a couple of hours max if you have to dig through code. Definitely reach out to experts and make a list of experts. Talk to all of them. Run the design by them.
[00:35:25] Don’t just ask them for input. Give them a straw man because then they can actually give you feedback on it, and it’s something to go off of.
00:35:31 — Senior Staff (IC7) promo story
Ryan:
[00:35:31] Continuing with your career story, I think the thing that got you promoted to senior staff or IC7 was public groups on Facebook. I’m curious about the story behind your involvement in that and anything interesting that happened at that point?
Boris:
[00:35:46] Yeah, so public groups was one of these projects that came out of this scoping for making Facebook Groups more about communities. There’s this one very narrow change that we wanted to make that seems so simple on the surface, but it was so complex under it, and it’s just funny explaining this to anyone that wasn’t there.
[00:36:02] They’re like, wait, this is like a one line change. And I’m like, no, it’s not. It was very difficult to pull it off. And so the change was, in order to participate in a public Facebook group, you no longer have to join first.
Ryan:
[00:36:14] So you’re saying you can just view like you have read access for all groups essentially, or public groups.
Boris:
[00:36:21] Read access for all groups and for some groups even comment access, so you can comment without joining first.
Ryan:
[00:36:27] Mm. Interesting.
Boris:
[00:36:28] And this is a thing, it feels like a one mind change and actually was a one line change, but there are all these downstream implications that were so tricky. One is, in the data model there’s essentially a field in the database that was like group member.
[00:36:41] We had this really intense technical debate about whether these people that are commenting in a group are group members. The model also changed where before to join a Facebook group an admin had to approve you, so there’s kind of a vote of confidence that you can be in this group. After we switched to this model where to join a public Facebook group, you just essentially press like follow.
[00:37:04] We actually went back and forth should it be join or follow? What’s the right verb to describe this? But it was essentially follow ‘cause there’s no reciprocal action. If you follow a group, are you a member? Should you be stored in that same part of the database? We just went back and forth on this for a while and I remember at the time there was this really senior engineer Bob, he was kind of the most senior engineer in the org at the time.
[00:37:26] He felt very strongly that it should not be the same thing. He pushed us pretty hard, even though it would be a ton of engineering work to migrate stuff to make it a different thing. We did this work because he was actually one of the early engineers on Facebook Groups, so he knew it really well.
[00:37:42] He felt pretty strongly. There were a bunch of these other downstream changes around moderation and different new admin tooling that admins would need to handle the influx of spam and things like this. I remember at the time thinking if anyone can make a comment, the comments are just gonna be filled up with spam.
[00:37:59] I had a hard time convincing people of this. At some point I built this Monte Carlo visualization of how this would work. It was just this really simple scratch pad of, you know, a comment comes in, there’s a certain probability of it being good or bad, and then what actually happens to comments.
[00:38:16] I think they actually did a pretty good job of convincing the integrity teams to jump in and help with this. At the time, the Pages Integrity team jumped in and they helped with comment ranking because ranking spam comments slower was the main technical mechanism to make it so people don’t see these comments.
[00:38:32] There are a bunch of these pretty gnarly downstream implications of letting people participate. There’s also this data model migration that we’re doing. To do all this, we had to staff a big team to make this happen. We hired a new director, Yaman, who hired a bunch of engineers.
[00:38:48] There were a bunch of internal transfers. Some of the most senior engineers from the org, like Henry Long, Joe Hum, and a few other engineers were all working on this. I was the same level as them, I was an IC6 at the time. I remember just feeling this kind of imposter syndrome of having to direct them and point them at work knowing in my mind that we’re the same level, even though levels are hidden. You know through rumors and stuff, who’s what. In hindsight, I think this was sort of misplaced imposter syndrome because levels don’t matter at all.
[00:39:27] This is my current view. Some people that are very junior can shoot way higher than that and just give you amazing results. Some people that are very senior can give you terrible results, so the level actually doesn’t matter that much. At the time, I remember just really thinking about this and it was hard to step into this role and eventually I did it.
[00:39:43] Eventually the thing that got me the promo to IC7 was reversing this decision that Bob did. He wanted to do this big migration, and we did it. It was so much work. It was like six months or a year of work or something, just migrating hundreds and hundreds of call sites to do this correctly.
[00:40:09] Technically, I felt like what we did is we essentially just added an if statement at every single one of these call sites. In the process, we audited all the call sites. We knew that it was safe, but we didn’t actually change the logic. What we’ve learned is that yes, member is the right field to model both followers and group members.
[00:40:27] This was the right decision, and so I pushed the same engineer that did this to then undo it. It was the right thing to push this engineer because it showed maturity on his part that he said yes and was able to do it. He also had the most context technically, so he could do it the best. I think for Bob, it made him feel better about me as a technical leader because he knew that I was willing to push back on decisions that even senior folks make. In the end, this was the right thing. We reversed the migration. It also took a long time to do it, but in the end it made it so everyone building on this infra could do it, and everyone wasn’t always constantly bumping into this should I use this field or this field?
Ryan:
[00:41:13] Yeah. I’m curious about that part ‘cause you had a strong technical disagreement with Bob or Senior TL. The outcome at the end seems like it strengthened the relationship. He was a champion for you in your promotion. I’m curious, how would you recommend going about strong technical disagreement in a way that doesn’t hurt the relationship?
Boris:
[00:41:37] I think the biggest thing is you have to earn it. You just have to earn trust. It could be as simple as what I did at the beginning, which is just disagree in committing and showing that I’m willing to do that and I’m willing to execute if someone else thinks it’s a good idea and I kind of look up to them.
But you also have to show that you have good technical judgment. You can’t really do that until you’ve earned trust. So take the time to get that trust first.
Ryan:
[00:42:03] And then on the imposter syndrome, leading those engineers that were also very strong. Do you have any advice for overcoming imposter syndrome?
Boris:
[00:42:12] Yeah, just don’t overthink it. No one really knows what they’re doing at any level. We’re all just trying to figure it out. It’s
Ryan:
[00:42:20] easier said than done. Was there an aha moment where you realized maybe I do got this, or this isn’t that big of a deal?
Boris:
[00:42:29] You know, I don’t think so. Really. There wasn’t a single moment. It just kind of goes away over time. At every level, it doesn’t matter what level you’re at, you should always feel a little bit of imposter syndrome because if you don’t, then you’re not pushing yourself hard enough.
Ryan:
[00:42:43] At this point in your career, you were more and more of a tech lead and therefore writing less and less code. You mentioned that at Meta especially, there are cases where other functions are understaffed and you view that as an opportunity for engineers to be more product minded and maybe help out with PM opportunities.
[00:43:09] I’m curious, when would you say that you should go that direction as opposed to escalating and saying, hey, we need more PM support, and trying to write more code instead?
Boris:
[00:43:20] Yeah. You have to understand the trade-offs. I think this is the thing that a lot of people don’t really get when they push for stuff. A very common failure mode is an engineer will push for an idea and then get frustrated when no one else buys into it or wants to fund it.
[00:43:36] The organization just doesn’t listen or their leader doesn’t listen. What you have to do is understand the trade-offs and think of it from the point of view of whoever you’re trying to convince. What do they care about? What are the projects they’re working on? What is this trade-off against?
[00:43:50] If they do this thing, are they gonna see their work as a success? I think that’s really important. For some orgs, they might not have PMs because it might just not be a very sexy project. It might be really hard to hire, and maybe the leader’s already feeling that pain.
[00:44:10] For some orgs, they are trying to hire PMs, but there are actually just much more important things those PMs should go to. For other orgs, they might actually have too many PMs. If you ask, that’s the right thing to do because they could just take a PM off a less important project and put them on your project because it’s more important.
[00:44:29] It’s really important to be situationally aware, understand the context you’re in, and understand how your decision makers think about it at this point.
00:44:39 — How to find side projects
Ryan:
[00:44:39] This is kind of the end of that part of your story. You credit a lot of your success to the side quests and having these side projects or running list of what you call 20% time ideas.
[00:44:53] I’m curious, do you have any tips on how to find opportunities for engineers?
Boris:
[00:44:58] Yeah, at some point there were probably like 50 to 100 engineers working on these side quests that I scoped out and spun out of various points.
[00:45:08] And so pretty much every week I would think of some project, just like on a run or something. Or maybe while I’m coding, I think of some idea, I’ll just do some basic validation and then I’ll ping an engineer that I know and be like, are you interested in this? Then I’ll connect them with a couple other engineers that might be interested.
[00:45:25] This kind of added up very quickly. For me, one way that I really think about my work is how can I do less of it? As an engineer, our superpower to do this is automation. The most tedious stuff you can automate. This is something that’s really hard for other fields, but for us, it’s this incredible thing that we can do.
[00:45:45] A lot of engineers don’t really do it for whatever reason, but we should all be doing it all the time. It’s so important. It’s leverage. It’s like free leverage. The thing I often did was every time I did a code review, if I was commenting about a particular kind of issue, maybe a stylistic issue or something, I literally had a spreadsheet where I would tally up that issue and I posted the link to that pull request.
[00:46:10] I would do this for every code review. When I commented about the same kind of thing more than a few times, I would just write a win rule for it to automate that. This is kind of an example of leverage. At some point, I automated most of my code reviews because I had a flock of lint rules that were doing all this work for me.
[00:46:29] This is actually kind of similar because all these side quests were improving prod infra and dev infra. These are things that slowed me down in my day-to-day coding. When I was doing less coding, this was actually very dangerous because as an engineer, you need to be anchored to reality.
[00:46:44] You need that intuition. If you’re not in the code anymore, then you lose it very quickly. It’s a very dangerous place to be in. For me, when I was in the code a lot, there were all these really cool ideas that came out of it. It was leverage, not just for me, but for the whole eng team because of this principle that if you have a problem, probably other people have it too.
[00:47:02] I did YC back in the day, and in YC they teach you that first you build for yourself. You have to build awesome stuff. You have to build stuff people love. If you’re trying to find a market to build for, you start by building for yourself. That’s a pretty good indicator other people probably have that same problem.
Ryan:
[00:47:18] Yeah. There was a quote that you wrote that I thought was really good. You said, “Better engineering is the easiest way to grow your network and gain influence as an engineer.” I could totally see your scope of influence was so much further than just the code you’re writing because you’re passing people all these great ideas and overseeing them.
[00:47:39] The leverage is really insane.
Boris:
[00:47:42] Absolutely. It’s also just an example of being situationally aware. At the time, engineers were evaluated in the performance cycle. We looked at project impacts. Do you remember the others?
Ryan:
[00:47:59] Direction? and engineering excellence.
Boris:
[00:48:00] Engineering excellence is a thing that a lot of engineers struggled with. I was one of the people that came along and was like, if you want to do engineering excellence, here’s a project. People are already incentivized to do it.
[00:48:13] They see it as an opportunity. I think it was a chance for me to hone my skills about working with people. You never want to tell anyone what to do in any context, personal or work. Everyone hates being told what to do.
[00:48:30] If you understand what a person wants, then you can go to the right person with the right opportunity and they see it as an opportunity. This just always works better for everyone.
Ryan:
[00:48:39] When I think about these 20% time ideas, there’s the top of funnel, finding the ideas, and then there’s actually executing on them, getting someone to do it, whether it’s yourself or someone else.
[00:48:53] The thing I’m interested in is the top of funnel. How do you source so many ideas as an engineer for these side quests that are impactful?
Boris:
[00:49:03] Just common sense. I don’t know, maybe spidey sense.
Ryan:
[00:49:09] What’s a concrete example?
Boris:
[00:49:13] A really concrete example is, I think liberal rules are a good one. Maybe another one is there were all these cases where we had SEV because Facebook groups were not being tested with very large sets of data. For example, you could imagine a Facebook group with 10 million members. No one’s ever tested this. There’s no unit test for this. You only see it in production.
[00:49:35] When I looked across the org, I started seeing similar cases. For example, if you have a profile with 20 million followers, a lot of stuff breaks, but obviously no one tests this in an automated way just because it’s kind of annoying to write a unit test with this much data.
[00:49:57] There are a bunch of instances of this. I pitched an engineer to build a way to write unit tests for large data sets, like a really big object, like a group with a lot of members, a profile with a lot of followers, an event with a lot of attendees. I think this still exists in infrastructure.
[00:50:14] It prevents a lot of issues, and you can scope it. He brought in a bunch of other engineers to do the work and help him out with it. So I guess just think about the problems that you actually hit day to day.
Ryan:
[00:50:26] Got it. Okay. So think about the problems, and if you’re experiencing that problem repeatedly, then it’s time for automation.
[00:50:33] That’s a great better engineering project.
Boris:
[00:50:36] Yeah, exactly. If you hit the same problem two or three times, you should probably look around, see if other people are hitting that problem too.
00:50:45 — Principal (IC8) promo story
Ryan:
[00:50:45] The last leg of your career at Meta, this is where you got the IC8 promo.
[00:50:49] I know that you moved orgs, so you did all of your growth in Facebook groups and then you moved to Instagram. I’m curious, what’s the story behind you moving orgs to Instagram?
Boris:
[00:51:02] At the time, I was dating my wife, and she was living in Berkeley. I was living in SF, and at some point she said, “I found my dream job.”
[00:51:16] I was like, sweet, awesome. Then she said, “We’re going to have to move.” I was like, okay, great. We had been dating like three months at the time, and we were kind of deciding why should we keep dating? She said, “We would have to move if you want to keep dating.”
[00:51:32] I was like, yeah, okay. I do. Let’s do it. The job ended up being in rural Japan, sort of in the middle of nowhere, and I was trying to figure out how to do it because I really liked the work that I was doing. First, I talked to Facebook groups leadership and tried to set up a Japan office for Facebook groups, but that didn’t work due to a bunch of organizational rules.
[00:51:55] Then I tried to do this with the VR org, and it was actually working, but then the person that was sponsoring it left to go to YouTube or something. At the time, Will Bailey reached out. He was in the Instagram Tokyo office, part of the landing team for Instagram. He said, “I want to grow this office. Do you want to be part of that?” I was like, yeah, let’s do it.
[00:52:11] I didn’t know anything. I didn’t even have Instagram installed at the time. I’d never used it in my life. I said yes, and then I immediately downloaded Instagram and moved the next week or something.
[00:52:31] I think it was a few weeks that I had in the US, but I moved out pretty quickly. I really fell in love with the Instagram culture. It was very different from Facebook culture, with a big emphasis on building awesome products, shipping stuff that people use, and thinking about things not just from a data point of view, but also from a human and experience point of view.
[00:53:00] You can see this in the app and in the craft that goes into it. It’s just completely different engineering and product and design cultures between the two companies. I’ve learned so much being on that team, and that was such a fun journey.
Ryan:
[00:53:14] You mentioned the unshipping, what is that?
Boris:
[00:53:19] Unshipping is the idea that if you just add features to an app, it’s cool for some small percent of users, but it’s actually bad for most users that don’t use the feature. You can think of an app where you only add features to it, and over time the features accumulate. If every feature is used by like 10% of people, the average user sees a bunch of features that they don’t use.
[00:53:41] It seems cluttered and confusing. When they open the app, they don’t know what to do. With software, fundamentally the screen is of limited size. That’s the limited real estate. It’s a limited resource that all the different features are competing for. By adding a feature, you’re taking the opportunity away from a different feature the person could have used. Unshipping is the idea that you have to meet some sort of usage bar.
[00:54:07] If a feature doesn’t meet that bar, then we just delete the feature. A small percent of users are going to be upset, but it’s actually great for the majority of users. On average, it’s really great for everyone.
00:54:20 — Building credibility in a new org
Ryan:
[00:54:20] At this point in your career, you moved across the world to work at Instagram. When you’re such a senior tech lead with a lot of credibility in your existing org, it’s much easier to get things done or at least influence others.
[00:54:36] They say, “Oh, I know Boris and I know his past work.” But I’m curious, how did you build up credibility at Instagram when you were so far away from everyone else?
Boris:
[00:54:50] A lot of the credit early on goes to Nam Nguyen, who is still the VP of Engineering at Instagram, and Jeff Wong, who was my director at the time, but now he’s a VP.
[00:55:03] There were a lot of connections made by these people. For example, Nam was like, “Hey, you really like working on code quality and tech reduction,” which we call better engineering at Meta. He connected me with the people working on it.
[00:55:20] This was Lukas Camra, Gabe, and a bunch of other folks that were working on this stuff. Those connections were really useful. A lot of it was I just had to earn the trust again. Honestly, this is a healthy thing to do. This is one of the really awesome things about Meta’s engineering culture.
[00:55:42] There are no titles, so you have to constantly re-earn your trust. Even if I was a great engineer in the past, I may not have been a great engineer at Instagram. If I wasn’t, then I don’t deserve influence. I don’t deserve to have a really loud voice that people listen to.
[00:55:59] I had to earn it along with everyone else. In my first few weeks, I spent a lot of time meeting people, mapping out the org, mapping out goals, and writing a lot of code to get to know the codebase. In Japan, it was totally different because 4:00 PM Tokyo time was like 7:00 PM New York time. There was just no time zone overlap.
[00:56:22] It was rough. But it was also great because in the few years before, I was doing so many meetings and docs that I just wasn’t coding. I started to feel pretty unhappy because as an engineer, we code. That’s the reason we pick this job. For me, when I write code, I have an emotional relationship with it, and it’s something I think about when I’m really deep in a problem. I dream about it.
[00:56:48] It’s so important for me to code. When I wasn’t doing this for years, it was rough, and I think I was starting to burn out a bit. It was a gift to be in this time zone where I literally couldn’t do meetings because people weren’t awake or didn’t want to do 9:00 PM meetings just to talk.
[00:57:05] I didn’t do any more one-on-ones, and I still don’t do any standing one-on-ones. I could spend a lot of time coding. I realized I was one of a few engineers at Instagram at the time that was coding this much. People code, but they don’t code that much because there are meetings and docs and other obligations.
[00:57:33] I was able to do a lot of stuff that I think everyone else wanted to do but just didn’t have time. This was kind of a superpower in that org. Pretty early on, Nam connected me with Joe Pamer, who’s still a good friend and mentor. He’s at Google now, and we started talking about how the codebase was written in Python and was rough for a lot of different reasons.
[00:58:01] The codebase should have been moved over to Hack, which is the main Facebook monolith. This is where all the language support is. There’s so much infrastructure. HHVM is an absolutely phenomenal web serving stack. There’s nothing else like it in terms of efficiency. If you’re using GraphQL, you absolutely have to use it because it is just so optimized for this stuff.
[00:58:20] Instagram just wasn’t using any of this, and engineering was suffering. In the early days, when Mikey was at Instagram, the basic principle for decisions was to do the simple thing that works. This worked really well, but at some point, it stopped working.
[00:58:37] Once you get to like a thousand engineers, 2000 engineers working on the codebase, and many years of tech debt and products built on top of each other, you have to make slightly different decisions than you would have made at the start. Even if Python was absolutely the right decision at the beginning, it was not the right decision by the time I was there.
[00:58:55] This was painfully obvious as an engineer, and I think a lot of other people saw this, but what stopped them was the amount of work it would have taken to move this stuff over. I started scoping this and figuring out what it would take. I began by finding the people that would disagree the most.
[00:59:11] There were a bunch of infra old-timers that thought this was a terrible idea and would never work. I talked to them first. I brought food in New York, and we got a bunch of beer and got to know them as people before we even talked about the technical problem.
[00:59:24] You have to build trust. I had to get to know them as people, and this was so valuable. This is still a lot of my friends today. After building this trust, I learned there were a bunch of other people that actually did want to do this and were kind of afraid to say it. These people came out of the woodwork too.
[00:59:42] Eventually, we started scoping this, and this project kind of spun out. It’s still going today, with many engineers working on it. It’s funny because at Facebook, this kind of problem rarely happens because the org is so engineering-driven. At Instagram, there were many problems of this shape because the org is very product-driven, so there isn’t a lot of time for those engineering-driven initiatives.
Ryan:
[01:00:04] At some point, you got it off the ground, kind of this bottoms-up initiative, and then it became high priority enough where it needed the in-person support of someone that wasn’t in Japan. I understand that Jake Bolam is someone that you helped onto the project, and he took more of a lead role, location-based and close to everyone else so he could help shepherd it along.
[01:00:30] I’m curious about that point of delegation. When do you decide to delegate something so big, and when do you decide you need to still be around? How do you navigate that trade-off?
Boris:
[01:00:43] Jake is amazing. We’re friends. Every time I go to Seattle, we hang out, and he’s just one of the best engineers I know.
[01:00:49] It was obvious that he would be a good owner for this. The same rules of delegation apply as always. You never delegate the thing you don’t want to do. That’s the most important rule. You always delegate the thing you do want to do and that you know well because then you can monitor the progress and make sure it’s going well.
[01:01:07] There’s a great book, High Output Management by Andy Grove. He was an old Intel CEO, and it’s the most boring-sounding book ever, but it’s the best. One of the pieces of advice is to delegate the thing that you like to do so you can monitor progress.
[01:01:24] It’s kind of the same thing. You delegate a little bit, you check in. The more trust you have, the less you have to check in. With Jake, he’s so good technically and so proactive. There was very little I had to do. It was very much on track from the start.
Ryan:
[01:01:37] I think this, coupled with some other work, a large migration to kind of GraphQL or modernizing some of Instagram’s data model, ended up getting you promoted to this principal level before you left Meta.
[01:01:51] What was the story behind the promotion or anything that you might share?
Boris:
[01:01:56] That promotion, I think, in a one-on-one I had with Will, my manager, he said, “Hey, I think we should put you up for IC8.” I was like, “Cool.” That was pretty much it. I hadn’t really thought about it.
[01:02:09] It’s not something I really asked for. I think Will does a great job of recognizing people and advocating for his team. He felt that I was ready, and that was that.
Ryan:
[01:02:19] At any point in your journey, it sounds like you were focused on impact and growing your leverage and credibility, and the promotions were a byproduct.
[01:02:34] I’m curious, though, to structure your thinking about how to get more leverage or have more impact. Did you ever think about the levels, or would you say that it’s not good to think about what’s the next level? Is it better to think in terms of leverage or impact or something else?
Boris:
[01:02:56] You have to think about what levels exist so that the company can communicate to an engineer what it is they expect the engineer to do. It also exists so that there’s some accountability. For example, in performance reviews, you can compare an engineer at a particular level to another engineer at that same level.
[01:03:14] And also sometimes on the finance side, different engineers are paid different amounts. You can think about what kind of portfolio you want. Levels exist for company reasons and not for engineering reasons. For me, it’s just never the way that I thought about any of this.
[01:03:30] The thing that I like to do is work on interesting projects. I like to figure out problems and solve them. I like to make the products that people use delightful. This is what really motivates me. So for me, this was just never really the way I thought about it.
[01:03:48] I remember my first week at Facebook, I was an IC4 and I had all these ideas for stuff that we should build. I started writing product briefs. I went to the VP of Connectivity and pitched him an idea, and he just didn’t understand it at all and thought it was terrible. That didn’t work.
[01:04:05] I had another idea for Messenger, and I pitched that too, but they also didn’t do it. They ended up building it a couple of years later, this particular idea. For me, it’s just about what are the cool ideas and how can I help? Who else is interested in this stuff and how can we build cool stuff?
01:04:23 — Joining Anthropic
Ryan:
[01:04:23] You left Meta to go to Anthropic, and I’m very curious, what was your thinking about going to Anthropic?
Boris:
[01:04:29] I remember using ChatGPT for the first time when it came out. This was years ago. I was in Japan.
[01:04:38] I was the only engineer in my town. I was the only person that spoke English in my town, and there was just no one that I could talk to about tech stuff. Every morning I read Hacker News. I remember using ChatGPT and I was just blown away by the product and the feeling it gave me. Nowadays we take it for granted, but LLMs are just magic.
[01:05:02] It’s absolutely incredible technology. I think now my view of it has shifted. To me, LLMs are this kind of alien life form that we get to nurture and bring into existence. It’s not just a technology. I’m also a really big reader. I read a lot of sci-fi.
[01:05:19] At the time, I thought, oh my God, I have to work on this stuff. What are the labs that are working on it? I went to talk to friends working at various labs. I remember my first lunch at Anthropic with Ben Mann, one of the founders. We were sitting at lunch with him and a bunch of other people. I mentioned a weird sci-fi book I liked, I think it was by Greg Egan, a hard sci-fi author. I had never met anyone who had read this book, and at the table, I gave an anecdote from it, and everyone around the table was like, oh, yeah, that book was good, but what about this other book?
[01:05:59] It was just a group of intense sci-fi nerds who think deeply about the same problems I care about. The other part for me was that when you read a lot of sci-fi, you get a sense of how this can play out in a speculative way.
[01:06:16] AI is transformative to society. It’s hitting engineering first and will affect every part of society. We’re seeing the very first waves of this right now. I read enough to know the bad ways this can play out, and there are many ways this can go wrong. For me, Anthropic was just the obvious choice because I wanted to be at a place where, in the tiniest way, I can make sure this goes well, which is all I can do as an engineer.
[01:07:05] Before I joined, I sort of took safety seriously. At Meta, it was always seen as a tax where integrity teams get you to do stuff, but it’s not really the thing anyone’s excited to do because it’s not the product. This was my view of safety before, but I kind of knew it could be very different. Now being at Anthropic, I know it’s completely different. I see every model that comes out and the new risks that come with it.
[01:07:22] As a company, we put our money where our mouth is in terms of how much compute goes to safety research and alignment research and how many people work on this. We’ve held up model releases in the past because we did not know they were safe. We had to make sure they were safe first.
[01:07:38] With Opus 4, the risks just went way up. If the model can design bio viruses and do things that are really dangerous, it’s not just about election manipulation, which is a big deal at Meta. As models get more dangerous, the risks get higher. You quickly get into territory where people can use the model to build things that are actually dangerous for humanity, not just politics in a country, but literally the existence of humanity.
[01:08:15] This is not sci-fi; this is a real risk today that we actively have to fight. For me, getting to be a part of this and contribute a little bit is what put me over.
Ryan:
[01:08:27] What about when you joined? When you think about the engineering cultures that you came from compared to Anthropic, were there any really jarring differences?
Boris:
[01:08:37] Yeah, I would say the two things. One is still being a startup, there’s a lot of common sense. It’s funny; this is something every big company loses. Over time, the decision makers get more distant from the impact of their decisions, whether it’s the product or the people.
[01:08:56] You have to come up with processes to bring them closer and improve the quality of decision making. But at a startup, everyone just has common sense and generally does the right thing, so I don’t have to spend a lot of time convincing people to do stuff if we should just do something. It’s obvious, and everyone just does it.
[01:09:11] The second thing is, for me personally, something that I learned over time motivates me the most is mission. It’s so important and keeps me excited to go to work every day. It’s what makes me code on the weekends because I want to do it, not because there’s a deadline.
[01:09:32] I felt this a lot at Facebook Groups. It was very mission-oriented. For a long time, Jen Dulski was the VP, and she used to be the CEO of Change.org. She ran all of Facebook Groups like a nonprofit. She had a theory of change about how to connect people to like-minded people to form communities.
[01:09:50] It was so motivating to work on that. At Instagram, maybe because of the geographic distance or something else, I just never quite felt that same mission. But at Anthropic, I feel that so strongly, and that’s probably the most exciting thing for me.
01:10:05 — Why Claude Code succeeded
Ryan:
[01:10:05] I know that your credit is the creator of Claude Code, and I think you’ve told that story in many places. I’m kind of curious, I was talking with a friend about what the environment was like when Claude Code came. There were a lot of competing existing tools that hooked into the model.
[01:10:27] What is it that was different about Claude Code that caught fire internally?
Boris:
[01:10:36] At the time, coding looked very different. If you thought about AI coding, people thought about auto-complete. There were some very early agents, but it was kind of a secondary thing next to the auto-complete.
[01:10:48] Oftentimes it was used for Q&A. It wasn’t really used for coding. When people thought about AI for coding, it was just a completely different product that you imagined. It was like tab to auto-complete, and I thought that’s what it was. I thought that was kind of the state of it.
[01:11:06] Then Ben, who was my manager at the time, pushed me to think a little bit bigger. He really internalized, because he was there from the beginning of Anthropic and at other labs before. He understood the scaling laws about how quickly the models were improving.
[01:11:27] He actually pushed me really hard to be like, don’t build for the model of today, build for the model six months from now. Honestly, for a long time, Claude Code was not a great product. Even when it was used internally, I used it for maybe like 10% of my code. I used it sometimes, but it really just can’t do most things because the model’s not capable enough.
[01:11:47] At some point, we released Sonnet and Opus 4, and I think this was maybe March of this year. The product just worked. We saw this in the usage data, and I saw this in my own coding. I started to be able to use it for probably like half of my code. This was literally six months after starting the project.
[01:12:09] At this point, most of Claude Code is written using Claude Code. I think it’s like 80 or 90%. If you look at teams at Anthropic, some teams have like 90% of their code written using Claude Code. This is not just our team. If you look at the impact on productivity, even though Anthropic has tripled since the start of the year, productivity per engineer has grown almost 70% per engineer because of Claude Code.
[01:12:29] As a product person, I usually think a step ahead. Being at a lab, you have to think differently. You have to think a step ahead, not two steps ahead, but you also have to be really aware of the model and the exponential growth we’re on.
Ryan:
[01:12:55] Did you see the recent interview with Karpathy?
Boris:
[01:12:57] I haven’t had a chance to watch it yet.
Ryan:
[01:12:59] One thing that he said in the podcast was kind of pushing back a little bit because vibe coding, although it has a lot of miraculous results because of what it can generate, there’s also a lot of slop or drawbacks.
[01:13:19] I’m curious, how do you think about that when the model produces a lot of code, but maybe it’s not exactly how you’d like it, or maybe the end result has some non-obvious problems with it?
Boris:
[01:13:34] AI coding is a tool like every other tool that we use, and you have to learn how to use it. Karpathy obviously knows how to code.
[01:13:43] A lot of people that are new to this kind of tool tend to just ask it to do stuff that’s a little bit too big, or they hold a different bar for the model’s code versus their own code. Something that I do for the Claude Code team is we have the same exact bar regardless of whether the code was written by the model or by a human.
[01:14:01] If the code sucks, we’re not gonna merge it. It’s the same exact bar, and you just ask the model to improve the code and make it better. There are different ways of wielding these tools. Sometimes you want vibe code, and this is really important for throwaway code and prototypes, code that’s not in the critical path.
[01:14:18] I do this all the time, but it’s definitely not the thing you want to do all the time because you want maintainable code sometimes. You want to be very thoughtful about every line sometimes. Depending on the problem, you want a different approach. There are a set of approaches that I’ll use.
[01:14:37] Sometimes I’ll vibe code stuff. This is actually quite rare. It’s mostly for prototypes and throwaway code. Usually, I pair with a model to write code. First, we align on a plan. This is like shift tab in Claude Code to get into plan mode.
[01:14:53] The model will make a plan, then I’ll see the code, and I might ask it to improve the code or clean it up. It’s a very involved process. I’m pairing with the model; we’re working together to write this code. Sometimes I’ll still write the code by hand. There are parts of our core query loop where I have very strong opinions about things like the names of parameters or which particular line of code is.
[01:15:18] For this, I’ll still write it by hand. The models are still overall not great at coding. There’s still so much room to improve, and this is the worst it’s ever gonna be. It’s insane to think a year back where the state of AI coding was type ahead. It’s just a completely different world, and you think about where this is headed and what’s about to happen over the next few months and years.
[01:15:50] What keeps me really excited about it is just having the context about this trajectory that we’re on.
01:15:56 — Claude Code use outside of code
Ryan:
[01:15:56] When people hear Claude Code, they think about coding. There are many use cases outside of just software engineering, like querying data for data scientists. What are your thoughts when you think of Claude Code for everything?
Boris:
[01:16:11] It was the craziest thing when I walked in. I remember walking into the office maybe six months ago. Our data scientist, Brandon, had Claude Code up on his computer. He sits next to us, and I’m like, dude, what are you doing? Are you trying it out? He’s like, no, no.
[01:16:24] He’s like, it’s doing my work. I was like, what? He figured out how to use a terminal and how to install Node.js. Then he installed Claude Code, and it was writing a bunch of SQL and doing analysis for him. Now when I walk by the data scientists that sit next to us, every person has a bunch of Claude Code up at the same time. It’s not just one anymore.
[01:16:43] They’re doing all sorts of stuff. They’re writing SQL and crunching data. They’re writing dbt pipelines and writing code. There are all these applications outside of coding, and it’s just so cool to see how people are using this for all sorts of stuff.
[01:17:04] There are even non-technical users; half of our sales team at Anthropic uses Claude Code to do their work. They can connect it to Salesforce and different data sources and do their work this way. It’s just so cool to see. This is not how we designed it. This is not the intent.
01:17:22 — What he thinks of competition
Ryan:
[01:17:22] When I hear Claude Code, I also think of Codex, one of the biggest competitors. I’m curious, what are your thoughts on the competition with Codex and OpenAI? What does Claude Code do better? I’m also curious about the stickiness of these AI products. What keeps people in Claude Code versus Codex, for instance?
Boris:
[01:17:44] First of all, I don’t really use the other products.
[01:17:50] For me, the thing I tell the team is it’s so easy to get sidetracked by looking at competitors. I think this is something that big companies fall into a failure mode a lot. Because there are so many competitors, it’s easy to see the thing you could build by just copying it. It’s a little bit harder to come up with novel ideas that solve the user need better.
[01:18:16] The thing that I try really hard to do and nudge our team to do is don’t get sidetracked by all these other products. There’s always gonna be a lot. The more there are, the bigger a sign of success it is for us. The thing we stay laser focused on is solving our problems, solving Anthropic researchers’ problems, and solving our users’ problems.
Ryan:
[01:18:38] Coming to the end of the conversation, I just want to ask a few career reflections. One thing I was curious about is that you didn’t have a CS degree or a computer science degree, and you’ve become such a strong software engineer. I was curious, is there any part of your career where it might have held you back in any way?
[01:18:59] Or do you think it’s not necessary or relevant?
Boris:
[01:19:02] Yeah, irrelevant. I studied economics and actually dropped out to start startups. For me, anything that you do, you learn on the job, and programming is just such a practical skill. I couldn’t imagine the kinds of things you learn in school. If you’re in a data structures class and you’re running this but haven’t built a product, how is it relevant at all?
[01:19:27] My recommendation would be to people: learn coding practically. It’s a very practical skill. If you want to go back and learn the theory after, go do that. Personally, I’ve never felt like it helped me back at all.
Ryan:
[01:19:41] What about productivity tips? I saw that you said you work roughly nine to six every day and you only type with two fingers, but your output is ridiculous.
[01:19:53] You have all these side projects, and of course your main stuff’s no joke. What’s your top productivity tips or how do you maintain that?
Boris:
[01:20:01] Yeah, nowadays my tips are very different than what I would’ve said a couple years ago. The tip is just learn how to use Claude Code and learn how to run a bunch of Claude Codes to do stuff. We launched plugins a couple weeks ago, and Daisy, one of the engineers that built it, had her Claudes set up an Asana board, made Asana tasks, and then she had a swarm of 20 Claudes build plugins over the weekend.
[01:20:26] She ran it in a Docker container, dangerous mode, and it was done after a couple days. This is the kind of thing that is the future of engineering. When we talk about tips for productivity, it’s learn how to use Claude to automate toil and how to use a bunch of Claudes together to do work.
[01:20:48] So you’re orchestrating instead of manually writing code. Years ago my tips would’ve been really different. It would’ve been a lot more prosaic, like blocking off time and things like this.
Ryan:
[01:21:02] Yeah, it’s interesting. With Claude Code, I wonder what that does for the famous maker’s schedule versus manager’s schedule.
[01:21:10] It feels like what you just said is that software engineers are becoming more like a manager’s style of working where you have a fleet of these Claude Codes and you don’t need deep focus to move forward. You need context switching across 20 different things. Do you no longer have big focus blocks for coding, or what are your thoughts on that?
Boris:
[01:21:33] Not as much. I tend to code on the weekends also. I love the quiet time. Every morning I open Claude Code, and the mobile app has a code tab in Claude now. We just launched this this week, but we’ve been using it for a while.
[01:21:49] Every morning I wake up and start a few agents to begin my code for the day. It’s crazy because if you’d asked me six months ago if this is how I would code, I would have said no. But it actually works. This is how I write a lot of my code now. I’ll start a few agents, and when I get to a computer, I’ll check in on the status. Sometimes I’ll merge it if the code looks good. Sometimes I’ll pull it locally and edit a little bit.
[01:22:24] I think you’re going to talk to Fiona later, and from what she told me, she hasn’t coded in a decade, but she’s writing code multiple times a week now. As a manager, even though her schedule is insane, she can still use the mobile app and web, and she can open a terminal to write code.
[01:22:41] It’s crazy. We get to live through this transition where the thing that we do and the thing that I grew up on is totally changing. It is becoming accessible to everyone.
01:22:57 — Advice for his younger self
Ryan:
[01:22:57] And then last question for you is, knowing everything that you know now in your career, if you could go back to yourself when you just entered the industry and give yourself some advice, what would you say?
Boris:
[01:23:10] Just use common sense.
[01:23:14] I think there’s a lot of stuff, especially in big companies, that pulls you away from common sense. There are a lot of things that are this way because they have been this way. There are misaligned incentives, but there are also good things. It is really important to use common sense for this. Early on in my career, I was starting a bunch of startups and worked at a lot of startups, and I think there too, it’s the same thing. Use common sense to figure out what the market wants and what users want to build it.
[01:23:45] So yeah, just trust yourself and develop your common sense.
Ryan:
[01:23:51] Awesome. Well, thank you so much, Boris, for your time. Really appreciate it.
