Robin and Jamon discuss the art of code review -- pairing, empathy, and projector reviews. An NBA trade almost derails the conversation.
Robin and Jamon discuss the art of code review -- pairing, empathy, and projector reviews. An NBA trade almost derails the conversation.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
This is KRNR. React Native Radio. Brought to you by 5G. Get yours injected today. Episode 196, the Art of Code Review.
Jamon Holmgren:
Hey React Native Radio friends. Welcome back. This is the React Native Radio podcast. I'm Jamon Holmgren, your host. I'm joined today by my superb co-host Robin. Hey Robin. It's the NBA trade deadline today. Do you have any predictions for today?
Robin Heinze:
The blue team?
Jamon Holmgren:
The blue team?
Robin Heinze:
I know nothing about basketball.
Jamon Holmgren:
Okay. Well at least he knew it was basketball.
Robin Heinze:
Don't please don't fire me.
Jamon Holmgren:
I'd have to fire a lot of people if I got rid of non-sports fans at Infinite Red. That's unfortunate.
Robin Heinze:
Hey, sports? That's another question. You asked me about-
Jamon Holmgren:
What do you like, cricket?
Robin Heinze:
Cricket. I like NCAA football on non-COVID years. It's more exciting. This is kind of a let down season.
Jamon Holmgren:
Are you an OSU, Oregon State fan?
Robin Heinze:
Yes, Oregon State.
Jamon Holmgren:
You grew up in that area.
Robin Heinze:
Don't give me any of those ducks.
Jamon Holmgren:
No ducks. No Oregon Ducks. Yeah. I followed college football for a little while. Anyway, I'm sure we've lost half our audience already.
Jamon Holmgren:
Today we're talking about the art of code review. I'm looking forward to this one. We have, I think, quite a few different perspectives. Even though it's just the two of us, I asked the team, I polled the team for some answers. And so I've got some content here.
Jamon Holmgren:
Before I get into that, I want to say this episode is sponsored by Infinite Red. Infinite Red is a premier React Native design and development agency located fully remote in the USA and Canada. We have years of React Native experience, deep roots in the React Native community. We are the best choice for your next React Native app, or if you need help with your current React Native app, it doesn't matter what platform either. We'll do windows, we'll do web, we'll do anything that has the words React Native on it. Hit us up. Hello@infinite.red. You can learn more on our website, infinite.red/reactnative. Don't forget to mention that you heard about us through the React Native Radio podcast. And also we are hiring senior React Native engineers in the US or Canada. Go to careers.infinite.red.
Jamon Holmgren:
All right, let's get into the topic. So the topic is the art of code review. And this topic kind of came up because Justin Searls who I've known for a long time, he's been a Ruby developer back when I did a lot of Ruby, he has been around the industry for a long time. He owns another agency called Test Double. He put out a tweet a couple of weeks ago that really discussed the efficacy of pull requests reviews, GitHub-style pull request reviews. This is something that's kind of near and dear to engineer's hearts because you know, most of us have some sort of pull request review process that involves GitHub or Bitbucket or something of the sort.
Jamon Holmgren:
In his tweet he mentions or he kind of argues that pull requests are designed for low trust environments, like open source. That's kind of where Git was created for, it was created for Linux originally. And that's an open source area. You have a lot of people submitting pull requests. You don't trust them all. It's kind of a high risk situation, if you've merged something that might break something or even being malicious. So it was designed for a low trust environment.
Jamon Holmgren:
He kind of contrasts this against pairing. There's the pull request process but you could also pair. You could do extreme programming. You could work together on something all the way throughout it. And he talks about collective ownership, pairing, testing, no code review to dread, instant empathy, empathetic feedback. He talks about how pull requests, he's talked to a lot of people who almost emotionally scarred by the feedback they're getting on their pull requests. It's just not empathetic.
Jamon Holmgren:
What are your initial thoughts Robin on code review and this Twitter thread that Justin put out?
Robin Heinze:
I think everything you said is pretty much correct and universally, we agree that those are the pros and cons of pairing and the pros and cons of code review, or like pull request code reviews.
Robin Heinze:
I think the biggest disagreement I have is that pull requests fundamentally lack empathy. I think that's a variable that can be controlled. It's not like a pull request requires you to be unempathetic. It's the people that are doing the reviews are choosing to be unempathetic. And granted text communication, if you're not experienced with it or skilled with it, can lack the personal body language and other things that communicate empathy and it can seem very harsh.
Robin Heinze:
But I think for a team like us, at Infinite Red where we've been remote for so long and we are incredibly used to communicating empathy via text without being able to see each other, I think our pull request process tends to be much more empathetic than what Justin is describing in his tweets.
Jamon Holmgren:
Yeah, totally. It is something where you can get better at that. You have to work at it though. It's not something that I think comes as naturally.
Robin Heinze:
No, I don't think it does. I think it's definitely a skill that you have to learn and you have to do intentionally. You have to think about what you're writing in a comment before you just fire it off. I think there's some guidelines that you could keep in mind to maintain a level of empathy. I tend to almost always phrase things as questions rather than statements.
Jamon Holmgren:
Can you give me an example of how that might go?
Robin Heinze:
Well, if someone has chosen to do something in a way that seems problematic to me, I'll ask, "Hey, can you walk me through your thought process for this?" or ask for their reasons behind something rather than questioning their decision right off the bat. Basically, always assuming good intent that something was intentional and that they had good reasons for it. That's the underlying assumption always.
Jamon Holmgren:
With that in mind, I'll take the devil's advocate on this one and say, maybe that's what Justin is saying. If you're pairing, then you have that context already. You've already walked through those discussions with them.
Robin Heinze:
Yeah, for sure. I mean, there's no question that pairing produces a lot more thorough review because you have two people that have walked through the building of this code together and both have the same mental model and understanding. And there's really not a need for a review at the end because someone's been there the whole way, making sure that things are being done in a way that makes sense. I mean, maybe there are people that would deny that that's the benefit of pairing, but I think a lot of people would agree. It's the other side of pairing that makes it maybe not so much the norm. It obviously has big downsides to go along with its big upsides.
Jamon Holmgren:
Right. He lists some of the arguments against pairing in his Twitter thread. He says that it's often seen as wasteful, emotionally exhausting and unsuitable for introverted people, which are big reasons. All three of those are very big reasons not to do it.
Robin Heinze:
There's absolutely trade offs. So I learned to program by pairing every single day. That was the way that my code school operated was every single day you would find a pair and spend the entire eight hours that day pairing with someone else to work through the app.
Jamon Holmgren:
Eight hours?
Robin Heinze:
Yeah, it was eight hours a day. It was exhausting.
Jamon Holmgren:
How did you do that?
Robin Heinze:
You mean, how did I do that without having a job? Or how did I make it through the whole day pairing for eight hours?
Jamon Holmgren:
How did you get through that?
Robin Heinze:
It was tough. It was a lot of work. We took breaks. You kind of get used to it. And because it was new material every day, it kept it sort of fresh. But it was, it was hard. And I mean, to be quite frank, I dreaded it. I dreaded the like, okay, I have to find a pair today. And of course you get to know everyone and you get to know who you mesh really well with.
Jamon Holmgren:
But you had to go find a pair? That reminds me of like in PE in middle school.
Robin Heinze:
Yes, it was like that. There was an element to that.
Jamon Holmgren:
Okay. Everybody find a partner. By the way, we have an odd number of people. So I'm going to be the last one standing.
Robin Heinze:
Yeah, it was a bit like that. We would do our daily standup when we got in and then there'd be like, go find a pair. And so you would wander around and pick someone, which was a really intense social experiment. But I would say I got to work with most of the people in the class.
Jamon Holmgren:
Oh that's cool.
Robin Heinze:
And of course there's people that I'm meshed better with, from a personality standpoint but also from a coding standpoint. There are some people that you just kind of think on the same wavelength with, and the coding flows a lot better and you don't have to explain your thought process as much. And so of course, I would be more excited on the days I got to work with them. But I think that's just natural. It's human nature.
Robin Heinze:
And I think it's definitely very taxing emotionally, mentally, socially. I don't think I could do it now in my professional career. I don't think I could do it every day or even most of a single day. But it gets amazing results. Especially if you're working with someone that you jive really well with.
Jamon Holmgren:
Yeah. At Infinite Red, we don't pair all the time obviously. We do have the mantra of don't do hard things alone. I think that we probably pair a little too infrequently. I think we could do this a little more.
Robin Heinze:
Yeah. I definitely agree. It's something that I almost have to be required to do. Like if I know it's expected...
Jamon Holmgren:
I can make that happen, Robin.
Robin Heinze:
I know. I have to be careful what I ask for. But there's such a mental barrier. Once you're in it, it feels good and it feels good to reap the benefits of it. But it's a hard thing to say, "I want to go try and pair today."
Jamon Holmgren:
Yeah, totally. I asked the rest of our team what they thought about this Twitter thread in a very empathetic way, by the way, right, Robin?
Robin Heinze:
Very empathetic.
Jamon Holmgren:
In text, of course. That's a whole different story. One of our developers, Silas, talked about how one of his clients from years ago had a policy of three people should have seen the code. So talking about the original author, maybe someone who was pairing with them and then the code reviewer.
Jamon Holmgren:
I kind of like that because it leaves room for maybe both of these approaches. You could have a pair and you could have a review. If you don't have a pair, then you really have to have two reviews. Now, if there were three people working on it, maybe you don't need a review. Maybe you're good, you know? So that was an interesting way to approach it.
Robin Heinze:
There's one approach that I actually really, really like, that's kind of a hybrid and I don't do as often as I should. I do it occasionally for especially really large PRs or really complex features.
Robin Heinze:
But what I'll do is I'll open up the PR and then pair with someone to walk through it, which is usually much more effective than them just reading through the diff themselves, because then I can explain my thought process along the way, avoid them having to make assumptions or ask questions and comments, and set the stage or set the context by walking it through myself. That's actually something I need to do more of.
Jamon Holmgren:
I like that. It brings in that high bandwidth communication, the emotional communication, and it also allows you to fill in context, like you said, and allows you to answer questions right away. Tightens up that feedback loop. But they're not sitting there puzzling through documentation with you when you're working on that.
Robin Heinze:
It can also really help build the mental model for them. Because a lot of times GitHub or Bitbucket, they just list the diff in alphabetical order. And so it can often be really hard to form a mental model of what these changes are and what the feature does and how it works by just reading the diff top to bottom.
Robin Heinze:
So if you have someone, "Okay, start here. And then okay, so then from here we move here. And from here we move here." It's much easier to understand the holistic picture of what happened and what changed.
Jamon Holmgren:
I've certainly been guilty of doing pull request reviews that have come off wrong. I remember one guy that I worked with was kind of upset about how I reviewed one of his PRs. And what he told me was, "You pointed out the same mistake that I made like eight times. And really you just needed to tell me once and I would have fixed it."
Robin Heinze:
"Here, also here. Also here. Same mistake here."
Jamon Holmgren:
Yeah, exactly. And I thought I was being helpful. Like, "Okay, here's-
Robin Heinze:
"Here's all the places that you need to fix."
Jamon Holmgren:
Yeah, exactly. And he was like, "Quit beating me over the head with this. I get it."
Robin Heinze:
I get it.
Jamon Holmgren:
And so he was right. I shouldn't have done it that way. I just I thought I was being helpful. And it came off the wrong way.
Robin Heinze:
I think I've definitely done that.
Jamon Holmgren:
Actually, I think about that now. If I see something, and I do this with blog posts too, if I'm reviewing a blog post. I'll just point out the first time. And then I'll say there are a few more instances that you can fix further down.
Robin Heinze:
Which is worse? Is it worse to point out all 10 instances and hurt their feelings, or is it worse to have them go and fix it and come back and have to say, "Um, there's actually..."
Jamon Holmgren:
I still think the second is better. I really do. I've never had someone get upset at me for doing the second. Usually they're just kind of embarrassed. Like, "Oh, I should have caught that."
Jamon Holmgren:
One of our developers, Kevin, said that it comes down to your culture, which you alluded to earlier, Robin. Are you addressing your pairing culture or are you addressing your PR review culture? And Justin's take on this, I know Justin a little bit. I'm actually going to send him this episode and get his thoughts on us discussing his Twitter thread. But he focused more on the pairing culture and what you could do to make the pairing culture work well. He didn't focus quite as much on what you could do to make pull requests work as well. His broader point of just pairing often and prioritizing normalization and trust building.
Jamon Holmgren:
We're big fans of trust building at Infinite Red. A lot of things that we do is centered around that. I do think that's good. But I think it can also apply to pull requests. He may disagree though, because it seems like the media itself is part of the problem there. But like you said, there are ways that you can do a hybrid approach where you're pairing with people during the code review.
Jamon Holmgren:
Another idea that I've seen is to, and Yulian does this quite often, one of our developers, do a video, and show the feature in action. Go through the PR and actually explain why he did different things.
Robin Heinze:
Keeping the async quality, which is really important when you have people all over the world.
Jamon Holmgren:
Yeah, totally.
Robin Heinze:
But you add the personal context. Yeah. I think there's a lot of different ways to not just need to pick one or the other.
Jamon Holmgren:
Right.
Robin Heinze:
I also think one thing I need to do more of is periodic pairing. I'm still the one responsible for a feature and building it primarily independently. But periodically I'll do a pairing check-in with my teammates saying, "Hey, can I walk you through what I've done so far? Let me know what you think." Especially that can help with architecture issues, because it's the worst feeling in the world when you get a PR open and someone basically says this architecture isn't going to work, or this fundamental thing needs to change. And you're like, if I had known this two days ago, I could have saved so much time.
Robin Heinze:
So doing that in-person periodic check-in where it's not building the entire feature start to finish with someone else live, which has the issue of bandwidth and quote unquote wasted time, having to use two people for one feature.
Jamon Holmgren:
That's a good point.
Robin Heinze:
But you still get some intermediate feedback rather than all at the end.
Jamon Holmgren:
Means that the feedback loop is very slow and it's like very late. And that totally plays into what you're saying. And I often feel bad. I look at someone's PR, I just did this the other day, actually. I looked at one of our engineer's PRs to an internal tool. And I was like, "Ah, that's not quite going to work." I could tell he worked hard on it. He did a good job with the direction he went. It was just, there were certain things about it that didn't quite work for the architecture. And so we then talked about it. I guess at that point it's like elevate the bandwidth. If you have to give that type of feedback, elevate the bandwidth, don't just put it into a, "this pull request was rejected."
Robin Heinze:
Exactly. "Hey, can we meet in Zoom really quick?" Yeah, exactly. You need to go beyond text communication for that kind of feedback.
Jamon Holmgren:
Another part of this is remove the audience, too. Like maybe a DM in Slack is a little more empathetic.
Robin Heinze:
I'll do that. If I have a serious concern with someone's PR, I'll DM them in Slack. It's just a respectful thing to do.
Jamon Holmgren:
And if someone starts feeling defensive, then nothing good happens, you know? It really, it doesn't work very well. So much of this is about just general communication too. Like how you approach this. Carlin in the thread also responded and he's worked for me for 10 years now, something like that. It's very close to 10 years. And he said, "At Infinite Red, I can't remember a single time when someone commented or requested changes on my PR and I felt like they were calling me stupid or something."
Robin Heinze:
Yeah. I think at Infinite Red specifically, we've worked hard to have a very blame-free, respectful culture. And I think that's something that we actively cultivate all the time. And it really helps for things like PRs and feeling safe, making PRs. The situations that Justin describes, I can't even imagine working somewhere where that's how people feel or that's how people are made to feel during their PRs. I just, I don't know.
Jamon Holmgren:
Yeah. I think we tend to look at these types of things through an Infinite Red...
Robin Heinze:
Through Infinite Red rose-colored glasses? Like, "That would never happen. That's not a thing."
Jamon Holmgren:
Why would you ever do that? And then people are like, "Yeah, that happens all the time."
Robin Heinze:
That happens all the time.
Jamon Holmgren:
Oh, come on. Really? But I mean, that's really why we started. Why Todd, Gant and I and Ken started Infinite Red was because we wanted a company that we would want to work at. This doesn't always work outside. But I'm not a big fan of fixing culture with tools. Tools can have an impact on culture, no doubt. But tools and processes don't fix your culture.
Robin Heinze:
No. Culture comes first.
Jamon Holmgren:
Exactly. Some shared values in how you approach things, and then the tools come out of that. And the process has come out of that rather than the other way around. And I think too often companies, because processes do fix so many problems, they're like, "Well, we'll just fix our culture problem by mandating this."
Robin Heinze:
More checklists.
Jamon Holmgren:
Yeah, more checklists. Exactly. By the way, I am a checklist fan, but not for cultural reasons, just because I forget things all the time.
Jamon Holmgren:
So Justin does categorize these into three different ways. There's projector reviews is what he calls them. Low comfort, low information, low empathy. It's everybody picking apart your code in front of everybody. That's like the worst.
Robin Heinze:
Terrible. I've never been through one of those. I'm very grateful that that's never been part of my career.
Jamon Holmgren:
You know what's funny? I actually did some of these at my old company with people like Carlin and Yulian and Kevin and people that I've quoted here.
Robin Heinze:
Which isn't a problem when you're an empathetic leader.
Jamon Holmgren:
Oh thanks.
Robin Heinze:
And you've created a culture of empathy. It could go wrong really, really easily.
Jamon Holmgren:
I totally understood that this would be scary for people. So people would volunteer like, okay, let's look at this maybe Rails controller or something we were working on at the time. And we would put it up there. And what I would tell people is we're going to work on this for one hour and we're going to throw away all of the changes we make. So none of this is like, if you want to bring it back to your code, you can do that. But this is for us to brainstorm. It was less about picking apart their code and more about what are some ideas that we might have to improve this code? What are some things we could do to... just ideas?
Jamon Holmgren:
And it was fun because it was like, what if we took this block of code here and we refactored this out into a service object? And just look at that, try it and let's look at it and see how it looks. And I think it went well. People actually have told me that they miss doing that. The ones that were there doing that.
Robin Heinze:
That's a good sign.
Jamon Holmgren:
Yeah. That is a good sign. I wouldn't mind doing it. Obviously. I'd probably start with some of my own code or something, like let's pick apart Jamon's code. But what are some ways that we can improve this code? And then remember we're throwing this away. So like this doesn't go back. We're not trying to make this all work in a perfect way. But we're trying to get ideas and spark curiosity, I guess, is the idea. That's a very different thing, though, than code review.
Robin Heinze:
Right. The desired outcome of those projector reviews wasn't, "Hey, we need to get this feature merged to go to production." That wasn't the goal. The goal was just collective learning and thinking and whatnot. But I don't think it's a very common technique to actually get production code reviewed in order to keep the train moving.
Jamon Holmgren:
Yeah and apparently some teams do this, but I don't know.
Robin Heinze:
Gosh, no, thank you.
Jamon Holmgren:
So the second one he says is pair programming. Low comfort, high information, high empathy. So it is uncomfortable still because you're in person, but you do get a lot of information, a lot of high bandwidth, and you also have the opportunity for high empathy.
Robin Heinze:
Right. Having it be a one-on-one versus a whole conference room audience.
Jamon Holmgren:
Right, yes. One-on-one high bandwidth. Yeah. That makes sense.
Robin Heinze:
Definitely low comfort. That's just the nature of pairing. I would always have a headache after a day of pairing because you're just kind of on all day. But yeah. Low comfort, high information, high empathy.
Robin Heinze:
And then pull request reviews are kind of the opposite. High comfort, because you're just typing anonymously. Well, not anonymously, but asynchronously. High information, low empathy.
Jamon Holmgren:
Because you don't have that bandwidth, the communication bandwidth. It's just text. So that's why when you do a pull request review, you need to be focusing very closely on the empathy that's coming through your words. It's hard to do.
Robin Heinze:
Which, like we said, can be helped by adding some of the high bandwidth into your review. Having them hop in Zoom to go over questions, you can kind of add in a little bit of that high empathy that you get with pairing.
Jamon Holmgren:
Yeah. I think that's good. And from my perspective, I don't think it has to be that way. I don't think it has to be that way. I think that, and really in all three, the projector reviews could be higher information and higher empathy. You'd have to work really hard to do that though. That it's an uncomfortable situation. Could pair programming be high comfort? I don't know, maybe.
Robin Heinze:
That's where I was going next is, with pull request reviews, I can see lots of ways to increase the empathy. With pairing, I don't know a ton of ways to increase the comfort besides just doing it so much that you're just really used to it.
Jamon Holmgren:
Yeah. I mean, that is one option I guess. When you do a pull request, there are different things that play into this too. Sometimes, like Carlin mentioned, if he spends a lot of time really putting together a good PR with lots of information, maybe he does a video, maybe comments on lines and makes sure that it's really well put together. And then the person, he tags the person to review it.
Robin Heinze:
Approved, merged.
Jamon Holmgren:
It's merged in like two seconds. You know they didn't look at it.
Robin Heinze:
Yeah, it's pretty deflating. It doesn't encourage you to put that much work into it every time.
Jamon Holmgren:
And I just get a text from my buddy that a trade went down for the Blazers. So we'll have to wrap up this podcast episode quick.
Robin Heinze:
Priorities, Jamon. Priorities.
Jamon Holmgren:
It does display trust, I guess. Like, "Oh, I trust you. Bring it in." But I think it has more negatives than positives.
Robin Heinze:
I think a really important part of empathetic code reviews is also praise. A really good code review should also involve, "Hey, I really like how you did this." Acknowledging good work just as much as you're pointing out mistakes.
Jamon Holmgren:
That's a very good point.
Robin Heinze:
Having a pull request just go straight to merge with no comments is like, okay, cool. Yeah. They didn't find anything wrong theoretically, even though they probably just didn't look at it. But they also did not acknowledge the many days of work that I just put in.
Jamon Holmgren:
Yeah. And I love being able to give praise in a pull request. And pointing out small things too, like, "Whoa, that's a really cool way to do this." It shows that I'm looking at it so they understand that I am. And hopefully it makes them feel good about the work that they just did.
Jamon Holmgren:
Darin talked about, he's another Infinite Red developer. He said, "I think PRs work well for code quality, but less so for shared ownership. Pairing can work well for both, but it's not for everyone. I certainly couldn't do it full-time."
Jamon Holmgren:
So shared ownership is an interesting one. It does, especially when someone just kind of merges, it does sort of feel like they are not taking ownership over it. They're like, "Well, that's your thing. And I didn't notice any major warts on it. So here it goes."
Robin Heinze:
It really perpetuates the siloing of knowledge. Like, "Oh, this bug is related to push notifications. Well, Mark did that. Mark will handle that." And not being able to own every part, even the stuff that you didn't build yourself.
Jamon Holmgren:
Yeah. Orta talked about in a previous episode owning your dependencies. And this is even closer to us, owning the code that you're working on. Not just the code you're working on, but that your teammates are working on. And having that sense of ownership and being able to like, "I notice a bug."
Jamon Holmgren:
Imagine this. "I noticed a bug. I went in, I looked at the changes you just made and here I think is where the bug came in." That to you is like, okay, well, that's awesome. You know the code really well so you can instantly be like, oh yeah. I can see all that would cause a bug. And it's cool because you can see that they're interested in your part of the code, quote unquote.
Robin Heinze:
Even better, I absolutely love it when a teammate reviews my PR, finds something wrong and then pings me to say, "Hey, can I just push another commit to your PR? I found this," and actually fixes it themselves.
Robin Heinze:
A, that's less work for me. B, I know they really looked at it and understood it well enough to add code themselves. And you have to do it right. I wouldn't just push a commit without letting them know ahead of time, because you never know what else they're planning on adding or if they would get offended. But I think it can really show that you've understood it to the point where you could contribute yourself.
Jamon Holmgren:
I remember talking to an engineer. We had a shared acquaintance, Eric Farkas, who's a great guy. When we found out that we had this shared friend, she said, "Oh, Eric is the best code reviewer I've ever worked with." That was the first thing she said. It didn't matter about his code or anything like that. But, "he's the best code reviewer I've ever worked with. He's spectacular. He'll actually look at my code. He pulls it down. He runs it and then provides empathetic, super thoughtful feedback that makes my code better in the end."
Jamon Holmgren:
I was like, whoa. I've never really thought that being a superpower. Being the best code reviewer that someone has ever worked with. That is a real skill. That's amazing.
Robin Heinze:
It's not all that common that you encounter someone who's really good at reviewing code in that way.
Jamon Holmgren:
Yeah, totally. Now we did have one person at Infinite Red who prefers pairing that mentioned that they preferred pairing and that was Yulian. And then he gave these reasons. He feels that it gives you a greater understanding of the problem, the potential solutions, and the decided upon approach for a given task or feature. Also, he mentioned growth of a closer working relationship with the person you pair with, which I think is a very good point. He likes the idea of shared ownership and also, on the psychological level, feeling the accomplishment of the win at the end of the collaboration. Because it's like, you both feel like it's a win, it's not just you by yourself. And also more focused on the problem at hand. I know for myself, if I'm working with someone else, I will focus more.
Robin Heinze:
Now it's worth noting that he wasn't always a pairing enthusiast.
Jamon Holmgren:
No, not at all. No. I've worked with him for about 10 years and he was kind of a solo siloed, leave me alone, I'm going to have my headphones on and do this type of thing. But as he's grown as an engineer, he's become more and more collaborative.
Robin Heinze:
Yeah, so practice it. It may be uncomfortable. You may dread it at first, but it does get easier the more you do it.
Jamon Holmgren:
To kind of wrap this up, Robin, what would you say are the big things for an effective code review?
Robin Heinze:
For a code review to be effective there has to be a pretty deep level of understanding on the part of the reviewer. And there's multiple ways to get there. But it's never going to be a truly effective review if they don't really have a good model or understanding of the code that's changing.
Jamon Holmgren:
Yep. I think that's huge.
Robin Heinze:
So understanding on the part of the code reviewer and empathy on the part of the code reviewer.
Jamon Holmgren:
Yes. Empathy, super, super critical. And I'm actually, I have access to your notes so I'm just going to read them. But these are Robin's notes. "Phrasing things as questions rather than commands or whatever. Including compliments." She mentioned this earlier. "Assuming good intent." That's a big one. "And asking for reasons behind the decision rather than going straight to questioning their decision." So I think those are all really good ones.
Jamon Holmgren:
Awesome. Very good information here. Robin, if people want to let you know their thoughts about code review, where can they find you?
Robin Heinze:
I'm @Robin_Heinze on Twitter. That's with an E at the end.
Jamon Holmgren:
And I'm @JamonHolmgren. You can tweet at our main account @ReactNativeRdio. As always thanks to our producer and editor, Todd Werth. Our transcript and release coordinator Jed Bartausky. Our designer, Justin Huskey, as well as Jenna Fucci. And our social media coordinator, Missy Warren. Thanks to our sponsor Infinite Red. Check us out. Infinite.red/reactnative. Special thanks to everybody listening today. Make sure to subscribe. Send this to someone who you think is really bad at code reviews and needs to get better at it.
Robin Heinze:
Hint, hint. Hey, hey, maybe you should check out this podcast about code reviews.
Jamon Holmgren:
I could just hear the person after listening to it and getting this sent to them. "Hey, wait a minute here. I'm not that bad."
Jamon Holmgren:
And a reminder that we are hiring senior react native engineers, US and Canada. Go to careers.infinite.red. See you all next time.
Robin Heinze:
Bye.