Boris Chney on Latent Demand
Key Points
- The pace of AI model development is so rapid that perspectives on tools and strategies can change dramatically within just a few months.
- Boris “Boris” Chney, creator of Claude Code and former Meta principal engineer, emphasizes “latent demand” as a core product principle and warns against designing solely for today’s model capabilities.
- He describes how “quad code” at Anthropic has tripled overall productivity—raising engineer output by about 70%—and stresses building solutions for the models that will exist six months from now.
- Chney recounts his promotion to senior engineer at Meta, detailing how he led the “chats and groups” project that integrated Messenger with Facebook Groups, scaling the effort from a solo hack to a multi‑engineer team.
Sections
- Boris Chney on Latent Demand & Future AI Models - In this segment, former Meta principal engineer and Claude Code creator Boris Chney explains the concept of latent demand, recounts cultural hurdles, highlights Quad Code’s productivity boost, and urges developers to build for AI models that will exist six months ahead.
- Facebook's Generalist Engineer Culture - The speaker describes how early Facebook encouraged engineers to combine coding, user research, and design— even soliciting cafeteria staff for feedback— fostering a generalist mindset that now drives hiring across product, data, and research roles.
- Cultural Conflict Between Rapid and Reliable Teams - The speaker describes how Facebook’s fast‑shipping product team and the reliability‑centric Messenger team clashed over metrics, organization, and values, causing a project to fail until a common objective bridged the divide.
- Driving Adoption of an Internal State Tool - The speaker explains how they recognized a shared Redux pain point, created the internal Unux solution, and boosted its adoption by analyzing issue data, personally contacting team leads, and delivering dozens of targeted tech talks.
- From Broken Arms to Functional Programming - After a motorcycle accident broke both arms, the speaker shifted from JavaScript to low‑keystroke languages like CoffeeScript, sparking an interest in Haskell and later Scala functional programming.
- From PHP to JavaScript: Promotion Journey - The speaker reflects on the pitfalls of job hopping and recounts how taking ownership of revamping Facebook Groups' clunky PHP site into a modern JavaScript interface led to their promotion to staff/E6 at Meta.
- Optimistic UI Mutation Queue - The speaker explains a bug with rapid button presses causing out‑of‑order responses, and how they solved it by queuing mutations for optimistic updates to preserve UI consistency.
- Three-Option Tactic for VP Reviews - The speaker explains a tongue‑in‑cheek practice of presenting three choices so senior leaders tend to select the middle one, highlighting how this aids decision‑making and reflects the dynamics of reporting to high‑level management.
- Earning Trust and Scaling Leadership - The speaker discusses how, regardless of past accomplishments or managerial titles, one must earn trust and authority in a new company, noting that the lack of titles can simplify this process, and explains the challenges of orchestrating large‑scale engineering scopes within a rapidly expanding organization.
- Launching a Tech Design Competition - A leader explains how they swiftly organized a technical design contest to front‑load risk, balancing immediate action with building consensus, and shares quick‑scoping tips for tech leads.
- One-Line Change, Big Ripple Effects - A developer explains how a seemingly minor database field adjustment for Facebook group membership sparked extensive debates over the semantics of “join” vs. “follow,” data‑model restructuring, and costly migration work, largely influenced by a senior engineer’s strong stance.
- Undoing a Massive Code Migration - An engineer led a year‑long effort to insert conditional logic across hundreds of call sites, then reversed the change to confirm the original data model was correct, showcasing technical leadership and the willingness to challenge senior decisions.
- Automating Tedious Code Review Tasks - The speaker describes tracking repetitive code‑review comments in a spreadsheet, converting frequent issues into custom lint rules for automation, and cautions that over‑automation can detach engineers from the code.
- Testing at Scale: Large‑Data Unit Tests - The speaker describes how missing automated tests for massive Facebook entities (groups, profiles, events) caused production failures and how they initiated infrastructure to generate unit tests for large‑scale data sets, rallying engineering effort to prevent similar issues.
- Instagram Culture vs Feature Overload - The speaker contrasts Instagram’s product‑centric, human‑focused engineering approach with Facebook’s, highlighting the concept of “unshipping” to avoid cluttering apps with rarely used features.
- Time Zone Freedom Revives Coding Passion - Being in a remote Japanese time zone eliminated meetings, letting the engineer refocus on hands‑on development, which alleviated burnout and restored their deep, emotional connection to coding.
- Delegating Leadership in Engineering Projects - The speaker describes handing a major initiative to a trusted engineer, stressing that delegation should only involve tasks you enjoy and understand.
- Engineer’s Motivation vs Corporate Portfolio - The speaker describes their personal drive to create delightful, problem‑solving products, frustration with company‑driven portfolio decisions, and recounts early rejected pitches that later became reality.
- Choosing Anthropic for AI Safety - The speaker explains why they left Meta to join Anthropic, emphasizing a commitment to rigorous AI safety and alignment work as an engineer to prevent escalating risks from advanced models.
- Mission‑Driven Shifts & Cloud Code Edge - The speaker contrasts the purpose‑filled work at change.org and Anthropic with a less motivating experience at Instagram, then explains how Cloud Code broke through early AI autocomplete tools by providing genuine coding assistance instead of mere Q&A.
- Setting Standards for AI Code - The speakers discuss Karpathy’s caution about “vibe coding,” emphasizing that AI‑generated code should be held to the same quality bar as human code and used wisely, especially for prototypes and non‑critical tasks.
- Non‑technical Teams Adopt Cloud Code - The speaker explains how employees across roles are using Cloud Code tools like Quad Code to write SQL, DBT pipelines, and integrate with Salesforce, and asks about its advantages and stickiness compared to competitor Codeex.
- Automation Over Manual Coding - The speaker stresses learning practical tools first and now boosts productivity by orchestrating “quad” code pipelines and AI assistants like Claude to automate engineering work.
- Trust Your Common Sense - The interviewee advises newcomers to rely on common sense and self‑trust to cut through corporate or startup noise, avoid misaligned incentives, and focus on what users and the market truly need.
Full Transcript
# Boris Chney on Latent Demand **Source:** [https://www.youtube.com/watch?v=AmdLVWMdjOk](https://www.youtube.com/watch?v=AmdLVWMdjOk) **Duration:** 01:24:33 ## Summary - The pace of AI model development is so rapid that perspectives on tools and strategies can change dramatically within just a few months. - Boris “Boris” Chney, creator of Claude Code and former Meta principal engineer, emphasizes “latent demand” as a core product principle and warns against designing solely for today’s model capabilities. - He describes how “quad code” at Anthropic has tripled overall productivity—raising engineer output by about 70%—and stresses building solutions for the models that will exist six months from now. - Chney recounts his promotion to senior engineer at Meta, detailing how he led the “chats and groups” project that integrated Messenger with Facebook Groups, scaling the effort from a solo hack to a multi‑engineer team. ## Sections - [00:00:00](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=0s) **Boris Chney on Latent Demand & Future AI Models** - In this segment, former Meta principal engineer and Claude Code creator Boris Chney explains the concept of latent demand, recounts cultural hurdles, highlights Quad Code’s productivity boost, and urges developers to build for AI models that will exist six months ahead. - [00:03:37](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=217s) **Facebook's Generalist Engineer Culture** - The speaker describes how early Facebook encouraged engineers to combine coding, user research, and design— even soliciting cafeteria staff for feedback— fostering a generalist mindset that now drives hiring across product, data, and research roles. - [00:07:30](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=450s) **Cultural Conflict Between Rapid and Reliable Teams** - The speaker describes how Facebook’s fast‑shipping product team and the reliability‑centric Messenger team clashed over metrics, organization, and values, causing a project to fail until a common objective bridged the divide. - [00:11:42](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=702s) **Driving Adoption of an Internal State Tool** - The speaker explains how they recognized a shared Redux pain point, created the internal Unux solution, and boosted its adoption by analyzing issue data, personally contacting team leads, and delivering dozens of targeted tech talks. - [00:14:47](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=887s) **From Broken Arms to Functional Programming** - After a motorcycle accident broke both arms, the speaker shifted from JavaScript to low‑keystroke languages like CoffeeScript, sparking an interest in Haskell and later Scala functional programming. - [00:18:42](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=1122s) **From PHP to JavaScript: Promotion Journey** - The speaker reflects on the pitfalls of job hopping and recounts how taking ownership of revamping Facebook Groups' clunky PHP site into a modern JavaScript interface led to their promotion to staff/E6 at Meta. - [00:21:47](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=1307s) **Optimistic UI Mutation Queue** - The speaker explains a bug with rapid button presses causing out‑of‑order responses, and how they solved it by queuing mutations for optimistic updates to preserve UI consistency. - [00:25:22](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=1522s) **Three-Option Tactic for VP Reviews** - The speaker explains a tongue‑in‑cheek practice of presenting three choices so senior leaders tend to select the middle one, highlighting how this aids decision‑making and reflects the dynamics of reporting to high‑level management. - [00:29:01](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=1741s) **Earning Trust and Scaling Leadership** - The speaker discusses how, regardless of past accomplishments or managerial titles, one must earn trust and authority in a new company, noting that the lack of titles can simplify this process, and explains the challenges of orchestrating large‑scale engineering scopes within a rapidly expanding organization. - [00:33:22](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=2002s) **Launching a Tech Design Competition** - A leader explains how they swiftly organized a technical design contest to front‑load risk, balancing immediate action with building consensus, and shares quick‑scoping tips for tech leads. - [00:36:28](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=2188s) **One-Line Change, Big Ripple Effects** - A developer explains how a seemingly minor database field adjustment for Facebook group membership sparked extensive debates over the semantics of “join” vs. “follow,” data‑model restructuring, and costly migration work, largely influenced by a senior engineer’s strong stance. - [00:40:00](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=2400s) **Undoing a Massive Code Migration** - An engineer led a year‑long effort to insert conditional logic across hundreds of call sites, then reversed the change to confirm the original data model was correct, showcasing technical leadership and the willingness to challenge senior decisions. - [00:45:40](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=2740s) **Automating Tedious Code Review Tasks** - The speaker describes tracking repetitive code‑review comments in a spreadsheet, converting frequent issues into custom lint rules for automation, and cautions that over‑automation can detach engineers from the code. - [00:49:06](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=2946s) **Testing at Scale: Large‑Data Unit Tests** - The speaker describes how missing automated tests for massive Facebook entities (groups, profiles, events) caused production failures and how they initiated infrastructure to generate unit tests for large‑scale data sets, rallying engineering effort to prevent similar issues. - [00:52:40](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=3160s) **Instagram Culture vs Feature Overload** - The speaker contrasts Instagram’s product‑centric, human‑focused engineering approach with Facebook’s, highlighting the concept of “unshipping” to avoid cluttering apps with rarely used features. - [00:56:11](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=3371s) **Time Zone Freedom Revives Coding Passion** - Being in a remote Japanese time zone eliminated meetings, letting the engineer refocus on hands‑on development, which alleviated burnout and restored their deep, emotional connection to coding. - [00:59:47](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=3587s) **Delegating Leadership in Engineering Projects** - The speaker describes handing a major initiative to a trusted engineer, stressing that delegation should only involve tasks you enjoy and understand. - [01:03:20](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=3800s) **Engineer’s Motivation vs Corporate Portfolio** - The speaker describes their personal drive to create delightful, problem‑solving products, frustration with company‑driven portfolio decisions, and recounts early rejected pitches that later became reality. - [01:06:30](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=3990s) **Choosing Anthropic for AI Safety** - The speaker explains why they left Meta to join Anthropic, emphasizing a commitment to rigorous AI safety and alignment work as an engineer to prevent escalating risks from advanced models. - [01:09:39](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=4179s) **Mission‑Driven Shifts & Cloud Code Edge** - The speaker contrasts the purpose‑filled work at change.org and Anthropic with a less motivating experience at Instagram, then explains how Cloud Code broke through early AI autocomplete tools by providing genuine coding assistance instead of mere Q&A. - [01:12:57](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=4377s) **Setting Standards for AI Code** - The speakers discuss Karpathy’s caution about “vibe coding,” emphasizing that AI‑generated code should be held to the same quality bar as human code and used wisely, especially for prototypes and non‑critical tasks. - [01:16:24](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=4584s) **Non‑technical Teams Adopt Cloud Code** - The speaker explains how employees across roles are using Cloud Code tools like Quad Code to write SQL, DBT pipelines, and integrate with Salesforce, and asks about its advantages and stickiness compared to competitor Codeex. - [01:19:36](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=4776s) **Automation Over Manual Coding** - The speaker stresses learning practical tools first and now boosts productivity by orchestrating “quad” code pipelines and AI assistants like Claude to automate engineering work. - [01:23:00](https://www.youtube.com/watch?v=AmdLVWMdjOk&t=4980s) **Trust Your Common Sense** - The interviewee advises newcomers to rely on common sense and self‑trust to cut through corporate or startup noise, avoid misaligned incentives, and focus on what users and the market truly need. ## Full Transcript
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
creator of Claude Code and former meta
principal engineer. And we talked about
everything that shaped his career. Can
you explain latent demand?
>> Latent demand I think is the [music]
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
also talked about quad code and what's
actually [music] happening in enthropic
right now. Even though enthropic has
tripled, productivity per engineer has
grown like almost 70% [music]
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 [music] 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
of these projects just trying to bring
like uh Messenger and Facebook closer
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
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
and uh there were three engineers that
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
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
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
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
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.
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
managers code, our data scientists code,
um our you know user researcher codes a
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
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,
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
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
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
bridging the gaps between messenger and
a lot of the group's um engineering
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
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
reliability and performance. That's all
they cared about. It was just polar
opposite values. Um and this isn't just
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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. [laughter]
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 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
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
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
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
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
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
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
effect when you come in and you really
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
[snorts] 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 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
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
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 [laughter] kind of just
kind of did 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 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 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
particular one I remember was like relay
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
network request comes back, you need to
also update the local cache to make sure
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
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
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 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
that?
Yeah, this is this is very much tongue
andcheek. Um, but maybe this is actually
kind of true at Meta at the time.
[laughter]
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
because I think not all leaders are like
this. A lot of leaders will do their
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
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
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
managers are like XCTO's and things like
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
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
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
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
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
outweighs it, which is you have to earn
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
respect. Doesn't mean that you should
deserve authority at a new company in a
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
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
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
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
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
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
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
like this problem of like how do you
merge these data models? Here are the
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
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
know how to proceed. So, we had to kind
of get everyone together to build
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
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
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
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
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
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
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
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
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 like pretty gnarly downstream
implications of uh letting people
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
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
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
right thing. So we reversed the
migration. It also took a long time to
do it, but in the end it made it so
everyone building on this 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
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
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 first.
>> And then on the imposttor syndrome, um
leading those engineers that were also
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
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
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
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
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
you're trying to convince, think of it
from their point of view. What do they
care about? What are the projects
they're working on? What is 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
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
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
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
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
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
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
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
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
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
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
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. [laughter]
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
Facebook group with like 10 million
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
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
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
gonna have to move. And I was like,
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
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
let's do it." And I didn't know
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
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
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
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,
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
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
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
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
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
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
really awesome things about meta
engineering culture that there are not
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
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
pretty unhappy cuz like as an engineer
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
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
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
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,
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
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
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
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
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
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
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
lot of time for those engineering driven
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
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
apply as always. So, you know, you
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
book uh high output management by uh
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
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
the same thing. You kind of delegate a
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."
>> 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
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
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
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
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
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
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
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.
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
are the labs that are that are working
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
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.
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
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
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
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
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
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
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
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
know like uh you know politics in a
country but like literally the existence
of humanity. Um and these this is not
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
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
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.
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
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
coding, people thought about like
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
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
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
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
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
all the time, but it's it's definitely
not the thing you want to do all the
time. Um, because you want maintainable
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
a set of approaches that I that I'll
use. Like sometimes I'll vibe code
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
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
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
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
when you think of cloud code for
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
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
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
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
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 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,
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. [laughter]
>> 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
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, [laughter] 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 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 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
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
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
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
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
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.
[laughter]
[gasps]
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
incentives. There's also a lot of good
things, but there's the these things
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
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
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
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