Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I'm going to be talking about three bad excuses that you make for not doing code review. Whiteboard has officially adopted a company wide stance on doing code reviews. We use the pool request system on GitHub which is fantastic by the way. If you haven't used the pool request system on GitHub I can recommend that explicitly. I think it's a very well done set of features that support pool requests and code review. In the short time that we've been requiring code review on our projects we've seen a uptick in our learning and our collaboration. We've seen all of the right markers for a healthy development team. For example, a circling around a problem and solving it together. This happens far more often. But so many people, including myself, have made excuses for why code review doesn't fit into their structure. We're going to talk about three of those excuses today. So quick I want to remind you about something I told you about in the last episode. Coming very soon we're going to be launching a weekly digest email. This is for soft skills weekly. This is going to be an email that has a list of resources around the internet. Things that have come up have been written or perhaps finds brand new finds that I'm going to be curating around the ideas of soft skills. So if you don't want to mess out on that head over to softskillsweekly.com and enter your email. And we will never spam you. We're only going to use those emails for soft skills weekly email updates. So head over to softskillsweekly.com and enter your email there. If you like the discussions we have on Developer Tea, then you're probably going to enjoy soft skills weekly. And I highly recommend that if you're wanting to level up in your career, this is probably one of the primary things that is underserved in the average developer's career. And that is soft skills. So I highly recommend that you go and sign up for this weekly digest. We're going to be sending out really great resources, things that I find throughout the week that I think are particularly compelling and things that other send to me that I will curate and evaluate that I find particularly compelling. So thank you to those of you who have already signed up for that. And I look forward to having more of you sign up as well. So we're talking about code review today. And specifically we're going to be talking about bad excuses, developers use to avoid code review. If you don't know what code review is, effectively you're going to have one person who is writing code. And then they're going to push it to some repository most likely or push it to a place where another developer can look at that code and then provide some level of recorded review in order to basically merge that code with the application, right, with the application's primary code base. Now typically you're going to use a tool like GitHub because it enables you to do a lot of these functions that otherwise you may have to do yourself. You may have to create a copy of your code base or something like that. And there's plenty of tools out there that allow you to do this. GitHub is free for public repositories and there's other options out there. Obviously. So the code review process has been shown to be really effective both anecdotally at whiteboard. We've seen the code review process be really effective there. Also in studies, it catches bugs, it improves the learning cycles that actually improves the reliability of your code in a similar way to testing. And it's going to improve the predictability of your code. It will likely improve the uniformity of your code, right. There's tons of things that code review improves. It gives you documentation of the changes over the life cycle of the application that you're building. And it also gives you the benefit of having someone who doesn't necessarily have the same blind spots that you have. So what are the excuses that people use for not doing something that has so many benefits, right? It seems a little bit crazy to see so many benefits and then avoid doing code review. But in fact, I have propagated the same excuses that I'm going to outline today. We're going to go over three excuses that developers use to avoid doing code review. We're going to do the first two, take a quick sponsor break and then we'll go over the third one. Number one, the very first excuse, we want to move fast and peer review just makes things go slowly. We want to move fast. Another version of this excuse, we want to be flexible and peer review puts up too much process in our way. It puts too many steps in our path in order to get to live, to push our features live. Now, I want to kind of walk you through why this is a bad excuse. And really, it comes down to language. It comes down to language and perhaps some bad assumptions. The first thing that we need to cover here is what does it mean exactly to move fast or perhaps more appropriately, the people who say that they want to move fast, is that the only thing on their minds? Because certainly speed is not a standalone value, right? Speed comes with cost. And what does it mean to move fast? Well, perhaps it means to write code quickly, perhaps it means to deploy features quickly or fix problems quickly. But if you're moving fast and you're also introducing new problems, then perhaps your speed is costing you more than it's helping you. And these are the kinds of questions that you have to ask yourself, what does it mean to move fast? Well, really what we need to do in our language is identify the difference between moving fast and being rushed. Moving fast means that you're moving at a speed that is maintainable. Moving fast means that your response time from inception of an idea to implementation of that idea is relatively rapid, right? That you're able to make decisions that you're agile, that you're able to change your mind, that you're able to move the application from one server to another, right? And none of these things are necessarily prohibited by code review. Is it going to cost you to do code review? I'm not going to propagate an illusion that code review is easy, nor am I going to say that it's fast on its own because code review does cost you something. But the question isn't about what code review costs you or the time that it takes, but rather what benefits do you gain out of code review? And can code review make you faster? Can code review actually increase the rate at which you release new features? Because it doesn't really help you if you're very fast at fixing bugs, if all you're creating is new bugs, because you're not going to be releasing new features. And I would say that most likely the people who want to move fast, they want to progress fast, not regress and then fix fast. You see the key difference there, right? If you're progressing quickly, then it's a new feature per day or new feature per week. And if a code review enables you to release five features and only introduce one bug, but no code review allows you to release more features, but it also introduces more bugs like six bugs. Well, now you have a problem, right? Because the following week or even this week, you're going to have to spend that extra time that you otherwise could be using to develop more features fixing bugs. Hopefully this is obvious. Once we have code review in place, we cut down significantly on our error margins. What's even more important is that once we have code review in place, our code is fundamentally going to be better. It's going to be refactored by the reviewer or it's going to be refactored as a result of the review. And so we're constantly going back and instead of getting the most simple solution in place and forgetting all of the hacks that we're putting in there, we have a reviewer come in and identify those hacks and clean them out before they ever have a chance to be the source of a new bug. So I want you to understand something. Moving fast or moving at a rapid pace doesn't mean having direct access to the live server. Moving fast means developing features in a solid and maintainable way at a rapid pace. Now, if you don't have solid and maintainable, you're just introducing more variability and more risk. Now, if you are willing to accept the variability and the risk and constantly be in a situation where you're not really sure how many bugs this next deployment is going to have in it, you're just going to kind of deploy and hope for the best. Well, that is a decision that you can make, but certainly not one I would recommend going with. If you choose to follow these practices code review and test coverage, these are things that are common practices, but we're talking about code review today. If you choose to follow the practices of code review, you're going to see an increase in quality in your code period. You're going to see an increase in quality in your code and you're going to see a lower risk. On top of all this, let's imagine for a second that you have a sole developer, a solo developer working on a project. And you don't have code review in place, but that solo developer is shipping features all the time. They may even be a very good developer. You depend on them to ship features and maybe they even have good test coverage in place, but they're the only one who's involved on the project. If that developer quits or if that developer gets sick for a week, well suddenly your development capacity has gone to zero. You went from 100% to zero in the course of one day. And the problem with this is let's say a brand new bug services the moment that that developer gets sick. Well, now you have no one who is involved with that project and it's going to be significantly harder to respond to those problems much less move forward any new features. Now if you had practiced code review, if you had practiced splitting the load of understanding some of the code base of a particular project amongst multiple developers, and I'm telling you this story, by the way, because this exact thing happened to me. I got sick a couple of weeks ago with a virus, a stomach bug, and I was completely wiped out for a week. I couldn't really work at all during that week. And the good thing was we did have code review in place. We did have other developers who have awareness of the code base that I was working on for that week or that I was slated to work on for that week. And we ended up accomplishing basically the same amount that we had planned to accomplish had I been working full time. Now some of that can be attributed to the hard work and the dedication of the members of the team who stepped up to the plate to kind of relieve the tension for the client when I was out. There's a little bit of grit that goes into that. But a large portion of this has to be credited to this process of code review. So we want to move fast. We don't want the process to limit our flexibility. In fact, the process is going to empower your flexibility. You have to understand the language differences and not just the one feature that you want to ship this very second that you've tested and you know is bug free. But the features moving forward into the future, the long schedule of your application. You have to look at it from that perspective. And once you understand that you want to reduce risk and you want to increase the quality of your code code review. Can't that can't be a good excuse for not doing code review. So that's reason number one. We went a little bit longer with reason number one. So I'm going to go ahead and jump over to today's sponsor, Flatiron School. Now I'm going to skip their the read details that they sent me and instead just talk to you kind of from from my own understanding of this industry. Okay. Flatiron School is providing you a guarantee of a job in this industry as long as you do your part. This is such an important thing to understand. If you're going to go to a coding boot camp and especially if you're going for the purpose of getting a job, right. This is going to be a good bet because if you don't get a job within 180 days after you finish schooling at Flatiron, then you get all your money back. Right. There's very little risk involved other than the time you spend learning how to code. And that part you're still going to get to keep. It's not like they can take that knowledge back away from you or that experience back away from you. Right. So this is a really good bet Flatiron School as long as you complete their New York or their online program and then you're actively seeking a job for the next 180 days, which hopefully hopefully you're going to do your part there. Then Flatiron School guarantees you're going to get a job. Now they place you in jobs of all types, apprenticeships, internships, entry level jobs of all types that they place you in. And the salaries are competitive. $74,000 dollars and more. But if your goal is to get your foot into this industry, if your goal is to get a job to get hired as a developer in Flatiron School, they guarantee that as a part of your tuition. That's such an important thing to understand. And I think it's a fantastic product offering. On top of that, by the way, if you're not ready to go to a bootcamp, if you are just now starting out, then Flatiron actually has some free resources. In fact, it's over 60 hours worth of content of free resources that you can find right now by going to spec.fm slash flatiron. That's spec.fm slash flat.ioin. And what this is, it's their bootcamp prep. It's a free, it's flatiron bootcamp prep. And what it is is free content to get you ready. It's really rigorous content and that you're going to have to put in a lot of energy, right? That's why they call it a bootcamp. And it's a good challenge for you if you want to get into this industry. It's not easy. This industry is not easy, right? Don't look at it with rose colored glasses. This is a challenge. This is something that you have to accomplish. Flatiron school is going to help you accomplish it. Go and check it out. Spec.fm slash flatiron. And by the way, if you go through that bootcamp prep, they're going to give you $500 off your first month's tuition. That's $500 with a value just for doing your homework, right? So go and check it out. Spec.fm slash flatiron. Thank you again to flatiron school for sponsoring today's episode of Developer Tea. So we've talked about the first bad excuse for not doing code review. I don't know if you know this by now, but I really think you should be doing code review. It's so important to propagate this message to all the developers in your company. And as a leader, as someone who is responsible for the pacing and the productivity of our team of developers, a whiteboard, I highly recommend this because I see it increasing our pacing, increasing our productivity. And by the way, making us saner individuals, mentally speaking. But the second excuse that I want to talk about today is quite somebody there's no need for us to do review because we only have two or three developers, right? There's we're all in the same room. We look over each other's shoulders all the time. I ask for help. We sit right next to each other so we don't really need this weird online review thing when we're sitting in the same room. And the reality is code review isn't only meant for large companies and enterprise projects. Okay. Code review can be executed in a team as small as two people, the original coder and the reviewer. If the excuse is that you don't really need a formalized process, there's two very important things that make a formalized process worth your efforts. Okay. Two very important things. Number one, you won't stick to doing the review uniformly unless you know what the standards are unless you have a commonly accepted way of doing that review. Right? It's very difficult to stick to something that you don't have formalized because the details of how you do code review, remembering those or having everybody remember the same thing. It's very difficult to do. So it's unlikely that you're going to stick to it at any uniform way. The second thing is documenting your reviews. If you don't have a process documentation of your reviews, we'll be lost. Right? You're sitting in the same room and saying, Hey, I think you should do it this way. Well, capturing that moment, capturing that learning moment. That's lost forever if you're just doing it verbally. If you've ever read through a commit history on a project that doesn't run on regular code reviews, then you'll probably run across a string of commit messages that show very similar changes in one or two files. And sometimes they have identical commit messages. I'm very guilty of this. And many times I would commit and then commit and use the up key on my keyboard to go to the previous commit message and just press enter because it was the fastest way to get something done. I thought, but the reality was when I was doing that, there was something that was being worked on, something that was being iterated on. And I was learning in that process. There's nothing wrong with that iterative process. What's wrong is when you don't take that learning and document it because you're not going to actually hold on to that same information forever. Right? How many times have you Googled the same things over and over? Well, if you don't have a Google resource handy, then documentation should be found in your code reviews. So documentation of your code reviews allows you to see the evolving nature of your code and learn from it. Finally, excuse number three, we are already doing pair programming. This is such a common excuse as to why you wouldn't you wouldn't also have a review. We're already doing pair programming. So reviews aren't really necessary. We already have two sets of eyes on the code. Well, pair programming is definitely helpful in terms of being accountable and writing code that's free of bad hacks that are kind of shameful pieces of code that we don't really want to show anyone. With a pair programmer, you don't really write that shameful code. Part of the reason code reviews are so important, even still, is because the process of reviewing is a totally different way of using your brain than the process of making new solutions. The creative process is very different from the critical process, right? The criticizing process. In other words, while you are scrutinizing someone else's code, you have a few benefits that come from your fresh perspective. For example, you are seeing the code directly. This means that you're effectively coming from an unbiased position. You don't have some level of connection to that code as the creator of it, which is very common. You don't have the issue of seeing the evolution of that code. We talked about the Einstein Lung effect in a recent episode. If you had seen the evolution of that code, then you may be locked into thinking that that solution is the correct one. It's much different when you come to this code from a fresh perspective. This means you'll be looking at an existing solution in order to make it better, rather than making a new solution where there is none. Based on quite a few fundamental psychological principles, the concept of fresh eyes makes a code review an entirely different process from pair programming. It still retains the other benefits that we've already discussed, like, for example, documentation and having a good paper trail, so to speak, of the etymology of your app. Saying pair programming is a good excuse for not doing code review is just not a good excuse. It's simply not a good excuse because pair programming and code review are fundamentally different things. I hope this episode has inspired you to reject some of the poor excuses for not doing code review. I'd love to hear your other excuses that you feel are actually more appropriate for not doing code review. There are plenty of people who still are not doing code review. I know this because I was one of them until not very long ago, and I was convinced by so many things that have led me to believe that code review is a fundamentally important process for sustainable development of applications. I hope that this has inspired you to consider doing code review in your own projects and share this message with other people who value that speed and who value a stable platform, for example. Thank you so much for listening to today's episode. Thank you again to today's sponsor Flatiron School. If you want to go through a boot camp, it's not going to be easy, but if you want to go through a boot camp and get $500 off your first month's tuition, by the way, spec.fm slash Flatiron. This is going to take you to those boot camp resources. If you go through this boot camp and you do your part and you look for a job actively for 180 days, Flatiron guarantees you will get a job. They'll give you your money back if you don't. Go and check it out, spec.fm slash Flatiron. Thank you so much for listening to today's episode. Don't forget we've launched SoftSkillsWeakly.com and we'll be sending out the first issue of SoftSkills Weekly very soon. I don't want you to miss out on it. Go and check it out. SoftSkillsWeakly.com. All it is is an email form. Enter the email that you check the most on that form and click Submit. Thank you so much for listening to today's episode of Developer Tea and until next time, enjoy your tea and go and do some code reviews.