Boris Cherny (Creator of Claude Code) On What Grew His Career And Building at Anthropic

The models are moving so quickly. If you

ask me this question in 3 months or 6 months, my answer will be totally different. This is Boris Chney. He's the

different. This is Boris Chney. He's the

creator of Claude Code and former meta principal engineer. And we talked about

principal engineer. And we talked about everything that shaped his career. Can

you explain latent demand?

>> Latent demand I think is the single most important principle in product.

>> You said that there were some clear cultural differences and that was difficult.

>> Oh my god, difficult is such an understatement. It was a nightmare. We

understatement. It was a nightmare. We

also talked about quad code and what's actually happening in enthropic right now. Even though enthropic has tripled,

now. Even though enthropic has tripled, productivity per engineer has grown like almost 70% because of quad code. Don't

build for the model of today. Build for

the model 6 months from now. The one

technical book I would recommend to everyone that has had the greatest impact on me as an engineer is what are your thoughts on the competition with codeex and openai?

Here's the full episode.

I want 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?

If I remember right, the project was chats and groups and this was a project to bring uh Messenger and Facebook a little bit closer together. And I

actually the first few projects that I worked on at Meta, it was about Messenger and Facebook. And I think the first one was like Zach had this idea about like syncing Messenger chats and

Facebook groups. Um, but there's a few

Facebook groups. Um, but there's a few of these projects just trying to bring like uh Messenger and Facebook closer together. And I think the motivation was

together. And I think the motivation was there was this feeling that this kind of public space social product was disappearing and that things were moving a little bit more into chat and these

kind of more casual realtime spaces. And

so we tried a few versions of the product and chats and groups is the one that worked. I think it was like number

that worked. I think it was like number three or number four at the time and I I was in the Facebook groups or in um Facebook at the time and I was working a lot with messenger that was like

organizationally very distant. And this

is a idea that I think Steve who was a PM at the time he sort of had this idea this is a thing we should build and I just picked up on that and I was like yeah hell yeah let's let's do this. Uh

and so I started hacking on it. Uh and

then pretty soon there were some signs of life. So I asked for more engineers

of life. So I asked for more engineers and uh there were three engineers that joined. There was uh Shatambri, uh

joined. There was uh Shatambri, uh Crystal and Chaang. They were like the first three engineers that joined this and then we got some uh we got some data science support, some design support. Um

and it started just on web. Then we also moved to mobile a little bit and uh yeah, I think we just kind of proved out this idea that you can have chats inside of Facebook groups and this kind of

product can work. And there's just like a lot of stuff honestly that didn't work at all about it. Um it was like a super jank experience I think by modern product standards. Like back in the day

product standards. Like back in the day everyone was building on web and all sorts of bugs were totally okay.

Nowadays, I think the standard honestly like the visual standard like quality standard is a lot higher and yeah so like the the product grew and we were such a small team like everyone had to

do everything and I remember like we didn't have a user researcher so I would go to the cafeteria during lunch and we would have a new feature and we would show the cafeteria workers the feature and be like hey can you figure out how

to open a chat and you know like sometimes they would find it sometimes they wouldn't be able to and this is just like an observational user research study So you kind of see how people like in a particular situation can do a task

and you don't prompt them that much. So

you you don't want to give too much away and you kind of see where they struggle.

You see what they get. Um and so we we did this and then like I I kind of taught the team how to do this. So then

pretty soon we would all go to the cafeteria at lunch and start like bugging cafeteria workers to you know as just kind of like representative users to be like you know does this make sense or not? It's interesting how the early

or not? It's interesting how the early Facebook culture that you were operating in let engineers do so much outside of just like the code. For instance, you're

doing UXR. It sounds like in some of it

doing UXR. It sounds like in some of it I remember in your story you did some design as well and you were coaching people to do design. So I think that's pretty interesting unique thing in

Facebook's culture. I think this is so

Facebook's culture. I think this is so important and I think to this day, you know, on the quad code team and this is the team that I'm on right now. We

really prioritize generalists. So I love working with generalists. If you're an engineer that codes, but you can also do product work. You can also do design.

product work. You can also do design.

You have product sense. You go, you want to go talk to your users. Like I love this kind of engineer to work with. And

this is actually how we recruit for all functions now. So like our product

functions now. So like our product managers code, our data scientists code, um our you know user researcher codes a little bit. So like I just love these

little bit. So like I just love these generalists and I think this is really like the way that I grew up like from the beginning when I was running you know my first startup when I was like 18 I had to do everything and uh up until

Facebook I worked at smaller companies where you had to do everything and I kind of feel like at big companies you get forced into this you know particular swim lane but it's just sort of official cuz like what is engineering? It's like

it's a very narrow skill set, but really the thing that you're doing is you're building product or you're building infra and there's just so much more that goes into doing that end to end besides just writing code. It it was just really

cool being at a place that um I think Facebook uniquely kind of rewarded that at that time. And I I think actually at the end of that half I got promoted and then I think the half after every single one of the engineers got promoted too.

In those early products, there was this concept um latent demand that you mentioned a few times, which uh it sounds like was the impetus for a lot of those product

directions. Can you explain latent

directions. Can you explain latent demand?

>> Latent demand I think is the single most important principle in product and I think if you look at especially at Facebook successful products, every single one has an element of latent

demand. So for example, a marketplace,

demand. So for example, a marketplace, it came from this observation that if you looked at Facebook groups at the time, 40% of the posts were buying and selling stuff. And so Facebook groups

selling stuff. And so Facebook groups were not designed for commerce, but that's what people were using it for.

And so it's kind of cool like you design this product in a way that can be hacked. It can be abused by users a

hacked. It can be abused by users a little bit, and then you look at the data, you see how they're abusing it, and then you build a product around it.

And so you know like there was Facebook groups and then there were buy sell groups and then that succeeded obviously because people already wanted to buy and sell and do commerce on Facebook groups and then marketplace was next. It was

just a natural extension of the same intent that people had. Um I think Facebook dating was pretty similar. I

think the observation was something like 60% of profile views were people of the opposite gender that were not friends with each other. Um, so you know this kind of like traditional like kind of like creeping on each other like and and

I think for like um like Nate and like FMS at the time like this this was evidence that this would work. And I I think the the principle in product is you can never get people to do something they do not yet do. The thing you can do

is you can find the intent that they have and then you can steer it to let them better kind of capitalize on that intent um and kind of do the thing the thing that they want more easily. I

think also at this part of your story, you mentioned that you worked across orgs. You worked because you were

orgs. You worked because you were bridging the gaps between messenger and a lot of the group's um engineering work. I'm curious, you said that there

work. I'm curious, you said that there were some clear cultural differences and that was difficult. Uh do you have any advice for working across uh very different culture orgs?

>> Oh my god, difficult is such an understatement. It was a nightmare. Like

understatement. It was a nightmare. Like

for Facebook at the time, we wanted to ship like we just wanted to go fast and ship awesome product as fast as we could. And then Messenger was all about

could. And then Messenger was all about reliability and performance. That's all

they cared about. It was just polar opposite values. Um and this isn't just

opposite values. Um and this isn't just cultural. It's not just like an engineer

cultural. It's not just like an engineer to engineer thing. It's like the engineers on that team were suspicious of us because we would affect their performance metrics. And

performance metrics. And organizationally, their or was set up in a way to ship slowly without regressing the metrics and we were set up to ship quickly. So it's like and then the goals

quickly. So it's like and then the goals were totally different you know like they had SOA up times and for us it was just about daily active users and engagement. So I think for me the

engagement. So I think for me the running was these kind of cultural values go super deep. It's not just a thing people talk about but you can actually see this in like in org design

and in in goal design and in every part of everything. And honestly, I think one

of everything. And honestly, I think one of the reasons that project uh failed was uh and eventually it evolved actually into something successful, but

that version of the project failed was because of this difference in values.

So I think that fundamentally if you want to get companies with really different values to succeed and kind of work together, you have to find some kind of shared goal or kind of shared interest,

shared belief, some kind of hypothesis that they want to test together that would be really interesting for both of them if it worked. Um, and I think this like chats and groups thing fundamentally was really cool for

Facebook, but it's not that cool for Messenger for a lot of reasons. So,

knowing what you know now, how would you change things going back to that kind of project?

>> I think I probably would have gone to Zuck and just been like, if you're really serious about this thing, we we should move Messenger into the Facebook or and I think this has since happened and it's actually happened like a few times like Messenger was in the or then

it moved out and then it moved in then moved out. It's a big company like this

moved out. It's a big company like this happens. But I think fundamentally for

happens. But I think fundamentally for this kind of thing to succeed, the the common report can't be, you know, the common manager can't be like Chris Cox.

It has to be like a little bit lower down. And so you can structure the orgs

down. And so you can structure the orgs to be a little bit more collaborative.

>> I see. To align the incentives so you don't get that kind of constant struggle.

>> Yeah. Exactly. 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 like what what's the butterfly effect of those kinds of projects? So, for

instance, um even before you got to meta, you worked on Undux, the state management framework for React. Um I'm

curious like how did that impact your career if at all?

>> Yeah, I mean for me side quests are so important and for me like when I hire engineers this is definitely something I look for. I want people with side

look for. I want people with side quests, like cool weekend projects, cool side projects, like even someone that's like, you know, just really into like making kombucha or something. Like you

want people that are generally curious and interested in stuff outside of their main work. These are kind of

main work. These are kind of well-rounded people. These are the kinds

well-rounded people. These are the kinds of people I enjoy working with. I think

for me, this is where a lot of my growth came from is um working on these kind of side projects. So something like Unex

side projects. So something like Unex honestly where it came from is uh React state management is honestly unnecessarily complicated and at the time the state-of-the-art was there

there was like flux and then there was this other thing called Redux and I just couldn't wrap my head around Redux. I

was just you know I I consider myself kind of average engineer like I build product. I'm like I'm not one of these

product. I'm like I'm not one of these like incredible systems engineers. And

so for me like Redux at the time I had these concepts of like you know like reducers and this kind of like just like this like very complicated flow you had to go to to just like update a little state and I just couldn't wrap my head

around it. So I I built a simpler thing

around it. So I I built a simpler thing that seemed to work. I used that um I was volunteering at a nonprofit at the time and uh they started using it and their engineers liked it. And then when

I joined Facebook, I saw a lot of kind of frustration around Redux usage because there was a internal group for people that use Redux and there were all these questions where people were asking

the same questions I did. Um, you know, like when you as an engineer or, you know, as a product person are running into a problem, sometimes it's just you.

Often it's other people too. And I think it's important to build the spidey sense for like when this problem might be shared by others. And so this is a problem that definitely was shared by others. And I could kind of see this in

others. And I could kind of see this in support posts and by the difficulty my team had using Redux.

And so I launched uh Unux internally and Unex is like it's fine. It's like not that great of a product, but at least it's better than Redux. And um at Facebook I didn't actually know how to get adoption. So I kind of posted about

get adoption. So I kind of posted about it. A few people started to use it. Um I

it. A few people started to use it. Um I

remember there was like Jeff Case on the notifications team was a big early adopter and we spent some late nights debugging some like gnarly like notification related bugs due to it. And

um I wanted to get more adoption. And so

what I did was I wrote a little script and I scraped the group of uh people reporting issues and I just tallied them by team. And then I reached out just

by team. And then I reached out just over chat to the tech lead and the manager for every team and I scheduled uh like a tech talk just for that team.

And I think overall I did maybe 20 30 40 tech talks something like that over the course of like a few weeks. Yeah.

>> And I I remember just like biking around the meta campus and kind of doing these talks and it was so fun cuz people were so engaged and they were just so excited that someone cares about solving this problem that they they really have and I

think at some point on was like the most popular state management framework at Facebook and then I think it got pretty quickly replaced by recoil and kind of more modern alternatives and nowadays it's like relay and and things like

that. Does that kind of side project

that. Does that kind of side project appear in your like performance review or is it like help you in some way? So I

think it was in my performance review. I

think by meta standards it's kind of a cherry on top. It wasn't really you know something that kind of gets you to the next level in itself. Um but I had a lot of other side quests around uh around that time too. Like at some point I got

really into TypeScript actually and this was like at the previous company I was at. We were using it. There weren't a

at. We were using it. There weren't a lot of good resources. And so I just like started writing a book about it cuz I was like someone like someone should do this. It's crazy it doesn't exist.

do this. It's crazy it doesn't exist.

This language is just like magnificent.

It's it's just this like really really shockingly shockingly good design. It has all these ideas that no other language had at the time. Um you know things like eventually

time. Um you know things like eventually like at the time there were no conditional types but like conditional types like literal types for everything.

Uh map types these are just like absolutely insane things. like even the like the gnarliest Haskeller is going to be impressed by this kind of language feature, but no one was writing about this stuff and so I just got like super

into it and like wrote this book and it it just sort of like ate up like a year of my life. Would not recommend it. Um

but it was really fun to go really deep on it and then I also started I think like the world's biggest TypeScript meetup at the time in in San Francisco and that was a really cool chance to meet uh there was like Ryan Doll who

created Node.js. there was um just like

created Node.js. there was um just like all all these like famous JavaScript celebrities and it just sort of made me realize like all these people are just people and um you know like everyone

just like builds cool stuff and 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.

>> Did you end up using TypeScript or that technical depth later in your time at Meta or or maybe even in anthropic?

Yeah, I think there was, you know, it's funny. I actually like I used to not

funny. I actually like I used to not care about languages and then at some point, this was maybe like 10 years ago, I used to ride a motorcycle and I got in a pretty bad accident actually. I broke

my arms. >> Oh my god.

>> Both of them.

>> Both of them. Yeah. I had like two slings on.

>> Oh my god. How'd you code?

>> Um, so that was the hard part. So like I actually like couldn't code for like a month and then you know my hands like still kind of hurt and so like I couldn't write JavaScript which is what I used to write at the time. And so I

actually had to branch out and learn other languages because they literally used less keystrokes.

And so I started with like coffees script because there was like less parenthesis and stuff. I don't I don't think that language even exists. No one

uses it nowadays. Um but that's also how I got into Haskell and kind of functional programming. Um cuz it was

functional programming. Um cuz it was kind of you can do the same thing with fewer keystrokes and that that was like literally the motivation at the time.

And then at some point I was working in uh at a hedge fund and this was like before uh before Facebook and I had a co-orker Rick who was really into Scola

and I really didn't understand Scola and uh he he kind of really got me into it and he got me into this like functional programming side of the house and this is still like the one technical book I

would recommend to everyone that has had the greatest impact on me as an engineer is this book called functional programming in Scola and you're probably never going to use schol today, but the

way it teaches you to think about coding problems is just such a change from the way that most people were encoding either practically or in school is just it's incredible. it's going to

it's incredible. it's going to completely change the way that you code.

And so for me it was it was kind of like Scola was like there was kind of like Haskell and kind of coffecript these kind of few key languages that was like a first step then Scola and then

Typescript and I think this kind of 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. This is more important than the code itself. And so

like getting this right leads to very clean code. And so even at Facebook

clean code. And so even at Facebook where I was writing mostly kind of flow and and hack and then later at Instagram Python um it it was very helpful here at anthropic I mostly write typescript and

python um so it's actually quite relevant but I but I think the the bigger lesson is just think in think in types >> at this point in your career uh you mentioned that you came in underleveled

you came in as a mid-level engineer even though you had a lot of experience and you said um in hindsight you were lucky to be underleveled and I'm curious is what's the the thinking behind that?

>> Just lower expectations.

Um yeah, I feel I feel like at a big company there's all these kind of um you know like at every level there's certain expectations in terms of kind of

the project impact and people impact and all this kind of stuff and the the specific criteria are kind of different across companies. Um but there's um I

across companies. Um but there's um I think a lot of it is about either project impact or kind of checking a bunch of check boxes and all this just takes a lot of time. Um and so I think

coming in under level it just gave me the space to explore and uh just like build cool stuff for the sake of building cool stuff. Definitely. And I

wonder if it also helps with building momentum. Like what I mean is if you

momentum. Like what I mean is if you came in as a mid-level or E4 and then you you crushing it. Everyone's saying

Boris is amazing. What this is crazy as opposed to you came in at your whatever I don't know expectations and you did

good. I think there can be this uh

good. I think there can be this uh effect when you come in and you really wow everyone. you have such a strong um

wow everyone. you have such a strong um you know first impression I think can be helpful for building a good reputation that gives you more credibility more projects and stuff like that in the future.

>> Yeah, I think that's totally true and I I think actually this is probably good advice for any company is like I think a lot of times engineers switch jobs and they really push you know like I want to go to a different company and I want

like a level plus one or whatever and actually there's a lot of downsides to that like you said. Going on to the thing that got you promoted to staff or E6 at Meta, I'm curious the story behind

um you know where you were at the time and what got you promoted into more of that leadership position. So what was happening was chats and groups that was launched and that that was going and

there was kind of a team working on this. Um, and uh, I actually had a I I'd

this. Um, and uh, I actually had a I I'd done a lot of JavaScript before I joined, but at Facebook, I'd never actually written JavaScript cuz it was all PHP.

>> And so I really just wanted to write JavaScript. And we had this like web

JavaScript. And we had this like web interface. And for Facebook groups in

interface. And for Facebook groups in particular, a lot of people use web as opposed to mobile because, for example, for like being a group admin or whatever, it's just easier to do on a big computer with a with a keyboard and

stuff. And at the time the site was

stuff. And at the time the site was really janky. It was like a static site.

really janky. It was like a static site.

It was all PHP. There's these little bits of JavaScript that are injected a little bit in different places. There's

all sorts of inconsistent state like all these problems that come out of it. It's

just it doesn't feel like a good UX. And

so I wanted to rewrite it in JavaScript and I got a lot of push back from the or at the time. And I think the big reason was that the info just wasn't really ready for it.

Luckily, at the same time, Comet was starting and Comet was like the rewrite of facebook.com on desktop. And this is like Tomcino, who's who's now at Versel, this was Jing Chen. Um, there there's a

bunch of these kind of core people that that were working on this. And I just really wanted to be involved. So, I

reached out and asked how I can help.

And I offered Facebook groups as the guinea pig for it. And I didn't ask anyone. Just kind of just kind of did

anyone. Just kind of just kind of did it. And then uh later I kind of went to

it. And then uh later I kind of went to my leadership in Facebook groups and I was like, "Hey, comments's coming. It's

going to be a bunch of work. We can get ahead of it." Kind of set the standard for everyone, build relationships with these other teams. And I still got a bunch of push back that was like, "Hey, you know, you can't put 20 engineers on

this." And uh after a bunch of reviews

this." And uh after a bunch of reviews and kind of haggling for engineers, I think we put we got like 12 engineers or something like that cuz it was a pretty big migration. You know, it's going to

big migration. You know, it's going to take like a year. groups is the single biggest product surface in all Facebook, which is actually kind of surprising.

Um, yeah, and the the migration kind of worked and and I think something that was pretty fun about it besides just like building relationships and friendships with this infra team I never would have worked with otherwise, which

was in itself so rewarding and so fun.

Um, I think a lot of it was we got to influence the direction of Comet. And

it's kind of weird because for an info project, a product team often cannot influence the direction. and they're

more seen as a customer of it. But what

happened here was because we helped co-build it, we built a lot of the abstractions that were then used by other teams that were also building on Comet. Um, and you know, for example, a

Comet. Um, and you know, for example, a particular one I remember was like relay mutations. So like you send API requests

mutations. So like you send API requests and you need some sort of consistency.

Um, but there's actually this bug where like let's say there's like a button and you press the button. Every time you press it, you send a post request. And

uh every time you press the button, it toggles the state of that button. For

really nice UX, what you want is as soon as you press the button, the state should toggle, which means you need an optimistic update. But also, uh when the

optimistic update. But also, uh when the network request comes back, you need to also update the local cache to make sure it's consistent. And if you're just like

it's consistent. And if you're just like mashing that button, what can happen is that the responses come in out of order and you might end up with a different state than what was in the UI. Um and so I wrote a system to kind of queue up

mutations. So it was like consistency at

mutations. So it was like consistency at the cost of reliability and this was kind of the right trade-off at the time.

Uh and everyone ended up using this and this is how I met like Joseona and a bunch of the relay team that was working on the the data stores. Um, and it was just really fun. And this is something

that since then and before then and you know whenever I work with engineers, I just love when people go a layer deeper and uh, you know, just try to figure out like what's going on and like 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 go talk to users like just be curious about these other parts of the stack.

>> Definitely. and in your agency and getting ahead of comet or this big JavaScript rewrite. You mentioned in

JavaScript rewrite. You mentioned in your in your writing that you know getting ahead of that actually gave you a lot more control and also dibs on opportunities. So when you talk about

opportunities. So when you talk about opportunities there is is this what you're kind of talking about like building these fundamental pieces of prod infra that are impactful for everyone that's going to take on the new

platform?

>> Yeah. Yeah, that's an example of it. Um,

and then maybe you know like a different kind of example is Comet was a lot higher quality than the thing that came before because it, you know, it's like a single page web app. Um, so it can just feel a lot more polished. But we hadn't

yet figured out like what exactly quality means on the product side. And

so I wrote a bunch of notes trying to define that and then did a bunch of tech talks trying to just like teach people on other teams like here's what we learned about quality. Um, and just kind of like setting up the conversation

about that.

you mentioned a big headcount ask for I guess this migration to comment you know I feel like I'd be curious what that

would look like in today with these new tools like cloud codeex etc. I'd be curious like knowing what you know now about cloud code and you let's say you

were in charge of doing that same scoping for that same job. How many

engineers do you think it'd take to do that 12 engineer job?

>> Yeah. So I think overall to move Facebook groups it it started with 12 engineers but I think at the end it was maybe like 20 or 30 engineers or something for about two years. So it

turned out to be a pretty big project.

Um I think nowadays it would be maybe I don't know like five engineers for six months something something like that.

>> So a fourth of the fourth of the time and um like more than a third or less than a third of the engineers as well.

>> Yeah. Yeah. cuz you just like everyone would just have a bunch of quads running in parallel and you know just like let it cook for a couple hours and then it comes back with a PR and then you give it like puppeteer or something so it can kind of see the UI and and adjust and I

I think that's pretty much all it would be and then I you know nowadays the world we're in is so different from a coding point of view because the models are moving so quickly that you know if

you ask me this question in 3 months or 6 months my answer will be totally different in 6 months the answer might be this is actually one engineer um it's just moving so quickly now it's really hard to to do these estimates or

to predict how they're going to change in the future.

>> At this point in your career you you had mentioned something maybe it was tongue-in-cheek I'm not sure. You said

this was when I learned to always present three options in VP reviews since 80% of the time they'll just pick the middle option and then it says you your VP picked the middle option in

frenies. Um what's the thinking behind

frenies. Um what's the thinking behind that?

Yeah, this is this is very much tongue andcheek. Um, but maybe this is actually

andcheek. Um, but maybe this is actually kind of true at Meta at the time.

Um, I think like decision makers that are far away from the work want to know that you did the due diligence of finding the right options and the right trade-offs and that you did the work,

but they also want to contribute somehow to the decision. Um, so, you know, the middle option is kind of the easy way to do that. It's a little tongue-in-cheek

do that. It's a little tongue-in-cheek because I think not all leaders are like this. A lot of leaders will do their

this. A lot of leaders will do their work themselves. They trust their teams

work themselves. They trust their teams more or less. There's sort of there's so many different ways to operate. Um, but

at the time I remember we had like a pretty non-technical leader and this was kind of the way to to help her make make decisions. I think at this point in your

decisions. I think at this point in your career you had the most proximity you've had to senior management. It's you said you were reporting to uh a senior director at some point and you were

involved in a lot of huge scoping conversations. I'm curious what's the

conversations. I'm curious what's the downstream effects of reporting to someone so senior like that.

>> Yeah, I think it kind of depends on the engineer and it depends on the company.

Um, so for example, like you know, now I'm at Anthropic and I think at anthropic it doesn't matter. Um, it

doesn't it doesn't matter which level you report to. There's some of the most senior people at the company report to line managers. Um, a lot of the line

line managers. Um, a lot of the line managers are like XCTO's and things like this. So um, it actually doesn't matter.

this. So um, it actually doesn't matter.

So I think this is kind of like a meta it's a very meta-pecific cultural um cultural observation. I think there's

cultural observation. I think there's sort of like two things going on. So one

is you want at meta you needed uh as an engineer you always needed to find scope. Some of this you can find

scope. Some of this you can find yourself and then some of it your manager helps you find or you know your tech lead or the people you surround yourself with and you know like the PSC process is like growing like famously

growing at meta and so you just have to constantly talk about your impact and like scope is like the biggest contributor to that like if you have enough scope and you executed well that's impact that's the formula I think

the other part was at meta no one had titles so even the most senior engineers their title was software engineer which I actually really love. And um you know like Bell We L We L We L We L We L We L We L We L We L We Labs had this with

like member of technical staff and this is true at anthropic too, but we actually go even further here.

Everyone's title is member of technical staff. It doesn't even matter if you're

staff. It doesn't even matter if you're an engineer or a PM or a designer, it's all the same title. Um, and I actually really love it because back to this point of working outside your lane and

doing stuff that just should be done and, you know, like are just good things to do regardless of what you are personally expected to do. Um, I think this kind of culture just sets that up.

I mean, I I I see a lot of the benefits of the no titles. I could also see a case though where um and maybe this is only true for big companies where you reach out to someone across the company

and you say hey I'd like to I don't know do this collaboration and if your title said director or whatever it kind of is like a shortcut for them to understand

how seriously to take you or how to interact with you like if you're a designer or some other role. So I mean now anthropics got a bit bigger at this point. Do you see uh any of that? I

point. Do you see uh any of that? I

mean, people probably all know you, so maybe you don't see it as much.

>> Yeah, I think I think this is definitely the downside. I think the upside

the downside. I think the upside outweighs it, which is you have to earn trust. And I I think this is true. Like,

trust. And I I think this is true. Like,

you know, regardless of what company you're at, you got to earn it. And just

because you did a cool thing before, doesn't mean that you have you should deserve respect. Well, everyone deserves

deserve respect. Well, everyone deserves respect. Doesn't mean that you should

respect. Doesn't mean that you should deserve authority at a new company in a new setting. Um, so I think even for

new setting. Um, so I think even for people coming in with manager titles, you kind of have to earn it. And in some ways, having a manager title makes it a little bit harder to earn this kind of trust. Um, so as an IC, you got to do it

trust. Um, so as an IC, you got to do it either way. And I I think just the lack

either way. And I I think just the lack of titles makes it a little easier. At

this point in your career, you were kind of like becoming more and 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. And I

was just thinking about how do you do that if there's so much to scope and you know you're one person. How do you go about doing such massive scoping requests for leadership?

>> Yeah, this was a totally insane time. So

I worked a lot with uh Tina Shutchman who's uh she she's now at Microsoft um but she was she was my manager at the time and then uh Ephe who's who's my manager after and there was a lot more

investment going into Facebook groups at the time. So I think the org was maybe

the time. So I think the org was maybe 150 or 200 people when I joined and by the time I left to Instagram I think it was like 600 or 800 people something like that. So there's this feeling from

like that. So there's this feeling from Zach that Facebook app should be all about communities and he just wanted us to go like faster and faster to make that a reality and you know as an

executive your kind of biggest way to do that is to put the right people in charge of decisions and then uh to give them resources and so like in you know in the case of meta it's it's just engineers um you don't need like GPUs

for this you need like engineers to do stuff and so we pitched this project to uh to Zach and it was called communities as the new organizations that was like the internal name and uh he grin just

like a a bunch of headcount to go towards this and so we just had to figure out what these people will do and you know for him I I get it it's like if the thing is important you got to put a bunch of people on it in hindsight what

I would have done differently is I I would have put way less people on it because what matters is like solving people's problems and building awesome product and this actually has to kind of be bottoms up and you kind of want to

like slowly dial this up as you find product market fit for new product lines you can't just do it all at once. And uh

yeah, we just had to like scope out all the stuff. Like there were weeks where I

the stuff. Like there were weeks where I had to, you know, do like a scoping dock for like, okay, we're going to put 30 engineers on this. Here's like three technical options. We're going to pick

technical options. We're going to pick this one. Next project, we're going to

this one. Next project, we're going to put 20 engineers on this. Here's three

options. We're going to pick this one.

Next project we're going to do. And just

like doing this like over and over again just to have like, you know, some some sort of confidence that this thing isn't totally crazy. We did some baseline

totally crazy. We did some baseline technical scoping roughly matching the number of engineers to the project. And

there there's actually some pretty fun stuff like I remember we were trying to merge Facebook groups and uh pages at some point like in the in the data model side and this was this like very gnarly

migration it would have been you know to fully do it this is like many years and like probably hundreds of engineers to fully do it because you have to do it across like the data model the product layer integrity systems ad systems

there's just all sorts of stuff that has to get merged and at the time Ysef Carver uh he just joined I think he came from either profile or events like a different or that that joined forces

with groups to make this happen and he was working on it but he was kind of struggling with a with a decision at the time and I think he was even more senior than I was but he just like wasn't making the decision on the data model and so I just took a bunch of people and

I was like all right the tech leads across the entire org we're going to spend the next like 3 hours on this day and we're going to do this like essentially like game where we get to do

architecture and so I split everyone up into two teams I think it was like blue team and green team or I I forget what these were. And we gave everyone this

these were. And we gave everyone this like this problem of like how do you merge these data models? Here are the requirements. And then everyone had 3

requirements. And then everyone had 3 hours in a whiteboard and they had to come up with a design. And what was cool is that going into it, we had no idea how we would do this because it just

seemed too crazy of a problem. But the

going out of it, we had two designs that were 80% the same. And so it was really obvious what we could execute on. And

then the 20% where the differences were, it was very obvious where the risk was.

And so we could kind of front front frontload a little bit of that risk with a little bit of technical spikes. Um but

also we can just start execution right away because we knew exactly what we had to do.

>> 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 um 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 like kind of a crazy idea?

>> Yeah, it was sort of crazy. I mean, with this sort of thing, you just have to kind of do it. So, I just I just kind of told everyone, "Hey, we're doing this."

And then I just put it on everyone's calendar and um it just seems fun, you know? So, like as an engineer, you would

know? So, like as an engineer, you would want to do it. But I think this is the sort of thing where like sometimes you need consensus and sometimes you just have to act. And in this case, because the path was unclear, it was important

to act. But at the same time, I didn't

to act. But at the same time, I didn't know how to proceed. So, we had to kind of get everyone together to build consensus. And so, I think it's like as

consensus. And so, I think it's like as a leader, you're kind of always juggling these kind of two things.

>> After that experience, just giving being given hundreds of engineers and scoping things out, do you have any tips for someone who's like a tech lead who's needs to do quick, you know, scoping?

Anything that worked well for you? I

think the biggest thing I think the biggest foe that I've seen is people just taking too long and getting too into the weeds. there's always an infinite number of details. Just start

with a high level. You know, most technical scoping you can do within like 30 minutes very very roughly. Um and if you don't know the systems like nowadays you would just use quad code run in the codebase and just ask it to like you

know like what are all the systems involved? They can actually just do this

involved? They can actually just do this for you. And this is another just

for you. And this is another just totally insane change. You know I when I was doing this stuff I never would have expected that AI could do this for me

now. Um but now it does. in the past. I

now. Um but now it does. in the past. I

think that would have been my biggest advice though is uh just time box it.

Spend maybe 30 minutes, maybe like couple hours max. If you have to like dig through code and stuff, um definitely reach out to experts and just make a list of experts. Talk to all of them. Run the design by them. Don't just

them. Run the design by them. Don't just

ask them for input. Give them a straw man cuz then they can actually like give you feedback on it and it's something to go off of. Continuing with your career story, I think the thing that got you

promoted to senior staff or IC7 was um public groups on Facebook. So I'm

curious like the story behind your involvement in that and you know anything interesting that happened at that point. Yeah. So public groups was

that point. Yeah. So public groups was one of these projects that came out of this uh the scoping for um you know like making Facebook groups more about communities. There's this like one very

communities. There's this like 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 like explaining this to anyone that wasn't there. They're like,

"Wait, this is like a oneline change."

And I'm like, "No, it's not." It's like 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.

>> So you're saying um you can just view like you have read access for all all groups essentially or public groups?

read access for all groups and for some groups even comment access. So you can comment without joining first.

>> Interesting.

>> And this is the thing you know it feels like a oneline change and it actually was a oneline change but there's all these downstream implications that were so tricky. So one is um you know in the

so tricky. So one is um you know in the data model there's essentially a field in the database that was like group member and we had this like really intense technical debate about like these people that are commenting in a

group are they group members and 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

and then after we switched to this model where to join a public Facebook group you just you just essentially press like follow and we actually went back and forth should it be join or follow like what's the right verb to describe this but it was essentially follow cuz

there's no reciprocal action you know if you follow a group are you a member like should you be stored in that same part of the database and we we just went back and forth on this for a while and I

remember at the time there was this like really senior engineer Bob he was kind of the most senior engineer in the in the or at the time and he felt very strongly that it should not be the same thing and he kind of pushed us pretty

hard um even though it would be a ton of engineering work to migrate stuff to make at a different thing. And so we did this work um because he was actually one of the early engineers on Facebook group. So he knew it really well. Um and

group. So he knew it really well. Um and

he felt pretty strongly. There's a bunch of these other like downstream changes around uh like moderation and different new like admin tooling that admins would need to handle kind of the influx of spam and things like this. And I

remember at the time thinking like if anyone can make a comment, the comments are just going to be like filled up with spam. And I had to hard I had a hard

spam. And I had to hard I had a hard time kind of convincing people of this.

And so at some point I built this like Monte Carlo like visualization of how this would work. And it was just like this like really simple kind of like scratch pad of you know like a comment comes in there's a certain probability of it being good or bad and then like

what actually happens to comments. And I

think that actually did a pretty good job of convincing the integrity teams to jump in and help with this. And so at the time the pages integrity team jumped in and they helped with a comment ranking because kind of ranking spam

comments lower was the main technical mechanism to make it so people don't see these comments. So there's a bunch of

these comments. So there's a bunch of these like pretty gnarly downstream implications of uh letting people participate. There's also this data

participate. There's also this data model migration that we're doing. And so

to do all this, we had to staff a big team to um to kind of make this happen.

And so we hired a new director, Yammen, who um hired a bunch of engineers.

There's a bunch of internal transfers.

So some of the most senior engineers from the org like uh there was like Henry Henry Long uh Joe Cham there was like a few other engineers and they were all working on this and I was the same

level as them. I was like a you know an IC6 at the time and so were they and I remember just feeling this kind of imposter syndrome of having to kind of direct them and kind of point them at

work knowing kind of in my mind that we're the same level even though levels are hidden. you kind of you know you

are hidden. you kind of you know you know through like rumors and stuff who's what you know in hindsight I think this is sort of like misplaced imposttor syndrome because levels don't matter at

all this is my current view and you know 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 and so the level actually

doesn't matter that much but at the time I remember just like really thinking about this and it it was just kind of hard to step into this role And eventually I did it. And it's funny,

eventually the thing that got me the promo to IC7 was reversing this decision that Bob did cuz he wanted to do this big migration.

And we did it. And it was just like, dude, it was so much work. It was like it was like 6 months or a year of work or something just migrating just hundreds and hundreds and hundreds of call sites to to do this correctly. And

then technically I felt like actually what we did is we essentially just added an if else at every single one of these call sites in the process. We audited

all the call sites. So we kind of knew that it was safe but uh we didn't actually change the logic. And so

actually what we learned is that yes member is the right field to model both followers and group members. 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

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.

And I think for Bob it made he he felt better about me as a technical leader because he knew that I was wishing I was willing to pull back to to push back on

um decisions that even senior folks make. Um and in the end this was the

make. Um and in the end this was the right thing. So we reversed the

right thing. So we reversed the migration. It also took a long time to

migration. It also took a long time to do it, but in the end it made it so everyone building on this info could do it and everyone wasn't always constantly bumping into this like should I use this

field or or this field.

>> Yeah, I'm curious about that part cuz you had a strong technical disagreement with Bob or senior TL. Um, but the outcome at the end is actually it seems

like it strengthened the relationship.

He was a champion for you in your your promotion. So, I'm curious, how would

promotion. So, I'm curious, how would you recommend going about strong technical disagreement in a way that doesn't hurt the relationship?

>> I think the biggest thing is you have to earn it. Yeah. You just have to earn

earn it. Yeah. You just have to earn trust and it could be as simple as, you know, like what I did at the beginning, which is just disagreeing and committing and showing that I'm willing to do that and I'm willing to just execute if

someone else thinks it's a good idea and I kind of look up to them.

But also you have to kind of show that you have good technical judgment. Um but

you can't really do that until you earn trust. So take the time to get that

trust. So take the time to get that trust first.

>> And then on the imposttor syndrome, um leading those engineers that were also very strong. Um do you have any advice

very strong. Um do you have any advice for overcoming imposter syndrome?

>> Yeah, just don't overthink it. You know,

no one really knows what they're doing, you know, at any level. No one really knows. We're all just trying to figure

knows. We're all just trying to figure it out.

>> That's easier said than done. Was there

like a an aha moment where you realize actually maybe I do got this or this isn't that big of a deal? You know, I don't I don't think so really. There

wasn't a single moment. It just it kind of goes away over time. And I think at every at every level, it doesn't matter what level you're at, you should always feel a little bit of imposter syndrome cuz if you don't, then you're not

pushing yourself hard enough.

>> At this point in your career, you were like more and more of a tech lead and and therefore you were writing less and less code. Um and you mentioned that um

less code. Um and you mentioned that um you know at Meta especially there's cases where other functions are underst staffed and you view that as an

opportunity for engineers so to be you know more product minded and maybe help out with uh you know the PM opportunities. I'm curious when would

opportunities. I'm curious when would you say that you should go that direction as opposed to escalating and say hey we need more PM support um and you know trying to write more code

instead. Yeah, you have to understand

instead. Yeah, you have to understand the trade-offs. I think this is the this

the trade-offs. I think this is the this is the thing that I think a lot of people don't really get when they push for stuff or, you know, I think a very common failure mode is an engineer will push for an idea and then get gets

frustrated when no one else buys into it or wants to fund it. Um, or the organization just like doesn't listen or their leader doesn't listen. But what

you have to do is understand the trade-offs. And whoever it is that

trade-offs. And whoever it is that you're trying to convince, think of it from their point of view. What do they care about? What are the projects

care about? What are the projects they're working on? What is this trade-off against? if they do this

trade-off against? if they do this thing, are are they going to see their work as a as a success? Um,

so I I think I think that's really important and for some orgs at sometimes they might not have PMs cuz it might just not be a very sexy project and so it might be really hard to hire and

maybe the leader is already feeling that pain. Maybe for some orgs uh they are

pain. Maybe for some orgs uh they are trying to hire PMs but there's actually just much much more important things those PMs should go to. For other orgs, they might they might actually have like

too many PMs. And so actually, if you ask, that's the right thing to do. Uh

because they could just take a PM off a less important project and put on your project cuz it's more important. So I

think it's really important to kind of be situationally aware, understand the context you're in, and understand how your decision makers think about it. at

this point and this is kind of the end of that part one of your story. You

credit a lot of your success to again the side quests and like having these side projects or running list of you called them 20% time ideas and I'm

curious do you have any tips on how to find opportunities for engineers? Yeah,

I think at some point there was probably I forget the exact numbers, but there was probably like 5000 engineers or something like this that were just like working on these like side quests that I like scoped out and like spun out of various points. And so pretty much like

various points. And so pretty much like every week I I'll think of like some project, you know, just like on a run or something or maybe like while I'm coding I think of some idea, I'll just do some basic validation and then I'll just ping

an engineer that I know and be like, "Yo, are you interested in this?" And

then I'll connect them with a couple other engineers that might be interested. And this kind of added up

interested. And this kind of added up very quickly. I think the for me one way

very quickly. I think the for me one way that I really think about my work is how can I do less of it? And as an engineer, our superpower to do this is automation.

The most tedious stuff you can automate.

And this is something that's like really hard actually for other fields, but for us it's this incredible thing that we can do. And as it's something a lot of

can do. And as it's something a lot of engineers don't really do 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. And

so a thing I often did was every time I did a code review, if I was commenting about a particular kind of issue, maybe like a stylistic issue or something, I literally had a spreadsheet where I

would tally up that issue and I posted kind of the link to that poll request and then I would do this for every code review and then when I commented about the same kind of thing more than a few times, I would just write a lint rule

for it to just automate that. Um, so

this is kind of an example of leverage.

So, and at some point I automated most of my code reviews cuz like I just had a you know like a flock of lint rolls that were just like doing all this work for me. And I think this is actually kind of

me. And I think this is actually kind of similar because all these side quests it was improving prod infra and dev infra.

And these are things that slowed me down in my day-to-day coding. And this is why like when I was doing west coding this was actually very dangerous because as an engineer you need to be anchored to reality. You need that intuition and if

reality. You need that intuition and if you're not in the code anymore then you lose it very quickly. It's it's a very dangerous place to be in. And so for me when I was in the code a lot there was all these really cool ideas that came

out of it and it was leveraged not just for me but for the whole edge team because again of this principle that if you have a problem probably other people have it too. And you know I did like YC

back in the day and in YC they teach you that first you build for yourself. You

have to build like awesome stuff. You

have to build stuff people love. But if

you're trying to find a market to build for you start by building for yourself.

And that's a pretty good indicator other people probably have that same problem.

>> 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. So I could totally see um

an engineer. So I could totally see um you had like 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 you know overseeing them. It's the the leverage is really uh

them. It's the the leverage is really uh insane.

>> Absolutely. Yeah. And and it's also just like an example of being contextually uh was it situationally aware >> um because you know at meta at the time engineers were evaluated in the

performance cycle uh we looked at project impact people do you remember the other >> direction >> direction >> and edge excellence >> and edge excellence yeah and the edge excellence is a thing that a lot of

engineers struggled with and so you know I was you know one of the people that came along and was like hey if you want to do edge excellence here's a project and people are already incentivized to do it. So, they see it as an

do it. So, they see it as an opportunity. And I think this is just

opportunity. And I think this is just like I don't know. I think it was a chance for me to kind of hone my skills about working with people where you never ever want to tell anyone what to

do in any in any context. In a personal context, in a work context, everyone hates being told what to do. But if you understand what a person wants, then you can go to the right person with a red opportunity and they see it as an

opportunity. Um, and this just always

opportunity. Um, and this just always works better for everyone. When I think about these 20% time ideas, I mean, there's the there's the top of funnel, finding the ideas, and then there's

actually, you know, executing on them, the, you know, getting someone to do it or whether it's yourself or someone else. Um, the thing I'm interested is

else. Um, the thing I'm interested is the top of funnel, like how how do you source so many ideas um as an engineer for these side quests that are impactful?

>> Just common sense.

I don't know. Maybe maybe spidey sense.

I I don't know the right word sense like how so like what's a what's a concrete example?

>> Yeah, like a really concrete example is um you know like I think lint rules are a good one. Maybe maybe another one is there were all these cases where we had

sevs because uh Facebook groups were not being tested with very large sets of so um and so like for example and so kind of like this is kind of like a Facebook

way of saying like you know rows in a database. So you could imagine like a

database. So you could imagine like a Facebook group with like 10 million members. Like no one's ever tested this.

members. Like no one's ever tested this.

There's no like unit test for this. You

only see it in production. And when I looked across the org, I started seeing similar cases of this. There's, for

example, like if you have a profile with like 20 million followers, a lot of stuff breaks. But obviously like no one

stuff breaks. But obviously like no one tests this in an automated way just cuz it's kind of annoying to write a unit test with this much data. And so there there's a bunch of instances of this.

And then um I pitched an engineer to build a way to write unit tests for large data sets. So you know 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. And uh I think this infra

attendees. And uh I think this infra still exists. Um and it's you know it

still exists. Um and it's you know it prevents a lot of issues and this is something where you can scope it and then he brought in a bunch of other engineers to do the work and and help him out with it. So I guess just think about the problems that you actually hit

day-to-day.

>> Got it. Okay. So think about the problems and if you're experiencing that problem repeatedly then it's time for automation and that's like a great uh better engineering project.

>> Yeah. Exactly. Exactly. Like if you hit the same problem like two or three times you should probably kind of look around see if other people are hitting that project hitting hitting that problem too.

>> The last leg of your career at Meta um this is where you got the E8 promo. I

know that um you moved orgs. So, you did all of your growth in Facebook groups and then you moved to Instagram. I'm

curious, uh, what's the story behind you moving orgs to Instagram? At the time, um, I was dating, my wife and I were

still, uh, dating. And, um, she was living in Berkeley, I was living in SF.

And at some point, she's like, I found my dream job. And I was like, sweet, awesome. And then she was like, we're

awesome. And then she was like, we're gonna have to move. And I was like, okay, great. we we've been dating like 3

okay, great. we we've been dating like 3 months at the time and uh we were kind of deciding like should we like keep dating and um and so she was like yeah we we would have to we'd have to move if

you want to like keep dating and I was like yeah okay I do let's let's do it and then so the job ended up being in like rural Japan like it was sort of like middle of nowhere and I was trying to figure out like how do I do it because I really like the work that I

was doing >> and so first I talked to uh like Facebook groups leadership and tried to set up like a Japan out there for for Facebook groups. That

didn't really work for, you know, a bunch of kind of organizational rules.

Um, 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, I think like YouTube or something. Uh, and then at the time Will

something. Uh, and then at the time Will Bailey reached out and he was in the Instagram Tokyo office. He was part of this like landing team for for Instagram and he was like, "Hey, I kind of want to grow this office. Do you want to be part

of that?" And I was like, "Yeah, let's

of that?" And I was like, "Yeah, let's let's do it." And I didn't know anything. I I didn't even have Instagram

anything. I I didn't even have Instagram installed at the time. I'd never used it in my life. And um I so I I said yes and then I immediately downloaded Instagram and then like I moved like I think like

the next week or something. Um so pretty much or or actually you know I think it was like a few weeks that that I had in the US.

But I I moved out pretty quickly. Um and

I actually really fell in love with the Instagram culture. Um it was very

Instagram culture. Um it was very different than Facebook culture. big

emphasis on building awesome products, on on shipping stuff that people don't use, on thinking about things not just from a data point of view, but also from a human point of view and an experience

point of view. And you can see this in the app and in the craft that goes into it. It's just completely different

it. It's just completely different engineering and product and design cultures between the two companies. Um,

so I learned so much being being on that team and that that was such a fun journey.

>> You mentioned the the un shipped part.

Um, what what is that?

>> Unchipping 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. And so, you can think

of an app where you only add features to it. And over time, the features

it. And over time, the features accumulate and they add up. And you

know, if every feature is used by like 10% of people, the average user sees a bunch of features that they don't use.

And so, it seems cluttered and confusing. And when they open the app,

confusing. And when they open the app, they don't know what to do. And uh you know like with software fundamentally the screen is a limited size. That's the

limited real estate. Uh there it's a limited resource that all the different features are competing for. And so by adding a feature that's taking the opportunity away from you know a

different feature the person could have used. Um and so unshipping is the idea

used. Um and so unshipping is the idea that you have to meet some sort of usage bar and if a feature doesn't meet that bar then we just delete the feature. And

a small percent of users are going to be pissed, but it's actually great for the majority of users. And on average, it's really great for everyone >> at this point in your career. Um, I

mean, you moved, you didn't just move orgs, you moved across the world to work at Instagram. And I think when you're

at Instagram. And I think 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 cuz they say,

"Oh, I know Boris and I know his past work." But I'm curious, how did you

work." But I'm curious, how did you build up credibility uh at Instagram uh when you were so far away from everyone else?

>> I think a lot of the credit early on this goes to like Nam who was Nam Guian, he was the he's still the VP of Avenge at Instagram and and Jeff Hang um who

was my director at the time but he now he's a VP. Um and you know will I think there was a lot of connections made by these people. So you know for example

these people. So you know for example Nam was like hey you really like doing you know working on code quality and like tech debt reduction you know which we call you know better engineering at meta and he kind of connected me with

the people working on it and this was like Lucas Camera and um Gabe and a bunch of this bunch of these other folks that that were working on this stuff. Uh

so so those connections were really useful. Um, and then I think a lot of it

useful. Um, and then I think a lot of it was I just had to earn the trust again.

And honestly, this is a healthy thing to do. And I think this is one of the

do. And I think this is one of the really awesome things about meta engineering culture that there are not titles. And so you kind of have to

titles. And so you kind of have to constantly reearn your trust. And you

know, even if I was a great engineer in the past, I may not have been a great engineer at Instagram. And if I wasn't, then I don't deserve influence. I don't

deserve to have a really loud voice that people listen to. So I had to earn it along with everyone else. And so my first few weeks I spent a lot of time like meeting people, mapping out the

org, mapping out goals, writing a lot of code so I can get to know the codebase.

But then in Japan it was totally different because you know like 400 p.m.

Tokyo time was like or it was like 9:00 a.m. Tokyo time was like 7:00 p.m. New

a.m. Tokyo time was like 7:00 p.m. New

York time. There was just like no time zone over.

>> It was rough. Yeah. Um, but it was also great because I think in the few years before I was doing so many meetings and docs and all this stuff, I just wasn't coding. Um, so I just started to feel

coding. Um, so I just started to feel pretty unhappy cuz like as an engineer we code. That's that's what we do. Like

we code. That's that's what we do. Like

that's that's the reason we pick this job is you like for me like when I write code I have an emotional relationship with a code and it's something that I think about when I'm really deep in a

problem. I dream about it. So it's just

problem. I dream about it. So it's just so important for me to code. And when I wasn't doing this for years, it was sort of rough. And I think I was starting to

of rough. And I think I was starting to burn out a bit. And so, actually, it was it was a gift to be in this time zone where I literally couldn't do meetings cuz people weren't awake or didn't want to like, you know, do 9:00 p.m. meetings

just to talk. Um, so I didn't do any more one-on- ones. And this is actually still something I I don't do. So, I

still don't do any standing one-on- ones. And I just could spend a lot of

ones. And I just could spend a lot of time coding. And what I realized is I

time coding. And what I realized is I was one of a few engineers at Instagram at the time that was coding this much.

Um, you know, people code, but people don't code that much because there's all this stuff that fills up your time there. There's meetings and, you know,

there. There's meetings and, you know, docs and all these other obligations.

And I was able to do a lot of stuff that I think everyone else wanted to do, but just didn't have time. Um, and this was

kind of a superpower in in that org. And

pretty early on, Nam connected me with uh with Joel Pamer, who's still a good friend and and and mentor and um he's he's at Google now. And we just started talking about like you know at the time

the codebase was written in Python and uh there it was sort of rough for a lot of different reasons and really the codebase should have been moved over to hack which is the main Facebook monolith you know and this is where all the

language support is. There's so much infra HHVM is just this absolutely phenomenal web serving stack. There's

nothing else like it in terms of like efficiency. If you're using GraphQL, you

efficiency. If you're using GraphQL, you absolutely have to use it because it's just so optimized for this stuff. And

Instagram just wasn't using any of this.

And engineering was suffering. Like in

the really early days, you know, like when like Mikey was at Instagram, really basic decisions were the the basic principle for decisions was do the simple thing that

works. And this worked really well. But

works. And this worked really well. But

then at some point it stopped working once you get to like a thousand engineers, 2,000 engineers working the codebase. and you know many many years

codebase. and you know many many years of techad and products built on top of each other you kind of have to do you have you have to make slightly different decisions than you would have made at the start and so even if Python was

absolutely the right decision at the beginning it was not the right decision by the time I was there and this was painfully obvious as an engineer and I think a lot of other people saw this but what stopped them was just the amount of work it would have taken to to move the

stuff over and so I just started like scoping this and kind of figuring out what it would take and so I started by finding the people that would disagree the And there's a bunch of these like info old-timers that just thought this was

like a terrible idea and would never work. And so I went to talk to them

work. And so I went to talk to them first at like food in New York and you know like we got a bunch of beer and just got to know them as people before we even talked about the technical problem. You have to build trust. So I

problem. You have to build trust. So I

had to kind of get to know them as people and this was so valuable and this is still a lot of my friends today. Um,

and after building this trust, I also learned there was a bunch of other people that actually did want to do this and were kind of afraid to say it. And

so these people came out of the woodwork too. And eventually we started scoping

too. And eventually we started scoping this and this project kind of spun out.

And it it's actually still going today.

And there's, you know, many engineers working on it. But it but it was it's funny because at Facebook I think this kind of problem rarely happens because the org is so engineering driven. At

Instagram there were many problems of the shape because the org is very product driven. So there isn't just a

product driven. So there isn't just a lot of time for those engineering driven initiatives. this project at some point

initiatives. this project at some point I mean you got it off off the ground kind of this bottoms up initiative and then at some point it became high pry

enough where it needed that uh in-person support of someone that wasn't in Japan and I understand that Jake Bolum is someone that you helped onto the project

and he kind of took more of a a lead role um but locationbased and you know close to everyone else so he can help shepherd it along. Um, I'm curious your

thoughts on that point of delegation. Like when do you decide when to delegate something so big and when do you decide, oh, I I need to still be around and how do you navigate that trade-off? Jake is

amazing. We're we're, you know, we're friends. Every time I go to Seattle, we

friends. Every time I go to Seattle, we we hang out and he's just one of the best engineers I know. So, it was obvious that he would be a good owner for this. The same rules of delegation

for this. The same rules of delegation apply as always. So, you know, you delegate. You never delegate the thing

delegate. You never delegate the thing you don't want to do. That's kind of 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. Um and there's this really great

well. Um and there's this really great book uh high output management by uh Andy Grove. He was a you know old Intel

Andy Grove. He was a you know old Intel CEO and it's just like the most boring sounding book ever, but it's just like the best. And this is one of the pieces

the best. And this is one of the pieces of advice is delegate the thing that you like to do so then you can monitor progress. And so yeah, it's it's kind of

progress. And so yeah, it's it's kind of the same thing. You kind of delegate a little bit. you check in. The more trust

little bit. you check in. The more trust you have, the less you have to check in.

And with Jake, he's so good technically and so proactive. There's just very little I had to do. It it was very much on track from the start. And so I think this coupled with um some other work uh

large migration to kind of GraphQL or modernize some of Instagram's data model ended up getting you uh promoted to this principal level before you left Meta.

Um, what was the story behind the promotion or anything that you might share >> that promotion? I think Will in in a one-on-one that I had with Will, my manager, he was like, "Hey, like I think

you should like we should put you up for IC8." And I was like, "Cool."

IC8." And I was like, "Cool."

>> And that was pretty much it. I I hadn't really thought about it. Yeah, it's not something I really asked for.

>> Um, I think Will was just like does a great job of recognizing people and kind of advocating for his team and he felt that I was ready and yeah, that was that. at any point in your journey

that. at any point in your journey because it sounds like you were impact and impact only and growing and your leverage and your credibility everything was growing and then the promos were

this lagging thing where they just oh they kept happening as a byproduct. Um

I'm curious though to structure your thinking about how to um get more leverage or kind of have more impact.

Did did you ever think about the levels or would you say that it's not good to think about like oh what's the next level more think in terms of just I don't know leverage or impact or

something else you have to think about what levels are for right 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 so for example in performance reviews the engineer at a particular level you can compare them to another engineer at that same level and also sometimes on the

finance side different engineers or you know the pit costs a different amount.

So you can kind of think about what kind of portfolio you want. So you know levels it kind of exists for company reasons and not for engineer reasons.

And for me it's just never the way that I thought about any of this. Like the

thing that I like to do is work on interesting projects. I like to figure

interesting projects. I like to figure out the problems and solve them. I like

to um just make the things that people use delightful like the products that they use delightful. this this is what really motivates me. So for me, this was just never really the way I thought about it. And I I don't know like my my

about it. And I I don't know like my my first week at Facebook, I was like an IC4 and I was I had like all these ideas for stuff that we should build. And so I just started writing like product briefs. And then I remember I went to

briefs. And then I remember I went to like the VP of like connectivity and like pitched him some idea and he just didn't understand it at all and thought it was terrible. And then like that didn't work. And then I had another idea

didn't work. And then I had another idea for messenger and like I went and like pitched that and like they also like didn't do it. But then they actually did end up building it a couple years later, this particular idea. So yeah, for me

it's just like, you know, what are what are the cool ideas and like how can I help and who else is interested in this stuff and how can we build build cool stuff? You left Meta to go to Anthropic

stuff? You left Meta to go to Anthropic and I'm very curious what was your thinking about going to anthropic.

>> I remember using chatt for the first time when it came out. This was uh you know this was like year years ago and I remember I was I was in Japan. I was the only engineer in my town. I was the only

person that spoke English in my town and there's just no one that I could talk to about tech stuff and I remember every every morning I read Hacker News and I I

remember using Chat GPT and I was just like blown away by by the product and just this this feeling that it gave me of just nowadays we take it for granted

but you know LMS are just magic. It's

just this absolutely incredible technology and I think now my view of it has shifted. It's like to me it's LMS

has shifted. It's like to me it's LMS are this kind of alien life form that we get to nurture and we get to bring into existence. It's not just a technology.

existence. It's not just a technology.

And I'm also a really big reader. I I

read a lot of sci-fi. That's kind of my my big genre. Um and so at the time I was like, "Oh my god, I have to work on this stuff." And you know, what are what

this stuff." And you know, what are what are the labs that are that are working on it? So I went to talk to friends

on it? So I went to talk to friends working, you know, at various labs. And

I feel like when I came to Anthropic, I remember my first lunch. This was with Ben man, who's uh one of the founders here. And we were sitting at lunch with

here. And we were sitting at lunch with like him and a bunch of other people.

And I mentioned this like weird like sci-fi book that I like. Uh it was I think it was like by Greg Egan or something. It's like hard sci-fi author.

something. It's like hard sci-fi author.

And I've literally never met anyone that's read this book. And at the table I kind of gave an anecdote from it. And

everyone around the table was like, "Oh yeah, yeah, that book was good, but like what about this other book?" And so it was just like this group of people of these like intense sci-fi nerds, these people that think so deeply about these

same problems I care about. And I I think the other part for me was how you're reading a lot of sci-fi, you kind of get a sense of, you know, in a very speculative way how this thing can play

out. AI is just so transformative to

out. AI is just so transformative to society. I think it's hitting

society. I think it's hitting engineering first and it's going to hit every part of society. It's going to affect everything. And we're seeing the

affect everything. And we're seeing the very first waves of this right now.

And I think I just, you know, like I I read enough that I kind of knew the bad ways that this can play out and there can be so many ways this thing goes wrong. And so for me, anthropic was just

wrong. And so for me, anthropic was just the obvious choice cuz I wanted to be at a place where in the tiniest way I could make sure this thing goes well, which is

as an engineer, this is all I can do.

Um, and it it's funny. I think like before I joined, I sort of took safety seriously. Like you know, it's like a

seriously. Like you know, it's like a thing that can happen. And you know at Meta it was always seen as this kind of tax where integrity teams and you know and so on they kind of like they get you to do stuff but it's not really the

thing anyone's really excited to do because it's not the product. And so

this was kind of my view of safety before but at the same time I kind of speculatively knew that it could be kind of a very different thing. And now being at Anthropic, I know it's completely different and I

see every model that comes out and kind of the new risks that come with it and how as a company we put our money where our mouth is, you know, in terms of like how much compute goes to safety research

and alignment research in terms of like how many people work on this. We've held

up model releases in the past because we did not know that they were safe and so we had to make sure that they were safe before. Um and I think also like with

before. Um and I think also like with Opus 4 the risks just went way up like if the model can design you know like bioviruses and can do these things that are like really really dangerous and

it's not just like you know like the baseline risk is something like election manipulation. This is something that you

manipulation. This is something that you know like at was a really big deal. This

is sort of a risk for kind of a low-level model. As the models get more

low-level model. As the models get more dangerous, the risks get higher and very quickly you get into this territory where people can use the model to build things that are actually dangerous for

humanity. Like not not just like you

humanity. Like not not just like you know like uh you know politics in a country but like literally the existence of humanity. Um and these this is not

of humanity. Um and these this is not sci-fi. This is a real risk today that

sci-fi. This is a real risk today that we actively have to fight. Um and so for me just like getting to be a part of this and getting to contribute a little bit this this is just what put me over.

What about when you joined? When you

think about the engineering cultures that you came from compared to enthropic, were there any really jarring differences?

Yeah, I would say the two things. One is

still being a startup, there's a lot of common sense. Um, and it's funny. I

common sense. Um, and it's funny. I

think this is something every big company loses and it's sort of this thing you have to fight because over time the decision makers get more distant from the impact of their decision, whether it's the product or

the people or whatever. you have to come up with all sorts of processes to bring them closer and to improve the quality of decision-m but still being at a startup uh everyone just has common sense and generally just does the right

thing. So I don't have to spend a lot of

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 it's obvious and everyone just does it. I

think the second thing is for me personally something that I learned over time motivates me the most is mission.

It's so important and it's the thing that keeps me going to work every day excited to go to work every day. It's

the thing that makes me like code on the weekends because I want to do it, not because there's a deadline. Um, and so I I felt this a lot actually in Facebook groups. It it was very missionoriented.

groups. It it was very missionoriented.

And um, for a long time, Jen Dolski was the VP and she she used to be the CEO of change.org. And so she ran all of

change.org. And so she ran all of Facebook groups like a nonprofit. She

had like a theory of change and this theory about how you want to connect people to like-minded people to form communities and it was just so motivating to work on that. And I feel like at Instagram, you know, maybe

because of the geographic distance or maybe something else, I just never quite felt that same mission. Um, but I feel like at anthropic I feel that so strongly and um that's probably the most

exciting thing for me. I know that you know you're you're credited as the creator of Cloud Code and I think you've you've told that story in many places um

but I'm kind of curious uh I was talking with a friend about what the environment was like when cloud code came and there were actually a lot of competing existing tools that hooked into the

model and I'm curious what is it that was different about cloud code that kind of won out and just caught like wildfire internally At the time coding looked very

different. If you thought about AI

different. If you thought about AI coding, people thought about like autocomplete. That was essentially it. I

autocomplete. That was essentially it. I

think there was like some very early agents, but it was kind of a secondary thing next to the auto autocomplete. And

often times it was used for Q&A. Um it

wasn't really used for coding. And so

when people thought about AI for coding, it was just a completely different product that you imagined. You know, it was like tab to autocomplete.

And I thought that's what it was. And I

thought that was kind of the state of it. And then um Ben who um was my

it. And then um Ben who um was my manager at the time uh he pushed me to think a little bit bigger and he I think really internalized cuz you know he was

there from the beginning of of Enthropic and you know he was like at at other labs before and so I think he really understood the scaling laws kind of internally about how quickly the models are improving and so he actually pushed

me really hard to be like don't build for the model of today build for the model 6 months from now. Um, and so honestly for a long time quad code was not a great product and even when it was

used internally I used it for maybe like 10% of my code or something like this.

You know use it sometimes but it really just can't do most things cuz the model is not capable enough and then at some point we released uh set and opus 4 and I think this was maybe March of this

year and the product just worked and we saw this in kind of the usage data and I saw this in my own coding. I started to be able to use it for probably like half of half of my code. And this was totally

borne out because this was actually like literally 6 months after starting the project. This was the timeline. And you

project. This was the timeline. And you

know at this point most of quad code is written using quad code. I think it's like 80 or 90%. If you look at teams at anthropic, there's some teams that you know like 90% of their code is written

using quad code. Um this is not just our team. And if you look at the impact on

team. And if you look at the impact on productivity even though anthropic has tripled I think since the start of the year uh productivity per engineer measured in you know like poor cost we

were talking about this before has grown like almost 70% per engineer because of quad code and so you know like as a product person I usually think a step ahead and I think being at a lab you

have to actually think kind of differently you have to think a step ahead um not two steps ahead um but also you have to be really aware of the model and kind of the exponential potential that we're on.

>> Did you see the recent interview with Karpathy?

>> I haven't had a chance to watch it yet.

>> Okay. So, one thing that he said in the podcast was kind of like a you know pushing back a little bit because um basically vibe coding although it has

a lot of miraculous results because of what it can generate there's also a lot of like he said like slop or you know there's like some drawbacks. So I'm

curious like how do you think about that when the model produces um 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.

AI coding is a tool like every other tool that we use and you have to learn how to use it. So I think one of the most you know Karpathy obviously like he knows how to code. I think a lot of people that are new to this kind of

tool, they 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. Um,

and so something that I do for the team is for the quad code team, we have the same exact bar regardless of whether the code was written by the model or by a human. And so if the code sucks, we're

human. And so if the code sucks, we're not going to merge it. It's the same exact bar and you just ask the model to improve the code and and make it better.

I think there's also kind of different ways of wielding these tools. Sometimes

you want to vibe code. Uh, and this is really important for throwaway code and prototypes, code that's not in the critical path. And you know, I do this

critical path. And you know, I do this all the time, but it's it's definitely not the thing you want to do all the time. Um, because you want maintainable

time. Um, because you want maintainable code sometimes. Um, you want to be very

code sometimes. Um, you want to be very thoughtful about every line sometimes.

So the way the the problem depending on the problem, you want a a different approach. And so, you know, there's like

approach. And so, you know, there's like a set of approaches that I that I'll use. Like sometimes I'll vibe code

use. Like sometimes I'll vibe code stuff. Um, this is actually quite rare.

stuff. Um, this is actually quite rare.

It's actually mostly for like prototypes and things like that that are throwaway code. Usually I pair with a model to

code. Usually I pair with a model to make to to write code. And so first we align on a plan, you know. So this is like shift tab in quad code to get into plan mode. And first the the model will

plan mode. And first the the model will make a plan, then I'll see the code, and then I I might ask it to improve the code or clean it up or so on. But it's a very involved process. I'm pairing with the model. We're working together to to

the model. We're working together to to write this code. And then sometimes I'll still write the code by hand. So you

know there's some parts of our core query loop where I have very strong opinions about like you know things like the names of parameters or kind of like on which particular line of code is um

some some code is and so for this I'll still write it by hand. I think the the thing though is the models I think are still overall not

great at coding. I think there's still so much room to improve and this is the worst it's ever going to be. But it's

just insane to me to think a year back where the state of AI coding was, you know, like type ahead and it's just a completely different world. And you sort of think about like where this is headed

and kind of what's about to happen and what this looks like over the next few months and few years. And yeah, I think for me what keeps me really excited about it is just having the context about this trajectory that we're on.

When people hear cloud code, they think about coding, but um there's many use cases outside of just software engineering like querying data for like data scientist. What are your thoughts

data scientist. What are your thoughts when you think of cloud code for everything? It was the craziest thing

everything? It was the craziest thing when I walked in. I remember walking into the office like maybe it was like 6 months ago or something and our data scientist Brandon had cloud code up on his computer. He like sits next to us

his computer. He like sits next to us and I'm like, "Dude, what are you doing?

Are you like trying it out?" And he's like, "No, no, I'm like it's like doing my work." I was like, "What?" So he like

my work." I was like, "What?" So he like he figured out how to like use a terminal and like how to install Node.js and then he installed quad code and then it was writing a bunch of SQL and like doing analysis for him. And now when I

walked by kind of the the the data scientists that sit next to us, every person has like a bunch of cloud codes up at the same time. It's not just one anymore. And they're doing all sorts of

anymore. And they're doing all sorts of stuff. They're like writing SQL and you

stuff. They're like writing SQL and you know kind of crunching data. Um they're

writing DBT pipelines and they're writing code. Um, so I think there's all

writing code. Um, so I think there's all these applications outside of coding and it's just so cool to see how people are are using this for all sorts of stuff

and there's even like totally nontechnical users like half of our sales team at Anthropic uses quad code to do their work like they they can like connect it to Salesforce and they can connect it to different data sources and

you know like they can do their work this way. So it it's just so cool to see

this way. So it it's just so cool to see this is not how we designed it. This is

not the intent. When I hear cloud code, I also think of Codeex, one of the biggest competitors. And I'm curious,

biggest competitors. And I'm curious, what are your thoughts on the competition with Codeex and OpenAI? What

does Cloud Code do better? Um, and also I'm curious like the stickiness of these AI products like, you know, what keeps people in cloud code versus um Codeex for instance.

>> You know, I'm not totally sure. I don't

personally, I don't really use the other products.

>> Okay. Okay. For me, you know, like the thing I tell the team is like it's so easy to get sidetracked by, you know, looking at competitors. And I think this is something that I saw that big companies fall into this failure mode a

lot where because there's so many competitors and it's so easy to see the thing you could build by just, you know, copying it.

It's a little bit harder to come up with novel ideas and things that solve the user need better. And so the thing that I try really hard to do and the thing

that I nudge our team to do is don't get sidetracked by all these other you know products there's always going to be a lot and the more there are the bigger a sign of success that is for us and the

thing we stay laser focused on is solving our problems and solving anthropic researchers problems and solving our users problems. Coming to the end of the conversation I just want

to ask a few career reflections. Um, one

thing I was curious about when I was looking is that um, you didn't have a CS degree or a computer science degree and you've, yeah, you've become such a strong software engineer and so I was

curious is there any part in your career where you know it might have held you back in any way or do you think it's not necessary or relevant?

>> Yeah, I studied economics and I actually dropped out to to startups.

Um, you know, for me, anything that you do, you learn on the job and I think programming is just such a practical skill. I couldn't imagine, you know, the

skill. I couldn't imagine, you know, the kinds of things you learn in school. And

like, you know, if you're if you're like in a data structures class or something, you're like running this, but you haven't like built a product, how is it relevant at all? Um, so I don't know. I

think my recommendation would be to people like learn coding practically.

It's a very practical skill. And then if you want to go back and learn the theory after, go do that. Um, but personally, I've never felt like it it's held me back at all.

>> What about productivity tips? So, I saw that you said you work roughly 9 to 6 every day and you only type with two fingers, but your output is ridiculous.

I mean, you have all these side projects and of course, your main stuff's no joke. So, what's your top productivity

joke. So, what's your top productivity tips or how do you maintain that? Yeah,

I think I think nowadays my tips are very different than what I would have said a couple years ago. Nowadays, the

tip is just learn how to use quad code and learn how to run a bunch of quad codes to do stuff like um you know we launched plugins like a couple weeks ago and Daisy who's one of the the the

engineer that built it she just had her quads like set up a sauna board make a tasks and then she had a swarm of like 20 clouds just like build plugins over the weekend and uh you know she ran it in like a docker container dangerous

mode and it was done after a couple days. Um and this is the kind of thing

days. Um and this is the kind of thing that is the future of engineering. Um,

and I think nowadays when we talk about tips for productivity, it's learn how to use claude in order to automate toil and also how to use a bunch of quads

together to to do uh work. So you're

kind of orchestrating instead of manually writing code. Um, I think years ago my tips would have been really different. It would have been a lot more

different. It would have been a lot more prosaic than that, you know, like about like blocking off time and and things like this.

>> Yeah, it's it's interesting with cloud code. I wonder what that does for you

code. I wonder what that does for you know the famous um like maker schedule versus like manager schedule. It feels

like what you just said is that software engineers becoming more like a manager style of working where you got a fleet of these cloud codes and you're not you

don't need deep focus to move forward.

You need context switching across like 20 different things. Um so do you no longer have big focus blocks for coding or what are your thoughts on that? not

as much. I tend to code on the weekends also. Um so I love the quiet time. Um

also. Um so I love the quiet time. Um

but yeah, otherwise I'll kind of start every morning I open Quad Code and um you know like the mobile app. It's like

there's like a code tab in Quad now. We

we just launched this this week, but we've been kind of using it for a while.

And so every morning I wake up and I start a few agents to just like start my code for the day. And it's crazy because I if you'd asked me like 6 months ago if this is how I would code, I would be like, "No, are you like are you crazy?

Like how can you code in this way?" But

it actually works. like this is here and it works and this is how I write a lot of my code now. And I'll I'll start a few agents then you know when I get to a computer I'll kind of check in on the status. Sometimes I'll just merge it if

status. Sometimes I'll just merge it if the code looks good. Sometimes I'll like pull it locally and kind of teleport to to edit a little bit. Um but yeah and and I think like you're going to talk to

Fiona later and I think for her from what she told me she hasn't coded in you know like a decade but she's writing code like multiple times a week now because as a manager even though her

schedule was insane uh she can still use the mobile app and she can use web and you know she can still open a terminal to just kind of write write code for her. Um, so yeah, it's it's just crazy

her. Um, so yeah, it's it's just crazy like we get to live through this transition where the thing that we do and like the thing that I grew up on, it's just totally changing and yeah,

it's just so cool. Like it's becoming accessible to everyone.

>> And then last question for you is um 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?

Just use common sense.

I think there's a lot of stuff in a especially in big companies that pulls you away from common sense. There's a

lot of this like organia. Things are

this way because they have been this way. There's a lot of misaligned

way. There's a lot of misaligned incentives. There's also a lot of good

incentives. There's also a lot of good things, but there's the these things also. So, it it's just really important

also. So, it it's just really important to use common sense for this. And you

know, early on in my career, I was kind of starting a bunch of startups and worked at a lot of startups. And I think there too, it's the same thing. Kind of

use common sense to figure out what the market wants and what users want to build it. So yeah, just like trust

build it. So yeah, just like trust yourself and and develop your common sense.

>> Awesome. Well, thank you so much, Boris, for your time. Really appreciate it.

>> Yeah. Thanks. Thanks for listening to the podcast. I don't sell anything or do

the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or

on Spotify. If you want to drop a

on Spotify. If you want to drop a review, that'll be super helpful. And if

there's any guests that you want to bring on to, please let me know. I feel

like sourcing very senior IC's, there's no wellstudied list out there on Google that I can just search this up. So, if

there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out to