Welcome to Syntax. On today's supper club, we have Sarah vessels from

GitHub here. She's a staff software engineer, GitHub, and she's been there for

eight years working on all kinds of things like get hub sponsors discussions branch renaming

pin repositories private graph contributions and a ton of stuff and we're going to be

talking a lot about code reviews we're going going to be talking about GitHub the process of

emerging code in a project and working in a collaborative environment. My name is

Scott Tolinsky, with me as always is Wes.

Welcome to the show, Sarah.

Hi, thanks for having me on.

Yeah, so code reviews.

We have a lot of developers who listen to this show,

and maybe they haven't been a part of big teams or they've been

a part of big teams or you know they haven't done this process of a code review.

I read a blog post of yours that was extremely good. We'll link to it in the

show about the process of code reviews and I kind of wanted to start off there. So could you explain

two developers who might not be aware you know what's the deal with a code review? What's the premise? Why would somebody do a code review and what does that entail?

Okay, so code review is having your team, having other people with context on what you're trying to build,

the bug you're trying to fix, anything you're doing in a repository, getting them to look over your changes.

This is assuming you're using like pull requests, merge requests,

if you're on GetLAP, that you're not just throwing your code out there to the main branch.

So it's part of the process. I think you might have automated testing. You might have

automated deploys to some kind of staging environment. Stuff like that to help you assess, like, did I do the right thing?

...