1
00:00:00,000 --> 00:00:02,116
The statistics around how long 
it takes to get a code review 

2
00:00:02,116 --> 00:00:04,788
are kind of depressing. 
The median is something around 

3
00:00:04,788 --> 00:00:06,665
10 hours. 
The average is something around 

4
00:00:06,665 --> 00:00:09,018
20 hours. 
The best like cases like the 

5
00:00:09,018 --> 00:00:12,282
P90, P95 are like three hours. 
We're re-entering a world where 

6
00:00:12,282 --> 00:00:14,640
more code changes than ever 
because agents and 

7
00:00:14,640 --> 00:00:17,160
auto-completes have really 
created an explosion of code. 

8
00:00:17,190 --> 00:00:18,330
Now, the code review is more 
important. 

9
00:00:18,390 --> 00:00:21,597
Greg Foster is the CTO and 
Co-Founder of Graphite, an AI 

10
00:00:21,597 --> 00:00:24,090
powered code review platform 
backed by Anthropic, helping 

11
00:00:24,090 --> 00:00:27,222
teams like Snowflake, Figma, and
Perplexity ship faster with 

12
00:00:27,222 --> 00:00:29,895
confidence. 
What is the best use case for AI

13
00:00:29,895 --> 00:00:32,040
code review? 
I am very convinced that from 

14
00:00:32,040 --> 00:00:34,831
here on out forevermore, every 
single code change will be 

15
00:00:34,831 --> 00:00:37,769
scanned by an LLM. 
If your company uses CI and your

16
00:00:37,769 --> 00:00:39,775
company runs linters, they're 
also gonna run an AI code 

17
00:00:39,775 --> 00:00:42,183
review. 
Graphite has a high velocity of 

18
00:00:42,183 --> 00:00:43,915
software development. 
What is your superpower? 

19
00:00:43,915 --> 00:00:47,125
Our team is in the P99 of 
productive engineering teams. 

20
00:00:47,154 --> 00:00:50,434
If you're trying to sell 
productivity, you better be the 

21
00:00:50,434 --> 00:00:53,377
most productive team around. 
We use aggressively every tool 

22
00:00:53,377 --> 00:00:55,194
that we built. 
We are stacking. 

23
00:00:55,194 --> 00:00:56,304
We're breaking up our code 
changes. 

24
00:00:56,304 --> 00:00:58,525
With a small code change, you're
gonna get reviewed faster. 

25
00:00:58,525 --> 00:01:02,144
The feedback per line of code 
you write is so much higher. 

26
00:01:02,375 --> 00:01:04,745
Explain what is stack PR? 
The Facebook engineering team, 

27
00:01:04,745 --> 00:01:07,025
they've been doing this for a 
decade plus. 

28
00:01:07,105 --> 00:01:09,865
The idea of branching off a 
branch, off a branch, you unlock

29
00:01:09,865 --> 00:01:11,565
parallelization. 
How do you make anything faster 

30
00:01:11,565 --> 00:01:13,035
in software engineering? 
You parallelize it. 

31
00:01:13,065 --> 00:01:15,791
Can I parallelize these annoying
waiting times, waiting for a 

32
00:01:15,791 --> 00:01:17,469
review, waiting for tests, 
waiting for deployments, and 

33
00:01:17,469 --> 00:01:18,975
keep writing code changes on top
of it. 

34
00:01:18,975 --> 00:01:21,155
There's a lot of concern like is
coding and engineering as a 

35
00:01:21,155 --> 00:01:24,048
profession gonna die off? 
And I think that is a shallow 

36
00:01:24,048 --> 00:01:26,025
mindset. 
Because to me, the profession of

37
00:01:26,025 --> 00:01:44,249
engineering is... 
Hello, everyone. 

38
00:01:44,249 --> 00:01:46,614
Welcome back to another new 
episode of the Tech Lead Journal

39
00:01:46,614 --> 00:01:48,648
podcast. 
Today, I'm very excited to have 

40
00:01:48,648 --> 00:01:52,470
Greg Foster, the CTO, co-founder
of graphite.dev, right? 

41
00:01:52,800 --> 00:01:55,110
So maybe you have heard about 
Graphite, maybe you don't. 

42
00:01:55,170 --> 00:01:58,290
But Graphite is one of the cool 
developer tools that people use 

43
00:01:58,290 --> 00:02:00,902
to improve their developer 
productivity, especially around 

44
00:02:00,902 --> 00:02:04,335
those pull request workflows. 
So Greg, I'm very excited to 

45
00:02:04,335 --> 00:02:07,396
have you in the show. 
I think we are gonna learn a lot

46
00:02:07,396 --> 00:02:10,149
about how to do PRs, code 
reviews, those kind of things, 

47
00:02:10,149 --> 00:02:12,330
and how to build a high 
performing engineering team. 

48
00:02:13,350 --> 00:02:14,790
Amazing! 
Thank you for having me, Henry. 

49
00:02:14,820 --> 00:02:15,840
I'm excited to talk about this 
stuff. 

50
00:02:15,840 --> 00:02:19,869
This is my favorite topic area, 
so anytime I have a chance to 

51
00:02:19,869 --> 00:02:23,125
speak about it, I love it. 
So Greg, first, uh, let me 

52
00:02:23,125 --> 00:02:26,189
invite you to probably tell us a
little bit more about your 

53
00:02:26,189 --> 00:02:28,749
story, right? 
I'd like to invite my guests to 

54
00:02:28,749 --> 00:02:31,344
actually share by sharing maybe 
career turning points that you 

55
00:02:31,344 --> 00:02:34,006
experienced in your career so 
that we can probably learn from 

56
00:02:34,006 --> 00:02:36,003
that. 
Sure thing. 

57
00:02:36,063 --> 00:02:40,263
Uh, I, I, I can share a little 
bit briefly about my, my career 

58
00:02:40,263 --> 00:02:43,017
up until now. 
It's not too long so I can cover

59
00:02:43,017 --> 00:02:45,647
it. 
Um, I'm excitedly turning 30 in 

60
00:02:45,647 --> 00:02:49,213
a month, which means I'm both 
kind of young, but also means 

61
00:02:49,213 --> 00:02:51,183
that I've been coding for about 
half of my life. 

62
00:02:51,183 --> 00:02:54,303
I think I started when I was 
like 14 or 15, as a way to make 

63
00:02:54,303 --> 00:02:57,003
money in high school. 
I was making early iOS apps. 

64
00:02:57,604 --> 00:03:01,474
I fell in love with engineering.
I went to college. 

65
00:03:01,684 --> 00:03:04,164
Not only can I do it on the 
side, I can now do it for my 

66
00:03:04,164 --> 00:03:06,048
main coursework. 
And I met the, I actually met 

67
00:03:06,048 --> 00:03:08,544
the two people I now co-found 
with really early on in college,

68
00:03:08,544 --> 00:03:11,036
we were all obsessed with 
engineering and the idea of 

69
00:03:11,036 --> 00:03:13,754
creating a company one day. 
I became really fast friends. 

70
00:03:14,384 --> 00:03:17,254
Every summer I'd go out to San 
Francisco and do internships at 

71
00:03:17,644 --> 00:03:19,804
amazing places like Google and 
Airbnb. 

72
00:03:20,074 --> 00:03:24,137
I ended up coming back to Airbnb
full-time, originally as an iOS 

73
00:03:24,137 --> 00:03:26,687
engineer because that's what I 
was doing in high school. 

74
00:03:26,687 --> 00:03:28,517
So I had a pretty good skillset 
for it. 

75
00:03:28,967 --> 00:03:32,383
But funny enough, like the first
day I came aboard, they said, 

76
00:03:32,383 --> 00:03:34,591
hey, iOS engineering, that's 
great, but actually, uh, we need

77
00:03:34,591 --> 00:03:38,474
you on this infra team. 
So I got, I guess, reorged and 

78
00:03:38,474 --> 00:03:41,555
swept onto a backend 
infrastructure team where I 

79
00:03:41,555 --> 00:03:44,039
found myself working on 
notification infrastructure, 

80
00:03:44,039 --> 00:03:47,657
which then cascaded into dev 
tools and internal developer 

81
00:03:47,657 --> 00:03:50,339
environments and continuous 
delivery platforms and release 

82
00:03:50,339 --> 00:03:52,361
management software. 
I was doing all sorts of stuff. 

83
00:03:52,451 --> 00:03:55,601
I was volunteering for SRE 
rotations, you name it. 

84
00:03:55,751 --> 00:03:56,771
And I fell in love with 
infrastructure. 

85
00:03:56,771 --> 00:03:59,879
I was like, iOS engineering, 
that's cool, but I'm even more 

86
00:03:59,879 --> 00:04:03,374
intrigued and just fascinated by
building for other software 

87
00:04:03,374 --> 00:04:05,608
engineers. 
What does it mean not only to 

88
00:04:05,608 --> 00:04:07,580
build something good, I built 
pretty good iPhone apps. 

89
00:04:07,580 --> 00:04:10,660
So what does it mean to not to 
build something good, but to how

90
00:04:10,660 --> 00:04:13,608
engineers can build good things 
and how can developers be more 

91
00:04:13,608 --> 00:04:15,290
productive? 
And that meta question just 

92
00:04:15,290 --> 00:04:17,675
really fascinated me. 
And I started working with the 

93
00:04:17,675 --> 00:04:21,344
most interesting people. 
And then around the start of 

94
00:04:21,344 --> 00:04:25,041
2020, I moved to New York. 
I was staying in touch with 

95
00:04:25,041 --> 00:04:26,882
those friends from college, 
Merrill and Tomas. 

96
00:04:27,256 --> 00:04:29,412
They were out in New York City, 
I was in San Francisco. 

97
00:04:29,982 --> 00:04:31,922
We had always wanted to create 
something together. 

98
00:04:31,922 --> 00:04:35,278
And we saw this chance to take 
this passion we had around dev 

99
00:04:35,278 --> 00:04:38,064
tools and not just do it 
internally at a company, but to 

100
00:04:38,064 --> 00:04:40,874
create a dev tool company and 
then serve and build for 

101
00:04:40,874 --> 00:04:42,188
everyone. 
It's cool to build for a 

102
00:04:42,188 --> 00:04:43,987
thousand people at Airbnb. 
It's even cooler to build for 

103
00:04:43,987 --> 00:04:45,103
all the engineers in the 
industry. 

104
00:04:45,823 --> 00:04:47,998
So it was kind of a no-brainer. 
It was a space I loved, it was 

105
00:04:47,998 --> 00:04:50,143
people I loved. 
I moved out to New York. 

106
00:04:50,413 --> 00:04:52,689
The pandemic came crashing down,
which was actually kind of 

107
00:04:52,689 --> 00:04:55,685
perfect 'cause then we just 
buckled down indoors and spent 

108
00:04:55,685 --> 00:04:59,187
like a year or two coding. 
As the world opened up, we were 

109
00:04:59,187 --> 00:05:00,580
also starting to flourish as a 
startup. 

110
00:05:00,790 --> 00:05:06,250
And from that 2020 to 2025 now, 
we have just been continuously 

111
00:05:06,550 --> 00:05:09,070
working and building and 
creating a team and everything. 

112
00:05:09,070 --> 00:05:10,695
And it's really coming together 
now. 

113
00:05:11,561 --> 00:05:13,241
Well, thank you for sharing your
story. 

114
00:05:13,241 --> 00:05:14,501
I think it's pretty interesting,
right? 

115
00:05:14,501 --> 00:05:17,725
The kind of like twist and turn 
you kind of like experienced in 

116
00:05:17,725 --> 00:05:19,643
your career. 
I was intrigued when you say, 

117
00:05:19,643 --> 00:05:21,371
uh, you are kind of like still 
young, right? 

118
00:05:21,371 --> 00:05:25,082
Like maybe turning 30 soon. 
And you mentioned that in the 

119
00:05:25,082 --> 00:05:27,672
beginning, maybe at 15 you 
started coding, you fell in love

120
00:05:27,672 --> 00:05:30,852
in engineering. 
I think at this age, many people

121
00:05:30,852 --> 00:05:33,411
thinking about starting in 
engineering, right, a bit 

122
00:05:33,411 --> 00:05:36,121
concerned about the impact of 
AI, should they start doing 

123
00:05:36,121 --> 00:05:38,361
software development, computer 
science, those kind of things. 

124
00:05:38,631 --> 00:05:41,981
What is your view, especially 
you represent people who just 

125
00:05:41,981 --> 00:05:45,140
kind of like, in the middle 
stage of the career, right? 

126
00:05:45,350 --> 00:05:50,339
So what do you think about this?
Oh, I think it's a golden age to

127
00:05:50,339 --> 00:05:52,142
get involved in software 
engineering. 

128
00:05:52,142 --> 00:05:55,066
I think it's such a great time. 
I think about my experience. 

129
00:05:55,066 --> 00:05:56,026
You're right, like it's a middle
age. 

130
00:05:56,026 --> 00:05:57,802
There's people, there's ton of 
people who learn engineering 

131
00:05:57,802 --> 00:05:58,911
before me. 
There's people who learn it 

132
00:05:58,911 --> 00:06:00,930
after me. 
When I learned it, it was a 

133
00:06:00,930 --> 00:06:03,133
little bit tough. 
I remember I was trying to 

134
00:06:03,133 --> 00:06:05,655
figure out how to code, and I 
wanted to learn how to code. 

135
00:06:06,255 --> 00:06:09,297
And I would go online, I'd look 
up tutorials, or I'd look up 

136
00:06:09,297 --> 00:06:11,845
books, and every resource I 
found, it would be like, okay, 

137
00:06:11,845 --> 00:06:13,457
you know, we're gonna teach you 
Java. 

138
00:06:13,457 --> 00:06:16,511
So given that, you know, C 
here's how to map that to Java. 

139
00:06:16,511 --> 00:06:19,085
And I'm like, I don't know C. 
I mean like given that you know 

140
00:06:19,085 --> 00:06:20,681
Java, here's how we're gonna 
learn Python or Rails. 

141
00:06:20,681 --> 00:06:21,745
I'm like, but I don't know that 
I'm like... 

142
00:06:21,804 --> 00:06:25,530
It wasn't until I found Coding 
for Dummies book that was 

143
00:06:25,530 --> 00:06:28,880
willing to walk me through the 
primitives of Java from scratch.

144
00:06:28,880 --> 00:06:32,562
I read that book. 
There was an iTunes U, iTunes 

145
00:06:32,562 --> 00:06:35,917
University course from Stanford 
on iOS engineering, and I loved 

146
00:06:35,917 --> 00:06:38,287
it. 
I was so excited and I was like 

147
00:06:38,287 --> 00:06:40,842
on my Windows iTunes thing 
watching this video and stuff. 

148
00:06:40,842 --> 00:06:43,308
And I was working my way through
and trying to figure out how to 

149
00:06:43,308 --> 00:06:44,666
build iPhone app and get into 
coding. 

150
00:06:45,146 --> 00:06:49,016
I think it's so, so, so, so, so 
much easier now to get over that

151
00:06:49,016 --> 00:06:51,336
initial learning curve. 
You have incredible resources 

152
00:06:51,336 --> 00:06:53,436
and tutorials. 
Heck, you got chat bots that are

153
00:06:53,436 --> 00:06:55,616
gonna unblock you and can like, 
help debug your program. 

154
00:06:55,616 --> 00:06:58,600
So the entry point curve has 
gotten easier, but I think the 

155
00:06:58,600 --> 00:07:01,172
upper end and the complexity and
the amazing things you can build

156
00:07:01,172 --> 00:07:03,206
is just as interesting and hard 
as it was before. 

157
00:07:03,206 --> 00:07:04,916
I don't think that that's like a
solved problem. 

158
00:07:05,726 --> 00:07:08,286
And even at the heart of it, I 
know there's a lot of concern 

159
00:07:08,306 --> 00:07:10,886
like, is coding and engineering 
as a profession gonna die off? 

160
00:07:10,886 --> 00:07:13,734
Like is this a not a good time 
to invest your skills into that?

161
00:07:13,743 --> 00:07:15,183
What if it's not here in five 
years? 

162
00:07:15,873 --> 00:07:19,585
And I think that that is a 
shallow mindset because to me 

163
00:07:19,585 --> 00:07:22,792
the profession of engineering, 
the art of engineering is one of

164
00:07:22,792 --> 00:07:24,217
solving problems and building 
things. 

165
00:07:24,517 --> 00:07:26,437
And I think it's very timeless 
and that's here to stay. 

166
00:07:26,867 --> 00:07:28,478
People have been solving 
problems and building things for

167
00:07:28,478 --> 00:07:31,207
thousands of years, and I'm just
really positive we're gonna be 

168
00:07:31,207 --> 00:07:32,877
doing that in a hundred years 
from now too. 

169
00:07:33,474 --> 00:07:37,502
Now coding, typing my fingers on
a keyboard and getting stuck on 

170
00:07:37,502 --> 00:07:40,399
bugs, that's definitely changing
and evolving and it's, you know,

171
00:07:40,399 --> 00:07:43,666
we can have a fun debate around 
to what degree we're gonna be 

172
00:07:43,666 --> 00:07:45,511
typing versus giving prompts and
telling other things. 

173
00:07:45,511 --> 00:07:48,029
But, heck, you know, software 
engineering has evolved before. 

174
00:07:48,261 --> 00:07:51,359
There was once punch cards, 
there was once, having very, 

175
00:07:51,359 --> 00:07:52,868
very low level forms of 
programming. 

176
00:07:52,868 --> 00:07:55,444
Then we got these higher 
abstracted languages and we got 

177
00:07:55,444 --> 00:07:56,528
scripting languages. 
It got a lot easier. 

178
00:07:56,528 --> 00:07:59,038
Heck, when I was doing iOS 
development, they were all 

179
00:07:59,038 --> 00:08:02,648
excited about Xcode, like visual
GUI framework for assembling 

180
00:08:02,648 --> 00:08:04,628
text boxes. 
And you barely needed to code to

181
00:08:04,628 --> 00:08:06,248
build the app is what they would
pitch you on. 

182
00:08:06,248 --> 00:08:07,208
Of course you still need to 
code. 

183
00:08:07,208 --> 00:08:09,895
It was kind of bad. 
So I just, I feel like there's 

184
00:08:09,895 --> 00:08:12,087
always that feeling in the air, 
like maybe you're not gonna 

185
00:08:12,087 --> 00:08:13,982
code, but that's if you're 
becoming an engineer 'cause you 

186
00:08:13,982 --> 00:08:15,005
just wanna write a bunch of 
code. 

187
00:08:15,005 --> 00:08:17,312
It's kinda the wrong reasoning. 
I think you should do it because

188
00:08:17,312 --> 00:08:18,816
you love building and creating 
and shipping stuff. 

189
00:08:18,966 --> 00:08:22,052
And you're, you should be using 
every tool available to you at 

190
00:08:22,052 --> 00:08:23,496
the time. 
That's just a means to an end. 

191
00:08:23,496 --> 00:08:26,406
So it's never been easier, I 
think, to get involved. 

192
00:08:26,406 --> 00:08:27,576
It's never been kind of more 
fun. 

193
00:08:27,996 --> 00:08:31,266
And the ceiling and what can be 
created is as expansive as ever.

194
00:08:31,266 --> 00:08:34,025
So I would thoroughly encourage 
other folks to get involved. 

195
00:08:34,804 --> 00:08:37,190
So I like what you said that, 
you know, software engineering 

196
00:08:37,190 --> 00:08:39,644
is all about solving problems 
and building things, right? 

197
00:08:39,644 --> 00:08:42,426
So as long as that's the goal, 
you like doing that, I think 

198
00:08:42,426 --> 00:08:44,894
software engineering is maybe 
one channel that people can use 

199
00:08:44,894 --> 00:08:46,424
to actually do those things, 
right? 

200
00:08:46,814 --> 00:08:49,884
And I personally, myself also 
kind of like enjoying my 

201
00:08:49,884 --> 00:08:52,014
software engineering again, 
simply because like you said, 

202
00:08:52,014 --> 00:08:53,778
right? 
There are so many different 

203
00:08:53,778 --> 00:08:56,552
languages these days, right? 
If we wanna pick up a new 

204
00:08:56,552 --> 00:09:00,329
language, it's quite easy to ask
AI to kind of like kickstart the

205
00:09:00,329 --> 00:09:02,705
process. 
And you use kind of like your 

206
00:09:02,705 --> 00:09:04,055
experience to actually 
accommodate, right? 

207
00:09:04,126 --> 00:09:06,594
The software that you write, the
architecture that you wanna 

208
00:09:06,898 --> 00:09:10,447
build and things like that. 
So definitely today's topic is 

209
00:09:10,447 --> 00:09:13,155
all about, you know, code 
review, right? 

210
00:09:13,399 --> 00:09:17,007
It's one aspect of the software 
development workflow that 

211
00:09:17,127 --> 00:09:20,967
everybody, I'm sure, is kind of 
like getting disrupted as well, 

212
00:09:20,967 --> 00:09:23,047
right? 
Because now the code is being 

213
00:09:23,047 --> 00:09:25,649
churned by AI. 
And at the same time, right? 

214
00:09:26,095 --> 00:09:28,545
There are also tools like what 
you have been building, right? 

215
00:09:29,055 --> 00:09:32,035
AI that is reviewing someone 
else's code, right? 

216
00:09:32,305 --> 00:09:35,468
So maybe let's start in the 
first place about the code 

217
00:09:35,468 --> 00:09:37,225
review. 
What do you think the importance

218
00:09:37,225 --> 00:09:39,205
of code review for software 
development these days? 

219
00:09:40,036 --> 00:09:42,286
Yeah, the importance of code 
review. 

220
00:09:42,699 --> 00:09:46,859
I really think it's kind of 
evolved over the ages. 

221
00:09:47,279 --> 00:09:49,215
Again, I've only been 
professionally engineering for 

222
00:09:49,215 --> 00:09:52,389
10 years, but I've read a lot 
about the history of this. 

223
00:09:53,109 --> 00:09:55,652
And from what I can tell, people
have been doing forms of code 

224
00:09:55,652 --> 00:09:57,197
review as long as people have 
been coding. 

225
00:09:57,557 --> 00:09:59,923
At certain points in time, the 
early, early points of time, it 

226
00:09:59,923 --> 00:10:03,382
would be laying out the 
software, physically printed on 

227
00:10:03,382 --> 00:10:06,597
a desk, having people pour over 
it, doing bug inspections, 

228
00:10:06,597 --> 00:10:09,227
really looking for faults, 
looking for errors, looking for 

229
00:10:09,227 --> 00:10:11,627
things that are gonna hit 
production, because the cost of 

230
00:10:11,627 --> 00:10:12,557
that is gonna be exceptionally 
high. 

231
00:10:12,557 --> 00:10:15,195
There's not modern mechanisms 
for catching and reverting and 

232
00:10:15,195 --> 00:10:17,514
rolling that stuff back. 
There's not even continuous 

233
00:10:17,514 --> 00:10:19,625
integration tests. 
So it was a large obsession 

234
00:10:19,625 --> 00:10:21,257
around looking for faults and 
bugs. 

235
00:10:21,917 --> 00:10:25,208
I think as time went on into the
90s, it was still a little bit 

236
00:10:25,208 --> 00:10:27,407
of that, but it was also a 
little bit more of collaboration

237
00:10:27,407 --> 00:10:28,787
and style. 
It might be desk checks, it 

238
00:10:28,787 --> 00:10:30,980
might be asking an engineer to 
come and look over your shoulder

239
00:10:30,980 --> 00:10:33,673
at a computer screen and check 
and review some things before 

240
00:10:33,673 --> 00:10:36,873
you commit it to a central 
server for repository. 

241
00:10:37,563 --> 00:10:41,831
And with the advent of GitHub 
around 2004-2005, I think we 

242
00:10:41,831 --> 00:10:46,087
really saw a flourishing of code
review, partly because open 

243
00:10:46,087 --> 00:10:50,454
source really needed it. 
Open source really removed a lot

244
00:10:50,454 --> 00:10:53,013
of trust-based barriers. 
It was different. 

245
00:10:53,013 --> 00:10:55,506
You weren't within a company 
where someone had passed a 

246
00:10:55,506 --> 00:10:58,509
hiring bar and you knew them, 
and if they made a major mistake

247
00:10:58,509 --> 00:11:00,653
or even a malicious mistake, 
they would just get fired. 

248
00:11:00,963 --> 00:11:02,913
Now you're an open source. 
Now no one, no one has trust. 

249
00:11:02,913 --> 00:11:05,059
Everyone's a stranger. 
Everyone's a pseudonym, but 

250
00:11:05,059 --> 00:11:06,633
we're still contributing 
together. 

251
00:11:06,753 --> 00:11:09,175
And so you have the advent of 
the pull request. 

252
00:11:09,175 --> 00:11:12,833
It's a stranger requesting me 
the maintainer to pull in their 

253
00:11:12,833 --> 00:11:15,469
changes. 
And so now I got the, and now I 

254
00:11:15,469 --> 00:11:16,858
have this maintainer who's 
carefully, thoughtfully 

255
00:11:16,858 --> 00:11:20,125
reviewing this change with deep 
skepticism but also excitement. 

256
00:11:20,485 --> 00:11:23,685
And you have a collaborative 
discussion going on in a 

257
00:11:23,685 --> 00:11:25,804
forum-based webpage. 
And you have that kind of the 

258
00:11:25,804 --> 00:11:28,180
avenue of what we see as like 
the modern code review. 

259
00:11:28,930 --> 00:11:31,824
Now that's looking for bugs. 
It's also looking for like is 

260
00:11:31,824 --> 00:11:34,309
this code change going in the 
direction I hope that this 

261
00:11:34,309 --> 00:11:37,216
project is going in. 
It's maybe a little bit of 

262
00:11:37,216 --> 00:11:39,551
teaching, even if the 
interactions are not the most 

263
00:11:39,551 --> 00:11:42,231
long lived. 
As time goes on further, I think

264
00:11:42,231 --> 00:11:45,286
you then have the advent of CI 
gaining deep popularity. 

265
00:11:45,286 --> 00:11:47,918
I think throughout the 2000s, 
late 2000s, it was becoming much

266
00:11:47,918 --> 00:11:50,436
more popular. 
Always keeping trunk green. 

267
00:11:50,436 --> 00:11:53,436
We never want trunk to fail 
builds and fail tests. 

268
00:11:53,796 --> 00:11:55,836
And we start running that. 
We have the compute and the 

269
00:11:55,836 --> 00:11:57,954
ability and the systems to now 
run that on every single code 

270
00:11:57,954 --> 00:12:00,954
change before it merges in. 
So now I'm looking a little bit 

271
00:12:00,954 --> 00:12:02,753
less for bugs. 
I'm still gonna look, I'm still 

272
00:12:02,753 --> 00:12:04,635
looking for bugs in code review 
and I still care about that. 

273
00:12:04,635 --> 00:12:07,755
But honestly if like, if that's 
how we're catching all of our 

274
00:12:07,755 --> 00:12:09,365
errors, that's kind of a last 
line of defense. 

275
00:12:09,640 --> 00:12:11,825
It's, it's a kind of a flaky way
to find about issues. 

276
00:12:11,825 --> 00:12:14,520
We should also be finding those 
in testing systems and in 

277
00:12:14,520 --> 00:12:16,765
careful rollout systems. 
But what's the point of code 

278
00:12:16,765 --> 00:12:18,815
review now? 
Well, I still have a trust-based

279
00:12:18,815 --> 00:12:21,637
system, but internally within 
companies, I don't have to worry

280
00:12:21,637 --> 00:12:23,450
as much about that. 
I mean, again, ideally we're 

281
00:12:23,450 --> 00:12:25,572
not, we don't have too many 
malicious actors within a 

282
00:12:25,572 --> 00:12:29,169
company. 
And I think the weight of it 

283
00:12:29,169 --> 00:12:33,225
really starts shifting towards 
context and education and mutual

284
00:12:33,225 --> 00:12:35,493
understanding. 
It's a way to share what's 

285
00:12:35,493 --> 00:12:38,926
happening in the code base. 
It's a way to share different 

286
00:12:38,926 --> 00:12:41,128
subjective styles, opinions, and
future directions. 

287
00:12:41,368 --> 00:12:44,332
A really great place to have a 
discussion around, oh my gosh, 

288
00:12:44,332 --> 00:12:45,508
is this where the code base is 
going? 

289
00:12:45,508 --> 00:12:46,618
Is this where the architecture 
is going? 

290
00:12:46,938 --> 00:12:49,025
It's in code review. 
It's also good to have that in a

291
00:12:49,025 --> 00:12:50,870
design doc review earlier on, 
but we're not all perfect 

292
00:12:50,870 --> 00:12:53,026
humans, and if we're gonna have 
it, let's have it before we 

293
00:12:53,026 --> 00:12:55,762
merge in the code change. 
It's a great moment of teaching 

294
00:12:55,762 --> 00:12:58,420
for a more senior engineer to 
show the ropes for more junior 

295
00:12:58,420 --> 00:13:00,648
engineer or to, or a senior 
engineer just ramping up to a 

296
00:13:00,648 --> 00:13:02,615
new system. 
It's a really good point in time

297
00:13:02,615 --> 00:13:04,738
to have these great discussions 
and feedback moments. 

298
00:13:05,240 --> 00:13:08,360
So I think about that, that's 
code review, I think up until 

299
00:13:08,360 --> 00:13:10,614
the moment of AI. 
Then we have, and we have AI 

300
00:13:10,614 --> 00:13:12,820
coming out to the scene. 
And it gets a little weird 

301
00:13:12,820 --> 00:13:14,765
because now the code change 
wasn't necessarily, it was 

302
00:13:14,765 --> 00:13:17,234
either partially written by 
human or maybe entirely not 

303
00:13:17,234 --> 00:13:19,200
written by a human. 
It gets a little weird. 

304
00:13:19,200 --> 00:13:21,499
So, okay, so from a teaching 
level, I don't really need to 

305
00:13:21,499 --> 00:13:24,480
teach the agent much about the 
system. 

306
00:13:24,480 --> 00:13:26,460
Now, maybe, I don't know, maybe 
we'll evolve and like this is 

307
00:13:26,460 --> 00:13:29,064
gonna be a moment for like where
agents get feedback and learn 

308
00:13:29,064 --> 00:13:30,510
how to update their Claude Code 
rules. 

309
00:13:30,660 --> 00:13:32,160
Maybe. 
That doesn't exist yet. 

310
00:13:32,873 --> 00:13:35,753
But also the trust issue has 
kind of reemerged a little bit. 

311
00:13:35,753 --> 00:13:38,257
Now, again, I don't actually 
don't trust it as much as, you 

312
00:13:38,257 --> 00:13:40,028
know, my teammate, I have pretty
good trust. 

313
00:13:40,028 --> 00:13:42,773
We've been working together for,
you know, whatever year plus. 

314
00:13:42,926 --> 00:13:46,258
This AI, it could be stupid, it 
could be malicious, I hope not, 

315
00:13:46,258 --> 00:13:48,256
but like it's, there's a higher 
risk of maliciousness. 

316
00:13:48,256 --> 00:13:49,816
I can't sue the AI if it goes 
rogue. 

317
00:13:50,767 --> 00:13:52,702
And it may, it may just make 
silly mistakes or just not be 

318
00:13:52,702 --> 00:13:55,038
smart enough for lack of context
that was clearly stated in a 

319
00:13:55,038 --> 00:13:57,178
meeting, but this thing wasn't 
in the meeting, so it just 

320
00:13:57,178 --> 00:13:59,530
doesn't know. 
And so the trust has gone down a

321
00:13:59,530 --> 00:14:01,554
little bit. 
So now I think we're re-entering

322
00:14:01,554 --> 00:14:04,784
a world where, okay, my gosh, 
more code changes than ever 

323
00:14:04,784 --> 00:14:08,136
because agents have really... 
Agents and auto completes and 

324
00:14:08,136 --> 00:14:10,578
things have really created an 
explosion of code. 

325
00:14:10,608 --> 00:14:12,132
That's great. 
That can be good, there's a lot 

326
00:14:12,132 --> 00:14:15,027
of benefits that come from that.
But there's a lot of code and I 

327
00:14:15,027 --> 00:14:17,011
trust it less. 
And heck, maybe no human in my 

328
00:14:17,011 --> 00:14:19,633
company has ever read it by the 
time I'm gonna do a code review.

329
00:14:19,993 --> 00:14:21,163
Now the code review is more 
important. 

330
00:14:21,343 --> 00:14:22,753
I need to be more thoughtful in 
it. 

331
00:14:23,143 --> 00:14:24,883
But I have more work to do than 
ever before. 

332
00:14:24,883 --> 00:14:26,533
So there's kind of an emergent 
bottleneck. 

333
00:14:26,533 --> 00:14:29,183
I think the simplest like 
short-term answer is just as 

334
00:14:29,183 --> 00:14:31,147
engineers, we're just gonna take
some of that time that we're 

335
00:14:31,147 --> 00:14:33,919
saving from writing the code and
we're gonna shift it to more 

336
00:14:33,919 --> 00:14:36,274
time intensive code reviews. 
We'll kinda see how that 

337
00:14:36,274 --> 00:14:38,291
evolves. 
Yeah, I agree with you. 

338
00:14:38,291 --> 00:14:42,333
It's a bit weird, should I say. 
Uh, so you write less code, but 

339
00:14:42,333 --> 00:14:45,815
at the same time you produce a 
lot more, and at the same time 

340
00:14:45,815 --> 00:14:47,735
you also review a lot more as 
well. 

341
00:14:48,002 --> 00:14:51,259
Time will tell, right, so which 
direction it will go to. 

342
00:14:51,289 --> 00:14:54,133
Maybe AI agents are gonna be 
more sophisticated, more clever 

343
00:14:54,133 --> 00:14:56,594
and things like that. 
But hopefully, code review is 

344
00:14:56,594 --> 00:14:59,359
still gonna be like an important
aspect of software development. 

345
00:14:59,809 --> 00:15:03,106
So I'm a bit intrigued when you 
say about GitHub, open source, 

346
00:15:03,106 --> 00:15:04,940
you know, the trust-based 
system, right? 

347
00:15:05,222 --> 00:15:07,872
In some debates within software 
engineering world, people say 

348
00:15:07,872 --> 00:15:10,755
that they don't like the pull 
request workflow, but because of

349
00:15:10,755 --> 00:15:13,692
the advent of, you know, GitHub,
I think many, many software 

350
00:15:13,692 --> 00:15:16,774
development teams now kind of 
like adopt pull request or merge

351
00:15:16,774 --> 00:15:18,804
request, uh, if they're using 
GitLab, right? 

352
00:15:19,104 --> 00:15:21,822
So maybe in the first place, 
let's bring this discussion, 

353
00:15:21,822 --> 00:15:23,727
right? 
What do you think about the pull

354
00:15:23,727 --> 00:15:26,246
request workflow? 
Is it something that is kind of 

355
00:15:26,246 --> 00:15:29,467
like a must have for software 
engineering team, or some people

356
00:15:29,467 --> 00:15:31,726
actually prefers, you know, pair
programming, trunk based 

357
00:15:31,726 --> 00:15:33,542
development? 
Just merge into master straight 

358
00:15:33,542 --> 00:15:36,388
away. 
Yeah, it's really interesting. 

359
00:15:36,388 --> 00:15:43,138
I think around 2010 era there 
was a lot of different emerging 

360
00:15:43,218 --> 00:15:46,404
patterns around pull requests. 
You think about different app, 

361
00:15:46,404 --> 00:15:49,288
different kind of, uh, ways you 
could organize your Git 

362
00:15:49,288 --> 00:15:51,172
repository. 
You could do trunk based 

363
00:15:51,172 --> 00:15:53,622
development, but you could also 
do long-lived feature branches. 

364
00:15:53,862 --> 00:15:56,784
You could do single commit pull 
request, you could do 

365
00:15:56,784 --> 00:15:59,343
multi-commit pull requests. 
You could do squash and merge, 

366
00:15:59,343 --> 00:16:00,975
you can do different merge 
strategies. 

367
00:16:01,284 --> 00:16:02,715
There's a lot of variance going 
on. 

368
00:16:03,195 --> 00:16:07,275
And what I noticed I think early
in my career is it didn't seem 

369
00:16:07,275 --> 00:16:11,565
like companies had the deepest 
confidence in their strategy. 

370
00:16:11,565 --> 00:16:13,925
It felt like there was kind of 
an open debate around like, what

371
00:16:13,925 --> 00:16:17,591
is the best way to run this? 
And I think what's emerged is 

372
00:16:17,591 --> 00:16:21,280
that there was patterns that 
were made sense in open source 

373
00:16:21,280 --> 00:16:24,989
and they made sense in older 
styles of waterfall engineering,

374
00:16:24,989 --> 00:16:28,427
but those didn't make as much 
sense in some new closed source,

375
00:16:28,427 --> 00:16:31,855
faster patterns of engineering. 
So what do I think about like in

376
00:16:31,855 --> 00:16:34,702
open source, feature long lived 
feature branches make a lot more

377
00:16:34,702 --> 00:16:36,222
sense. 
Forking patterns make a lot more

378
00:16:36,222 --> 00:16:38,481
sense. 
It's possible that we just want 

379
00:16:38,481 --> 00:16:41,299
to have long periods of 
development in slightly 

380
00:16:41,299 --> 00:16:43,228
different directions. 
And that's probably the beauty 

381
00:16:43,228 --> 00:16:45,797
of open source is that things 
can deviate and go in different 

382
00:16:45,797 --> 00:16:47,698
directions. 
You can have forks of projects, 

383
00:16:47,698 --> 00:16:50,511
you can support various things. 
There doesn't need to be a 

384
00:16:50,511 --> 00:16:52,193
central dictator at the top 
saying, no, it's gotta be this 

385
00:16:52,193 --> 00:16:53,833
way. 
We gotta unify and merge all in 

386
00:16:53,833 --> 00:16:55,997
and run the roadmap. 
That works in open source, 

387
00:16:55,997 --> 00:16:59,079
that's, that's beautiful. 
You also had a classic, you 

388
00:16:59,079 --> 00:17:02,343
know, hangover of I think older 
patterns of shipping software. 

389
00:17:02,838 --> 00:17:05,520
Whether you were shipping 
physical software and you needed

390
00:17:05,520 --> 00:17:08,513
to cut a release at a very 
specific moment in time that was

391
00:17:08,513 --> 00:17:10,795
gonna be quite permanent and 
maybe you wanna fix that, then 

392
00:17:10,795 --> 00:17:12,917
you wanna run QA and get some 
hot fixes into that. 

393
00:17:12,917 --> 00:17:15,318
But you really wanna like hold a
stable release branch. 

394
00:17:15,978 --> 00:17:20,631
And that also held up for a 
while in certain forms of mobile

395
00:17:20,631 --> 00:17:23,310
and certain forms of like 
shipping open source CLIs or 

396
00:17:23,310 --> 00:17:24,738
libraries, you wanted these 
feature branches. 

397
00:17:25,416 --> 00:17:29,005
On the other hand, you had I 
think a real progression in 

398
00:17:29,005 --> 00:17:31,252
closed source development, 
probably spearheaded by great 

399
00:17:31,252 --> 00:17:34,062
engineering cultures at Facebook
and Google and many companies 

400
00:17:34,062 --> 00:17:37,114
that then fractured out of those
early engineering teams that 

401
00:17:37,114 --> 00:17:39,052
really centralized around trunk 
based development. 

402
00:17:39,382 --> 00:17:42,382
And they said, hey, you know, 
realistically we just want one 

403
00:17:42,382 --> 00:17:45,532
source of truth, trunk, and we 
want to update it constantly. 

404
00:17:45,832 --> 00:17:48,819
We wanna iterate on it. 
And we don't really need to, it 

405
00:17:48,819 --> 00:17:51,869
depends the case, but many 
cases, I don't need to publish 

406
00:17:51,869 --> 00:17:55,186
long lived feature branches and 
I don't need a lot of forking 

407
00:17:55,186 --> 00:17:56,778
mechanisms. 
I don't want there to be three 

408
00:17:56,778 --> 00:17:58,092
different versions of truth in 
my company. 

409
00:17:58,522 --> 00:18:04,792
And I don't even want multiple 
commits on my branch because 

410
00:18:04,792 --> 00:18:08,807
within a company, what started 
emerging I think is that the 

411
00:18:08,807 --> 00:18:11,512
atomic unit of change was the 
thing being reviewed and tested.

412
00:18:11,512 --> 00:18:13,113
That was the unit. 
It was the PR. 

413
00:18:13,113 --> 00:18:16,111
And GitHub... it all got a 
little bit weird because it was 

414
00:18:16,111 --> 00:18:19,266
assumed that you would spend 
months on a pull request, 

415
00:18:19,266 --> 00:18:22,420
iterating, updating it, and then
that would get pulled back in as

416
00:18:22,420 --> 00:18:24,058
like a feature branch merging 
back in the trunk. 

417
00:18:24,448 --> 00:18:26,441
I think that pattern sort of 
dissolving in closed source. 

418
00:18:26,647 --> 00:18:28,948
So you look at like Facebook, 
they create a pattern of diffs. 

419
00:18:29,095 --> 00:18:30,265
They don't have a PR, they just 
have a diff. 

420
00:18:30,305 --> 00:18:33,745
The diff is just one atomic 
block that is different from the

421
00:18:33,867 --> 00:18:35,547
trunk and it can have versions. 
That's cool. 

422
00:18:35,547 --> 00:18:37,197
So it can have versions. 
But it's just one thing. 

423
00:18:37,650 --> 00:18:40,514
And other companies who couldn't
rebuild it from scratch, they 

424
00:18:40,581 --> 00:18:42,791
shoehorned it into GitHub. 
They said squash and merge. 

425
00:18:43,001 --> 00:18:44,321
Alright, I don't care what your 
commits were. 

426
00:18:44,321 --> 00:18:46,828
I don't care how many like fix, 
final fix, you know, you put on 

427
00:18:46,828 --> 00:18:49,288
this PR branch, we're just gonna
squash it and put it on a trunk.

428
00:18:49,288 --> 00:18:50,518
We're just gonna kind of force 
that pattern. 

429
00:18:50,548 --> 00:18:53,628
It's kinda weird 'cause we, I 
think the whole industry got 

430
00:18:53,628 --> 00:18:55,974
very excited about Git and 
GitHub and they're very cool 

431
00:18:55,974 --> 00:18:59,385
software. 
And we just used it as our 

432
00:18:59,385 --> 00:19:02,398
closed source systems for 
collaborating and coaching. 

433
00:19:02,668 --> 00:19:05,336
But we were shoving a lot of 
stuff that was built 

434
00:19:05,336 --> 00:19:06,418
intelligently for open source 
patterns. 

435
00:19:06,418 --> 00:19:09,736
We started shoving it into these
emerging closed source patterns.

436
00:19:10,066 --> 00:19:13,132
So now by 2025, I think from 
what I can tell, and we work 

437
00:19:13,132 --> 00:19:16,432
with a lot of companies, it 
really seems like there's a 

438
00:19:16,432 --> 00:19:18,787
centralization around patterns. 
It really seems like everyone is

439
00:19:18,787 --> 00:19:20,971
kind of getting on board with 
trunk based development. 

440
00:19:21,871 --> 00:19:24,541
Everyone is kind of centralizing
around single commit branches. 

441
00:19:24,541 --> 00:19:26,003
Now I know that that's a spicy 
topic. 

442
00:19:26,003 --> 00:19:27,653
Some developers really love 
multiple commits. 

443
00:19:28,103 --> 00:19:31,561
But I can tell you from the 
data, most companies just have 

444
00:19:31,561 --> 00:19:34,321
squash, I think squash on merge 
enabled where like they don't, 

445
00:19:34,321 --> 00:19:36,955
whatever you do with your code, 
we're just gonna compress that 

446
00:19:36,955 --> 00:19:40,673
when we hit merge. 
And you even have monorepo 

447
00:19:40,673 --> 00:19:42,487
patterns emerging. 
Again, monorepos don't make a 

448
00:19:42,487 --> 00:19:44,985
lot of sense in open source. 
It's antithetical in open 

449
00:19:44,985 --> 00:19:46,739
source. 
I want as many diverse small 

450
00:19:46,739 --> 00:19:48,561
projects as possible. 
Close source, we have these 

451
00:19:48,561 --> 00:19:51,666
monorepo patterns. 
So, I don't know, is the pull 

452
00:19:51,666 --> 00:19:54,249
request gonna still exist in the
future? 

453
00:19:55,439 --> 00:19:58,469
I do believe there will be an 
atomic unit of change that's 

454
00:19:58,469 --> 00:20:00,979
gonna get reviewed and tested 
and validated before it's merged

455
00:20:00,979 --> 00:20:01,949
in. 
That makes sense. 

456
00:20:01,949 --> 00:20:03,139
That's true. 
That's valid. 

457
00:20:04,219 --> 00:20:06,083
Does the name make sense? 
No, I think we gotta, I think we

458
00:20:06,083 --> 00:20:08,187
gotta come up with a better name
for this because once again, I'm

459
00:20:08,187 --> 00:20:11,099
just begging you to stamp my PR 
so I can merge it in. 

460
00:20:11,099 --> 00:20:13,559
I'm not requesting you to pull 
in my changes to anything. 

461
00:20:13,559 --> 00:20:15,074
That doesn't make sense. 
So the title's gotta change. 

462
00:20:15,224 --> 00:20:16,814
I think we can slim off a lot of
these features. 

463
00:20:16,814 --> 00:20:19,684
I think we can simplify it down 
to be more simple construct. 

464
00:20:20,244 --> 00:20:22,406
But the general idea that's 
gonna remain, we're still gonna 

465
00:20:22,406 --> 00:20:24,722
have code review. 
I think we're still gonna have 

466
00:20:24,722 --> 00:20:27,284
testing and some big processing 
step before integrating and 

467
00:20:27,284 --> 00:20:30,220
deploying it. 
Well, thanks for giving a little

468
00:20:30,220 --> 00:20:31,643
bit of historical context as 
well. 

469
00:20:31,643 --> 00:20:35,229
Like the different patterns 
people use and like how it got 

470
00:20:35,229 --> 00:20:38,209
evolved to now, right? 
And I'm sure you have seen a lot

471
00:20:38,209 --> 00:20:40,325
of patterns by working with many
different software engineering 

472
00:20:40,325 --> 00:20:43,053
teams, right? 
And I guess in many parts of 

473
00:20:43,053 --> 00:20:45,275
software engineering team, this 
is my hypothesis, like there 

474
00:20:45,275 --> 00:20:48,275
will be a lot of them still 
using pull requests or merge 

475
00:20:48,275 --> 00:20:50,829
requests, right, simply because,
you know, kind of like the 

476
00:20:50,829 --> 00:20:53,010
version control system. 
Maybe these days it's about 

477
00:20:53,010 --> 00:20:55,430
GitHub or GitLab. 
There's not many other options 

478
00:20:55,430 --> 00:20:58,517
that people use. 
Uh, and then in-built to those 

479
00:20:58,517 --> 00:21:01,157
tools are the merge requests and
pull requests. 

480
00:21:01,577 --> 00:21:04,845
So if we can dive deeper into 
pull requests, I know Graphite 

481
00:21:04,845 --> 00:21:07,727
being, you know, the front and 
center about pull requests, 

482
00:21:07,727 --> 00:21:10,763
right, code review. 
What are some of the best 

483
00:21:10,763 --> 00:21:13,966
practices of pull requests that 
you think you can advocate to 

484
00:21:13,966 --> 00:21:17,252
the listeners here? 
Oh, there's such an easy answer 

485
00:21:17,252 --> 00:21:19,194
to this. 
And I don't take credit for 

486
00:21:19,194 --> 00:21:20,880
this. 
I, It's popular among the 

487
00:21:20,880 --> 00:21:22,332
industry. 
It's timeless advice. 

488
00:21:22,662 --> 00:21:25,988
Google, I think, did the best 
job of helping advocate and 

489
00:21:25,988 --> 00:21:28,832
popularize this. 
Make your code changes small. 

490
00:21:30,598 --> 00:21:33,412
I can, I can die on this hill. 
This is is an easy hill to die 

491
00:21:33,412 --> 00:21:35,965
on. 
It's just, in general, on 

492
00:21:35,965 --> 00:21:40,255
average, caveat, caveat, caveat,
but in general, make those code 

493
00:21:40,255 --> 00:21:42,235
changes small. 
And what do I mean by small? 

494
00:21:42,415 --> 00:21:46,367
I think a good size is like 50, 
maybe 150 lines somewhere in 

495
00:21:46,367 --> 00:21:49,061
that ballpark. 
Of course, I love saying this 

496
00:21:49,061 --> 00:21:51,484
because then I get all these, 
uh, people in their armchair 

497
00:21:51,484 --> 00:21:53,551
being like, wait a second. 
One time I wrote like a 2,000 

498
00:21:53,551 --> 00:21:56,399
line PR and it was so good. 
One time I had to do a code mod 

499
00:21:56,399 --> 00:21:58,409
and it was 10,000 lines, but 
that was the right decision. 

500
00:21:59,549 --> 00:22:01,912
And so I love just kind of, it 
is a great way to bait people 

501
00:22:01,912 --> 00:22:04,093
into getting really excited to 
give me, gimme an edge case. 

502
00:22:04,369 --> 00:22:07,213
But I do think that in general, 
small code changes are good. 

503
00:22:07,213 --> 00:22:09,784
Why are they good? 
I think with a small code 

504
00:22:09,784 --> 00:22:11,194
change, you're gonna get 
reviewed faster. 

505
00:22:11,611 --> 00:22:12,470
That's great. 
Why? 

506
00:22:12,470 --> 00:22:13,430
Why are you gonna get reviewed 
faster? 

507
00:22:13,430 --> 00:22:15,258
Because your teammate's gonna 
get a notification and if they 

508
00:22:15,258 --> 00:22:17,283
see it's 50 lines, they're going
like, oh yeah, I'll just go 

509
00:22:17,283 --> 00:22:18,638
review. 
If they see it's 2000 lines, 

510
00:22:18,638 --> 00:22:19,820
they're like, I'm going to 
lunch. 

511
00:22:19,820 --> 00:22:22,640
And like I hope someone who 
wanna handle this after. 

512
00:22:22,880 --> 00:22:24,904
You just get all these people 
who's just like pretending that 

513
00:22:24,904 --> 00:22:28,160
they didn't see it. 
Uh, number two, the comments per

514
00:22:28,160 --> 00:22:31,846
line, the feedback per line of 
code you write is so much 

515
00:22:31,846 --> 00:22:33,567
higher. 
If your code change is small... 

516
00:22:33,567 --> 00:22:36,265
It's so interesting. 
Not even per line, just even on 

517
00:22:36,265 --> 00:22:39,665
average, just the number of 
comments a large PR received. 

518
00:22:39,665 --> 00:22:42,905
I think once you start crossing 
like the one to 2,000 line 

519
00:22:42,905 --> 00:22:45,335
boundary, you just start 
approaching like zero comments. 

520
00:22:45,335 --> 00:22:47,720
You just are so much more 
statistically likely to get like

521
00:22:47,720 --> 00:22:51,599
a LGTM (Looks Good To Me). 
Where's a, if I read a 50 line 

522
00:22:51,599 --> 00:22:53,681
PR, I'm gonna get some great 
feedback and some great 

523
00:22:53,681 --> 00:22:55,746
discussion on that PR. 
So I'm gonna get better 

524
00:22:55,746 --> 00:22:58,076
feedback. 
If there's a bug, if, no, if 

525
00:22:58,076 --> 00:23:01,003
there's a bug before I merge it 
in, okay, it's way easier to 

526
00:23:01,003 --> 00:23:03,572
figure out what's going wrong on
a 50 line PR than a 2,000 line 

527
00:23:03,572 --> 00:23:05,291
PR. 
And then if there's an issue 

528
00:23:05,291 --> 00:23:08,933
after I merge it in, well, heck,
I'd rather revert 50 lines than 

529
00:23:08,933 --> 00:23:12,593
revert 2,000 lines. 
So in general, I think small 

530
00:23:12,593 --> 00:23:16,508
code changes are fantastic, but 
there's a reason that sometimes 

531
00:23:16,508 --> 00:23:19,873
you write large pull requests. 
Like we're, you can appreciate 

532
00:23:19,873 --> 00:23:22,708
the wisdom that small is good, 
but we got a job to do. 

533
00:23:22,768 --> 00:23:25,550
And that job is to go and 
actually ship a feature, build a

534
00:23:25,550 --> 00:23:28,633
system, and sometimes I end up 
writing and we end up writing 

535
00:23:28,633 --> 00:23:30,718
large code changes. 
But why do we do that? 

536
00:23:31,078 --> 00:23:35,978
I think we do that because 
there's fixed costs and slowdown

537
00:23:35,978 --> 00:23:38,818
around just the execution of any
code change. 

538
00:23:39,223 --> 00:23:43,473
And so if I need to change a lot
of code and I'm doing it in bite

539
00:23:43,473 --> 00:23:46,843
wise, by small bites, I still 
gotta pass CI on all those. 

540
00:23:46,843 --> 00:23:48,673
I still gotta go back and forth 
on a feedback loop. 

541
00:23:49,313 --> 00:23:51,985
My god, the statistics around 
how long it takes to get a code 

542
00:23:51,985 --> 00:23:56,203
review are kind of depressing. 
I think like the median is 

543
00:23:56,203 --> 00:23:59,425
something around 10 hours. 
The average is something around 

544
00:23:59,425 --> 00:24:02,203
20 hours. 
The best like cases like the 

545
00:24:02,203 --> 00:24:05,129
P90, P95s are like three hours. 
Like it's quite depressing 

546
00:24:05,129 --> 00:24:06,842
statistics. 
So you're incurring some high 

547
00:24:06,842 --> 00:24:09,508
fixed cost there. 
Your CI, 30 minutes, let's say 

548
00:24:09,508 --> 00:24:12,142
you pass it first time around, 
then you gotta merge that out. 

549
00:24:12,142 --> 00:24:13,582
If you're lucky, that's pretty 
instantaneous. 

550
00:24:13,582 --> 00:24:16,096
But if you're at a bigger 
company, that merge process, 

551
00:24:16,096 --> 00:24:18,117
multiple release staging 
environments, that could take 

552
00:24:18,117 --> 00:24:21,422
its own couple hours. 
So heck, with all the fixed cost

553
00:24:21,422 --> 00:24:24,142
of like you don't want to be 
blocked, so why not just get a 

554
00:24:24,142 --> 00:24:26,482
bunch of work into one of these 
things and then shoot it off? 

555
00:24:26,482 --> 00:24:28,222
So you get, you start really 
getting that temptation. 

556
00:24:28,642 --> 00:24:34,202
And it's this chain of reasoning
that led companies like, I 

557
00:24:34,202 --> 00:24:37,684
think, Facebook and then from 
the, the many people who 

558
00:24:37,684 --> 00:24:40,227
descended from Facebook 
companies like Twitter and 

559
00:24:40,227 --> 00:24:43,551
Pinterest and many others to 
start leaning on a stacked 

560
00:24:43,551 --> 00:24:45,438
mentality. 
So there's this concept of 

561
00:24:45,438 --> 00:24:48,217
stacking, it's very core to what
we build at Graphite, but it's 

562
00:24:48,217 --> 00:24:50,063
also just a popular thing that 
anyone can do. 

563
00:24:50,063 --> 00:24:51,658
You can do this open source 
technologies, you can just do 

564
00:24:51,658 --> 00:24:52,943
this by hand if you're really 
hardcore. 

565
00:24:53,343 --> 00:24:55,253
But the idea of branching off a 
branch, off a branch. 

566
00:24:55,343 --> 00:24:58,123
Like why not? 
Why not have many small chunks 

567
00:24:58,123 --> 00:25:00,903
of small pieces of work and 
break them all up? 

568
00:25:01,973 --> 00:25:04,403
The benefit of doing this is you
unlock parallelization. 

569
00:25:05,093 --> 00:25:07,373
How do you make anything faster 
in software engineering? 

570
00:25:07,373 --> 00:25:09,593
You parallelize it. 
How do I make my CI faster? 

571
00:25:09,593 --> 00:25:11,123
I parallelize it. 
Same with my service. 

572
00:25:11,123 --> 00:25:13,050
It is, it's like one of the only
ways I can make things faster. 

573
00:25:13,290 --> 00:25:16,500
So can I parallelize these 
annoying waiting times, waiting 

574
00:25:16,500 --> 00:25:18,300
for a review, waiting for tests,
waiting for deployments? 

575
00:25:18,300 --> 00:25:20,479
Can I parallelize that and keep 
writing code changes on top of 

576
00:25:20,479 --> 00:25:22,788
that? 
If I can, then I get the best of

577
00:25:22,788 --> 00:25:24,764
both worlds. 
Then I get my small code changes

578
00:25:24,764 --> 00:25:27,730
and all the benefits and I also 
can just write my code and do my

579
00:25:27,730 --> 00:25:29,952
job a little bit faster. 
So I think it's that, that's 

580
00:25:29,952 --> 00:25:32,484
kind of the beauty of stacking, 
which is the premise of saying, 

581
00:25:32,484 --> 00:25:35,208
don't just create a code change 
and then wait and then create 

582
00:25:35,208 --> 00:25:36,450
the next one and then wait. 
It's like, no, no, no. 

583
00:25:37,110 --> 00:25:39,690
Do all the waiting in parallel 
and keep coding along alongside.

584
00:25:40,110 --> 00:25:43,083
This has become extra important 
because that coding time is 

585
00:25:43,083 --> 00:25:45,090
going down further and further 
and further. 

586
00:25:45,448 --> 00:25:47,585
We're all loving using Claude 
Code and Cursor and these 

587
00:25:47,585 --> 00:25:51,340
wonderful tools, and we brag 
about how fast it is to code 

588
00:25:51,340 --> 00:25:53,708
now, but again, those fixed 
costs haven't gone down. 

589
00:25:53,708 --> 00:25:55,028
So now you really want that 
parallelization. 

590
00:25:55,058 --> 00:25:57,806
So I think small code changes, 
yes, there's problems that 

591
00:25:57,806 --> 00:26:00,167
emerge from that. 
Things like stacking. 

592
00:26:00,227 --> 00:26:02,465
Other systems too, merge queues.
There's different techniques and

593
00:26:02,465 --> 00:26:05,373
technologies that then can 
emerge to assist in achieving 

594
00:26:05,373 --> 00:26:08,536
that dream. 
And I think anyone who has tried

595
00:26:08,536 --> 00:26:11,001
creating really small code 
changes and attempted to walk 

596
00:26:11,001 --> 00:26:14,275
that good path and been burned, 
I think it's for a lack of 

597
00:26:14,275 --> 00:26:16,191
tooling and support. 
Not because the original premise

598
00:26:16,191 --> 00:26:18,119
and idea was flawed. 
Yeah. 

599
00:26:18,119 --> 00:26:20,639
So I think the fixed cost is 
something that many people try 

600
00:26:20,639 --> 00:26:23,039
to avoid, right? 
So whenever you raise a PR, 

601
00:26:23,039 --> 00:26:26,021
first, somebody needs to pick 
up, review, finish all the 

602
00:26:26,021 --> 00:26:28,145
comments, you know, get ready 
for merge. 

603
00:26:28,165 --> 00:26:29,815
And then there's a CI build, 
right? 

604
00:26:29,965 --> 00:26:32,985
And then maybe there's a bug, 
you have to go back, fix it and 

605
00:26:32,985 --> 00:26:34,977
all that. 
So I think the fixed cost that 

606
00:26:34,977 --> 00:26:37,174
you mentioned is can be really 
painful for some software 

607
00:26:37,174 --> 00:26:39,782
engineering teams. 
And hence this stacked PR thing 

608
00:26:39,782 --> 00:26:41,702
maybe is like very helpful, 
right? 

609
00:26:41,702 --> 00:26:44,985
In order to kind of like unblock
developers so that they can pick

610
00:26:44,985 --> 00:26:47,685
up the next task building on top
of what they submitted, right? 

611
00:26:48,105 --> 00:26:50,765
But some people maybe have not 
actually experienced this 

612
00:26:50,765 --> 00:26:53,090
because stacked PR is not 
something that is built 

613
00:26:53,090 --> 00:26:56,115
natively, maybe on GitHub or 
maybe GitLab and some of these 

614
00:26:56,115 --> 00:26:58,401
tools, right? 
So maybe explain a little bit 

615
00:26:58,401 --> 00:27:00,363
what is stacked PR? 
You mentioned branch off a 

616
00:27:00,363 --> 00:27:02,641
branch off a branch. 
But some people think branch off

617
00:27:02,641 --> 00:27:05,813
a branch is not a good pattern. 
But why, uh, are we advocating 

618
00:27:05,813 --> 00:27:08,520
for that? 
And what do you think are like 

619
00:27:08,520 --> 00:27:11,537
some common benefits that people
have whenever they adopt this 

620
00:27:11,537 --> 00:27:13,713
stacked PR? 
Totally. 

621
00:27:13,913 --> 00:27:15,968
Yeah, yeah. 
So we go a little bit deeper on 

622
00:27:15,968 --> 00:27:19,463
the pattern of stacked PRs. 
And again, I don't wanna create,

623
00:27:19,463 --> 00:27:22,253
I don't wanna claim credit for 
having invented this. 

624
00:27:23,103 --> 00:27:25,903
The Facebook engineering team, I
keep calling it Facebook. 

625
00:27:25,973 --> 00:27:27,817
I've not gotten the Meta. 
The Facebook engineering team, 

626
00:27:27,817 --> 00:27:30,849
they've been doing this for a 
decade plus, like there's a 

627
00:27:30,849 --> 00:27:34,509
thousand, a hundred thousand 
engineers who have really tried 

628
00:27:34,509 --> 00:27:37,483
and tested these patterns. 
Still a small fragment of the 

629
00:27:37,483 --> 00:27:40,019
overall engineering population. 
And the reason, the other reason

630
00:27:40,019 --> 00:27:42,341
that a lot of people don't 
necessarily know about this is 

631
00:27:42,341 --> 00:27:44,221
because it never made sense in 
open source. 

632
00:27:44,221 --> 00:27:47,212
It's very interesting. 
So it never got that open source

633
00:27:47,212 --> 00:27:50,251
propagation of idea because open
source moves slower. 

634
00:27:50,491 --> 00:27:54,809
These PRs are open for a week or
a month, and they're long 

635
00:27:54,809 --> 00:27:56,131
discussions and they're really 
thoughtful. 

636
00:27:56,161 --> 00:27:59,359
And the idea of breaking them up
into 10 small pieces in parallel

637
00:27:59,359 --> 00:28:02,086
and getting reviewed, you don't 
need the velocity. 

638
00:28:02,356 --> 00:28:04,844
You also the maintainer might 
not even want it because the 

639
00:28:04,844 --> 00:28:07,606
maintainer doesn't want your 
piece by piece, small ideas. 

640
00:28:07,606 --> 00:28:09,016
They want the whole thing or 
nothing. 

641
00:28:09,226 --> 00:28:11,046
They don't want you to commit 
half of it and then walk away as

642
00:28:11,046 --> 00:28:13,276
a stranger, because I don't have
trust. 

643
00:28:13,276 --> 00:28:15,256
At a company, I trust that 
you're still coming into work 

644
00:28:15,256 --> 00:28:17,056
tomorrow and you started this 
feature and you're gonna use 

645
00:28:17,056 --> 00:28:19,206
this feature. 
And yeah, I want you to have 

646
00:28:19,206 --> 00:28:21,166
like that continuous trickle 
based development, that's really

647
00:28:21,166 --> 00:28:22,768
healthy. 
It's not allowed to worry about 

648
00:28:22,768 --> 00:28:25,572
you ghosting on me. 
So this idea, I think, has made 

649
00:28:25,572 --> 00:28:27,850
wonderful sense in companies and
still makes great sense in 

650
00:28:27,850 --> 00:28:29,875
companies, but it just didn't, 
it didn't get the lift off in 

651
00:28:29,875 --> 00:28:32,548
the open source community. 
And it didn't get the native 

652
00:28:32,548 --> 00:28:33,798
integration within tools like 
GitHub. 

653
00:28:34,528 --> 00:28:37,359
Okay, but, so to go a little 
deeper, what does it mean to 

654
00:28:37,359 --> 00:28:39,363
stack pull request or stack your
code changes? 

655
00:28:39,993 --> 00:28:42,143
Well, we all know what an 
individual code change is. 

656
00:28:42,143 --> 00:28:45,528
It's a, you create a change, a 
commit to branch, and it's based

657
00:28:45,528 --> 00:28:47,338
off something. 
And it's usually based off your 

658
00:28:47,338 --> 00:28:50,552
trunk, your main, your master. 
Okay, so it's a difference off 

659
00:28:50,552 --> 00:28:53,218
of the trunk. 
What if we create another 

660
00:28:53,218 --> 00:28:55,216
change? 
What if we, but what are, 

661
00:28:55,216 --> 00:28:59,258
instead of stacking it on trunk,
what if we stacked it on PR-A? 

662
00:28:59,278 --> 00:29:01,884
So now you have PR-A, PR-B. 
What's a real world example of 

663
00:29:01,884 --> 00:29:03,480
this? 
Let's say we're coding up a 

664
00:29:03,480 --> 00:29:05,620
feature for our website. 
What do I need to do? 

665
00:29:05,620 --> 00:29:08,950
I need to go and update my 
server, add some functionality. 

666
00:29:09,040 --> 00:29:11,232
I need to add a new endpoint. 
And I need to go and update my 

667
00:29:11,232 --> 00:29:12,880
website to call that endpoint 
and then show some information 

668
00:29:12,880 --> 00:29:15,964
to the user. 
Okay, so I could do this all as 

669
00:29:15,964 --> 00:29:18,010
a one of 2000 line PR, one shot 
thing. 

670
00:29:18,010 --> 00:29:19,403
I could spend a day or two and 
code that up. 

671
00:29:19,763 --> 00:29:21,653
Or what I could do is I could 
create a code change. 

672
00:29:21,653 --> 00:29:24,574
I could go, I could first add 
some functions to my server. 

673
00:29:24,604 --> 00:29:25,654
Fantastic. 
Boom, done. 

674
00:29:25,654 --> 00:29:27,364
Let's shave that off PR, put 
that up. 

675
00:29:27,364 --> 00:29:29,902
Start, wait, start that. 
Start that clock for my code 

676
00:29:29,902 --> 00:29:33,004
review for a couple of hours. 
Next, lemme go code up that 

677
00:29:33,004 --> 00:29:36,248
endpoint and let me, as I code 
up that endpoint that relies on 

678
00:29:36,248 --> 00:29:39,124
that function, stack it on top. 
I need that other code. 

679
00:29:39,154 --> 00:29:41,234
So lemme stack it on top. 
We have PR-A, PR-B. 

680
00:29:42,334 --> 00:29:45,120
Put that up for review. 
Now I got two things that are in

681
00:29:45,120 --> 00:29:46,393
parallel getting reviewed. 
Maybe different people, maybe 

682
00:29:46,393 --> 00:29:48,153
the same people. 
I'm parallelizing my testing as 

683
00:29:48,153 --> 00:29:50,121
well. 
Then I start coding the client 

684
00:29:50,121 --> 00:29:52,383
side, the update to the website 
that's gonna fetch that new 

685
00:29:52,383 --> 00:29:54,123
endpoint. 
Maybe by the time I finish 

686
00:29:54,123 --> 00:29:55,827
coding that, the other code 
changes, maybe they're good to 

687
00:29:55,827 --> 00:29:57,143
go. 
Maybe they're finally ready in 

688
00:29:57,143 --> 00:29:59,313
that three to five hour interim.
They're good to merge. 

689
00:29:59,553 --> 00:30:00,513
I can merge 'em. 
I can wait. 

690
00:30:00,513 --> 00:30:02,173
I could do whatever I want, but 
I'm unblock there. 

691
00:30:02,613 --> 00:30:04,923
And then I put up that third PR 
up for review. 

692
00:30:05,223 --> 00:30:08,056
This wouldn't be possible if 
these were all stacked off of 

693
00:30:08,056 --> 00:30:10,121
main, all based off of my main 
master. 

694
00:30:10,391 --> 00:30:12,271
I need these to be based off one
another. 

695
00:30:12,921 --> 00:30:14,876
Without stacking, what would I 
do? 

696
00:30:14,876 --> 00:30:17,076
I would either just keep 
bloating and adding to the 

697
00:30:17,076 --> 00:30:18,686
existing PR. 
So people do that, but then 

698
00:30:18,686 --> 00:30:20,786
that's, it is kind of cheating. 
'Cause sometimes you get a 

699
00:30:20,786 --> 00:30:23,174
review and then you extend the 
PR and you're like, I'm gonna 

700
00:30:23,174 --> 00:30:26,225
piggyback that old stamp. 
Or you just wait and work on 

701
00:30:26,225 --> 00:30:28,525
something else and you just 
can't continue that same idea. 

702
00:30:28,525 --> 00:30:29,905
But here with stacking, I can 
break it up. 

703
00:30:30,085 --> 00:30:32,935
I can paralyze the things and I 
can also keep my chain of flow. 

704
00:30:33,146 --> 00:30:35,966
So now, and I can zipper merge 
those like cars on a highway. 

705
00:30:35,966 --> 00:30:38,930
I can just zipper merge those 
into trunk and I can keep 

706
00:30:38,930 --> 00:30:40,616
moving. 
And the net effect, I'm getting 

707
00:30:40,616 --> 00:30:41,996
the parallelization and I'm 
never blocked. 

708
00:30:42,296 --> 00:30:44,816
I just keep checkpoint saving, 
just keep branching, just 

709
00:30:44,816 --> 00:30:45,896
breaking off a little piece 
here. 

710
00:30:46,206 --> 00:30:50,141
Now it gets tricky. 
If I was to do this in vanilla 

711
00:30:50,141 --> 00:30:52,031
Git, it works up until the 
point. 

712
00:30:52,031 --> 00:30:55,067
The point that this stops 
working is the day that my 

713
00:30:55,067 --> 00:30:57,951
teammate asks for a little bit 
of an edit on that first PR. 

714
00:30:57,951 --> 00:30:59,699
They get back to me in code 
review and they're like, hey, it

715
00:30:59,699 --> 00:31:01,508
looks great, Greg, but you know,
can we update this PR? 

716
00:31:01,988 --> 00:31:05,678
And I'm like, oh my god, because
I can update that PR. 

717
00:31:06,038 --> 00:31:09,038
But now my Git pointers are all 
over the place. 

718
00:31:09,038 --> 00:31:10,748
I am in like Git rebase hell 
now. 

719
00:31:10,748 --> 00:31:13,143
Like I update that now, PR 
number two, PR number three, 

720
00:31:13,143 --> 00:31:15,709
they're all over the place. 
Like the diffs look crazy on 

721
00:31:15,709 --> 00:31:16,645
GitHub. 
It's a mess. 

722
00:31:17,255 --> 00:31:20,125
And there are correct Git 
commands to run, but they are 

723
00:31:20,125 --> 00:31:22,823
very complicated, like three 
point rebates with like raw 

724
00:31:22,823 --> 00:31:25,375
hashes and it's just, it is 
super painful. 

725
00:31:25,855 --> 00:31:27,415
I don't care how good of an 
engineer you are, it's very 

726
00:31:27,415 --> 00:31:28,675
painful to try and do that by 
hand. 

727
00:31:28,984 --> 00:31:32,056
Imagine if it's a 10 stack, you 
do not want to go down 10 

728
00:31:32,056 --> 00:31:33,775
branches and perfectly reorder 
them. 

729
00:31:34,019 --> 00:31:36,535
And then perfectly resubmit them
to GitHub and then perfectly 

730
00:31:36,535 --> 00:31:39,606
update GitHub's merge branches. 
So this is where tooling, again,

731
00:31:39,606 --> 00:31:40,749
Graphite. 
I don't wanna be too preachy, 

732
00:31:40,749 --> 00:31:42,855
but Graphite like this is part 
of the problem we solve is like 

733
00:31:42,855 --> 00:31:44,742
we will actually carefully 
maintain the pointers and like 

734
00:31:44,742 --> 00:31:48,211
run the commands and update the 
remote pull requests and handle 

735
00:31:48,211 --> 00:31:49,866
this. 
Same thing with Facebook's 

736
00:31:49,866 --> 00:31:51,414
internal systems. 
Like what are they, what's the 

737
00:31:51,414 --> 00:31:53,827
code doing behind the scenes? 
It's doing all that rearranging 

738
00:31:53,827 --> 00:31:56,072
and restacking and just 
realignment for you. 

739
00:31:56,162 --> 00:31:58,940
So you can really quickly make a
down stack update and everything

740
00:31:58,940 --> 00:32:01,580
just flows naturally. 
You can get even more advanced 

741
00:32:01,580 --> 00:32:02,958
too. 
If you build more advanced 

742
00:32:02,958 --> 00:32:05,145
tooling, you can also merge in 
stacks and batches. 

743
00:32:05,425 --> 00:32:08,419
If half of it or all of it gets 
finally approved and ready to 

744
00:32:08,419 --> 00:32:09,775
go, great. 
One shot it in. 

745
00:32:10,015 --> 00:32:13,004
So I can mix and match to what 
degree I'm doing things 

746
00:32:13,004 --> 00:32:14,507
atomically. 
I'm doing things more in a 

747
00:32:14,507 --> 00:32:16,593
zipper merge fashion and it 
gives you a lot of flexibility 

748
00:32:16,593 --> 00:32:18,398
and power. 
But that's the general premise 

749
00:32:18,398 --> 00:32:21,080
is creating these small, small 
pieces in a continuous work 

750
00:32:21,080 --> 00:32:23,575
stream. 
In many ways, it's so funny, 

751
00:32:23,575 --> 00:32:27,135
it's so reminiscent of a pattern
we all know, which is like the 

752
00:32:27,135 --> 00:32:29,495
original premise of Git commits.
The original premise of Git 

753
00:32:29,495 --> 00:32:32,730
commits says I have a branch and
I'm creating a many small little

754
00:32:32,730 --> 00:32:34,907
commit checkpoints. 
Why did that not work? 

755
00:32:34,907 --> 00:32:35,927
Why does that not work in the 
modern world? 

756
00:32:35,927 --> 00:32:39,062
I think what happened is that 
artifact of history, but the 

757
00:32:39,062 --> 00:32:41,387
unit of code change ended up not
being the commit. 

758
00:32:41,567 --> 00:32:44,927
It ended up being the branch. 
You don't test your commits. 

759
00:32:44,927 --> 00:32:46,767
You don't review your commits, 
you review the branch. 

760
00:32:47,267 --> 00:32:52,363
And so we needed a new entity, a
new data structure to stack my 

761
00:32:52,363 --> 00:32:54,515
branches. 
Ideally, we could have done this

762
00:32:54,515 --> 00:32:57,073
with commits and branches, but 
now it has to be branches and 

763
00:32:57,073 --> 00:32:59,876
stacks. 
And we could simplify that. 

764
00:32:59,876 --> 00:33:01,756
And now if I can make every 
branch a single commit, I can 

765
00:33:01,756 --> 00:33:03,605
start getting to a simpler world
and we start getting closer to 

766
00:33:03,605 --> 00:33:05,680
what Facebook just rebuilt from 
scratch. 

767
00:33:05,680 --> 00:33:07,420
But if you wanna do this in a 
GitHub compatible way, you're 

768
00:33:07,420 --> 00:33:08,590
gonna have to stack your 
branches. 

769
00:33:09,370 --> 00:33:11,295
I, when we were first building 
Graphite, I thought long and 

770
00:33:11,295 --> 00:33:12,652
hard. 
I'm like, man, can we just do 

771
00:33:12,652 --> 00:33:13,660
this all with commits and 
branches? 

772
00:33:14,050 --> 00:33:17,380
And the only reason we didn't go
down that path was like, I just 

773
00:33:17,380 --> 00:33:19,360
know people don't, people don't 
review and test commits. 

774
00:33:19,360 --> 00:33:21,100
They don't merge commits. 
They merge in those branches. 

775
00:33:21,100 --> 00:33:22,926
If I wanna meet people and 
engineers where they're at, 

776
00:33:22,926 --> 00:33:24,340
we're gonna have to do this on a
branch level. 

777
00:33:25,452 --> 00:33:27,341
Yeah. 
So I think these days, like what

778
00:33:27,341 --> 00:33:30,495
you said, right, the atomic 
change is actually the PR or the

779
00:33:30,495 --> 00:33:33,197
branch, right? 
So people make a lot of commits 

780
00:33:33,197 --> 00:33:36,325
on that branch, maybe a few 
trial and error, bug fixes and 

781
00:33:36,325 --> 00:33:38,237
things like that. 
And then they raise a pull 

782
00:33:38,237 --> 00:33:40,551
request and that's kind of like 
the atomic change that a 

783
00:33:40,551 --> 00:33:43,216
developer will submit, right? 
And I think, thanks for trying 

784
00:33:43,216 --> 00:33:45,545
to explain about stacked PR. 
I know for some people maybe 

785
00:33:45,545 --> 00:33:48,425
it's still kind of like a bit 
abstract, but the moment when 

786
00:33:48,425 --> 00:33:50,944
you see an image or 
visualization, I'm sure probably

787
00:33:50,944 --> 00:33:54,257
it makes more sense, right? 
And when you work in a bigger, 

788
00:33:54,257 --> 00:33:57,069
larger software engineering team
where you have many different 

789
00:33:57,069 --> 00:34:00,009
modules, more people, right? 
I think this stacked PR also 

790
00:34:00,009 --> 00:34:02,997
kind of like, makes sense much 
better, because simply of those,

791
00:34:02,997 --> 00:34:05,811
you know, un-bottlenecking the 
process of software development 

792
00:34:05,811 --> 00:34:09,449
and merging into trunk. 
And uniquely, um, you have 

793
00:34:09,449 --> 00:34:12,429
shared this before, right? 
Graphite as a software 

794
00:34:12,429 --> 00:34:15,735
engineering team has actually a 
high velocity of software 

795
00:34:15,735 --> 00:34:18,458
development, producing code 
changes and things like that. 

796
00:34:18,909 --> 00:34:22,884
And you produce this statistic 
before, way back, I dunno, how 

797
00:34:22,884 --> 00:34:25,014
much different it has been since
then. 

798
00:34:25,375 --> 00:34:29,106
Like in your, you are in the P99
percentile of the software 

799
00:34:29,106 --> 00:34:30,646
engineering team in the 
statistic, right? 

800
00:34:30,946 --> 00:34:34,170
And you kind of like raise lots 
of PR within this team. 

801
00:34:34,784 --> 00:34:37,853
And funnily enough, right, the 
time too merge is actually 

802
00:34:37,853 --> 00:34:40,274
longer, is like within three 
hours and things like that. 

803
00:34:40,424 --> 00:34:43,690
So maybe, give us a glimpse of 
what is your statistics these 

804
00:34:43,690 --> 00:34:46,092
days. 
And why such things actually 

805
00:34:46,092 --> 00:34:48,873
become like a superpower for the
Graphite team? 

806
00:34:49,938 --> 00:34:50,873
Yeah. 
Yeah. 

807
00:34:51,250 --> 00:34:53,889
This blog post, this LinkedIn 
post I made a while back, maybe 

808
00:34:53,889 --> 00:34:57,540
a year or two year, year and a 
half ago, where I braggishly 

809
00:34:57,540 --> 00:35:01,672
said our team is in the P99 of 
productive engineering teams. 

810
00:35:01,940 --> 00:35:05,470
And I, it's kinda a spicy post. 
I like sometimes writing a spicy

811
00:35:05,470 --> 00:35:06,442
LinkedIn post. 
Why not? 

812
00:35:06,712 --> 00:35:09,226
Life is short, right? 
You know, it's... but I wrote 

813
00:35:09,226 --> 00:35:13,012
this post, I don't really love 
to brag, but I wrote this post 

814
00:35:13,012 --> 00:35:17,687
because I kept getting asked by 
people, you know, VCs and bigger

815
00:35:17,707 --> 00:35:21,226
companies, and they would say, 
you know, hey, Graphite you guys

816
00:35:21,226 --> 00:35:23,424
sell software that makes 
engineering teams faster. 

817
00:35:23,424 --> 00:35:24,957
Fundamentally, you know, it's 
nice and there's a lot of, 

818
00:35:24,957 --> 00:35:27,174
there's a lot of niceties and 
features and beauty to it. 

819
00:35:27,178 --> 00:35:29,324
But like the reason people are 
buying this, they're making the 

820
00:35:29,324 --> 00:35:33,104
engineering teams faster. 
If you're trying to sell 

821
00:35:33,104 --> 00:35:36,689
productivity, you better be the 
most productive team around. 

822
00:35:36,719 --> 00:35:39,103
Otherwise how can you go advise 
these other incredible companies

823
00:35:39,103 --> 00:35:41,377
to be faster? 
You better be walking the walk. 

824
00:35:42,097 --> 00:35:42,937
I was like, I thought about 
that. 

825
00:35:42,937 --> 00:35:45,082
I was like, yeah, you know, you 
know, and I, this team is 

826
00:35:45,082 --> 00:35:46,944
amazing. 
I'm like, let me, lemme just go 

827
00:35:46,944 --> 00:35:49,356
and braggishly write, you know, 
some numbers about why we 

828
00:35:49,356 --> 00:35:51,516
actually are insanely fast and 
be proud of that. 

829
00:35:51,516 --> 00:35:54,131
Let's be proud of that. 
Huge caveat, measuring software 

830
00:35:54,131 --> 00:35:57,689
developer productivity is like 
one of the most fraught things 

831
00:35:57,689 --> 00:36:00,554
you can possibly do. 
You'll get crucified in every 

832
00:36:00,554 --> 00:36:02,401
which way. 
It's a whole field. 

833
00:36:02,874 --> 00:36:05,655
And if there was a true answer, 
I think the entire art would 

834
00:36:05,655 --> 00:36:07,444
look very different. 
We don't go into performance 

835
00:36:07,444 --> 00:36:09,024
reviews. 
We don't hire and fire people 

836
00:36:09,024 --> 00:36:10,374
based on like single numerical 
metrics. 

837
00:36:10,374 --> 00:36:12,504
We all know that. 
So that's kind of proved to me 

838
00:36:12,504 --> 00:36:15,400
like no one has ever really 
cracked what it means to measure

839
00:36:15,400 --> 00:36:17,954
quantitatively productivity. 
But that being said, I wanted to

840
00:36:17,954 --> 00:36:19,734
write a spicy post and people 
kept asking me about it. 

841
00:36:19,734 --> 00:36:22,211
So, okay, like, let's do it by 
number of changes merged and 

842
00:36:22,211 --> 00:36:24,189
amount of code merged. 
I know this is a shallow metric,

843
00:36:24,189 --> 00:36:27,088
but like, let's just try that. 
And what you see is, you know, 

844
00:36:27,088 --> 00:36:29,252
the Graphite engineering team is
insanely fast. 

845
00:36:29,372 --> 00:36:30,842
We're not the fastest. 
There's a few others. 

846
00:36:30,920 --> 00:36:34,453
I'll give a shout out, uh, the 
Harvey AI. 

847
00:36:34,529 --> 00:36:38,213
Last time I checked the Harvey 
AI team, man, they ship code 

848
00:36:38,213 --> 00:36:39,119
fantastically. 
I don't know what they're doing.

849
00:36:39,119 --> 00:36:41,709
I wanna talk to more their 
engineers, but they are also 

850
00:36:41,709 --> 00:36:44,764
incredibly fast. 
I always just imagine they bring

851
00:36:44,764 --> 00:36:48,061
like a legal lawyer grindset 
mindset to it, and they're just 

852
00:36:48,061 --> 00:36:49,679
like, they're so trained from 
the law profession. 

853
00:36:49,679 --> 00:36:51,209
And then they somehow apply that
to engineering. 

854
00:36:51,209 --> 00:36:53,343
But they're, they're also, so 
there's some companies that are 

855
00:36:53,343 --> 00:36:56,101
really scrappy and fast. 
But why, why is Graphite 

856
00:36:56,101 --> 00:36:59,246
engineering team, ship a lot of 
code, ship a lot of code 

857
00:36:59,246 --> 00:37:00,823
changes? 
Why are we really productive 

858
00:37:00,823 --> 00:37:02,173
along those measurements of 
productivity? 

859
00:37:02,923 --> 00:37:05,377
We work hard and we're very 
smart, but we're not the, we 

860
00:37:05,377 --> 00:37:07,179
don't work the hardest. 
You know, these, there's like 

861
00:37:07,179 --> 00:37:08,755
teams who don't go home on the 
weekends. 

862
00:37:08,755 --> 00:37:10,345
There's teams who have sleeping 
bags in the office. 

863
00:37:10,345 --> 00:37:12,919
I think it's a bit screwed up. 
Like I want people to have 

864
00:37:12,919 --> 00:37:15,356
families and not get sick. 
So, you know, we work hard. 

865
00:37:15,376 --> 00:37:17,078
We, I don't want people to 
sleeping bags in the office. 

866
00:37:17,078 --> 00:37:18,068
And there's other teams who do 
that. 

867
00:37:18,398 --> 00:37:22,468
What we do is we have 
parallelization and we, you 

868
00:37:22,468 --> 00:37:24,908
know, don't get blocked on 
things. 

869
00:37:24,908 --> 00:37:27,086
Why do we do that? 
'Cause we use aggressively every

870
00:37:27,086 --> 00:37:29,198
tool that we build. 
We are stacking. 

871
00:37:29,198 --> 00:37:30,848
We are doing all these best 
practices. 

872
00:37:31,133 --> 00:37:32,258
We're breaking up our code 
changes. 

873
00:37:32,258 --> 00:37:34,178
We're getting incredible 
parallelization benefits. 

874
00:37:34,409 --> 00:37:37,833
We're merging things in batches.
We're reviewing them in charted 

875
00:37:37,833 --> 00:37:39,679
fashions. 
And we're using AI code 

876
00:37:39,679 --> 00:37:41,782
reviewers, and we're using merge
queues, and we're using every 

877
00:37:41,782 --> 00:37:44,122
tool in the toolbox to try and 
keep its engineering team as 

878
00:37:44,122 --> 00:37:45,577
fast as possible. 
Because we're building it. 

879
00:37:45,577 --> 00:37:46,687
It's dog fooding. 
It's a great thing. 

880
00:37:46,687 --> 00:37:47,837
You should use the stuff that 
you're building. 

881
00:37:47,837 --> 00:37:49,413
So we're using everything that 
we're building. 

882
00:37:49,879 --> 00:37:51,859
And I think it leads to these 
advantages. 

883
00:37:51,967 --> 00:37:53,807
Now people always ask me, 
they're like, okay, hey Greg, 

884
00:37:53,807 --> 00:37:56,343
you know, your engineering team 
ships a lot of code changes. 

885
00:37:56,484 --> 00:37:59,763
But if they're all just really 
small code changes, are you just

886
00:37:59,763 --> 00:38:02,133
like creating a different way of
doing the same amount of work? 

887
00:38:02,353 --> 00:38:04,982
But no. 
Fair question. 

888
00:38:04,982 --> 00:38:07,608
But when I check the numbers, 
when we check the numbers, it is

889
00:38:07,608 --> 00:38:09,950
actually the case that the net 
amount of code being added to 

890
00:38:09,950 --> 00:38:12,013
the code base shipped and merged
in, also removed, 'cause it's 

891
00:38:12,013 --> 00:38:14,347
important to measure it how much
code you're removing as well, 

892
00:38:14,347 --> 00:38:17,326
that is also higher in 
proportion to the changes being 

893
00:38:17,326 --> 00:38:19,918
smaller. 
So my sense is that the net 

894
00:38:19,918 --> 00:38:21,553
productivity is actually quite 
high. 

895
00:38:21,763 --> 00:38:24,535
And why is it high? 
Again, I think we're getting the

896
00:38:24,535 --> 00:38:26,352
benefits of parallelization. 
If I had to put a single point 

897
00:38:26,352 --> 00:38:27,720
on it. 
Cause the other interesting 

898
00:38:27,720 --> 00:38:29,974
thing you see with stacking, 
I've tried to measure this, 

899
00:38:29,974 --> 00:38:32,235
'cause customers will be like, 
oh, so you're gonna, you're 

900
00:38:32,235 --> 00:38:33,750
gonna make my code changes 
faster. 

901
00:38:34,230 --> 00:38:37,395
And it's really subtle. 
The average code change doesn't 

902
00:38:37,395 --> 00:38:39,090
necessarily get that much 
faster. 

903
00:38:39,090 --> 00:38:40,405
It depends. 
There's a lot of like case by 

904
00:38:40,405 --> 00:38:41,938
case. 
But the average code change, if 

905
00:38:41,938 --> 00:38:45,244
it used to take seven hours to 
merge, it might still take about

906
00:38:45,244 --> 00:38:47,815
seven hours to merge. 
Why is that the case? 

907
00:38:47,815 --> 00:38:49,449
It might, it still takes a 
couple hours to get reviewed, it

908
00:38:49,449 --> 00:38:50,545
still takes a couple hours past 
CI. 

909
00:38:50,755 --> 00:38:53,763
Like those kind of like forces 
aren't inherently being changed,

910
00:38:54,183 --> 00:38:56,314
but we just parallelize 
everything. 

911
00:38:56,344 --> 00:38:59,695
So you now have 10 code changes 
in parallel taking seven hours 

912
00:38:59,695 --> 00:39:02,345
to merge instead of just one 
blocking on one blocking on 

913
00:39:02,345 --> 00:39:04,117
another one. 
So we unlocked these 

914
00:39:04,117 --> 00:39:05,405
productivity gains. 
It was fun. 

915
00:39:05,405 --> 00:39:08,414
I wrote that, that blog post and
then a lot of people messaged 

916
00:39:08,414 --> 00:39:10,223
me. 
But live a little, you know, 

917
00:39:10,223 --> 00:39:13,840
write a spicy LinkedIn post. 
Yeah, definitely as a dev tools,

918
00:39:13,840 --> 00:39:15,116
right? 
You're gonna preach what... 

919
00:39:15,116 --> 00:39:16,852
you're gonna do what you preach,
right? 

920
00:39:16,852 --> 00:39:19,612
So I think definitely a cool 
story to share, right? 

921
00:39:19,612 --> 00:39:22,539
And I think the stacked PR is 
kind of like play a big role as 

922
00:39:22,539 --> 00:39:24,894
part of the productivity that 
you guys have, right? 

923
00:39:25,074 --> 00:39:27,880
And especially with your 
advocate about, you know, small 

924
00:39:27,880 --> 00:39:30,954
PR, and, you know, stacking a 
few changes in batches. 

925
00:39:30,954 --> 00:39:32,304
I think that will be really 
cool. 

926
00:39:32,604 --> 00:39:34,921
And I also use Graphite with my 
team, right? 

927
00:39:35,031 --> 00:39:38,746
And we always love to see this, 
uh, weekly software email, like 

928
00:39:38,746 --> 00:39:40,654
weekly in code or something like
that, right? 

929
00:39:40,924 --> 00:39:43,894
Where Graphite will send you an 
insights based on your pull 

930
00:39:43,894 --> 00:39:46,540
requests, right? 
So things like number of lines 

931
00:39:46,540 --> 00:39:49,582
and always like top reviewers, 
top number of code changes, 

932
00:39:49,582 --> 00:39:51,966
those kind of things is always 
something that we like to brag 

933
00:39:51,966 --> 00:39:54,183
on. 
And yeah, I think those things 

934
00:39:54,183 --> 00:39:56,674
are great, right? 
So definitely we can measure a 

935
00:39:56,674 --> 00:39:59,371
little bit of software 
productivity and you know, how 

936
00:39:59,371 --> 00:40:02,296
much quality and how much 
velocity that you have simply by

937
00:40:02,296 --> 00:40:06,299
analyzing the pull requests. 
So let's move on a little bit to

938
00:40:06,299 --> 00:40:07,877
the AI code review aspect, 
right? 

939
00:40:07,877 --> 00:40:09,887
Because now Graphite also has 
that tool. 

940
00:40:09,917 --> 00:40:13,455
Uh, I think it's called Diamond.
So like you said, right, these 

941
00:40:13,455 --> 00:40:16,305
days, maybe most of the code are
written by AI. 

942
00:40:16,644 --> 00:40:20,102
So maybe written by human. 
But also at the same time AI is 

943
00:40:20,102 --> 00:40:23,172
helping to review. 
I think this, as far as I 

944
00:40:23,172 --> 00:40:26,384
experience it, right? 
It's not as mature as like human

945
00:40:26,384 --> 00:40:29,523
reviewing code. 
So what do you think is the best

946
00:40:29,523 --> 00:40:31,839
use case for AI code review as 
of now? 

947
00:40:32,629 --> 00:40:36,628
The best use case of AI code 
review, saving face, not 

948
00:40:36,628 --> 00:40:38,187
embarrassing yourself or your 
technique. 

949
00:40:38,187 --> 00:40:39,607
No, I said, I say that. 
I say that jokingly. 

950
00:40:39,607 --> 00:40:43,301
Semi jokingly, semi, semi real. 
AI code review is so interesting

951
00:40:43,301 --> 00:40:46,206
to me. 
This is, I think it, we are, we 

952
00:40:46,206 --> 00:40:50,231
are experiencing the emergence 
in the advent of a new pillar 

953
00:40:50,231 --> 00:40:55,433
within the software engineering 
lifecycle that's here to stay. 

954
00:40:55,983 --> 00:41:00,156
I am very convinced that from 
here on out forevermore, every 

955
00:41:00,156 --> 00:41:04,389
single code change we write at 
companies will be scanned by an 

956
00:41:04,389 --> 00:41:08,388
LLM and they'll spot check it. 
In the same way that we all use 

957
00:41:08,388 --> 00:41:10,276
CI. 
If your company uses CI and your

958
00:41:10,276 --> 00:41:12,513
company runs linters, I think 
they're also gonna run an AI 

959
00:41:12,513 --> 00:41:14,751
code reviewer. 
In fact, we call it AI code 

960
00:41:14,751 --> 00:41:16,120
review. 
People in the industry calls it 

961
00:41:16,120 --> 00:41:19,070
AI code review. 
But I think that that is a more 

962
00:41:19,070 --> 00:41:20,818
of a market term. 
If I was to be really 

963
00:41:20,818 --> 00:41:22,318
engineering about it, I'd 
actually just call this a subset

964
00:41:22,318 --> 00:41:24,407
of CI. 
Because what is it 

965
00:41:24,407 --> 00:41:26,867
fundamentally? 
We're saying you put up a code 

966
00:41:26,867 --> 00:41:29,624
change and we're gonna run some 
compute in the cloud for two 

967
00:41:29,624 --> 00:41:30,585
minutes. 
We're gonna hum away and then 

968
00:41:30,585 --> 00:41:31,955
we're gonna give you some 
feedback and tell you that 

969
00:41:31,955 --> 00:41:33,604
there's an issue or not. 
And like that's, that's kinda 

970
00:41:33,604 --> 00:41:36,478
what my unit tests do. 
This thing's cool because it 

971
00:41:36,478 --> 00:41:39,671
takes like zero configuration. 
It's very flexible, it's very 

972
00:41:39,671 --> 00:41:41,625
fluid. 
It's not brittle like my unit 

973
00:41:41,625 --> 00:41:43,221
tests. 
So zero configuration, zero 

974
00:41:43,221 --> 00:41:44,367
maintenance. 
That's really nice. 

975
00:41:44,577 --> 00:41:47,218
But it's kind of just a new form
of testing and validation. 

976
00:41:47,368 --> 00:41:50,452
Just like my unit test, it's not
gonna catch everything, but it's

977
00:41:50,452 --> 00:41:52,439
gonna catch some stuff. 
And at the right price, I'd 

978
00:41:52,439 --> 00:41:54,712
rather have at the right price, 
and if it's low false positive, 

979
00:41:54,712 --> 00:41:56,998
I'd always rather have it than 
not have it, you know? 

980
00:41:57,275 --> 00:41:58,288
And what's really creative about
it? 

981
00:41:58,288 --> 00:42:00,401
What's really interesting to me 
about it is actually, I think 

982
00:42:00,401 --> 00:42:02,435
it's starting in some ways to 
supersede linting. 

983
00:42:02,668 --> 00:42:04,835
Now, of course, it's not as 
deterministically correct as 

984
00:42:04,835 --> 00:42:06,875
linting, but it's faster than 
linting. 

985
00:42:07,025 --> 00:42:09,524
I run ESlint and we run, you 
know, various linting patterns 

986
00:42:09,524 --> 00:42:13,139
on our code base, but it takes 
like five minutes, 10 minutes 

987
00:42:13,139 --> 00:42:16,371
sometimes to clone, to build, to
then execute a deterministic 

988
00:42:16,371 --> 00:42:18,995
linter. 
These LLMs return in like 30 

989
00:42:18,995 --> 00:42:20,733
seconds or less. 
Like, so sometimes it'll 

990
00:42:20,733 --> 00:42:23,457
actually just be the fastest way
to like catch simple issues even

991
00:42:23,457 --> 00:42:25,540
faster than building my code. 
It'll tell me it's not gonna 

992
00:42:25,540 --> 00:42:26,895
build. 
I find that really cool. 

993
00:42:27,435 --> 00:42:30,803
But what's the utility of this? 
It's another way to check for 

994
00:42:30,803 --> 00:42:33,515
certain forms of errors, 
mistakes, style issues, so on. 

995
00:42:34,295 --> 00:42:36,605
So it's a really good way to get
a first check of feedback too. 

996
00:42:36,605 --> 00:42:39,598
You can start getting some 
subsets of what we get outta 

997
00:42:39,598 --> 00:42:41,550
code review. 
And I can get it fast and I can 

998
00:42:41,550 --> 00:42:42,642
get it before I bother my 
teammate. 

999
00:42:43,262 --> 00:42:46,342
And as I've talked about in this
conversation, you know, I'd 

1000
00:42:46,342 --> 00:42:49,172
really rather get some feedback 
in 30 seconds than in three 

1001
00:42:49,172 --> 00:42:51,329
hours or five hours. 
That has a ton of benefits to 

1002
00:42:51,329 --> 00:42:53,216
me. 
I'm still contextually locked 

1003
00:42:53,216 --> 00:42:54,624
in. 
It's still paged into my human 

1004
00:42:54,624 --> 00:42:57,202
brain memory so I have it so I 
can go and fix it really 

1005
00:42:57,202 --> 00:42:59,786
quickly. 
Also it is the most painstaking 

1006
00:42:59,786 --> 00:43:03,464
thing to wait three hours, get a
code review and have a, your 

1007
00:43:03,464 --> 00:43:05,334
teammate be like, yeah, it looks
good, except please just fix 

1008
00:43:05,334 --> 00:43:07,319
this like one thing and then 
I'll stamp it. 

1009
00:43:07,319 --> 00:43:09,929
'Cause then I fix it, and then I
gotta wait on three hours for my

1010
00:43:09,929 --> 00:43:11,189
teammate to come back from 
lunch. 

1011
00:43:11,249 --> 00:43:12,629
And I'm just, I don't wanna 
merge this thing. 

1012
00:43:12,629 --> 00:43:15,567
So if I can review, reduce 
review cycles, and I can, by the

1013
00:43:15,567 --> 00:43:18,837
time I'm putting it in front of 
my teammate, all the stupid 

1014
00:43:18,837 --> 00:43:22,153
stuff has been flagged, fixed, 
handled, and they can really 

1015
00:43:22,153 --> 00:43:25,109
start thinking about the higher 
level questions – what humans 

1016
00:43:25,109 --> 00:43:27,527
are still good at up until now, 
we'll see, we'll see that it's 

1017
00:43:27,527 --> 00:43:29,993
constant race. 
But I want my teammate worrying 

1018
00:43:29,993 --> 00:43:33,181
about like the architecture and 
where we're taking the code base

1019
00:43:33,181 --> 00:43:35,249
and does this make sense and in 
line with the patterns. 

1020
00:43:35,249 --> 00:43:37,278
Is there a teaching moment? 
I want them worrying about that 

1021
00:43:37,278 --> 00:43:39,591
and not worrying about every 
single if statement and for loop

1022
00:43:39,591 --> 00:43:41,590
and just, I get this quite right
and perfect. 

1023
00:43:42,470 --> 00:43:44,485
Some of the people who love on 
the team too, that, you know, 

1024
00:43:44,485 --> 00:43:46,786
that we find tech leads really 
love this stuff too, because 

1025
00:43:46,786 --> 00:43:49,296
they can then go into custom 
rules files and custom style 

1026
00:43:49,296 --> 00:43:51,400
guides and really encode a lot 
of nuance. 

1027
00:43:51,640 --> 00:43:54,840
Some of these people are tired 
of going around the company and 

1028
00:43:54,840 --> 00:43:57,094
being like the bad guy and 
upholding some of these best 

1029
00:43:57,094 --> 00:43:59,492
practices and now they can tell 
a bot to go around the company 

1030
00:43:59,492 --> 00:44:02,358
and be the bad guy. 
So there's a lot of cool 

1031
00:44:02,358 --> 00:44:04,646
emergent properties. 
But I think it kinda goes 

1032
00:44:04,646 --> 00:44:06,446
without saying like, this is a 
pre-flight check. 

1033
00:44:06,446 --> 00:44:09,301
This is like a CI, but the same 
way, you don't merge in your 

1034
00:44:09,301 --> 00:44:11,262
code after you pass CI. 
You merge in your code after you

1035
00:44:11,262 --> 00:44:14,210
pass CI and get a human review. 
I think we're gonna keep living 

1036
00:44:14,210 --> 00:44:16,800
in that world for a while, for 
security reasons, for context 

1037
00:44:16,800 --> 00:44:19,650
reasons, because machines make 
mistakes and can't be held 

1038
00:44:19,650 --> 00:44:21,196
accountable. 
We still need that human review.

1039
00:44:21,716 --> 00:44:23,786
But man, it's cool! 
Man, it's useful! 

1040
00:44:23,786 --> 00:44:26,619
And I really think, uh, we 
spend, like everyone spends 

1041
00:44:26,619 --> 00:44:29,170
hundreds of dollars, thousands 
of dollars on CI and testing. 

1042
00:44:29,650 --> 00:44:31,866
I think we'll also be running 
this outta that same bucket as 

1043
00:44:31,866 --> 00:44:33,745
well. 
Wow! 

1044
00:44:33,775 --> 00:44:35,848
Definitely makes sense, right, 
now that you mentioned about it,

1045
00:44:35,848 --> 00:44:37,525
right? 
So we should just think of it 

1046
00:44:37,525 --> 00:44:40,429
like one aspect of CI, like the 
gatekeeping process, right? 

1047
00:44:40,699 --> 00:44:44,547
To actually find issues, errors,
style divergence, right? 

1048
00:44:44,877 --> 00:44:47,734
So within seconds, right? 
So because this LLM tends to 

1049
00:44:47,734 --> 00:44:50,262
have like bigger context and 
they can do pattern matching 

1050
00:44:50,262 --> 00:44:53,332
quite fast, so I think that's 
where we get the benefits. 

1051
00:44:53,452 --> 00:44:56,616
And I think in the spirit of 
shifting left, right, I think 

1052
00:44:56,616 --> 00:45:00,502
there's also no blocker, so to 
speak, right, to run this on 

1053
00:45:00,502 --> 00:45:03,178
your local, right? 
So that you can actually catch 

1054
00:45:03,178 --> 00:45:04,840
all these issues using AI 
faster. 

1055
00:45:04,870 --> 00:45:08,146
Although these days, I think 
people use AI to churn out code,

1056
00:45:08,146 --> 00:45:11,073
not to actually review it after,
you know, they finish their 

1057
00:45:11,073 --> 00:45:13,616
work, right? 
But I think going forward, I 

1058
00:45:13,616 --> 00:45:17,081
could actually see the use case 
where you use AI to actually 

1059
00:45:17,081 --> 00:45:20,868
review your branch locally first
before you even push it to the 

1060
00:45:20,868 --> 00:45:22,836
GitHub, right? 
So I think thanks for sharing 

1061
00:45:22,836 --> 00:45:25,508
that. 
Another thing that I wanna ask 

1062
00:45:25,508 --> 00:45:28,094
you, coming back to the 
productivity of your software 

1063
00:45:28,094 --> 00:45:31,197
engineering team. 
Apart from stacked PR, what do 

1064
00:45:31,197 --> 00:45:34,422
you think are the biggest, you 
know, levers within your 

1065
00:45:34,422 --> 00:45:37,600
engineering team that can 
actually produce much, much 

1066
00:45:37,600 --> 00:45:39,894
higher velocity and also being 
more productive? 

1067
00:45:40,976 --> 00:45:45,399
You know, so I can only speak 
from personal experience from 

1068
00:45:45,399 --> 00:45:48,447
one set of anecdotes as my 
experience at Graphite in the 

1069
00:45:48,447 --> 00:45:50,335
startup. 
So with the large caveat of, you

1070
00:45:50,335 --> 00:45:52,513
know, what works for us might 
not work for other people. 

1071
00:45:52,513 --> 00:45:54,685
We are case by case. 
But I can tell you some of the 

1072
00:45:54,685 --> 00:45:56,725
stuff we do do. 
One thing we do, it's really 

1073
00:45:56,725 --> 00:45:58,532
simple, but we choose to be full
in person. 

1074
00:45:58,945 --> 00:46:02,991
We're about, as this recording, 
we're probably about 45 people 

1075
00:46:02,991 --> 00:46:04,998
in a room right now. 
It's kind of busting out the 

1076
00:46:04,998 --> 00:46:06,636
seams, so we're getting another 
floor in the building. 

1077
00:46:06,936 --> 00:46:10,871
But there are timeless 
advantages to just being 

1078
00:46:10,871 --> 00:46:15,630
face-to-face with all the people
you're working with, even in a 

1079
00:46:15,630 --> 00:46:19,716
world post COVID, where remote 
work is more popular and really 

1080
00:46:19,716 --> 00:46:22,544
beneficial to some folks, you 
know, work-life balance and 

1081
00:46:22,544 --> 00:46:24,118
things. 
But if you really wanna optimize

1082
00:46:24,118 --> 00:46:26,800
for the productivity of your 
team, I think it's very hard to 

1083
00:46:26,800 --> 00:46:29,998
beat just being in a room having
great deep relationships with 

1084
00:46:29,998 --> 00:46:32,518
your teammates. 
Being able to look 'em in the 

1085
00:46:32,518 --> 00:46:34,776
face and have a conversation. 
Being able to get that tonality 

1086
00:46:34,776 --> 00:46:36,496
of voice. 
Being able to jump to a 

1087
00:46:36,496 --> 00:46:39,076
whiteboard. 
Being able to say things in 

1088
00:46:39,076 --> 00:46:41,098
passing, ideas, joke, all these 
things. 

1089
00:46:41,098 --> 00:46:44,518
To be able to go on a coffee 
walk and muse about some big 

1090
00:46:44,518 --> 00:46:47,758
idea that you're hacking on. 
All this stuff really matters. 

1091
00:46:48,028 --> 00:46:51,037
I think about it, I once heard 
this term of like fidelity of 

1092
00:46:51,037 --> 00:46:52,411
communication. 
There's many ways you can 

1093
00:46:52,411 --> 00:46:53,443
communicate. 
You can Slack message. 

1094
00:46:53,443 --> 00:46:54,733
You can call. 
You can video call. 

1095
00:46:54,917 --> 00:46:57,853
You can just go, say, go get in 
a room with a person. 

1096
00:46:58,258 --> 00:47:00,673
There's different qualities of 
fidelity of communication. 

1097
00:47:00,673 --> 00:47:02,807
And I think it goes without 
saying that the highest fidelity

1098
00:47:02,807 --> 00:47:05,958
is just two people in a room 
having a heart to heart, talking

1099
00:47:05,958 --> 00:47:07,687
about something serious. 
And it's really hard to beat 

1100
00:47:07,687 --> 00:47:09,888
that. 
So we don't have unlimited time.

1101
00:47:09,888 --> 00:47:11,338
I know every startup's in a 
rush. 

1102
00:47:11,638 --> 00:47:13,583
So let's also make, let's use 
that time the best we can. 

1103
00:47:13,583 --> 00:47:15,448
Let's have really high fidelity.
So we believe in that. 

1104
00:47:15,658 --> 00:47:18,460
Now, that means many trade offs.
It means that we can't hire 

1105
00:47:18,460 --> 00:47:20,188
certain people remote who we'd 
love to hire. 

1106
00:47:20,398 --> 00:47:22,678
It means that it's a little bit 
less flexible of lifestyle for 

1107
00:47:22,678 --> 00:47:25,368
the people who work together. 
But we get that benefit we get. 

1108
00:47:25,368 --> 00:47:28,930
And not just productivity too. 
I really enjoy and care about 

1109
00:47:28,930 --> 00:47:31,714
just people being friends with 
people they work with and having

1110
00:47:31,714 --> 00:47:33,010
deep relationships and caring 
about one another. 

1111
00:47:33,010 --> 00:47:34,420
Life is long. 
Careers are long. 

1112
00:47:34,900 --> 00:47:38,912
And I think there's huge value 
in learning from one another, 

1113
00:47:38,912 --> 00:47:40,800
building relationships. 
I, you know, one day we'll go to

1114
00:47:40,800 --> 00:47:42,738
new jobs and careers and stuff, 
but we'll remember the people we

1115
00:47:42,738 --> 00:47:44,420
worked with and both had a 
really good experience. 

1116
00:47:44,570 --> 00:47:45,800
So I really, I really value 
that. 

1117
00:47:46,466 --> 00:47:47,786
I think this is becoming more in
vogue. 

1118
00:47:47,786 --> 00:47:50,420
This used to be weird. 
I would say this in like 2022 

1119
00:47:50,420 --> 00:47:51,746
and people would like, that's 
crazy. 

1120
00:47:51,746 --> 00:47:54,219
You're a full in-person startup.
And now I think by 2025 it's 

1121
00:47:54,219 --> 00:47:55,736
like kind of back in vogue a 
little bit. 

1122
00:47:55,736 --> 00:48:00,298
So the pendulum swings. 
Other things we do, I don't 

1123
00:48:00,298 --> 00:48:04,618
think we do anything too crazy. 
We dogfood heavily. 

1124
00:48:04,789 --> 00:48:08,555
One of our advantages as a dev 
tool team, it's not just, and 

1125
00:48:08,555 --> 00:48:10,847
I'm talking a little bit about 
like empathy and communication 

1126
00:48:10,847 --> 00:48:12,955
internally, but we also get it 
with our users. 

1127
00:48:13,195 --> 00:48:17,095
It's a great cheat code to be a 
dev tools company because our 

1128
00:48:17,095 --> 00:48:19,685
users are the same as us, the 
engineering team. 

1129
00:48:20,225 --> 00:48:23,255
And we do foster a culture of 
say, hey, you know, like your 

1130
00:48:23,255 --> 00:48:27,054
feelings and ideas you, 
teammate, I see on the team, it 

1131
00:48:27,054 --> 00:48:28,901
matters. 
Like if you are looking at the 

1132
00:48:28,901 --> 00:48:31,269
CLI, the website, the button, 
the merge, the stacking pattern,

1133
00:48:31,269 --> 00:48:33,396
and you're like, this doesn't 
feel right, this could be a 

1134
00:48:33,396 --> 00:48:34,740
little bit better. 
You're probably totally correct 

1135
00:48:34,740 --> 00:48:36,399
'cause you are the user, you 
know. 

1136
00:48:36,489 --> 00:48:38,124
It's not like we're building a 
healthcare thing or a financial 

1137
00:48:38,124 --> 00:48:40,629
service or a law firm. 
Like we're building dev tools. 

1138
00:48:40,629 --> 00:48:42,369
So you're your, your values of 
matter. 

1139
00:48:42,519 --> 00:48:45,543
And what's great is we get to be
in Slack channels with hundreds 

1140
00:48:45,543 --> 00:48:47,839
of user companies. 
Such cool companies, everyone 

1141
00:48:47,839 --> 00:48:50,531
from like Figma to Notion to 
Shopify. 

1142
00:48:50,531 --> 00:48:52,511
These really cool companies that
we built for. 

1143
00:48:52,751 --> 00:48:55,721
We're also in there with their 
engineering teams and we're just

1144
00:48:55,721 --> 00:48:58,163
debating ideas on what are you 
doing for your best developer 

1145
00:48:58,163 --> 00:48:59,381
practices, and here's what we're
doing. 

1146
00:48:59,591 --> 00:49:01,221
Here's how we're building it 
into Graphite. 

1147
00:49:01,311 --> 00:49:02,741
We're expanding our Postgres 
database. 

1148
00:49:02,741 --> 00:49:04,789
Hey, Notion, you had a great 
blog post about how you sharded 

1149
00:49:04,789 --> 00:49:06,751
your Postgres database. 
Can you get on a call and talk 

1150
00:49:06,751 --> 00:49:08,111
to us about that? 
And we're gonna trade ideas. 

1151
00:49:08,201 --> 00:49:10,421
And they love that. 
They love that 'cause they want 

1152
00:49:10,421 --> 00:49:12,916
us to be better and faster, more
reliable 'cause then they can 

1153
00:49:12,916 --> 00:49:14,531
use it. 
So there's this incredible 

1154
00:49:14,531 --> 00:49:17,835
synergy and it's not everyone 
gets to play this game, but we 

1155
00:49:17,835 --> 00:49:20,607
get to play this game as a dev 
tool where us and our users and 

1156
00:49:20,607 --> 00:49:23,802
that line is very blurry. 
I'd love to cultivate the 

1157
00:49:23,802 --> 00:49:27,237
feeling that we are actually 
just an extension of all these 

1158
00:49:27,237 --> 00:49:29,385
user companies. 
They go on Slack and they have 

1159
00:49:29,385 --> 00:49:31,192
internal dev tools teams, and 
then they also have a Slack 

1160
00:49:31,192 --> 00:49:33,039
channel with Graphite. 
And I want them to feel like we 

1161
00:49:33,039 --> 00:49:35,275
are just an extension of their 
dev tool team, to have that 

1162
00:49:35,275 --> 00:49:36,775
relationship. 
And then likewise, internally, 

1163
00:49:36,775 --> 00:49:40,233
we get to really thrive on the 
feeling that like we are part of

1164
00:49:40,233 --> 00:49:42,577
thousand of the coolest 
companies in the industry. 

1165
00:49:42,637 --> 00:49:43,927
We don't have to pick which one 
we work at. 

1166
00:49:43,927 --> 00:49:45,586
We work at all of 'em. 
We get to bill for all of them. 

1167
00:49:46,154 --> 00:49:48,704
And then last thing I'll say is 
then having a lot of trust and 

1168
00:49:48,704 --> 00:49:52,114
bottoms up feeling and 
empowerment to let people on the

1169
00:49:52,114 --> 00:49:54,014
team. 
Then go and apply that. 

1170
00:49:54,194 --> 00:49:57,384
You know, you don't have to go 
through 10 meetings and 10 

1171
00:49:57,384 --> 00:49:59,611
approval processes to take that 
feeling and then update the CLI 

1172
00:49:59,611 --> 00:50:01,964
and update one of the command. 
Let's actually trust the team. 

1173
00:50:02,324 --> 00:50:03,605
Again, we can cheat. 
We're small. 

1174
00:50:03,635 --> 00:50:05,261
When you're 45 people, you can 
pull this off. 

1175
00:50:05,261 --> 00:50:07,412
I get that at a thousand persons
company, it's a little bit 

1176
00:50:07,412 --> 00:50:08,947
harder. 
But let's lean, if we had the 

1177
00:50:08,947 --> 00:50:10,821
advantage, let's lean into it 
and let's really empower people 

1178
00:50:10,821 --> 00:50:13,741
to very quickly take ideas, 
change them, ship them. 

1179
00:50:13,921 --> 00:50:15,955
Maybe put 'em behind a feature 
flag, but still get 'em out to 

1180
00:50:15,955 --> 00:50:17,261
production. 
And let's iterate really, really

1181
00:50:17,261 --> 00:50:19,519
quickly. 
We're a company about speed and 

1182
00:50:19,519 --> 00:50:21,181
velocity. 
Let's make sure we're really 

1183
00:50:21,181 --> 00:50:23,997
living up to that, both in our 
cultural practices, not just 

1184
00:50:23,997 --> 00:50:27,201
what we build as well. 
Thanks for sharing some of 

1185
00:50:27,201 --> 00:50:29,899
these, uh, elements or recipes, 
how you build your engineering 

1186
00:50:29,899 --> 00:50:32,005
team, right? 
Because it's always cool to hear

1187
00:50:32,005 --> 00:50:33,943
from different teams, right, how
they succeed. 

1188
00:50:34,273 --> 00:50:36,433
And probably some of us also can
learn about, you know, building 

1189
00:50:36,433 --> 00:50:39,433
relationship, building trust, 
the fidelity of communications. 

1190
00:50:39,613 --> 00:50:40,963
I think that's really important 
as well. 

1191
00:50:40,963 --> 00:50:43,389
Even though software engineers, 
some don't like to kinda like 

1192
00:50:43,389 --> 00:50:47,099
talk to each other, but I think 
it's always very important to 

1193
00:50:47,099 --> 00:50:49,539
build relationship. 
And I think the cool thing about

1194
00:50:49,539 --> 00:50:51,855
you mentioned, right, working 
with other software engineers 

1195
00:50:51,855 --> 00:50:54,630
from other companies, right? 
Collaborating, I think that's 

1196
00:50:54,630 --> 00:50:56,857
super fun. 
Speaking about those, right, 

1197
00:50:56,857 --> 00:50:59,922
like the hiring process, 
especially these days with the 

1198
00:50:59,922 --> 00:51:03,832
proliferation of AI tools. 
Do you look at software engineer

1199
00:51:03,832 --> 00:51:06,667
hiring differently now? 
What kind of attributes that 

1200
00:51:06,667 --> 00:51:10,207
actually you assess these days? 
I don't think we do it 

1201
00:51:10,207 --> 00:51:13,150
perfectly, but we do do it and 
we do it pretty efficiently and 

1202
00:51:13,150 --> 00:51:17,697
effectively, I would say. 
So we used to try to be as 

1203
00:51:17,697 --> 00:51:20,738
amenable as possible to the 
candidate, so it has changed a 

1204
00:51:20,738 --> 00:51:22,066
little bit. 
We used to be as amenable to 

1205
00:51:22,066 --> 00:51:22,924
the... as possible to the 
candidate. 

1206
00:51:22,924 --> 00:51:25,372
We said there's pretty much two 
ways you can kind of interview, 

1207
00:51:25,372 --> 00:51:27,484
maybe three ways you can 
interview in software 

1208
00:51:27,484 --> 00:51:31,794
engineering, but at the very 
least, you can do some in-person

1209
00:51:31,794 --> 00:51:37,114
or synchronous coding tests and 
conversational interviews. 

1210
00:51:37,114 --> 00:51:40,168
You can do some Leetcode stuff. 
You can architect on a 

1211
00:51:40,168 --> 00:51:42,229
whiteboard, you can talk about 
your former job experiences. 

1212
00:51:42,789 --> 00:51:45,289
Or you can do a take home. 
And often, often it's a mix, but

1213
00:51:45,289 --> 00:51:48,277
instead of a Leetcode test, you 
can also a big take home and go 

1214
00:51:48,277 --> 00:51:50,077
do that. 
There's kinda a third door we 

1215
00:51:50,077 --> 00:51:52,489
don't do too much, but there's 
also the whole game of work 

1216
00:51:52,489 --> 00:51:53,659
trials. 
They're kinda tricky. 

1217
00:51:54,469 --> 00:51:56,681
But there's a few predominant 
ways of engineering 

1218
00:51:56,681 --> 00:51:58,067
interviewing. 
They all suck. 

1219
00:51:58,217 --> 00:52:01,135
If you go online, you go to 
Hacker News and you like look at

1220
00:52:01,135 --> 00:52:03,917
any one of these, you'll find 
haters for all of them. 

1221
00:52:04,277 --> 00:52:08,357
For work trials and take homes, 
people are like, how dare you? 

1222
00:52:08,357 --> 00:52:11,594
I have a wife and kids and a 
family and like I, you're asking

1223
00:52:11,594 --> 00:52:13,597
me to do all this, that's and is
not paid. 

1224
00:52:13,597 --> 00:52:16,544
This is insane. 
But then you also look up like, 

1225
00:52:16,544 --> 00:52:18,639
you know, 30 minute Leetcode 
interviews and people are like, 

1226
00:52:18,639 --> 00:52:20,267
this is crazy. 
This is nothing like real 

1227
00:52:20,267 --> 00:52:22,127
software engineering. 
How dare you test me like this? 

1228
00:52:22,877 --> 00:52:24,167
Like just ask me to build a 
thing. 

1229
00:52:25,247 --> 00:52:27,200
So there's just, there's, you 
know, there, it's, it really is 

1230
00:52:27,200 --> 00:52:29,363
a less lesser of all evil 
situation. 

1231
00:52:29,843 --> 00:52:31,373
Companies do all different 
practices. 

1232
00:52:31,593 --> 00:52:34,223
What I've noticed just in 
practice is that take-homes are 

1233
00:52:34,223 --> 00:52:37,084
kind of dying a little bit, at 
least take-homes as we've known 

1234
00:52:37,084 --> 00:52:39,402
them. 
They become very low signal for 

1235
00:52:39,402 --> 00:52:41,737
us, because they were always a 
little muddy in the signal. 

1236
00:52:41,737 --> 00:52:43,777
You might spend extra time on it
and how do I compare that? 

1237
00:52:43,777 --> 00:52:46,832
But now if I give you a take 
home, you just like you're gonna

1238
00:52:46,832 --> 00:52:49,262
run a ton of AI code on that. 
Like there's no doubt. 

1239
00:52:49,262 --> 00:52:51,312
Why would you not? 
Like now you're, now what I'm 

1240
00:52:51,312 --> 00:52:53,672
trying to grade is like what 
you've created with AI. 

1241
00:52:53,942 --> 00:52:55,952
Now, and to the credit of take 
homes. 

1242
00:52:55,952 --> 00:52:57,962
I think there are progressive 
companies who are thinking about

1243
00:52:57,962 --> 00:53:00,377
this and saying, okay, great. 
I actually expect you to use AI 

1244
00:53:00,377 --> 00:53:02,987
and I'm gonna give you a 
challenge that's so challenging 

1245
00:53:02,987 --> 00:53:07,082
that you better be using AI and 
you might still not complete it.

1246
00:53:07,232 --> 00:53:08,522
And we're gonna evaluate that 
correctly. 

1247
00:53:08,672 --> 00:53:11,332
And on top of that, I want you 
to describe the code that was 

1248
00:53:11,332 --> 00:53:13,880
created, and I'm gonna get you 
in gotchas if you can't really 

1249
00:53:13,880 --> 00:53:15,782
reason about like why the AI 
made certain choices. 

1250
00:53:15,932 --> 00:53:18,632
That's like a, like an evolving,
I think pattern of interviewing.

1251
00:53:19,592 --> 00:53:22,361
I am not confident yet enough to
lean heavily on that practice. 

1252
00:53:22,361 --> 00:53:24,386
And I'd rather see the industry 
flush out a little bit more. 

1253
00:53:24,716 --> 00:53:29,365
What we choose to lean on is for
better or for worse is algorithm

1254
00:53:29,365 --> 00:53:32,821
style, you know, synchronous 
coding questions along with some

1255
00:53:32,821 --> 00:53:34,861
classic architecture 
whiteboarding and some classic 

1256
00:53:34,861 --> 00:53:36,211
conversations about your former 
experiences. 

1257
00:53:36,737 --> 00:53:39,245
And, you know, I'll tell you, 
for all their evils, the coding 

1258
00:53:39,245 --> 00:53:40,745
interviews have a lot of merit 
to 'em. 

1259
00:53:41,135 --> 00:53:43,929
They're very prepable no matter 
who you are, you know, anyone 

1260
00:53:43,929 --> 00:53:45,738
can go and just do some practice
questions. 

1261
00:53:45,738 --> 00:53:47,538
So there's a little bit of 
fairness to that. 

1262
00:53:48,393 --> 00:53:50,853
A really smart new grad can pass
'em and a really smart senior 

1263
00:53:50,853 --> 00:53:53,231
engineer can pass 'em too. 
Like so all walks of life can 

1264
00:53:53,231 --> 00:53:54,723
pass 'em. 
They're extremely 

1265
00:53:54,723 --> 00:53:57,333
standardizable, which is again, 
has really nice or nice fairness

1266
00:53:57,333 --> 00:53:58,888
to 'em. 
They're very respectful of 

1267
00:53:58,888 --> 00:54:01,283
people's time outside of the 
prepping, like, we're gonna do 

1268
00:54:01,283 --> 00:54:03,168
this and we're gonna do this in 
30, 45 minutes and we're gonna 

1269
00:54:03,168 --> 00:54:05,395
get you an answer. 
So I don't need a week of your 

1270
00:54:05,395 --> 00:54:08,116
time from it. 
So there's some strengths to it 

1271
00:54:08,116 --> 00:54:10,421
and it, also... 
I can, I they're relatively 

1272
00:54:10,421 --> 00:54:11,988
cheap proof. 
I can sit there synchronously 

1273
00:54:11,988 --> 00:54:14,491
with you and I can make sure 
the, an AI's not writing, 

1274
00:54:14,491 --> 00:54:16,387
another human's not writing it, 
all this stuff. 

1275
00:54:16,905 --> 00:54:20,039
And for better or for worse, I 
do feel like the success 

1276
00:54:20,039 --> 00:54:22,200
correlation of them is still 
quite high to a person being 

1277
00:54:22,200 --> 00:54:24,020
very strong in the room. 
I get it. 

1278
00:54:24,020 --> 00:54:27,330
I get that your job is not doing
Leetcode questions in practice, 

1279
00:54:27,330 --> 00:54:31,167
but for some reason it still is 
the case that if you ace one of 

1280
00:54:31,167 --> 00:54:33,440
those interview questions, you 
tend to be quite strong in the 

1281
00:54:33,440 --> 00:54:35,360
room I find. 
It kinda reminds me of SATs. 

1282
00:54:36,110 --> 00:54:39,486
Yeah, SATs are like nothing like
what I do in college, but 

1283
00:54:39,486 --> 00:54:41,890
somehow they're still kind of 
correlated to being generally 

1284
00:54:41,890 --> 00:54:44,934
smart and there's not really, or
there's not a lot of better ways

1285
00:54:44,934 --> 00:54:47,825
to measure in a fair way. 
So it's a lesser of all evil 

1286
00:54:47,825 --> 00:54:48,830
situation. 
We'll see, I'll see. 

1287
00:54:48,830 --> 00:54:50,120
I dunno, maybe the industry will
keep evolving. 

1288
00:54:50,240 --> 00:54:51,260
But I don't need to evolve this 
too. 

1289
00:54:51,260 --> 00:54:52,580
This is my other belief about 
startups. 

1290
00:54:52,580 --> 00:54:56,043
It's like I can barely innovate 
on one successful business idea.

1291
00:54:56,043 --> 00:54:58,766
I don't also need to reinvent 
the wheel on like engineering 

1292
00:54:58,766 --> 00:55:00,433
interviews. 
That's a separate really hard 

1293
00:55:00,433 --> 00:55:02,117
problem. 
So let me like just like use 

1294
00:55:02,117 --> 00:55:03,251
what's already worked in the 
past. 

1295
00:55:03,251 --> 00:55:04,811
And I'm gonna, I'm gonna try and
innovate on dev tools. 

1296
00:55:05,867 --> 00:55:08,267
Yeah. so definitely, I mean the 
landscape has changed, right? 

1297
00:55:08,267 --> 00:55:10,265
The kind of works that 
developers are doing have 

1298
00:55:10,265 --> 00:55:11,429
changed. 
But I think the fundamentals 

1299
00:55:11,429 --> 00:55:15,032
kind of like stay the same. 
You still need to have a good 

1300
00:55:15,032 --> 00:55:17,027
system design, architecture, 
good algorithmic, problem 

1301
00:55:17,027 --> 00:55:19,745
solving, I guess, right? 
So I think the code that you 

1302
00:55:19,745 --> 00:55:21,861
write also needs to be clean, 
tidy, and all that. 

1303
00:55:22,101 --> 00:55:25,048
So definitely those fundamentals
have not changed as of now. 

1304
00:55:25,228 --> 00:55:27,998
But I dunno, in the future, 
maybe near future that it might 

1305
00:55:27,998 --> 00:55:29,427
change. 
But definitely thanks for 

1306
00:55:29,427 --> 00:55:31,338
sharing that, hiring tips that 
you have. 

1307
00:55:31,878 --> 00:55:35,351
So as we go to the end of our 
conversation, I only have one 

1308
00:55:35,351 --> 00:55:38,433
last question for you, Greg. 
This is what I call the three 

1309
00:55:38,433 --> 00:55:40,476
technical leadership wisdom. 
If you can think of it, just 

1310
00:55:40,476 --> 00:55:43,104
like three advice you wanna give
to the listeners, maybe you can 

1311
00:55:43,104 --> 00:55:45,756
share your version today. 
You mentioned you were gonna ask

1312
00:55:45,756 --> 00:55:48,050
me this, so I was trying to 
think a little bit about this. 

1313
00:55:48,290 --> 00:55:51,290
I have two, we'll see if I, if I
spawn a third idea. 

1314
00:55:51,290 --> 00:55:53,699
But there's two ideas at least 
that come to mind here. 

1315
00:55:54,452 --> 00:55:56,932
I am relatively new to technical
leadership. 

1316
00:55:57,012 --> 00:55:59,429
I, again, I'll be very, very, 
very honest about it, but I'm 

1317
00:55:59,429 --> 00:56:01,392
doing the job and I'm in it and 
it's high stakes. 

1318
00:56:01,392 --> 00:56:02,972
I'm trying to be reflective 
about it. 

1319
00:56:03,272 --> 00:56:06,410
One thing I have really come to 
deeply internalize and like all 

1320
00:56:06,410 --> 00:56:09,191
wisdom, it sounds trite, but 
I've really kind of started to 

1321
00:56:09,191 --> 00:56:14,048
internalize this, which is the 
premise that people don't really

1322
00:56:14,048 --> 00:56:17,652
mind hard challenging work. 
I think there's a fear. 

1323
00:56:17,652 --> 00:56:20,562
I found this fear as like a new 
leader manager of like, I don't 

1324
00:56:20,562 --> 00:56:21,833
wanna give people a ton of hard 
work. 

1325
00:56:21,868 --> 00:56:23,651
That kind of sucks. 
I think people don't really mind

1326
00:56:23,651 --> 00:56:25,804
that. 
What people mind is not having 

1327
00:56:25,804 --> 00:56:29,928
the agency and the autonomy to 
go about delivering on that hard

1328
00:56:29,928 --> 00:56:32,842
work how they want to. 
That's what sucks to be saddled 

1329
00:56:32,842 --> 00:56:35,613
with something huge and to not 
be given the chance to do it how

1330
00:56:35,613 --> 00:56:37,528
you wanna do it. 
And I think a lot about this, 

1331
00:56:37,528 --> 00:56:39,468
especially when you work on a 
team of smart engineers who 

1332
00:56:39,468 --> 00:56:42,205
super intelligent, really good 
at problem solving. 

1333
00:56:42,205 --> 00:56:43,645
That's the whole reason, that's 
why they were hired. 

1334
00:56:44,095 --> 00:56:46,785
You gotta give these people, I 
think, I think what I find is I 

1335
00:56:46,785 --> 00:56:48,745
really wanna set people up. 
I wanna remove ambiguity. 

1336
00:56:48,865 --> 00:56:51,823
I wanna help set the what and 
give some nice constraints to 

1337
00:56:51,823 --> 00:56:53,911
the problem. 
And then I want, I want really 

1338
00:56:53,911 --> 00:56:56,155
give people free reign about how
they go about achieving that. 

1339
00:56:56,555 --> 00:56:58,618
Even if it's not how I would 
achieve it or how I'd come to 

1340
00:56:58,618 --> 00:56:59,995
it. 
There's a little bit of a 

1341
00:56:59,995 --> 00:57:01,225
disagree commit. 
There's a little bit of trust 

1342
00:57:01,225 --> 00:57:02,926
built into that. 
Just a mutual respect that my 

1343
00:57:02,926 --> 00:57:04,590
ideas are not better than other 
people's ideas. 

1344
00:57:05,335 --> 00:57:08,638
And so I think, on one hand, 
yeah, I wanna set people up with

1345
00:57:08,638 --> 00:57:10,406
big challenges. 
I want to point them in the 

1346
00:57:10,406 --> 00:57:12,584
right direction, and I want them
to be amazing and surprising and

1347
00:57:12,584 --> 00:57:14,495
creative in how they go about 
solving those things. 

1348
00:57:15,275 --> 00:57:18,497
That's the first idea. 
Second idea that comes to mind 

1349
00:57:18,497 --> 00:57:23,449
is, as I interview lots of 
people, as I work with lots of 

1350
00:57:23,449 --> 00:57:27,637
people and as I grow this 
company, I am shocked by the, 

1351
00:57:27,637 --> 00:57:30,225
sometimes the lack of just 
excitement and enthusiasm. 

1352
00:57:30,645 --> 00:57:33,195
Excitement and enthusiasm is so 
cheap. 

1353
00:57:34,185 --> 00:57:36,891
If you wanna go get a job 
somewhere, if you wanna go join 

1354
00:57:36,891 --> 00:57:39,232
a team somewhere, impress a 
manager, just do something. 

1355
00:57:39,232 --> 00:57:42,621
Like one of the easiest, 
cheapest things to go do is just

1356
00:57:42,621 --> 00:57:46,897
be super excited about it. 
Be like, be chomping at the bit.

1357
00:57:47,049 --> 00:57:49,425
Be, you know, have that smile on
your face, be reading stuff up, 

1358
00:57:49,425 --> 00:57:51,065
be curious about it. 
Be bringing that to the table. 

1359
00:57:51,395 --> 00:57:53,675
And of course, there's like a 
whole other layer on top of 

1360
00:57:53,675 --> 00:57:54,995
that, of like polished 
execution. 

1361
00:57:54,995 --> 00:57:57,987
But at the fundamental, like, 
there is a dearth, there's a 

1362
00:57:57,987 --> 00:58:01,205
lack of people who are just 
really humble and excited. 

1363
00:58:01,205 --> 00:58:03,215
I interview so many people, I 
work with so many people. 

1364
00:58:03,215 --> 00:58:06,065
I'm like, you just told me that 
this was your dream job and 

1365
00:58:06,065 --> 00:58:08,245
like, nothing more in the world.
Like, you just, you are like, 

1366
00:58:08,245 --> 00:58:09,717
hey, I know I might not be 
perfect. 

1367
00:58:09,797 --> 00:58:11,635
I'm just so excited. 
I wanna prove you wrong. 

1368
00:58:11,635 --> 00:58:14,501
I wanna work my ass off. 
And no one says that, but you 

1369
00:58:14,501 --> 00:58:16,307
just say that. 
That's so endearing and 

1370
00:58:16,307 --> 00:58:17,757
compelling to everyone around 
you. 

1371
00:58:17,757 --> 00:58:19,577
And I, I'm using the context of 
getting a job, but you can use 

1372
00:58:19,577 --> 00:58:21,147
that on an existing team on all 
these. 

1373
00:58:22,090 --> 00:58:24,522
Maybe there's a little bit of 
entitlement or arrogance within 

1374
00:58:24,522 --> 00:58:27,210
the software engineering field 
where people are used to being 

1375
00:58:27,210 --> 00:58:29,163
sold and not having to sell 
themselves as much. 

1376
00:58:29,163 --> 00:58:31,203
But I do occasionally meet 
people like this. 

1377
00:58:31,203 --> 00:58:34,103
I do occasionally find people 
who have this general excitement

1378
00:58:34,103 --> 00:58:37,386
and attitude. 
Oh my God, it is so compelling, 

1379
00:58:37,386 --> 00:58:39,514
so endearing. 
I think it's partly what makes a

1380
00:58:39,514 --> 00:58:41,843
good founder good in the eyes of
a VC and when they're good 

1381
00:58:41,843 --> 00:58:43,304
enough founder selling, that 
they're bringing that energy. 

1382
00:58:43,675 --> 00:58:46,341
I think engineers holistically 
could benefit by leaning into 

1383
00:58:46,341 --> 00:58:47,936
that enthusiasm that ener, that 
energy more. 

1384
00:58:47,936 --> 00:58:51,146
And I think it's gonna open up 
opportunities and trust and 

1385
00:58:51,146 --> 00:58:53,846
people are gonna conspire for 
your success 'cause they're just

1386
00:58:53,846 --> 00:58:56,501
rooting for you at that point. 
So those are my two ideas that 

1387
00:58:56,501 --> 00:58:58,328
come to mind. 
I'll, I'll email you back if I 

1388
00:58:58,328 --> 00:59:01,390
come up with a third wisdom. 
No problem. 

1389
00:59:01,390 --> 00:59:02,920
So thanks for sharing those. 
Definitely. 

1390
00:59:02,920 --> 00:59:05,218
I can see you kind of like the 
people person, right? 

1391
00:59:05,218 --> 00:59:07,479
Always want to build 
relationship, giving people 

1392
00:59:07,479 --> 00:59:09,250
freedom, right? 
So definitely those kind of 

1393
00:59:09,250 --> 00:59:10,660
things. 
Definitely many people, uh, kind

1394
00:59:10,660 --> 00:59:13,023
of like love, right, to have a 
leader like that. 

1395
00:59:13,173 --> 00:59:14,283
So I think thanks for sharing 
that. 

1396
00:59:14,283 --> 00:59:18,172
And I love the mentioning about 
energy, excitement, you know, 

1397
00:59:18,172 --> 00:59:20,898
enthusiasm, bring it to the 
table to your day-to-day work. 

1398
00:59:21,168 --> 00:59:24,128
Definitely can build a much, 
much, bigger energy for the 

1399
00:59:24,128 --> 00:59:25,587
team. 
And also maybe bring happiness 

1400
00:59:25,587 --> 00:59:27,545
for the team as well. 
So thanks for sharing that. 

1401
00:59:28,115 --> 00:59:31,305
So Greg, if people would love to
connect with you, learn more 

1402
00:59:31,305 --> 00:59:34,379
about, I dunno, Graphite, maybe 
your techniques of building a 

1403
00:59:34,379 --> 00:59:36,415
high performing engineering 
team, is there a place where 

1404
00:59:36,415 --> 00:59:38,762
they can find you online? 
Sure thing. 

1405
00:59:38,792 --> 00:59:40,802
Yeah. 
So of course you have our 

1406
00:59:40,802 --> 00:59:44,006
website graphite.dev. 
If you wanna follow me, tag me 

1407
00:59:44,006 --> 00:59:45,920
on LinkedIn. 
Oh man, has anyone ever said 

1408
00:59:45,920 --> 00:59:48,542
that? 
But come follow me on LinkedIn, 

1409
00:59:48,542 --> 00:59:51,236
uh, Greg Foster. 
One day, I'll get good at 

1410
00:59:51,236 --> 00:59:54,375
Twitter, but not there yet. 
And always feel free to shoot me

1411
00:59:54,375 --> 00:59:56,787
an email, greg@graphite.dev. 
Always interested in hearing 

1412
00:59:56,787 --> 00:59:58,739
ideas and from folks using the 
tool. 

1413
00:59:59,654 --> 01:00:01,454
Right, so I'll put that in the 
show notes. 

1414
01:00:01,454 --> 01:00:04,096
So thank you so much, uh, Greg 
for today's conversation. 

1415
01:00:04,126 --> 01:00:07,569
And I hope that Graphite can 
popularize a lot about stacked 

1416
01:00:07,569 --> 01:00:10,935
PRs and help improve people in 
terms of doing their code review

1417
01:00:10,935 --> 01:00:12,453
and pull request workflow as 
well. 

1418
01:00:12,453 --> 01:00:14,412
So thanks for bringing that 
product to the market. 

1419
01:00:15,520 --> 01:00:17,070
Thank you for having me, Henry. 
This is great.