 Is it on? All right. So who in this room doesn't know what a pull request is? There's at least one, perfect. Two. All right, so a pull request is essentially the, it's the github word for it, really, for just requesting a code review for some sort of change. And in reality, I was talking to a few people, I think it was during lunch or last night, I don't remember, and there was some conversation about how people would use github for like planning their wedding. So that's kind of a completely different way to do it. So we're gonna dive into, pull request, I'm just using as a very general term for just, if you're in a situation where you deal with a code review and it sucks. So to start out, that is a live github repo. So github.com slash AU Smith slash how not to review a pull request. If you wanna copy of the slides because I will have some links in them, this way maybe you don't have to take pictures. So let's look at a maybe possibly decent pull request comment. So here I'm specifically pointing out, hey, these are, you may not want to do this, you may not want to use the same ID here because here's a link to the documentation that says how we can't do that. The action items are very clear for you person and this is the last good comment that's going to be in this entire presentation. All right, so in my professional career so far, I have seen four types of code review behavior. There's timid code reviews, so they're going to be, or rather rabbits. So questioning their statements in the code review may lack conviction, so it's hard to determine exactly what to take as the action item from them. Then there's idealists that they're probably not really reading your code, they're probably a little more interested in their solution for the problem. Then there's Spartans, so they're going to be a little bit more terse, hard to get further information from. Maybe their comment was just straight up missing information, or maybe it was just something really short, like fix this. Then there's tornadoes. So these would be a bit more indiscriminate, so when you submit a pull request on GitHub, it will actually highlight trailing white space. Let's say you accidentally did that a bunch of times in your pull request, and then you had a tornado come along and come in on every single one. Sometimes a little overzealous. So these are especially more entertaining when you start to combine them. So someone who's not, their comments don't have a lot of conviction, but they come in on absolutely everything. Or maybe Spartan idealists. So not only were they too terse to understand what the heck they wanted from you, but they also only cared about their solution. Or Spartan idealist rabbit, oh. All right, we've exceeded my Photoshop skills. So let's look at some actual code comments. You may notice throughout this presentation from here on out, there's little cat personas. Those are actually my cats. Fun aside, my partner bought that little outfit for our cat just for this presentation. Okay, so let's say Business Cat here is my engineering manager, and I just submitted this code change that has this changing operating systems. And so they comment, did you even read the memos? So at this point, I'm totally frantically reading through my emails, trying to figure out what the hell I missed from my manager and wondering whether or not it's gonna come up in my next review. Or how about if I submitted an open source change, and I was just straight up told, delete your account. I kind of don't feel okay with that one. An I statement, I don't feel okay with this. Or if someone just said, why would you even do this? Like me reading that, I'm totally like, why would you even do this? The connotation sucks there. And it's not like I went out there and had this as the title of my pull request. Though you may actually notice if you go to that GitHub repo reference at the beginning that this is actually the title of one pull request on that repo. This is not typically what we're seeking when we submit a code change, right? Let's look at a few more that are on the more passive aggressive side. Like just fix this. So, all right, sure. I happen to know just because the spelling's very obviously wrong here, but what if that was a slightly more abstract situation? Or on that same really light code change, maybe change this to do something useful? Yeah, that doesn't feel great. Or how about just a link to the correct spelling? The second comment there, whatever, this is fine. Totally would have been acceptable and made me feel just as badly if they had done that this is fine dog. Or how about this is not bad for someone in your position. All right, so notice that all of these were totally attacking the actual author of the change and they weren't focused on the actual code that we were trying to make changes to. What was nice about not being first in artifacts today is that multiple people, both John and Aisha, mentioned taking a deep breath and that's gonna be kind of our focus here. So that concept is called active pausing. So it's, while the definitions vary, it's basically just taking a step back, recognizing that you feel an emotion and figuring out how it's impacting you. So one example is taking a deep breath, right? Or this might manifest in the form of you taking a five minute walk before giving a response or maybe you pause before responding to an email, like you write out all of your feedback and then you just minimize that window and come back to it in half an hour. The goal here is not to bottle it up. It's not to say, okay, so I felt that emotion so now I'm gonna completely ignore it and I'm never gonna go and do that fit on the mattress in the middle of my living room later, like John was describing. It's instead to identify what emotions you are feeling, consider why you feel those emotions, think about your desired outcome and that one's important. You need to think about what you want to happen with your follow-up interaction with them and then choose the responses most likely to achieve that outcome. If you're interested in reading more about active pausing, the first two are more focused on the definition and the last link there is talking about some physical exercises that you can do like stress balls and the like. All right, so let's talk about typos. Sometime they can be totally harmlessly funny, like take capsule till dead or embarrassing. We remember all who served hot breakfast, who had served hot breakfast. Or downright insulting like the Lyndon B. Johnson School of Pubic Affairs. Fun story about this one. So Lyndon B. Johnson's school apparently issued an official apology and sent out new copies of the commencement program afterwards. That was nice of them. So how can typos, I mean, I don't know that I would have wanted to keep that but I probably would have burned it and enjoyed that cathartic experience. So how can that actually affect a comment in a code review? We have made the mistake of overcomplicating things before. We should now make this mistake again. I think they meant we should not make this mistake again. And assuming this is my engineering manager, it's got double meaning, like do they want us to overcomplicate that, I don't know. My point though is that written communication presents many avenues to misinterpretation. Typos like you shit on all the points. I think that was supposed to be you hit on all the points. I think connotation is important. Like what an innocent change. So was I supposed to know better? Is that an insult or emphasis? Like when someone writes why not try X? I might read why not try X? Like questioning me or why not try X? Like hey, maybe this is a better solution. Or commas are really, really important. So I definitely did a double take when this one showed up in an email a couple weeks ago. I have too soon to be three children and wife. I'm not sure if they wanted to say sons. I'm also not sure if it's a wife. So I'm assuming they meant I have too soon to be three children and a wife, I think. All right, let's go back to this. So, hey, delete your account. That sucks, right? Or how about what were you thinking? It was more like Darth Vader from episode three in Star Wars, right? Just shouting in the sky. So, exactly. So this one actually has a interesting story and is one of the few non-fictional comments in here. So I was being told, I went out asking others, coworkers and friends, some examples of bad code review experiences they had had. And this was a college friend said that they had just graduated, they were their first week into their job and they submit this and they're excited and they submit their first code change. They submit their first pull request. And this is a 50 to 100 person company and this is the comment that her CEO pops into this first pull request. Their self-confidence is shattered at this point, right? How about I would consider your solution if you had senior in your title. I'm seriously not sure why senior in my title would matter at all here. This one is not a true story, by the way. Oh, for me. So these boil down to the concept of psychological safety which came up as the number one key factor for a successful team at Google after they did an internal study, I believe the year was 2012. And it's the concept of can we take risks on our team without feeling insecure or embarrassed? Alex Harms, so earlier this week, there were apparently a few conferences earlier this week besides RailsConf. So DevOps Days in Atlanta was Tuesday, Wednesday this week and Alex Harms did this really good presentation which I highly encourage you checking out called Psychological Safety the Hard Parts. And she had this really good comment saying of nobody, wow, I spilled nobody wrong. Nobody sets out to do the wrong thing. That's impressive. All right, that one's not intentional, right? Also if you wanna see an absolutely awesome presentation I recommend that Vimeo link cause she is presenting at the Lean Agile Scotland conference and her slides end up not working. So she ends up doing the entire presentation without slides which was freaking awesome. Similar to the talk we just did actually. And without this sense of safety we tend to see teams have a breakdown of creativity and support within the team and the result is usually a decrease in productivity. That link is from an O'Reilly conference where a Slack manager came in with a Slack join Slack as a manager and they had a product that they had to produce within two months of her joining the company and this is where I was first exposed to psychological safety. All right, let's go back to some code comments. You should initialize this variable before entering the loop. All right, well I'm pretty sure I did that on line 15. So did you miss it? Or maybe suggesting that four char in characters should be four C in characters? Like that seems a little pedantic. Or how about the all important naming problem where they just kind of generally are, I'm not sure they read the actual code at this point. So for me these boiled down to a concept that called trust but verify where if for example, this individual had instead trusted the person who wrote the code to have at least run it once, they probably would have known that, hey it was already initialized first. This concept where you're willing to trust your teammates, like you hired them, right? So you're willing to trust your teammates and also verify what they did. I think this applies to both technical and human problems personally and I try to apply it to my everyday. A recent example of this was a coworker of mine was fighting with a technology called RabbitMQ and he had been handed some, he had been handed a set of certificates from another team who had tasked us with spinning up the RabbitMQ server and he was bashing his head against the problem for like three days where it just wouldn't run and then he realized that the certificates he was handed were actually bad but it took three days of troubleshooting for him to find that. So totally trusted the other guy to do the right thing but forgot to do the verification step. This sort of comment like what test cases has it been verified against? I encourage everybody to put that sort of review comment in code reviews. This doesn't need to be fictional. So, let's say that Count C here just missed it. Let's give them the benefit of the doubt. We're all human. We all make mistakes. We're emotional beings. Shit happens. Adam Osborn who I didn't learn about until I started putting together this presentation looking for good quotes. He said, people think computers will keep them from making mistakes. They're wrong. With computers, you make mistakes faster. And this kind of lines up with the mentality today that we should fail fast, right? Though I kind of disagree with the concept of we use computers to fail more. I don't like that idea but I definitely like the rest of the concept and if you're curious about Adam Osborn. Apparently in 1981 he was working on portable computers. So that was cool. All right, so what I hope you take away from this presentation. Active pausing is really, really useful for being able to get to a positive outcome when you start to feel emotional or feel an emotion, not emotional. Written communications are really hard and really easy to misinterpret. Psychological safety helps teams be productive. So creating that safe space for other people is really important. Trust but verify. You'll be happier, I promise. And we all make mistakes. The obligatory slide of a lot of links and why I made this into a GitHub repo in the first place because I didn't want people to be like, what the hell are all these links? The first two are focused around the code review process itself. That very first one actually is a great presentation that a blog post about a presentation at a conference earlier this year on basically the same topic that this ended up being. Fortunately I had already submitted the abstract at this point. The second one is a good blog series. The third item is actually a talk from Uptime Conf last August here in Pittsburgh, which was, it was really, really good. If you wanna watch someone present better than I ever will in my life, I encourage that presentation, but that's where I learned about Trust but Verify. We mentioned the successful Google teams. We mentioned the Slack engineering manager. Anatomy have a great pull request. This is a member of the Rails core team talking about his experience reviewing open source pull requests and what makes them good and easy to review. And then the last two are if you're interested in the concept of mindfulness, which active pausing is a part of mindfulness. John Kabat-Zinn is considered the foremost expert in the subject and Time Magazine thought it was an important enough topic to do an entire issue on at the end of last year. So thank you very much. Thanks for your time. Those really are my cats. We do take lots and lots of pictures of them. The obligatory comment that I failed to mention at the beginning is I worked for a company called Pindrop. All right, now I can write off this entire talk. So yeah, thanks for your time.