The Evolution of Code Review: From Bug-Finding to Team Building

Transcript

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture podcast. Today I’m sitting down with Greg Foster. Greg, welcome. Thanks for taking the time to talk to us.

Greg Foster: Thanks for having me, Shane. Excited to be here.

Shane Hastie: My normal starting point with these conversations is who’s Greg?

Introductions [00:52]

Greg Foster: It’s a broad question. I am a guy living in New York City. I love photography, I love coffees and making espressos and lattes in the morning. I used to work at Airbnb out in San Francisco as a dev tools engineer about five years ago, which is a lovely, really fun company full of cool meeting rooms and puppies running around before I learned how to make coffees. But now I work at a dev tools company, a dev tools startup out in New York City, building the future of code review.

Shane Hastie: The future of code review. The thing we love to hate. What makes a good code review?

The purpose of code reviews [01:27]

Greg Foster: I think a lot about this. Whenever we start asking these three why’s, five why’s question, I think a lot about this. What is the purpose of code review? We all have to do it. As I came into industry, I graduated in 2017, I was coding, I’d done internships, this was just an innate thing. You go about your job, people are handing you pull requests, and you code review them. And it seemed like it was a law from God that you would just… Everything needed about one other random engineer to stamp it.

Sometimes this specific code owner, but otherwise just someone had to review it and stamp it. And I thought a lot about this. I actually once did a personal research blog post of like, what is the history of code review? Where did this come from? And feel free if you have stories on this, but the best I could tell is it originated even in the ’60s or ’70s.

You could go even further back. People would actually print out the bare-bone software, the code, and people would pour over desks and they would stare at it and they’d try and find bugs with the software because those bugs would be really expensive. And that got a little bit better, it got a little more digital. People would be working on a virtual file system together. They would do desk checks, someone would be held over to your desk and pour over your shoulder and try and check the changes you’re making.

Mostly focused around finding bugs and this kind of evolved further and further and eventually we got to the point where you could have code changes submitted and proposed. I think GitHub probably most popularized this in open-source where you didn’t necessarily trust the people submitting the changes, and so you’d have a maintainer carefully reviewing those before pulling in the request into the repository and it’s got a little bit more formal.

At this point, I think SOC 2 and HIPAA and a lot of these compliances mandate it. You can’t even get away from it. It’s a required process, but why do we do this? One, the origin was for bugs. I don’t think it’s as useful for bugs these days. I think we now have continuous integration tests. We have linting, we have all these patterns, we have careful deployments, we have a lot of patterns to find the bugs. If you’re relying on code review just to find your bugs, that’s kind of a last line of defence. You’re going to be letting a lot of stuff out to production. There’s other big benefits. There’s sharing context. If you have a bunch of engineers hacking together, maybe in a room, maybe remote, how do you know what other people are working on? What direction they’re taking things? Yes, maybe you talk to them and broadly they’re building some feature, but how are they approaching it?

What patterns they’re adding to the code base. It’s an amazing moment to share context maybe with junior engineers who are learning the patterns or maybe experienced engineers who are trying to align their architecture direction with your architecture direction. There’s this huge learning moment that goes into it. It’s actually even more important these days that we have all the AI writing the code. Where are you going to get that context? Where are you going to know what’s happening in your code base? If not for code review, there’s other aspects. Security matters a lot for code review. You want to make sure you’re looking out for vulnerabilities. Maybe something that you might catch from an instance standpoint, but if I had to pick the most useful part of it, I just think it’s really valuable as a sharing and education exercise of why we do this code review stuff.

Shane Hastie: I want to assert and we seem to see this as a reasonably consistent thing in the industry. The team is the unit of productive delivery in most engineering organizations today. What makes a good team?

The three pillars of a good team: kindness, expertise, and urgency [04:21]

Greg Foster: Well, I’m working on trying to build a good team around me. At my current job, I personally try to maximize three characteristics. Number one, I want folks who are really kind, not necessarily nice, I try to pick the word kind. They’re folks who are going out of their way to be social, good communicators, build real relationships. If you’re working on hard problems in high-pressure environments, that’s all great and fun and wonderful, but if you’re not kind about how you’re going about it’s going to be hell. People are going to be demotivated, they’re not going to want to come into work, you’re not going to want to come into work. I think it’s like the bare bones’ foundation, but it’s an unskippable part of this process. On top of that, I want folks who are quite expert on my team, depends what you’re working on, but I think a lot of the interesting problems in the world require deep expertise.

I work on dev tools and we build for some of the best software engineers in the industry and I couldn’t possibly build for, we couldn’t build for them if we ourselves weren’t quite expert about how we’re approaching things. If we’re working in Git, we’re telling these companies how to go merge in your pull requests. We’re building them a merge queue. We’re building them a CLI for stacking their PRs. We better know some Git fundamentals. We better know different options. We better have worked at other companies and seen how merge systems work, how CIS systems work to have those opinions to help guide and help other developers. I don’t know if every team needs the maximal expertise, but I personally really like working on a team that’s full of experts. I also get selfishly, to benefit because I get to learn from each other. We all get a little bit happier because we’re trading ideas, we’re all learning from each other.

And then the third one is I really look for urgency. There’s a limit on everything. You can’t ship too fast, but I really like a team that focuses on urgency, that’s constantly trying to find ways to unblock, is constantly looking for leverage, trying to find ways to get feedback and validation and get it out a little bit faster. Tighten those loops. Is this separate from burn and churn culture? I hate right now that there’s a popularity around. We work 9, 9, 6, we work 90 hours a week. Elon Musk says, “It’s great to sleep on the floor”, so we should be sleeping on the floor. I see startups like this, and I don’t want to tell people how to live their lives, but that’s not a team I want to be a part of because I think it’s going to hinder your health.

It’s going to hinder your ability to have friends and family outside of work that’s not long-term useful. So, I don’t think you need to be extreme end of grindy, but I do love urgency and I love people bringing that attitude to the team and when I combine those three things, when you got an urgent team, a kind team and an expert team, I think you get a lot of magic happening. If you drop any element, it’s a bit of a car crash. You’re expert and urgent, but you’re a bunch of assholes, it’s going to be a bad time. If you’re expert and kind, but you have no urgency. If you’re just going to be the world’s slowest moving model, you’re not going to get anywhere. I really need all three on the team and then I think that’s where you start making magic.

Shane Hastie: How do you build expertiese?

Building expertise through experience [06:50]

Greg Foster: Expertise on a team? Yes. Oh, man. Yes. I think experiences go a long way, right? If I have expertise myself, I don’t want to claim to be the world’s best expert, but if I have any, it’s come from my experiences. When I graduated college and joined Airbnb, I came aboard and I had a bit of a try-hard mentality. I was so excited to come in and just try and be the best engineer I could. I would buy textbooks from the O’Reilly and try and pour over them in the mornings. I had no idea what I was doing because I was hired as an iOS engineer. That was where all my projects had been, all my side hobbies and they brought me in. But then immediately I got re-orged onto an infrastructure team and I was immediately out of my depth. It was a total mismatch with my skill set, but I think the manager who brought me in got put on that team, so I was put on that team.

And then really quickly, everyone around me left actually, it was a little bit chaotic and I found myself independently in charge of helping hold onto the notification system, all the emails, all the SMS, the push notifications, the queuing, the deliverability, the data infrastructure behind that, and I had no idea what I was doing, but my approach. You asked how do you build expertise? My personal approach there was one, read up on it as much as I could. Two, I volunteered for every on-call opportunity I could. I was permanent on-call for the notification system. I also volunteered to be on-call for the company-wide SRE rotation, which you could volunteer to be part of. I volunteered to be part of the release management, deploy train situation. Anytime, there was one of those situations, I put my hand up and volunteer to be on that.

Other people didn’t want it because there were so many pages. There were pages during the day, pages in the off hours. It was not productive for my sleep schedule, but man, I love being in those on-call moments. You get paged, it’s the middle of the night, you’re frantically trying to figure out, “Okay, my service, my system is down”. But in that moment, yes, your heart rate is spiked, but you have this incredible moment where you can do a lot of things. You can start pulling levers, you can pull experts in to help you. You can start shipping changes really quickly because a lot of processes get really fast when you’re trying to bring the site back online. And I got to do this at Airbnb just constantly. Every night I was getting tagged into every incident. I once read that if your anxiety is spiked at a moment when you’re learning something, you remember it really well.

Again, I don’t know how healthy this is, but I happen to be doing that and after a couple of years of this, I felt really comfortable and I felt like I knew how to bring a site back online. I knew how to deploy things. I had seen all these other services and systems and how they were well orchestrated and well architected or how they were poorly architected and I started forming these opinions and that accumulated a wonderful set of experiences and I think at the heart of what I was doing is I was getting a ton of reps in a really short amount of time and that’s what I would encourage to anyone else who’s trying to get a lot of expertise is how quickly can you do a lot in a short amount of time in a reflective way where you’re learning from it, incidents and postmortems happen to be, that whole cycle happens to a great moment to learn.

You might be learning expertise in different areas, but whatever you can do to minimize that loop. I sometimes interview and talk to engineers who come from big tech like Facebook and Google and stuff, and I get so bummed because they’ll tell me a story where they’re working on a migration that takes two years and they’ve thoughtfully architected it and they’re rolling it out and heck they’re leaving the company at that point. That’s why they’re talking to me and they haven’t even landed this migration. And it’s a bummer because they’re not going to see the entire feedback loop of all their choices that they’ve put in. They’re not going to get to experience it, they’re not going to see it all the way through, and I get it, they got to move on. But I think the more you can position yourself into shorter and tighter feedback loops to learn from those experiences, that’s how the expertise is going to grow.

Shane Hastie: So one of the things we were chatting about earlier is your passion about how should software engineers build the craft?

The craft of software engineering [10:15]

Greg Foster: Yes. What does it mean to do software engineering well? How can it be done even better? It’s a really fun problem that I like to think about. I started coding in high school and as I alluded to in this story, I was making iPhone apps. I did some internships, I took some classes, I worked at Airbnb and I got to a point where I felt pretty confident that I can code any reasonable thing that comes my way. It’ll take time and I’ll have to do some Googling and stack overflowing nowadays ask ChatGPT, but I could reasonably figure out how to build a thing. The much more interesting question to me these days is not how do you build a server, but how can and should a team build a server? How should the craft of engineering be done? And it’s an open-ended question. That’s what makes it fun.

What I’ve found personally is that there’s some great inventions and patterns and practices that have been created at various tech companies, but are kind of siloed and haven’t always seen the light of day, or at least I didn’t know about them.

Even working at a pretty good tech company like Airbnb, there was a lot of stuff I had never been exposed to and you can bounce around different companies. I’ve personally found that Google and Facebook have pushed the envelope on most of these practices and for a long time were 5 to 10 years ahead on code collaboration, whether it’s how Google does their build and deployment systems. They have an incredible thing I’ve learned about called TAP, their systems for stacking their code changes, which I think Facebook really pioneered, their patterns of keeping trunk green and even that whole concept of trunk-based development and having thousands and thousands of engineers working on a single trunk, these are kind of amazing to me and they were blowing my mind, mono-repo patterns, all this stuff.

And what I’ve come to believe is that most useful things in software engineering that are possible and useful have been done somewhere somehow in a company on someone’s shell script. Engineers are amazingly good at solving their own problems. So if it’s a real problem and it’s solvable, some engineers somewhere has probably found a solution. They probably just haven’t broadly made it accessible to the rest of the world. It may not be published or communicated or easily accessible or open-source.

So a lot of what I’ve spent the last couple of years doing has been figuring out, “Okay, what are these wonderful great inventions’ developer patterns?” A smaller fun one was, so I work on code review and building code review platform, and I was working with a Slack engineering team and they mentioned that they had custom-built a Slack bot that would send you a notification and if the PR that you were being notified about was under 15 lines, it would just include the entire block of code in the Slack message and using Slack buttons, you could approve it, request changes, leave a comment on it, and they found that that was really useful because you could get feedback faster.

Someone on their phone could just quickly react to a code change and also gently encourage smaller code changes, which I believe, and a lot of people believe is a universally good pattern, and I was like, “Oh, that’s a great idea”. That doesn’t exist in the broader software engineer community, but you guys are doing internally at your company. That’s awesome. How can we make this more accessible? How can we bring these patterns out? That’s one random example, but there’s so many cool interesting patterns and techniques that all these companies build internally that just aren’t broadly accessible. So that’s how I like to try and find some of those.

Shane Hastie: You made the point in the founding of Graphite, the group of friends coming together, that’s very different to a lot of organizations and how do you grow that?

Growing from co-founders to a full team while maintaining relationships [13:28]

Greg Foster: Yes, it’s been such a nice journey. I can speak for myself. So, I came together, I get to work with two of my best friends, Merrill and Tomas. We met maybe at this point like 10 or 11 years ago at the start of college. Tomas was in the same grade as me. Merrill was a little bit older. Tomas and I ended up being project partners on every single CS class through all of college. I think we had coded in high school. We came in, we were taking an upper-level class and we just buddied up. We were project partners in everything, and we’d be roommates in internships out in San Francisco. I remember we took an operating system class together and I was a morning bird and he was a night owl, and so he would code up until about 2:00 or 3:00 a.m. go to sleep, just save the code base, go to sleep.

I’d wake up at 5:00 or 6:00 a.m. pick up the code base where he left it off, just desperately trying to not get destroyed by this operating systems class, and we had a lot of fun. Merrill was doing all these startup clubs with us and we were getting just deep in the tech scene and we always knew we wanted to create a company together and once we got jobs full time, we’d call each other up every six months or so and be like, “Hey, are you ready? Is it time to create a company?” And, “No, no, I’m up for promotion this quarter. I can’t do it this quarter”. Like, “Hey, are you ready?” “No, I got this thing going on”.

But finally, about three years after I graduated, the timing was right, everyone was ready and I got to do my dream come true, which is, “Hey, build really cool dev tools with people I really loved and cared about in the world and get to do it in New York. In a city where it’s not always the case, you get to build a deep tech, dev tools style company”.

A little more common now, but when we were doing it, we were thinking about this in 2019, it was more e-commerce, it was more fintech and we’re like, “No, let’s create a dev tools company in New York”. We took that energy. That energy that I’m describing. I think we’ve done our best to kind of spread and grow throughout the team. The people we’ve brought on board, we’ve really looked for folks who have that enthusiasm, who care about being connected with and friends and being kind with the people that they work with. We’re a full in-person company, which today in 2025 is not that unreasonable, but we created this in 2020 and we respected the rules of COVID, but in and around that 2021, 2022, every startup I knew was going hybrid, remote. It was easier to hire. They were all leaning into that and we said, “No, we want to be full in person and we really care about the human relationships. That’s why we came together to build this. We’re building collaborative software. We want the team to be in person”.

And it’s funny, I’m talking to you on this podcast. I’m in our office, we just finished up a happy hour we’re everyone humorously showed off what they built this week. We shared a couple of drinks; we ordered pizza to the office and then I tucked into this room. But I love getting to know the people on this team and I think if you’re looking for it and if you’re creating culture that self-selects for that, it’s not too hard to keep expanding that out. The hardest part about it for us and for a lot of companies is the pressure to cheat on it a little bit and the pressure, you got to hire faster. You got to hire the best people. We’re like, “What if we let this one slide? What if we hire one person remote or this person a little shaky, but let’s let them in the door”. That temptation’s really there.

That temptation’s there if the company’s not doing well, the temptation’s there if the company’s doing really well because you’ve got to hire even faster. It’s hard on all angles and I think props to my co-founders honestly who’ve done a really good job of this too, of holding the line even when it’s stressful, even when we really, really, really need more people on the team to take our time and find those good folks up front. My sense is that it magnifies the people we’ve brought on in the early days. They bring on the next wave of people. I’m not in all the hiring conversations anymore, so I’ve got to trust that I’ve brought together the folks with the right set of values and there are right set of preferences because now their preferences are applying down the line. And then just on top of all of it, just continuing to spend time going out together for lunch as a team, spending time outside of work.

We do big team retreats. My favourite thing that happened this year, I’m so happy we took a nice big team retreat and treat everyone. We took them to Hawaii for a week. I was so excited about, but afterwards, after we did a trip to Hawaii, about nine or so people on the team then went and took a vacation together to a different island in Hawaii. Me and my co-founders, we came back, but they went on a trip and I’m like, “Oh my God, that’s so fantastic”. If there’s nine people on this team who voluntarily want to go take a vacation together, they got to actually like it, that is pretty indicative that they care about and like each other. “Thank God we must be doing something kind of right, let’s keep paying that forward if we can”.

Shane Hastie: What’s the really important question, I haven’t asked you?

How AI tools are changing coding while engineers remain essential [17:28]

As we’re thinking about software engineering, building teams working on this, there’s lots of things we could ask. One thing I think a lot about these days is how does software collaboration, code changes, building teams work when we also have all this AI hype going on? I keep reading in the news that we’re not going to need software engineers in the future. The teams are going to be smaller. There’s going to be one person companies worth a billion dollars. There’s lots of sensational articles out and about right now. It’s not all sensation; I also use AI tools. I use Cursor and Claude and some of these great systems to help create code. I use stuff to help review it. Heck, personally, I’m a little bit dyslexic, so I really benefit from software that helps check and lint and validate. I use Grammarly when I’m writing emails and stuff so I’m not just completely all over the place.

So, AI has some value, but there’s a conversation going on in the background. Is it going to ruin software engineering? Is it going to change collaboration? I think my best guess of where this is kind of going is we are entering a world where humans and engineers will keep solving problems and keep creating code and collaborating on it and some set of all the code changes are going to be AI-generated. Some set are going to be written by hand by humans. Some set are going to be in the middle where AI helped a little bit, but a human helped all the way. And I’m very interested in how that changes the review side, the conversation side, the context gaining side. One thing I’ve recently realized as I’m using these tools is I’m losing context in the code base. I’m losing context because I’m managing more, but I’m also losing context because I didn’t write even stuff I am building. I didn’t necessarily write it. I don’t have as much of a sense. Everyone’s losing a little bit of context here.

And I’m realizing that we were all getting deep context on the code for free by entering flow states and coding for a couple of hours. We were also absorbing everything that’s going on. One of my favourite ways to ramp up to a new area of a code base is just to try and refactor it a little bit or write some tests for it, but if I’m not doing the refactoring, I’m not writing the test, I’m having Claude code do that. I’m really failing to build a lot of this context, so I’m trying to think about how in this kind of new emergent world where I think I’m going to have to maintain context. I don’t believe in AI so much that I don’t have to understand what’s going on.

I think I still need to weigh in on engineering decisions and I think these companies will still be full of engineers weighing in on decisions, helping solve problems and shipping software, but for not writing all of it. How do you maintain the context? How do you go into a meeting room and decide the next set of features, the next set of architecture designs and then feed that back into the loop? My best guess right now is code review helps, but I think we’ll actually need practices on top of that. I think there’ll actually have to be periods and patterns of us all. I don’t know just reading the code or even refactoring it, not because it’s useful with the company because that’s actually a good practice now to maintain the context, otherwise it’ll atrophy too much. I’m actually curious, Shane, if you have a take here, but how are these organizations in your mind going to change and evolve as the Asian collaborative flow? It’s definitely going to be part of the story. I don’t think it’ll be the full story though.

Shane Hastie: One of the things that we have started to hear and see is when using the generative AI tools, your pull requests get bigger, and you made the point earlier, the pressure to smaller pull requests has been a good practice, so I’m with you. I do not believe that the profession of software engineering is under threat. We will need software engineers. The way we work is definitely going to change and finding and getting that context is going to be, I think, a genuine challenge where I look to the engineers to help us figure out.

Greg Foster: One thing I like is when you think about the outer loop of software development, you have the inner loop and the outer loop, the inner loop’s like, “Okay, we’re sitting down, we’re coding”. That one’s getting eaten away pretty fast, but there’s this big outer loop of software development and I think it’s a little bit safer from a skillset investment standpoint, from a fear of becoming deprecated, it’s a little bit safer. It’s like validating and integrating these code changes. Is this the right code change? Is it passing tests? Is it where I want the code to go and then I got to deploy that thing. I got to merge it without merge conflicts. I got to carefully put that onto servers and roll that out to production. I got to watch some graphs, make sure I’m not taking on the site. A lot of that stuff I think is a lot more resilient.

Half of it is just deterministic compute that’s not being disrupted too much and half of it is thoughtful operations and I think it’s here to stay for a lot longer, but I suspect at the very least developers will be shifting some of their focus and skillsets there and I don’t hate that I didn’t become an engineer just because I like tapping keys on a keyboard. I became an engineer because they’re like building stuff and solving problems and I get to still do that even if I’m not typing as much. I suspect PMs and engineering managers feel like they’re building stuff and solving problems. They’re not writing a ton of code, so I think there’s still room to get excited about the craft of it.

This is what I tell people when I talk to friends and stuff and they’re like, “Ooh, is it a bad time to get into engineering?” I’m like, “No, actually, I think it’s the best time ever. I think it’s the heyday to get into engineering”. In some ways it’s never been more fun. I’ve never worked on more weekend side projects than right now. It’s definitely, it’s a weird time, but it’s a fun time.

Shane Hastie: A lot of good stuff there, Greg. Thank you very much for taking the time to talk to us. If people want to continue the conversation, where do they find you?

Greg Foster: Find me on LinkedIn. We can try and share my handle, but I’m just Greg Foster on LinkedIn. Shoot me a message. I love talking about this stuff.

Shane Hastie: Well, thank you so much for taking the time. It was a pleasure.

Greg Foster: Thank you for having me, Shane.

Mentioned: