#231 - Faster Code Reviews, Faster Code Shipping with Stacked PRs - Greg Foster

[00:01:28] Introduction

Henry Suryawirawan: 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.

Greg Foster: 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.

[00:02:21] Career Turning Points

Henry Suryawirawan: 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.

Greg Foster: 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.

[00:05:11] Now is The Golden Time to Be in Software Engineering

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:09:08] The Evolution of Code Review in Software Development

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:14:59] The Popularity of Pull Request Workflow

Henry Suryawirawan: 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.

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:21:01] Pull Request Best Practices

Henry Suryawirawan: 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?

Greg Foster: 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.

[00:26:17] The Stacked PR and Its Benefits

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:34:07] How Graphite Ships Code Remarkably Fast

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:40:03] The Cool Things About AI Code Review

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:45:23] Graphite’s Unique Recipes for Engineering Productivity

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:50:55] Hiring Engineers in the Age of AI

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

[00:55:31] 2 Tech Lead Wisdom

Henry Suryawirawan: 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.

Greg Foster: 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.

Henry Suryawirawan: 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?

Greg Foster: 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.

Henry Suryawirawan: 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.

Greg Foster: Thank you for having me, Henry. This is great.

– End –