I really want people to change that mentality of being afraid of code reviews and be excited for them. Look at it as a just a learning experience. Think of it as showing your code to someone perhaps that might be more senior than you, and you've got their time, you've got their experience. I mean, how exciting is that? Hello and welcome to the Pibytes podcast, where we talk about python career and mindset. We're your hosts. I'm Julian Sequeira. And I'm Bob Baldebos. If you're looking to improve your python, your career, and learn a mindset for success, this is the podcast for you. Let's get started. What are we going to talk about today? So I figured today we could talk about a bit of a scary topic. We talk about code reviews. What do you reckon? Yeah, that might be scary. Maybe you turn people away. Shall we do it? No. All right. Thanks, everyone for joining us. We're just going to stop. No, I'm kidding. Yeah. So what does a code review, Bob, tell us? Okay, so when we work with other developers in a team, we're going to submit our code to be merged into the main branch, into the main code base. But as developer, we cannot just merge any changes in. We have to have it reviewed by fellow developers. And that's where the code review comes in. Yeah. So it's like a best practice. Why is it then that we hear from a lot of the people in our community, from emails, Twitter, wherever, that they're a bit of a. Not taboo, but bit of a scary, controversial, sometimes process? Yeah, that's a great question. And I think it comes down to that people are sometimes scared to reveal their code. I think it's. It's not good enough or they're making mistakes they shouldn't have made. I'm not sure why that is. Because we should be allowed to fail. Right. There's somehow in the industry, sometimes a high bar, like it has to be perfect. Well, perfect code, of course, never exists. What do you think? Well, I'm going to get up on my soapbox for a minute. We should have a sound effect for when I get on my soapbox. We'll get that in one day. Well, it's interesting you say that we should be allowed to. To be the people learning, you know, we shouldn't feel that criticism or that feeling of criticism. When someone tells us something, you think about it. We went through years and years of schooling as kids and we spent the whole time learning from someone else, from the teacher in front of us, or the multiple teachers. So why does that have to suddenly stop when it comes to learning a new skill or working in a new environment? You know, until you're 100% confident and you should still get code reviews done then. But even so, you're learning all the time. So code reviews, I think it's this mindset shift that we need to change, that they should be something that builds people up. It's about, it's a learning experience. It's not a way to crucify people and shoot them down and smack them down and say, hey, you, your code sucks. Go back to the drawing board and don't waste my time. It should be a great, this is great progress. Let's work on it together and provide meaningful feedback. So when my question for you then is with the code review process, how is it that people can take it to be a critical thing to get that feedback? I think inherently it's just not fun to be criticized. But of course it depends the reviewer, right. Some can be harsh, some can be picky, but some can also be incredibly humane about it. So it depends a little bit who you end up with, right? But it's also a chicken and egg, right. You have to kind of go through it. You have blind spots. There are things you're not seeing yourself. You only get to the next level if you're willing to be vulnerable. And that's through code reviews. Right. So it's funny, like I've had code review commands that I still remember. Why are you doing two times a list comprehension looping through the sequence twice? Well, you can do a classic for loop and I thought it was fancy by using this comprehension for everything, do this simple for loop back to basics. Right. And I felt a bit stupid about that. Still can still remember it. So it has kind of an impact. Right? Yeah. And are all code reviews? This might seem like a bit of a noob question, but I want to ask because I see value in. I'll get there with this. But a real code review is generally virtual, like over some sort of a code reviewing tool where you see the code set side by side and see the changes that are going to be committed. Think GitHub style. But is that the only way to do code reviews? No, in my case it has been because I've been always been working remotely with developers. But I can imagine that in the office you could sit side by side, but I think it will always go through BitBucket, GitHub or GitLab, whatever tool you're using. Also for documentation and to keep that visibility. Right? Exactly. On certain branches, yeah. And this is where I find people tend to feel a little more criticized as with anything getting any sort of feedback over a text medium without context in the form of your tone of voice, your facial expressions. You know, is someone criticizing you, picture everyone criticizing your work with the angry dad face, you know, and disappointed father face. And so it's really not like that. It's just this. This is why, and this is moved. Getting off topic slightly, but this is why I always encourage pick up the phone. And yes, it kind of, you know, ruined it with, with coronavirus and everything. But one of my favorite experiences when I've been coding at work has been to sit in the room with one of my teammates, my, one of my best mates at work, and we sit there and we write code up on the whiteboard. And, you know, it tends to sometimes be a bit more pseudo. Cody, that's another one we need to talk about one day. But, you know, it's an amazing experience where we go through the code together, and that is our code review. And yes, it goes through the tool. Yes, we have the side by side, but that's what provides a more valuable experience for me. Anyway, that's a great point. Having this all virtual. It can come off way harsher than it really is. So it's always good to keep connecting with your team and seeing them face to face. And then if you see the smiley faces, then that's not that bad, right? Yeah, there you go. So there's a tip for anyone put a smiley face in your code review. No, I'm kidding. But, so, Bob, tell me, with, with your code reviews, historically, what's been something special you want to tell me? Yeah, what I wanted to share, like the feedback. I've been giving them some client code reviews. Oh, nice. Yeah, very cool. Yeah, because you've been doing, you've been doing a lot of code reviews with our clients, right? Every day I wake up with a full inbox of GitHub notifications. But yeah, some things I can highlight. For example, also keep it a bit more python and technical. For example, if you try and accept and you just do a bare except and not naming your exceptions, like accept value error, accept type error, whatever. If I see that an alarm goes off, I want educate that person. Like be pythonic, use software, best practices. Right? And the Zen of Python says, of course, explicit is better than implicit. So if I see an except colon and say, no, no, no bare exceptions, what exception is this code going to raise? Right? So I make them thoughtful about that. So I put a command there. And then the nice thing about code reviewing tools, of course, that can grow out into a whole thread of back and forth with maybe ten commands, right? And it's kind of a way not only to make the code better, but I also see it as a training tool because they learn from it and next time they're going to do this better. Yeah. Or for example, I see 20 lines of code between and try and accept. It's like, well, are all these lines susceptible to raise that exception? Probably not. So you want to narrow that try except down and I give them that feedback and then they can make the change. Then of course the diff becomes outdated. But again, it goes back to going back and forth on that thread and it's a great way of learning the next code review. Then those mistakes in parenthesis or not following the best practices you see disappear because they learned. And it's also making up for training. We often don't get on the job. We're not taught all these things when we start again. The code reviewing is a great opportunity for mentor M and T or team members to train each other on how things can be more pythonic, how to follow software best practices, or design things. Like, maybe you're putting too much logic in your API and you should break that out into the business layer. Where should code really go? I'm really fascinated by that. Can go on for hours. I hope you get the point. Please do. No, actually that resonates with me a lot because most of the things that I've learned, well, that stuck with me as I've been learning coding throughout all these years has been through code reviews and going back to the work situation where it was a formal code review process, I really learned some new things. And even as simple as you're doing your doc strings wrong and, you know, it was just something I took for granted. I'd just done it, but I didn't have that opportunity before where someone had looked at any of my code that had doc strings to point it out before. And so I really want people to change that mentality of being afraid of code reviews and be excited for them. You know, don't sit there as a, it's a gate that you need to pass to be considered successful. Look at it as a just a learning experience. Think of it as showing your code to someone perhaps that might be more senior than you, and you've got their time, you've got their experience. I mean, how exciting is that? You get to learn from someone else looking at your code and going, hey, this is great. Here are some things you could change to make it even better. Yeah. For you, it was really a before and after because for me, it was like that. There's a time before the code reviewing and there's a time after the code reviewing where you. You noticeably have grown through that mentor feedback, right? Oh, yeah, exactly. When I started doing code reviews myself, it felt really good. I mean, it doesn't feel like nitpicking. It feels like you're helping this person, you're helping your teammate to really drill down and get that better result out of their code. So, yeah, man, I think it's a great feature and a great habit to build, but, yeah, I was just going to say that's how we started, right? Oh, yeah, that's a funny story. Like when I think I challenged you to make a certain application or script and you came back with me with your code, right? And then I reviewed it. I didn't. This was literally. Okay, disclaimer. This was literally, I want to say, weeks after just started picking up my first python tutorial or anything. So my code was extremely rough. This is. We decided right off the bat to start challenging each other to learn python. So. Yeah. Well, you had the courage to submit it, you know, and let's see what happens. Well, you know what? That's still one of. That's still one of the lessons that I, as you mentioned with the code review guide, that's something that I haven't forgotten to date. So the very first programming language I learned back in high school was c. While everyone else was living, learning visual basic, I was learning c. And I'm actually kind of grateful now for that because it pushed me more than I think VB would have. But, you know, the thing is, I learned how to do for loops, the C style. So I think the index, right? Yeah, exactly. For I in range, blah, blah, blah. Something like that, right? Yeah. Yeah. So I was doing, doing that whole C notation time my for loop, and I told you this is for I in sequence, right? Yeah, for I in object. I just went, what? How does this even work? And it worked. And you removed, you know, a whole heap of my code. And now when I see that, I always remember that comment. You're going, dude, that c coding, get to python. What's wrong with you? No, you didn't say that. But I was nicer than that. You were nicer than that. Actually going to dig it up after our podcast episode to see. So that link will not be in the show notes if anyone's looking for it. Just people can probably dig it up. But go to the blog. Go to the blog. Exactly. So speaking of which, we're going to close this off here. So thank you so much for listening. If you do want to see more about what we're doing, get to know Bob and myself a bit more. Meet our community, please. As we're going to say at the end of every episode, head to the link in the show notes, pibytes. And then it's pages community, I believe. Bob. Yeah, pibytes forward slash, pages slash community. And that will get you to our slack community where we have, you know, 2200 something developers all coding and talking Python together. It's, it's awesome. Fun. Yeah. So join and hit us up there and let us know if code reviews instill some fear or. Yeah, and send us a message. We'd love to know what your favorite code review's been, what you've learned, what your takeaways are, and your thoughts. So send us a message of Slack. We hope you enjoyed this episode. To hear more from us, go to pyrite friends, that's Pybit es friends and receive a free gift just for being a friend of the show. And to join our thriving slack community of Python programmers, go to PI Bytes community. That's Pibit es forward slash community. We hope to see you there and catch you in the next episode.