The statistics around how long it takes to get a code review
are kind of depressing. The median is something around
10 hours. The average is something around
20 hours. The best like cases like the
P90, P95 are like three hours. We're re-entering a world where
more code changes than ever because agents and
auto-completes have really created an explosion of code.
Now, the code review is more important.
Greg Foster is the CTO and Co-Founder of Graphite, an AI
powered code review platform backed by Anthropic, helping
teams like Snowflake, Figma, and Perplexity ship faster with
confidence. What is the best use case for AI
code review? I am very convinced that from
here on out forevermore, every single code change will be
scanned by an LLM. If your company uses CI and your
company runs linters, they're also gonna run an AI code
review. Graphite has a high velocity of
software development. What is your superpower?
Our team is in the P99 of productive engineering teams.
If you're trying to sell productivity, you better be the
most productive team around. We use aggressively every tool
that we built. We are stacking.
We're breaking up our code changes.
With a small code change, you're gonna get reviewed faster.
The feedback per line of code you write is so much higher.
Explain what is stack PR? The Facebook engineering team,
they've been doing this for a decade plus.
The idea of branching off a branch, off a branch, you unlock
parallelization. How do you make anything faster
in software engineering? You parallelize it.
Can I parallelize these annoying waiting times, waiting for a
review, waiting for tests, waiting for deployments, and
keep writing code changes on top of it.
There's a lot of concern like is coding and engineering as a
profession gonna die off? And I think that is a shallow
mindset. Because to me, the profession of
engineering is... Hello, everyone.
Welcome back to another new episode of the Tech Lead Journal
podcast. Today, I'm very excited to have
Greg Foster, the CTO, co-founder of graphite.dev, right?
So maybe you have heard about Graphite, maybe you don't.
But Graphite is one of the cool developer tools that people use
to improve their developer productivity, especially around
those pull request workflows. So Greg, I'm very excited to
have you in the show. I think we are gonna learn a lot
about how to do PRs, code reviews, those kind of things,
and how to build a high performing engineering team.
Amazing! Thank you for having me, Henry.
I'm excited to talk about this stuff.
This is my favorite topic area, so anytime I have a chance to
speak about it, I love it. So Greg, first, uh, let me
invite you to probably tell us a little bit more about your
story, right? I'd like to invite my guests to
actually share by sharing maybe career turning points that you
experienced in your career so that we can probably learn from
that. Sure thing.
Uh, I, I, I can share a little bit briefly about my, my career
up until now. It's not too long so I can cover
it. Um, I'm excitedly turning 30 in
a month, which means I'm both kind of young, but also means
that I've been coding for about half of my life.
I think I started when I was like 14 or 15, as a way to make
money in high school. I was making early iOS apps.
I fell in love with engineering. I went to college.
Not only can I do it on the side, I can now do it for my
main coursework. And I met the, I actually met
the two people I now co-found with really early on in college,
we were all obsessed with engineering and the idea of
creating a company one day. I became really fast friends.
Every summer I'd go out to San Francisco and do internships at
amazing places like Google and Airbnb.
I ended up coming back to Airbnb full-time, originally as an iOS
engineer because that's what I was doing in high school.
So I had a pretty good skillset for it.
But funny enough, like the first day I came aboard, they said,
hey, iOS engineering, that's great, but actually, uh, we need
you on this infra team. So I got, I guess, reorged and
swept onto a backend infrastructure team where I
found myself working on notification infrastructure,
which then cascaded into dev tools and internal developer
environments and continuous delivery platforms and release
management software. I was doing all sorts of stuff.
I was volunteering for SRE rotations, you name it.
And I fell in love with infrastructure.
I was like, iOS engineering, that's cool, but I'm even more
intrigued and just fascinated by building for other software
engineers. What does it mean not only to
build something good, I built pretty good iPhone apps.
So what does it mean to not to build something good, but to how
engineers can build good things and how can developers be more
productive? And that meta question just
really fascinated me. And I started working with the
most interesting people. And then around the start of
2020, I moved to New York. I was staying in touch with
those friends from college, Merrill and Tomas.
They were out in New York City, I was in San Francisco.
We had always wanted to create something together.
And we saw this chance to take this passion we had around dev
tools and not just do it internally at a company, but to
create a dev tool company and then serve and build for
everyone. It's cool to build for a
thousand people at Airbnb. It's even cooler to build for
all the engineers in the industry.
So it was kind of a no-brainer. It was a space I loved, it was
people I loved. I moved out to New York.
The pandemic came crashing down, which was actually kind of
perfect 'cause then we just buckled down indoors and spent
like a year or two coding. As the world opened up, we were
also starting to flourish as a startup.
And from that 2020 to 2025 now, we have just been continuously
working and building and creating a team and everything.
And it's really coming together now.
Well, thank you for sharing your story.
I think it's pretty interesting, right?
The kind of like twist and turn you kind of like experienced in
your career. I was intrigued when you say,
uh, you are kind of like still young, right?
Like maybe turning 30 soon. And you mentioned that in the
beginning, maybe at 15 you started coding, you fell in love
in engineering. I think at this age, many people
thinking about starting in engineering, right, a bit
concerned about the impact of AI, should they start doing
software development, computer science, those kind of things.
What is your view, especially you represent people who just
kind of like, in the middle stage of the career, right?
So what do you think about this? Oh, I think it's a golden age to
get involved in software engineering.
I think it's such a great time. I think about my experience.
You're right, like it's a middle age.
There's people, there's ton of people who learn engineering
before me. There's people who learn it
after me. When I learned it, it was a
little bit tough. I remember I was trying to
figure out how to code, and I wanted to learn how to code.
And I would go online, I'd look up tutorials, or I'd look up
books, and every resource I found, it would be like, okay,
you know, we're gonna teach you Java.
So given that, you know, C here's how to map that to Java.
And I'm like, I don't know C. I mean like given that you know
Java, here's how we're gonna learn Python or Rails.
I'm like, but I don't know that I'm like...
It wasn't until I found Coding for Dummies book that was
willing to walk me through the primitives of Java from scratch.
I read that book. There was an iTunes U, iTunes
University course from Stanford on iOS engineering, and I loved
it. I was so excited and I was like
on my Windows iTunes thing watching this video and stuff.
And I was working my way through and trying to figure out how to
build iPhone app and get into coding.
I think it's so, so, so, so, so much easier now to get over that
initial learning curve. You have incredible resources
and tutorials. Heck, you got chat bots that are
gonna unblock you and can like, help debug your program.
So the entry point curve has gotten easier, but I think the
upper end and the complexity and the amazing things you can build
is just as interesting and hard as it was before.
I don't think that that's like a solved problem.
And even at the heart of it, I know there's a lot of concern
like, is coding and engineering as a profession gonna die off?
Like is this a not a good time to invest your skills into that?
What if it's not here in five years?
And I think that that is a shallow mindset because to me
the profession of engineering, the art of engineering is one of
solving problems and building things.
And I think it's very timeless and that's here to stay.
People have been solving problems and building things for
thousands of years, and I'm just really positive we're gonna be
doing that in a hundred years from now too.
Now coding, typing my fingers on a keyboard and getting stuck on
bugs, that's definitely changing and evolving and it's, you know,
we can have a fun debate around to what degree we're gonna be
typing versus giving prompts and telling other things.
But, heck, you know, software engineering has evolved before.
There was once punch cards, there was once, having very,
very low level forms of programming.
Then we got these higher abstracted languages and we got
scripting languages. It got a lot easier.
Heck, when I was doing iOS development, they were all
excited about Xcode, like visual GUI framework for assembling
text boxes. And you barely needed to code to
build the app is what they would pitch you on.
Of course you still need to code.
It was kind of bad. So I just, I feel like there's
always that feeling in the air, like maybe you're not gonna
code, but that's if you're becoming an engineer 'cause you
just wanna write a bunch of code.
It's kinda the wrong reasoning. I think you should do it because
you love building and creating and shipping stuff.
And you're, you should be using every tool available to you at
the time. That's just a means to an end.
So it's never been easier, I think, to get involved.
It's never been kind of more fun.
And the ceiling and what can be created is as expansive as ever.
So I would thoroughly encourage other folks to get involved.
So I like what you said that, you know, software engineering
is all about solving problems and building things, right?
So as long as that's the goal, you like doing that, I think
software engineering is maybe one channel that people can use
to actually do those things, right?
And I personally, myself also kind of like enjoying my
software engineering again, simply because like you said,
right? There are so many different
languages these days, right? If we wanna pick up a new
language, it's quite easy to ask AI to kind of like kickstart the
process. And you use kind of like your
experience to actually accommodate, right?
The software that you write, the architecture that you wanna
build and things like that. So definitely today's topic is
all about, you know, code review, right?
It's one aspect of the software development workflow that
everybody, I'm sure, is kind of like getting disrupted as well,
right? Because now the code is being
churned by AI. And at the same time, right?
There are also tools like what you have been building, right?
AI that is reviewing someone else's code, right?
So maybe let's start in the first place about the code
review. What do you think the importance
of code review for software development these days?
Yeah, the importance of code review.
I really think it's kind of evolved over the ages.
Again, I've only been professionally engineering for
10 years, but I've read a lot about the history of this.
And from what I can tell, people have been doing forms of code
review as long as people have been coding.
At certain points in time, the early, early points of time, it
would be laying out the software, physically printed on
a desk, having people pour over it, doing bug inspections,
really looking for faults, looking for errors, looking for
things that are gonna hit production, because the cost of
that is gonna be exceptionally high.
There's not modern mechanisms for catching and reverting and
rolling that stuff back. There's not even continuous
integration tests. So it was a large obsession
around looking for faults and bugs.
I think as time went on into the 90s, it was still a little bit
of that, but it was also a little bit more of collaboration
and style. It might be desk checks, it
might be asking an engineer to come and look over your shoulder
at a computer screen and check and review some things before
you commit it to a central server for repository.
And with the advent of GitHub around 2004-2005, I think we
really saw a flourishing of code review, partly because open
source really needed it. Open source really removed a lot
of trust-based barriers. It was different.
You weren't within a company where someone had passed a
hiring bar and you knew them, and if they made a major mistake
or even a malicious mistake, they would just get fired.
Now you're an open source. Now no one, no one has trust.
Everyone's a stranger. Everyone's a pseudonym, but
we're still contributing together.
And so you have the advent of the pull request.
It's a stranger requesting me the maintainer to pull in their
changes. And so now I got the, and now I
have this maintainer who's carefully, thoughtfully
reviewing this change with deep skepticism but also excitement.
And you have a collaborative discussion going on in a
forum-based webpage. And you have that kind of the
avenue of what we see as like the modern code review.
Now that's looking for bugs. It's also looking for like is
this code change going in the direction I hope that this
project is going in. It's maybe a little bit of
teaching, even if the interactions are not the most
long lived. As time goes on further, I think
you then have the advent of CI gaining deep popularity.
I think throughout the 2000s, late 2000s, it was becoming much
more popular. Always keeping trunk green.
We never want trunk to fail builds and fail tests.
And we start running that. We have the compute and the
ability and the systems to now run that on every single code
change before it merges in. So now I'm looking a little bit
less for bugs. I'm still gonna look, I'm still
looking for bugs in code review and I still care about that.
But honestly if like, if that's how we're catching all of our
errors, that's kind of a last line of defense.
It's, it's a kind of a flaky way to find about issues.
We should also be finding those in testing systems and in
careful rollout systems. But what's the point of code
review now? Well, I still have a trust-based
system, but internally within companies, I don't have to worry
as much about that. I mean, again, ideally we're
not, we don't have too many malicious actors within a
company. And I think the weight of it
really starts shifting towards context and education and mutual
understanding. It's a way to share what's
happening in the code base. It's a way to share different
subjective styles, opinions, and future directions.
A really great place to have a discussion around, oh my gosh,
is this where the code base is going?
Is this where the architecture is going?
It's in code review. It's also good to have that in a
design doc review earlier on, but we're not all perfect
humans, and if we're gonna have it, let's have it before we
merge in the code change. It's a great moment of teaching
for a more senior engineer to show the ropes for more junior
engineer or to, or a senior engineer just ramping up to a
new system. It's a really good point in time
to have these great discussions and feedback moments.
So I think about that, that's code review, I think up until
the moment of AI. Then we have, and we have AI
coming out to the scene. And it gets a little weird
because now the code change wasn't necessarily, it was
either partially written by human or maybe entirely not
written by a human. It gets a little weird.
So, okay, so from a teaching level, I don't really need to
teach the agent much about the system.
Now, maybe, I don't know, maybe we'll evolve and like this is
gonna be a moment for like where agents get feedback and learn
how to update their Claude Code rules.
Maybe. That doesn't exist yet.
But also the trust issue has kind of reemerged a little bit.
Now, again, I don't actually don't trust it as much as, you
know, my teammate, I have pretty good trust.
We've been working together for, you know, whatever year plus.
This AI, it could be stupid, it could be malicious, I hope not,
but like it's, there's a higher risk of maliciousness.
I can't sue the AI if it goes rogue.
And it may, it may just make silly mistakes or just not be
smart enough for lack of context that was clearly stated in a
meeting, but this thing wasn't in the meeting, so it just
doesn't know. And so the trust has gone down a
little bit. So now I think we're re-entering
a world where, okay, my gosh, more code changes than ever
because agents have really... Agents and auto completes and
things have really created an explosion of code.
That's great. That can be good, there's a lot
of benefits that come from that. But there's a lot of code and I
trust it less. And heck, maybe no human in my
company has ever read it by the time I'm gonna do a code review.
Now the code review is more important.
I need to be more thoughtful in it.
But I have more work to do than ever before.
So there's kind of an emergent bottleneck.
I think the simplest like short-term answer is just as
engineers, we're just gonna take some of that time that we're
saving from writing the code and we're gonna shift it to more
time intensive code reviews. We'll kinda see how that
evolves. Yeah, I agree with you.
It's a bit weird, should I say. Uh, so you write less code, but
at the same time you produce a lot more, and at the same time
you also review a lot more as well.
Time will tell, right, so which direction it will go to.
Maybe AI agents are gonna be more sophisticated, more clever
and things like that. But hopefully, code review is
still gonna be like an important aspect of software development.
So I'm a bit intrigued when you say about GitHub, open source,
you know, the trust-based system, right?
In some debates within software engineering world, people say
that they don't like the pull request workflow, but because of
the advent of, you know, GitHub, I think many, many software
development teams now kind of like adopt pull request or merge
request, uh, if they're using GitLab, right?
So maybe in the first place, let's bring this discussion,
right? What do you think about the pull
request workflow? Is it something that is kind of
like a must have for software engineering team, or some people
actually prefers, you know, pair programming, trunk based
development? Just merge into master straight
away. Yeah, it's really interesting.
I think around 2010 era there was a lot of different emerging
patterns around pull requests. You think about different app,
different kind of, uh, ways you could organize your Git
repository. You could do trunk based
development, but you could also do long-lived feature branches.
You could do single commit pull request, you could do
multi-commit pull requests. You could do squash and merge,
you can do different merge strategies.
There's a lot of variance going on.
And what I noticed I think early in my career is it didn't seem
like companies had the deepest confidence in their strategy.
It felt like there was kind of an open debate around like, what
is the best way to run this? And I think what's emerged is
that there was patterns that were made sense in open source
and they made sense in older styles of waterfall engineering,
but those didn't make as much sense in some new closed source,
faster patterns of engineering. So what do I think about like in
open source, feature long lived feature branches make a lot more
sense. Forking patterns make a lot more
sense. It's possible that we just want
to have long periods of development in slightly
different directions. And that's probably the beauty
of open source is that things can deviate and go in different
directions. You can have forks of projects,
you can support various things. There doesn't need to be a
central dictator at the top saying, no, it's gotta be this
way. We gotta unify and merge all in
and run the roadmap. That works in open source,
that's, that's beautiful. You also had a classic, you
know, hangover of I think older patterns of shipping software.
Whether you were shipping physical software and you needed
to cut a release at a very specific moment in time that was
gonna be quite permanent and maybe you wanna fix that, then
you wanna run QA and get some hot fixes into that.
But you really wanna like hold a stable release branch.
And that also held up for a while in certain forms of mobile
and certain forms of like shipping open source CLIs or
libraries, you wanted these feature branches.
On the other hand, you had I think a real progression in
closed source development, probably spearheaded by great
engineering cultures at Facebook and Google and many companies
that then fractured out of those early engineering teams that
really centralized around trunk based development.
And they said, hey, you know, realistically we just want one
source of truth, trunk, and we want to update it constantly.
We wanna iterate on it. And we don't really need to, it
depends the case, but many cases, I don't need to publish
long lived feature branches and I don't need a lot of forking
mechanisms. I don't want there to be three
different versions of truth in my company.
And I don't even want multiple commits on my branch because
within a company, what started emerging I think is that the
atomic unit of change was the thing being reviewed and tested.
That was the unit. It was the PR.
And GitHub... it all got a little bit weird because it was
assumed that you would spend months on a pull request,
iterating, updating it, and then that would get pulled back in as
like a feature branch merging back in the trunk.
I think that pattern sort of dissolving in closed source.
So you look at like Facebook, they create a pattern of diffs.
They don't have a PR, they just have a diff.
The diff is just one atomic block that is different from the
trunk and it can have versions. That's cool.
So it can have versions. But it's just one thing.
And other companies who couldn't rebuild it from scratch, they
shoehorned it into GitHub. They said squash and merge.
Alright, I don't care what your commits were.
I don't care how many like fix, final fix, you know, you put on
this PR branch, we're just gonna squash it and put it on a trunk.
We're just gonna kind of force that pattern.
It's kinda weird 'cause we, I think the whole industry got
very excited about Git and GitHub and they're very cool
software. And we just used it as our
closed source systems for collaborating and coaching.
But we were shoving a lot of stuff that was built
intelligently for open source patterns.
We started shoving it into these emerging closed source patterns.
So now by 2025, I think from what I can tell, and we work
with a lot of companies, it really seems like there's a
centralization around patterns. It really seems like everyone is
kind of getting on board with trunk based development.
Everyone is kind of centralizing around single commit branches.
Now I know that that's a spicy topic.
Some developers really love multiple commits.
But I can tell you from the data, most companies just have
squash, I think squash on merge enabled where like they don't,
whatever you do with your code, we're just gonna compress that
when we hit merge. And you even have monorepo
patterns emerging. Again, monorepos don't make a
lot of sense in open source. It's antithetical in open
source. I want as many diverse small
projects as possible. Close source, we have these
monorepo patterns. So, I don't know, is the pull
request gonna still exist in the future?
I do believe there will be an atomic unit of change that's
gonna get reviewed and tested and validated before it's merged
in. That makes sense.
That's true. That's valid.
Does the name make sense? No, I think we gotta, I think we
gotta come up with a better name for this because once again, I'm
just begging you to stamp my PR so I can merge it in.
I'm not requesting you to pull in my changes to anything.
That doesn't make sense. So the title's gotta change.
I think we can slim off a lot of these features.
I think we can simplify it down to be more simple construct.
But the general idea that's gonna remain, we're still gonna
have code review. I think we're still gonna have
testing and some big processing step before integrating and
deploying it. Well, thanks for giving a little
bit of historical context as well.
Like the different patterns people use and like how it got
evolved to now, right? And I'm sure you have seen a lot
of patterns by working with many different software engineering
teams, right? And I guess in many parts of
software engineering team, this is my hypothesis, like there
will be a lot of them still using pull requests or merge
requests, right, simply because, you know, kind of like the
version control system. Maybe these days it's about
GitHub or GitLab. There's not many other options
that people use. Uh, and then in-built to those
tools are the merge requests and pull requests.
So if we can dive deeper into pull requests, I know Graphite
being, you know, the front and center about pull requests,
right, code review. What are some of the best
practices of pull requests that you think you can advocate to
the listeners here? Oh, there's such an easy answer
to this. And I don't take credit for
this. I, It's popular among the
industry. It's timeless advice.
Google, I think, did the best job of helping advocate and
popularize this. Make your code changes small.
I can, I can die on this hill. This is is an easy hill to die
on. It's just, in general, on
average, caveat, caveat, caveat, but in general, make those code
changes small. And what do I mean by small?
I think a good size is like 50, maybe 150 lines somewhere in
that ballpark. Of course, I love saying this
because then I get all these, uh, people in their armchair
being like, wait a second. One time I wrote like a 2,000
line PR and it was so good. One time I had to do a code mod
and it was 10,000 lines, but that was the right decision.
And so I love just kind of, it is a great way to bait people
into getting really excited to give me, gimme an edge case.
But I do think that in general, small code changes are good.
Why are they good? I think with a small code
change, you're gonna get reviewed faster.
That's great. Why?
Why are you gonna get reviewed faster?
Because your teammate's gonna get a notification and if they
see it's 50 lines, they're going like, oh yeah, I'll just go
review. If they see it's 2000 lines,
they're like, I'm going to lunch.
And like I hope someone who wanna handle this after.
You just get all these people who's just like pretending that
they didn't see it. Uh, number two, the comments per
line, the feedback per line of code you write is so much
higher. If your code change is small...
It's so interesting. Not even per line, just even on
average, just the number of comments a large PR received.
I think once you start crossing like the one to 2,000 line
boundary, you just start approaching like zero comments.
You just are so much more statistically likely to get like
a LGTM (Looks Good To Me). Where's a, if I read a 50 line
PR, I'm gonna get some great feedback and some great
discussion on that PR. So I'm gonna get better
feedback. If there's a bug, if, no, if
there's a bug before I merge it in, okay, it's way easier to
figure out what's going wrong on a 50 line PR than a 2,000 line
PR. And then if there's an issue
after I merge it in, well, heck, I'd rather revert 50 lines than
revert 2,000 lines. So in general, I think small
code changes are fantastic, but there's a reason that sometimes
you write large pull requests. Like we're, you can appreciate
the wisdom that small is good, but we got a job to do.
And that job is to go and actually ship a feature, build a
system, and sometimes I end up writing and we end up writing
large code changes. But why do we do that?
I think we do that because there's fixed costs and slowdown
around just the execution of any code change.
And so if I need to change a lot of code and I'm doing it in bite
wise, by small bites, I still gotta pass CI on all those.
I still gotta go back and forth on a feedback loop.
My god, the statistics around how long it takes to get a code
review are kind of depressing. I think like the median is
something around 10 hours. The average is something around
20 hours. The best like cases like the
P90, P95s are like three hours. Like it's quite depressing
statistics. So you're incurring some high
fixed cost there. Your CI, 30 minutes, let's say
you pass it first time around, then you gotta merge that out.
If you're lucky, that's pretty instantaneous.
But if you're at a bigger company, that merge process,
multiple release staging environments, that could take
its own couple hours. So heck, with all the fixed cost
of like you don't want to be blocked, so why not just get a
bunch of work into one of these things and then shoot it off?
So you get, you start really getting that temptation.
And it's this chain of reasoning that led companies like, I
think, Facebook and then from the, the many people who
descended from Facebook companies like Twitter and
Pinterest and many others to start leaning on a stacked
mentality. So there's this concept of
stacking, it's very core to what we build at Graphite, but it's
also just a popular thing that anyone can do.
You can do this open source technologies, you can just do
this by hand if you're really hardcore.
But the idea of branching off a branch, off a branch.
Like why not? Why not have many small chunks
of small pieces of work and break them all up?
The benefit of doing this is you unlock parallelization.
How do you make anything faster in software engineering?
You parallelize it. How do I make my CI faster?
I parallelize it. Same with my service.
It is, it's like one of the only ways I can make things faster.
So can I parallelize these annoying waiting times, waiting
for a review, waiting for tests, waiting for deployments?
Can I parallelize that and keep writing code changes on top of
that? If I can, then I get the best of
both worlds. Then I get my small code changes
and all the benefits and I also can just write my code and do my
job a little bit faster. So I think it's that, that's
kind of the beauty of stacking, which is the premise of saying,
don't just create a code change and then wait and then create
the next one and then wait. It's like, no, no, no.
Do all the waiting in parallel and keep coding along alongside.
This has become extra important because that coding time is
going down further and further and further.
We're all loving using Claude Code and Cursor and these
wonderful tools, and we brag about how fast it is to code
now, but again, those fixed costs haven't gone down.
So now you really want that parallelization.
So I think small code changes, yes, there's problems that
emerge from that. Things like stacking.
Other systems too, merge queues. There's different techniques and
technologies that then can emerge to assist in achieving
that dream. And I think anyone who has tried
creating really small code changes and attempted to walk
that good path and been burned, I think it's for a lack of
tooling and support. Not because the original premise
and idea was flawed. Yeah.
So I think the fixed cost is something that many people try
to avoid, right? So whenever you raise a PR,
first, somebody needs to pick up, review, finish all the
comments, you know, get ready for merge.
And then there's a CI build, right?
And then maybe there's a bug, you have to go back, fix it and
all that. So I think the fixed cost that
you mentioned is can be really painful for some software
engineering teams. And hence this stacked PR thing
maybe is like very helpful, right?
In order to kind of like unblock developers so that they can pick
up the next task building on top of what they submitted, right?
But some people maybe have not actually experienced this
because stacked PR is not something that is built
natively, maybe on GitHub or maybe GitLab and some of these
tools, right? So maybe explain a little bit
what is stacked PR? You mentioned branch off a
branch off a branch. But some people think branch off
a branch is not a good pattern. But why, uh, are we advocating
for that? And what do you think are like
some common benefits that people have whenever they adopt this
stacked PR? Totally.
Yeah, yeah. So we go a little bit deeper on
the pattern of stacked PRs. And again, I don't wanna create,
I don't wanna claim credit for having invented this.
The Facebook engineering team, I keep calling it Facebook.
I've not gotten the Meta. The Facebook engineering team,
they've been doing this for a decade plus, like there's a
thousand, a hundred thousand engineers who have really tried
and tested these patterns. Still a small fragment of the
overall engineering population. And the reason, the other reason
that a lot of people don't necessarily know about this is
because it never made sense in open source.
It's very interesting. So it never got that open source
propagation of idea because open source moves slower.
These PRs are open for a week or a month, and they're long
discussions and they're really thoughtful.
And the idea of breaking them up into 10 small pieces in parallel
and getting reviewed, you don't need the velocity.
You also the maintainer might not even want it because the
maintainer doesn't want your piece by piece, small ideas.
They want the whole thing or nothing.
They don't want you to commit half of it and then walk away as
a stranger, because I don't have trust.
At a company, I trust that you're still coming into work
tomorrow and you started this feature and you're gonna use
this feature. And yeah, I want you to have
like that continuous trickle based development, that's really
healthy. It's not allowed to worry about
you ghosting on me. So this idea, I think, has made
wonderful sense in companies and still makes great sense in
companies, but it just didn't, it didn't get the lift off in
the open source community. And it didn't get the native
integration within tools like GitHub.
Okay, but, so to go a little deeper, what does it mean to
stack pull request or stack your code changes?
Well, we all know what an individual code change is.
It's a, you create a change, a commit to branch, and it's based
off something. And it's usually based off your
trunk, your main, your master. Okay, so it's a difference off
of the trunk. What if we create another
change? What if we, but what are,
instead of stacking it on trunk, what if we stacked it on PR-A?
So now you have PR-A, PR-B. What's a real world example of
this? Let's say we're coding up a
feature for our website. What do I need to do?
I need to go and update my server, add some functionality.
I need to add a new endpoint. And I need to go and update my
website to call that endpoint and then show some information
to the user. Okay, so I could do this all as
a one of 2000 line PR, one shot thing.
I could spend a day or two and code that up.
Or what I could do is I could create a code change.
I could go, I could first add some functions to my server.
Fantastic. Boom, done.
Let's shave that off PR, put that up.
Start, wait, start that. Start that clock for my code
review for a couple of hours. Next, lemme go code up that
endpoint and let me, as I code up that endpoint that relies on
that function, stack it on top. I need that other code.
So lemme stack it on top. We have PR-A, PR-B.
Put that up for review. Now I got two things that are in
parallel getting reviewed. Maybe different people, maybe
the same people. I'm parallelizing my testing as
well. Then I start coding the client
side, the update to the website that's gonna fetch that new
endpoint. Maybe by the time I finish
coding that, the other code changes, maybe they're good to
go. Maybe they're finally ready in
that three to five hour interim. They're good to merge.
I can merge 'em. I can wait.
I could do whatever I want, but I'm unblock there.
And then I put up that third PR up for review.
This wouldn't be possible if these were all stacked off of
main, all based off of my main master.
I need these to be based off one another.
Without stacking, what would I do?
I would either just keep bloating and adding to the
existing PR. So people do that, but then
that's, it is kind of cheating. 'Cause sometimes you get a
review and then you extend the PR and you're like, I'm gonna
piggyback that old stamp. Or you just wait and work on
something else and you just can't continue that same idea.
But here with stacking, I can break it up.
I can paralyze the things and I can also keep my chain of flow.
So now, and I can zipper merge those like cars on a highway.
I can just zipper merge those into trunk and I can keep
moving. And the net effect, I'm getting
the parallelization and I'm never blocked.
I just keep checkpoint saving, just keep branching, just
breaking off a little piece here.
Now it gets tricky. If I was to do this in vanilla
Git, it works up until the point.
The point that this stops working is the day that my
teammate asks for a little bit of an edit on that first PR.
They get back to me in code review and they're like, hey, it
looks great, Greg, but you know, can we update this PR?
And I'm like, oh my god, because I can update that PR.
But now my Git pointers are all over the place.
I am in like Git rebase hell now.
Like I update that now, PR number two, PR number three,
they're all over the place. Like the diffs look crazy on
GitHub. It's a mess.
And there are correct Git commands to run, but they are
very complicated, like three point rebates with like raw
hashes and it's just, it is super painful.
I don't care how good of an engineer you are, it's very
painful to try and do that by hand.
Imagine if it's a 10 stack, you do not want to go down 10
branches and perfectly reorder them.
And then perfectly resubmit them to GitHub and then perfectly
update GitHub's merge branches. So this is where tooling, again,
Graphite. I don't wanna be too preachy,
but Graphite like this is part of the problem we solve is like
we will actually carefully maintain the pointers and like
run the commands and update the remote pull requests and handle
this. Same thing with Facebook's
internal systems. Like what are they, what's the
code doing behind the scenes? It's doing all that rearranging
and restacking and just realignment for you.
So you can really quickly make a down stack update and everything
just flows naturally. You can get even more advanced
too. If you build more advanced
tooling, you can also merge in stacks and batches.
If half of it or all of it gets finally approved and ready to
go, great. One shot it in.
So I can mix and match to what degree I'm doing things
atomically. I'm doing things more in a
zipper merge fashion and it gives you a lot of flexibility
and power. But that's the general premise
is creating these small, small pieces in a continuous work
stream. In many ways, it's so funny,
it's so reminiscent of a pattern we all know, which is like the
original premise of Git commits. The original premise of Git
commits says I have a branch and I'm creating a many small little
commit checkpoints. Why did that not work?
Why does that not work in the modern world?
I think what happened is that artifact of history, but the
unit of code change ended up not being the commit.
It ended up being the branch. You don't test your commits.
You don't review your commits, you review the branch.
And so we needed a new entity, a new data structure to stack my
branches. Ideally, we could have done this
with commits and branches, but now it has to be branches and
stacks. And we could simplify that.
And now if I can make every branch a single commit, I can
start getting to a simpler world and we start getting closer to
what Facebook just rebuilt from scratch.
But if you wanna do this in a GitHub compatible way, you're
gonna have to stack your branches.
I, when we were first building Graphite, I thought long and
hard. I'm like, man, can we just do
this all with commits and branches?
And the only reason we didn't go down that path was like, I just
know people don't, people don't review and test commits.
They don't merge commits. They merge in those branches.
If I wanna meet people and engineers where they're at,
we're gonna have to do this on a branch level.
Yeah. So I think these days, like what
you said, right, the atomic change is actually the PR or the
branch, right? So people make a lot of commits
on that branch, maybe a few trial and error, bug fixes and
things like that. And then they raise a pull
request and that's kind of like the atomic change that a
developer will submit, right? And I think, thanks for trying
to explain about stacked PR. I know for some people maybe
it's still kind of like a bit abstract, but the moment when
you see an image or visualization, I'm sure probably
it makes more sense, right? And when you work in a bigger,
larger software engineering team where you have many different
modules, more people, right? I think this stacked PR also
kind of like, makes sense much better, because simply of those,
you know, un-bottlenecking the process of software development
and merging into trunk. And uniquely, um, you have
shared this before, right? Graphite as a software
engineering team has actually a high velocity of software
development, producing code changes and things like that.
And you produce this statistic before, way back, I dunno, how
much different it has been since then.
Like in your, you are in the P99 percentile of the software
engineering team in the statistic, right?
And you kind of like raise lots of PR within this team.
And funnily enough, right, the time too merge is actually
longer, is like within three hours and things like that.
So maybe, give us a glimpse of what is your statistics these
days. And why such things actually
become like a superpower for the Graphite team?
Yeah. Yeah.
This blog post, this LinkedIn post I made a while back, maybe
a year or two year, year and a half ago, where I braggishly
said our team is in the P99 of productive engineering teams.
And I, it's kinda a spicy post. I like sometimes writing a spicy
LinkedIn post. Why not?
Life is short, right? You know, it's... but I wrote
this post, I don't really love to brag, but I wrote this post
because I kept getting asked by people, you know, VCs and bigger
companies, and they would say, you know, hey, Graphite you guys
sell software that makes engineering teams faster.
Fundamentally, you know, it's nice and there's a lot of,
there's a lot of niceties and features and beauty to it.
But like the reason people are buying this, they're making the
engineering teams faster. If you're trying to sell
productivity, you better be the most productive team around.
Otherwise how can you go advise these other incredible companies
to be faster? You better be walking the walk.
I was like, I thought about that.
I was like, yeah, you know, you know, and I, this team is
amazing. I'm like, let me, lemme just go
and braggishly write, you know, some numbers about why we
actually are insanely fast and be proud of that.
Let's be proud of that. Huge caveat, measuring software
developer productivity is like one of the most fraught things
you can possibly do. You'll get crucified in every
which way. It's a whole field.
And if there was a true answer, I think the entire art would
look very different. We don't go into performance
reviews. We don't hire and fire people
based on like single numerical metrics.
We all know that. So that's kind of proved to me
like no one has ever really cracked what it means to measure
quantitatively productivity. But that being said, I wanted to
write a spicy post and people kept asking me about it.
So, okay, like, let's do it by number of changes merged and
amount of code merged. I know this is a shallow metric,
but like, let's just try that. And what you see is, you know,
the Graphite engineering team is insanely fast.
We're not the fastest. There's a few others.
I'll give a shout out, uh, the Harvey AI.
Last time I checked the Harvey AI team, man, they ship code
fantastically. I don't know what they're doing.
I wanna talk to more their engineers, but they are also
incredibly fast. I always just imagine they bring
like a legal lawyer grindset mindset to it, and they're just
like, they're so trained from the law profession.
And then they somehow apply that to engineering.
But they're, they're also, so there's some companies that are
really scrappy and fast. But why, why is Graphite
engineering team, ship a lot of code, ship a lot of code
changes? Why are we really productive
along those measurements of productivity?
We work hard and we're very smart, but we're not the, we
don't work the hardest. You know, these, there's like
teams who don't go home on the weekends.
There's teams who have sleeping bags in the office.
I think it's a bit screwed up. Like I want people to have
families and not get sick. So, you know, we work hard.
We, I don't want people to sleeping bags in the office.
And there's other teams who do that.
What we do is we have parallelization and we, you
know, don't get blocked on things.
Why do we do that? 'Cause we use aggressively every
tool that we build. We are stacking.
We are doing all these best practices.
We're breaking up our code changes.
We're getting incredible parallelization benefits.
We're merging things in batches. We're reviewing them in charted
fashions. And we're using AI code
reviewers, and we're using merge queues, and we're using every
tool in the toolbox to try and keep its engineering team as
fast as possible. Because we're building it.
It's dog fooding. It's a great thing.
You should use the stuff that you're building.
So we're using everything that we're building.
And I think it leads to these advantages.
Now people always ask me, they're like, okay, hey Greg,
you know, your engineering team ships a lot of code changes.
But if they're all just really small code changes, are you just
like creating a different way of doing the same amount of work?
But no. Fair question.
But when I check the numbers, when we check the numbers, it is
actually the case that the net amount of code being added to
the code base shipped and merged in, also removed, 'cause it's
important to measure it how much code you're removing as well,
that is also higher in proportion to the changes being
smaller. So my sense is that the net
productivity is actually quite high.
And why is it high? Again, I think we're getting the
benefits of parallelization. If I had to put a single point
on it. Cause the other interesting
thing you see with stacking, I've tried to measure this,
'cause customers will be like, oh, so you're gonna, you're
gonna make my code changes faster.
And it's really subtle. The average code change doesn't
necessarily get that much faster.
It depends. There's a lot of like case by
case. But the average code change, if
it used to take seven hours to merge, it might still take about
seven hours to merge. Why is that the case?
It might, it still takes a couple hours to get reviewed, it
still takes a couple hours past CI.
Like those kind of like forces aren't inherently being changed,
but we just parallelize everything.
So you now have 10 code changes in parallel taking seven hours
to merge instead of just one blocking on one blocking on
another one. So we unlocked these
productivity gains. It was fun.
I wrote that, that blog post and then a lot of people messaged
me. But live a little, you know,
write a spicy LinkedIn post. Yeah, definitely as a dev tools,
right? You're gonna preach what...
you're gonna do what you preach, right?
So I think definitely a cool story to share, right?
And I think the stacked PR is kind of like play a big role as
part of the productivity that you guys have, right?
And especially with your advocate about, you know, small
PR, and, you know, stacking a few changes in batches.
I think that will be really cool.
And I also use Graphite with my team, right?
And we always love to see this, uh, weekly software email, like
weekly in code or something like that, right?
Where Graphite will send you an insights based on your pull
requests, right? So things like number of lines
and always like top reviewers, top number of code changes,
those kind of things is always something that we like to brag
on. And yeah, I think those things
are great, right? So definitely we can measure a
little bit of software productivity and you know, how
much quality and how much velocity that you have simply by
analyzing the pull requests. So let's move on a little bit to
the AI code review aspect, right?
Because now Graphite also has that tool.
Uh, I think it's called Diamond. So like you said, right, these
days, maybe most of the code are written by AI.
So maybe written by human. But also at the same time AI is
helping to review. I think this, as far as I
experience it, right? It's not as mature as like human
reviewing code. So what do you think is the best
use case for AI code review as of now?
The best use case of AI code review, saving face, not
embarrassing yourself or your technique.
No, I said, I say that. I say that jokingly.
Semi jokingly, semi, semi real. AI code review is so interesting
to me. This is, I think it, we are, we
are experiencing the emergence in the advent of a new pillar
within the software engineering lifecycle that's here to stay.
I am very convinced that from here on out forevermore, every
single code change we write at companies will be scanned by an
LLM and they'll spot check it. In the same way that we all use
CI. If your company uses CI and your
company runs linters, I think they're also gonna run an AI
code reviewer. In fact, we call it AI code
review. People in the industry calls it
AI code review. But I think that that is a more
of a market term. If I was to be really
engineering about it, I'd actually just call this a subset
of CI. Because what is it
fundamentally? We're saying you put up a code
change and we're gonna run some compute in the cloud for two
minutes. We're gonna hum away and then
we're gonna give you some feedback and tell you that
there's an issue or not. And like that's, that's kinda
what my unit tests do. This thing's cool because it
takes like zero configuration. It's very flexible, it's very
fluid. It's not brittle like my unit
tests. So zero configuration, zero
maintenance. That's really nice.
But it's kind of just a new form of testing and validation.
Just like my unit test, it's not gonna catch everything, but it's
gonna catch some stuff. And at the right price, I'd
rather have at the right price, and if it's low false positive,
I'd always rather have it than not have it, you know?
And what's really creative about it?
What's really interesting to me about it is actually, I think
it's starting in some ways to supersede linting.
Now, of course, it's not as deterministically correct as
linting, but it's faster than linting.
I run ESlint and we run, you know, various linting patterns
on our code base, but it takes like five minutes, 10 minutes
sometimes to clone, to build, to then execute a deterministic
linter. These LLMs return in like 30
seconds or less. Like, so sometimes it'll
actually just be the fastest way to like catch simple issues even
faster than building my code. It'll tell me it's not gonna
build. I find that really cool.
But what's the utility of this? It's another way to check for
certain forms of errors, mistakes, style issues, so on.
So it's a really good way to get a first check of feedback too.
You can start getting some subsets of what we get outta
code review. And I can get it fast and I can
get it before I bother my teammate.
And as I've talked about in this conversation, you know, I'd
really rather get some feedback in 30 seconds than in three
hours or five hours. That has a ton of benefits to
me. I'm still contextually locked
in. It's still paged into my human
brain memory so I have it so I can go and fix it really
quickly. Also it is the most painstaking
thing to wait three hours, get a code review and have a, your
teammate be like, yeah, it looks good, except please just fix
this like one thing and then I'll stamp it.
'Cause then I fix it, and then I gotta wait on three hours for my
teammate to come back from lunch.
And I'm just, I don't wanna merge this thing.
So if I can review, reduce review cycles, and I can, by the
time I'm putting it in front of my teammate, all the stupid
stuff has been flagged, fixed, handled, and they can really
start thinking about the higher level questions – what humans
are still good at up until now, we'll see, we'll see that it's
constant race. But I want my teammate worrying
about like the architecture and where we're taking the code base
and does this make sense and in line with the patterns.
Is there a teaching moment? I want them worrying about that
and not worrying about every single if statement and for loop
and just, I get this quite right and perfect.
Some of the people who love on the team too, that, you know,
that we find tech leads really love this stuff too, because
they can then go into custom rules files and custom style
guides and really encode a lot of nuance.
Some of these people are tired of going around the company and
being like the bad guy and upholding some of these best
practices and now they can tell a bot to go around the company
and be the bad guy. So there's a lot of cool
emergent properties. But I think it kinda goes
without saying like, this is a pre-flight check.
This is like a CI, but the same way, you don't merge in your
code after you pass CI. You merge in your code after you
pass CI and get a human review. I think we're gonna keep living
in that world for a while, for security reasons, for context
reasons, because machines make mistakes and can't be held
accountable. We still need that human review.
But man, it's cool! Man, it's useful!
And I really think, uh, we spend, like everyone spends
hundreds of dollars, thousands of dollars on CI and testing.
I think we'll also be running this outta that same bucket as
well. Wow!
Definitely makes sense, right, now that you mentioned about it,
right? So we should just think of it
like one aspect of CI, like the gatekeeping process, right?
To actually find issues, errors, style divergence, right?
So within seconds, right? So because this LLM tends to
have like bigger context and they can do pattern matching
quite fast, so I think that's where we get the benefits.
And I think in the spirit of shifting left, right, I think
there's also no blocker, so to speak, right, to run this on
your local, right? So that you can actually catch
all these issues using AI faster.
Although these days, I think people use AI to churn out code,
not to actually review it after, you know, they finish their
work, right? But I think going forward, I
could actually see the use case where you use AI to actually
review your branch locally first before you even push it to the
GitHub, right? So I think thanks for sharing
that. Another thing that I wanna ask
you, coming back to the productivity of your software
engineering team. Apart from stacked PR, what do
you think are the biggest, you know, levers within your
engineering team that can actually produce much, much
higher velocity and also being more productive?
You know, so I can only speak from personal experience from
one set of anecdotes as my experience at Graphite in the
startup. So with the large caveat of, you
know, what works for us might not work for other people.
We are case by case. But I can tell you some of the
stuff we do do. One thing we do, it's really
simple, but we choose to be full in person.
We're about, as this recording, we're probably about 45 people
in a room right now. It's kind of busting out the
seams, so we're getting another floor in the building.
But there are timeless advantages to just being
face-to-face with all the people you're working with, even in a
world post COVID, where remote work is more popular and really
beneficial to some folks, you know, work-life balance and
things. But if you really wanna optimize
for the productivity of your team, I think it's very hard to
beat just being in a room having great deep relationships with
your teammates. Being able to look 'em in the
face and have a conversation. Being able to get that tonality
of voice. Being able to jump to a
whiteboard. Being able to say things in
passing, ideas, joke, all these things.
To be able to go on a coffee walk and muse about some big
idea that you're hacking on. All this stuff really matters.
I think about it, I once heard this term of like fidelity of
communication. There's many ways you can
communicate. You can Slack message.
You can call. You can video call.
You can just go, say, go get in a room with a person.
There's different qualities of fidelity of communication.
And I think it goes without saying that the highest fidelity
is just two people in a room having a heart to heart, talking
about something serious. And it's really hard to beat
that. So we don't have unlimited time.
I know every startup's in a rush.
So let's also make, let's use that time the best we can.
Let's have really high fidelity. So we believe in that.
Now, that means many trade offs. It means that we can't hire
certain people remote who we'd love to hire.
It means that it's a little bit less flexible of lifestyle for
the people who work together. But we get that benefit we get.
And not just productivity too. I really enjoy and care about
just people being friends with people they work with and having
deep relationships and caring about one another.
Life is long. Careers are long.
And I think there's huge value in learning from one another,
building relationships. I, you know, one day we'll go to
new jobs and careers and stuff, but we'll remember the people we
worked with and both had a really good experience.
So I really, I really value that.
I think this is becoming more in vogue.
This used to be weird. I would say this in like 2022
and people would like, that's crazy.
You're a full in-person startup. And now I think by 2025 it's
like kind of back in vogue a little bit.
So the pendulum swings. Other things we do, I don't
think we do anything too crazy. We dogfood heavily.
One of our advantages as a dev tool team, it's not just, and
I'm talking a little bit about like empathy and communication
internally, but we also get it with our users.
It's a great cheat code to be a dev tools company because our
users are the same as us, the engineering team.
And we do foster a culture of say, hey, you know, like your
feelings and ideas you, teammate, I see on the team, it
matters. Like if you are looking at the
CLI, the website, the button, the merge, the stacking pattern,
and you're like, this doesn't feel right, this could be a
little bit better. You're probably totally correct
'cause you are the user, you know.
It's not like we're building a healthcare thing or a financial
service or a law firm. Like we're building dev tools.
So you're your, your values of matter.
And what's great is we get to be in Slack channels with hundreds
of user companies. Such cool companies, everyone
from like Figma to Notion to Shopify.
These really cool companies that we built for.
We're also in there with their engineering teams and we're just
debating ideas on what are you doing for your best developer
practices, and here's what we're doing.
Here's how we're building it into Graphite.
We're expanding our Postgres database.
Hey, Notion, you had a great blog post about how you sharded
your Postgres database. Can you get on a call and talk
to us about that? And we're gonna trade ideas.
And they love that. They love that 'cause they want
us to be better and faster, more reliable 'cause then they can
use it. So there's this incredible
synergy and it's not everyone gets to play this game, but we
get to play this game as a dev tool where us and our users and
that line is very blurry. I'd love to cultivate the
feeling that we are actually just an extension of all these
user companies. They go on Slack and they have
internal dev tools teams, and then they also have a Slack
channel with Graphite. And I want them to feel like we
are just an extension of their dev tool team, to have that
relationship. And then likewise, internally,
we get to really thrive on the feeling that like we are part of
thousand of the coolest companies in the industry.
We don't have to pick which one we work at.
We work at all of 'em. We get to bill for all of them.
And then last thing I'll say is then having a lot of trust and
bottoms up feeling and empowerment to let people on the
team. Then go and apply that.
You know, you don't have to go through 10 meetings and 10
approval processes to take that feeling and then update the CLI
and update one of the command. Let's actually trust the team.
Again, we can cheat. We're small.
When you're 45 people, you can pull this off.
I get that at a thousand persons company, it's a little bit
harder. But let's lean, if we had the
advantage, let's lean into it and let's really empower people
to very quickly take ideas, change them, ship them.
Maybe put 'em behind a feature flag, but still get 'em out to
production. And let's iterate really, really
quickly. We're a company about speed and
velocity. Let's make sure we're really
living up to that, both in our cultural practices, not just
what we build as well. Thanks for sharing some of
these, uh, elements or recipes, how you build your engineering
team, right? Because it's always cool to hear
from different teams, right, how they succeed.
And probably some of us also can learn about, you know, building
relationship, building trust, the fidelity of communications.
I think that's really important as well.
Even though software engineers, some don't like to kinda like
talk to each other, but I think it's always very important to
build relationship. And I think the cool thing about
you mentioned, right, working with other software engineers
from other companies, right? Collaborating, I think that's
super fun. Speaking about those, right,
like the hiring process, especially these days with the
proliferation of AI tools. Do you look at software engineer
hiring differently now? What kind of attributes that
actually you assess these days? I don't think we do it
perfectly, but we do do it and we do it pretty efficiently and
effectively, I would say. So we used to try to be as
amenable as possible to the candidate, so it has changed a
little bit. We used to be as amenable to
the... as possible to the candidate.
We said there's pretty much two ways you can kind of interview,
maybe three ways you can interview in software
engineering, but at the very least, you can do some in-person
or synchronous coding tests and conversational interviews.
You can do some Leetcode stuff. You can architect on a
whiteboard, you can talk about your former job experiences.
Or you can do a take home. And often, often it's a mix, but
instead of a Leetcode test, you can also a big take home and go
do that. There's kinda a third door we
don't do too much, but there's also the whole game of work
trials. They're kinda tricky.
But there's a few predominant ways of engineering
interviewing. They all suck.
If you go online, you go to Hacker News and you like look at
any one of these, you'll find haters for all of them.
For work trials and take homes, people are like, how dare you?
I have a wife and kids and a family and like I, you're asking
me to do all this, that's and is not paid.
This is insane. But then you also look up like,
you know, 30 minute Leetcode interviews and people are like,
this is crazy. This is nothing like real
software engineering. How dare you test me like this?
Like just ask me to build a thing.
So there's just, there's, you know, there, it's, it really is
a less lesser of all evil situation.
Companies do all different practices.
What I've noticed just in practice is that take-homes are
kind of dying a little bit, at least take-homes as we've known
them. They become very low signal for
us, because they were always a little muddy in the signal.
You might spend extra time on it and how do I compare that?
But now if I give you a take home, you just like you're gonna
run a ton of AI code on that. Like there's no doubt.
Why would you not? Like now you're, now what I'm
trying to grade is like what you've created with AI.
Now, and to the credit of take homes.
I think there are progressive companies who are thinking about
this and saying, okay, great. I actually expect you to use AI
and I'm gonna give you a challenge that's so challenging
that you better be using AI and you might still not complete it.
And we're gonna evaluate that correctly.
And on top of that, I want you to describe the code that was
created, and I'm gonna get you in gotchas if you can't really
reason about like why the AI made certain choices.
That's like a, like an evolving, I think pattern of interviewing.
I am not confident yet enough to lean heavily on that practice.
And I'd rather see the industry flush out a little bit more.
What we choose to lean on is for better or for worse is algorithm
style, you know, synchronous coding questions along with some
classic architecture whiteboarding and some classic
conversations about your former experiences.
And, you know, I'll tell you, for all their evils, the coding
interviews have a lot of merit to 'em.
They're very prepable no matter who you are, you know, anyone
can go and just do some practice questions.
So there's a little bit of fairness to that.
A really smart new grad can pass 'em and a really smart senior
engineer can pass 'em too. Like so all walks of life can
pass 'em. They're extremely
standardizable, which is again, has really nice or nice fairness
to 'em. They're very respectful of
people's time outside of the prepping, like, we're gonna do
this and we're gonna do this in 30, 45 minutes and we're gonna
get you an answer. So I don't need a week of your
time from it. So there's some strengths to it
and it, also... I can, I they're relatively
cheap proof. I can sit there synchronously
with you and I can make sure the, an AI's not writing,
another human's not writing it, all this stuff.
And for better or for worse, I do feel like the success
correlation of them is still quite high to a person being
very strong in the room. I get it.
I get that your job is not doing Leetcode questions in practice,
but for some reason it still is the case that if you ace one of
those interview questions, you tend to be quite strong in the
room I find. It kinda reminds me of SATs.
Yeah, SATs are like nothing like what I do in college, but
somehow they're still kind of correlated to being generally
smart and there's not really, or there's not a lot of better ways
to measure in a fair way. So it's a lesser of all evil
situation. We'll see, I'll see.
I dunno, maybe the industry will keep evolving.
But I don't need to evolve this too.
This is my other belief about startups.
It's like I can barely innovate on one successful business idea.
I don't also need to reinvent the wheel on like engineering
interviews. That's a separate really hard
problem. So let me like just like use
what's already worked in the past.
And I'm gonna, I'm gonna try and innovate on dev tools.
Yeah. so definitely, I mean the landscape has changed, right?
The kind of works that developers are doing have
changed. But I think the fundamentals
kind of like stay the same. You still need to have a good
system design, architecture, good algorithmic, problem
solving, I guess, right? So I think the code that you
write also needs to be clean, tidy, and all that.
So definitely those fundamentals have not changed as of now.
But I dunno, in the future, maybe near future that it might
change. But definitely thanks for
sharing that, hiring tips that you have.
So as we go to the end of our conversation, I only have one
last question for you, Greg. This is what I call the three
technical leadership wisdom. If you can think of it, just
like three advice you wanna give to the listeners, maybe you can
share your version today. You mentioned you were gonna ask
me this, so I was trying to think a little bit about this.
I have two, we'll see if I, if I spawn a third idea.
But there's two ideas at least that come to mind here.
I am relatively new to technical leadership.
I, again, I'll be very, very, very honest about it, but I'm
doing the job and I'm in it and it's high stakes.
I'm trying to be reflective about it.
One thing I have really come to deeply internalize and like all
wisdom, it sounds trite, but I've really kind of started to
internalize this, which is the premise that people don't really
mind hard challenging work. I think there's a fear.
I found this fear as like a new leader manager of like, I don't
wanna give people a ton of hard work.
That kind of sucks. I think people don't really mind
that. What people mind is not having
the agency and the autonomy to go about delivering on that hard
work how they want to. That's what sucks to be saddled
with something huge and to not be given the chance to do it how
you wanna do it. And I think a lot about this,
especially when you work on a team of smart engineers who
super intelligent, really good at problem solving.
That's the whole reason, that's why they were hired.
You gotta give these people, I think, I think what I find is I
really wanna set people up. I wanna remove ambiguity.
I wanna help set the what and give some nice constraints to
the problem. And then I want, I want really
give people free reign about how they go about achieving that.
Even if it's not how I would achieve it or how I'd come to
it. There's a little bit of a
disagree commit. There's a little bit of trust
built into that. Just a mutual respect that my
ideas are not better than other people's ideas.
And so I think, on one hand, yeah, I wanna set people up with
big challenges. I want to point them in the
right direction, and I want them to be amazing and surprising and
creative in how they go about solving those things.
That's the first idea. Second idea that comes to mind
is, as I interview lots of people, as I work with lots of
people and as I grow this company, I am shocked by the,
sometimes the lack of just excitement and enthusiasm.
Excitement and enthusiasm is so cheap.
If you wanna go get a job somewhere, if you wanna go join
a team somewhere, impress a manager, just do something.
Like one of the easiest, cheapest things to go do is just
be super excited about it. Be like, be chomping at the bit.
Be, you know, have that smile on your face, be reading stuff up,
be curious about it. Be bringing that to the table.
And of course, there's like a whole other layer on top of
that, of like polished execution.
But at the fundamental, like, there is a dearth, there's a
lack of people who are just really humble and excited.
I interview so many people, I work with so many people.
I'm like, you just told me that this was your dream job and
like, nothing more in the world. Like, you just, you are like,
hey, I know I might not be perfect.
I'm just so excited. I wanna prove you wrong.
I wanna work my ass off. And no one says that, but you
just say that. That's so endearing and
compelling to everyone around you.
And I, I'm using the context of getting a job, but you can use
that on an existing team on all these.
Maybe there's a little bit of entitlement or arrogance within
the software engineering field where people are used to being
sold and not having to sell themselves as much.
But I do occasionally meet people like this.
I do occasionally find people who have this general excitement
and attitude. Oh my God, it is so compelling,
so endearing. I think it's partly what makes a
good founder good in the eyes of a VC and when they're good
enough founder selling, that they're bringing that energy.
I think engineers holistically could benefit by leaning into
that enthusiasm that ener, that energy more.
And I think it's gonna open up opportunities and trust and
people are gonna conspire for your success 'cause they're just
rooting for you at that point. So those are my two ideas that
come to mind. I'll, I'll email you back if I
come up with a third wisdom. No problem.
So thanks for sharing those. Definitely.
I can see you kind of like the people person, right?
Always want to build relationship, giving people
freedom, right? So definitely those kind of
things. Definitely many people, uh, kind
of like love, right, to have a leader like that.
So I think thanks for sharing that.
And I love the mentioning about energy, excitement, you know,
enthusiasm, bring it to the table to your day-to-day work.
Definitely can build a much, much, bigger energy for the
team. And also maybe bring happiness
for the team as well. So thanks for sharing that.
So Greg, if people would love to connect with you, learn more
about, I dunno, Graphite, maybe your techniques of building a
high performing engineering team, is there a place where
they can find you online? Sure thing.
Yeah. So of course you have our
website graphite.dev. If you wanna follow me, tag me
on LinkedIn. Oh man, has anyone ever said
that? But come follow me on LinkedIn,
uh, Greg Foster. One day, I'll get good at
Twitter, but not there yet. And always feel free to shoot me
an email, greg@graphite.dev. Always interested in hearing
ideas and from folks using the tool.
Right, so I'll put that in the show notes.
So thank you so much, uh, Greg for today's conversation.
And I hope that Graphite can popularize a lot about stacked
PRs and help improve people in terms of doing their code review
and pull request workflow as well.
So thanks for bringing that product to the market.
Thank you for having me, Henry. This is great.