Criticism and Code Reviews: Building Better Developers, One Habit at a Time

Welcome to Building Better Developers, the Develop-a-Nor podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well hello and welcome back. We are continuing our season of Building Better Habits. Conveniently enough, we are Building Better Developers. We are Develop-a-Nor. I am Rob Brodhead, one of the co-founders of Develop-a-Nor and also founder of RB Consulting, where we go in and help you work with technology through simplification, automation, integration. We help you figure out what you have and then what is the best route to take that, leverage it and move forward. And it may even be things like, you know, maybe you don't have much technology, so we help you find the technology you need or build the team you need. But more importantly, however that mix is and everybody's is unique, just like every person is unique, every business has its uniqueness. So we get in there, we get to know what you're doing, what are all your special things that make you special, and then find the ways to use technology to emphasize that and improve that along the way. We are Building Better Habits. So one of the things we're doing is we have challenges each week. So I want to talk a little bit about the challenges before I get into the good, bad. And that is the one that I'm really charged about or whatever, that's really starting to work is the Pomodoro thing. We talked about just do one a day. And then I said, well, I've moved it to two a day. I may in a week or two ahead move it to three. And the nice thing I'm finding in this is that I'm limiting the Pomodoros that I do. Instead of trying to get as many in as possible, I'm being very focused. And it also helps me, it's a little bit along the lines of the make a list of your top three items or three to five items you're going to get done today. Because it really works well to pair effectively a Pomodoro with something I want to do. Because it's almost like a gimme. So if I do two Pomodoros, that's basically, essentially I want to make progress on item one and item two. And so those are two things that are right away going to be, or maybe it's the two Pomodoros are on one item, depending on what I'm working with. But it really is helping me hone in on what is it that I'm working on? What is it that I want to focus on? So I really like the Pomodoros. The automation was an interesting one is because I finally swung back around and took one of the most simplistic things you can do. And I highly recommend it if you're like me. I've got multiple servers that I've administered to some level. And one of the things I do every month is I go in, actually it's every other week, twice a month I go in and just check for updates, make sure that log files haven't blown up. I've got regular backups. I may clean up some of the older backup files and stuff like that. But the backup files in particular is one of those that I go through and I'll go just sort of basically compress or just gzip some files and delete some of the older ones. And I was like, I could probably make this a lot easier on myself if I just utilized, delete everything once it gets more than seven days old or something like that. And so on each of the servers, I just like I added a nice little cron tab job, a little cron job that like runs at 3am and just says blow away the stuff that's too old. So I don't have to worry about those specific files getting too big. And I was like, it doesn't, it probably saves me, I don't know, it may end up saving me 15 or 20 minutes, you know, twice a month. It's not a lot of time, but it's a nice little automation and it allows for situations where if I miss it for a month or something like that, then things don't back up. And in some cases, that's actually critical because there are some cases where we've got stuff, there's so much space that's involved with all of those backups. And if you start going, if you double your backups, you go from seven days, seven daily backups to 14 daily backups, that can be gigs of data in some of these cases. So it's a great little automation to do. So don't undersell even the simplest of automations as something that may help you out. Even if it's not saving you a ton of time, it may save you missing something and save you causing an error in the future. Good thing and bad thing. I guess the good thing I do want to talk about is like, the good thing is these challenges and actually embracing them. Even though what's probably some of you have done, that was the automation challenge to something from weeks ago. And I went through it and did it, but didn't really get into the automation. But because I didn't complete the challenge of take seven days and then find something that you're going to automate. I didn't do it, but then I came back around to it. And so that was a good thing is that it was, I stuck with it enough that even though it took me a while to get to the finish, better late than never. And it was something that was like, wow, that's like a, that's a win for me and a win for me in the future because I'm saving a little bit of time. Bad thing is it's sort of, this was one I was thinking was sort of a good and a bad. Bad thing is I guess I am busy, busy, busy, busy. I have got like, my schedule is full all the time. Now it's like, if you look at my calendar, you would see gaps. If you look at what I actually have on my to-do list and have to get done on a daily basis, I usually like start every day with three days worth of work on my list. And so it's just, but it's just like, it's that season. So, you know, there's, we have these times where it's like work sort of light and things not that bad. And you can, you know, you can take an extra long lunch or you can catch up on news or the world or whatever it happens to be. That's not the case for me right now. So I'm just like, you know, making sure that I keep enough caffeine and just keep charging along on it. Somebody who hopefully has had enough caffeine, because we're doing a morning start this time on the other side there, Michael, go ahead and introduce yourself. Hey everyone. My name is Michael Milosz. I'm also the founder of Envision QA, where we are your software development and quality assurance partner. We build tailored software to meet the unique needs of healthcare professionals and small to mid-size e-commerce businesses. You know, whether you're a healthcare provider or an e-commerce entrepreneur, partnering with Envision QA means unlocking your software's full potential. Experience the confidence of knowing your software meets the highest quality and compliance standards while driving success in your industry. Now, what does that mean? Well, it means we can do software audits. We can help you analyze what your software stack is doing and make sure it meets the needs of your business. If it doesn't, hey, we can help you build a custom solution. Switching gears. So before I get to my good and bad, briefly talk about some of the challenges I've been working on. So still working on the Pomodoro technique. I'm actually up to about three to four times a day working with that. Along with that, it has helped me kind of focus on some of the other challenges, like taking breaks. So I've gotten into a very bad habit of sitting down and the next thing I know is three, four hours later, I haven't moved from my desk at all, which has really been taking a toll on my body. I've been getting stiff. You know, we're not spring chickens anymore. So I do need to get up and start taking those breaks. So I've been trying to use the Pomodoro to force me to get into those habits of taking breaks. With that, I've also been focusing on the planning and scheduling, trying to ensure that when I block meetings, I give myself time so I can take those breaks and not have to be half focused and just kind of pace around or, you know, not really be able to focus on the meeting because my mind is somewhere else. Good thing, bad thing. Good thing I've been committed to my challenges. I've been getting things done. I've also been getting a lot of the year end stuff prep starting to get done. I've been able to work on my business more. So I'm feeling a little more comfortable that I'm going to end the year right this time instead of being scrambling at the end of the year, trying to make sure all my taxes and bookkeeping is done. Bad thing. Thanks to wonderful laws in that in this country, getting your checks deposited and cashed on time from the banks can become a challenge when checks are a little bigger than you normally expect. So wonderful bank has been holding on to my money a little longer than expected, which fortunately means I have to delay paying bills. So that's where I'm at for this week. All right. This time, this is going to be a fun one. So every take a deep breath, we're going to talk about criticism. We're going to talk about getting it and giving it. We're going to talk about in particular, one of the things that like that sparked this that I think will probably like right away trigger several of you is a code review. Now code reviews are very specific instances where honestly, if you don't go in there expecting criticism, then you don't understand what a code review is. It's just like if you go out and buy a house and you hire a house inspector and they come back and they say, it's great. It's awesome. They get your money back. It's like code review is the same thing. There should be some level of feedback that comes in a code review. If they, if the code review feedback is that is perfect code, they are lying or they didn't even look at your code because none of us write that. Now it could be something where they'll say, yes, it followed, you know, check followed all the check boxes and stuff like that. Or it could be that you wrote three lines of code and it's like, okay, yeah, that's not how hard could, how hard would it be? How impossible would it be to actually mess that up? But usually you're going to get something. You should get some question or some sort of feedback that is them trying to understand it is not an attack on you. And that I think is where a lot of us like we build this. These are our babies. These are things that come out of our mind. These are our creations, even if it's a very simple like for loop or something like that. And it includes things like naming our functions and our variables and how we write our comments and all these things are all, they come out of us. These are creations that we have created, that we have made. And so, yes, we, a lot of us, I think, get too personally tied to these things. And that makes it hard for somebody to critique, you know, your child and says, hey, you know, your child's not that very good looking. Well, it's like, you know, if you're like me, it's like, well, look what you got to, he didn't have much to work with. But you may also do something where it's like, you know, hey, I get to say that, but you don't or something like that. So this is where I think we can learn from our experience to also help others. When we go into a code review or also, this happens a lot in design meetings and requirements meetings, depending on what your level is as a developer and how, where you're at in the project that you're on, there's probably going to be some level of you giving your opinion on something. Now your opinion, because we're all developers, our opinions are always based on cold, hard facts, or maybe not. They are, we have a lot of religion in our world, whether we like this language better or that language better or this ID better or that ID better or things like that. And we have to, we really need to like check ourselves and step back and go, wait a minute, I am not perfect. This, all of you, that'll be your challenge for the week. I am not perfect. I think I may have come up with our challenge for the week right there. The whole point is that when we have a team is that everybody's got different experience. I'm blessed right now I'm with a team that's got a dozen people that I interact with in various ways on different days and they all have very different technical backgrounds, multiple different languages they've worked with, environments, lines of business, all this stuff. There's all of this feedback that comes into our group that comes from wildly different places. And it can be jarring at times because it can be like, somebody will say, this is how we always did it at this company. And you hear that and you go, how on earth did you survive as a company? Because I've never seen that. Now what you need to realize in these things is that there, when you say this is how our company always did it and this is how it worked and this is what I, you know, this is my experience, there's probably somebody else in that room saying, how on earth did your company survive? How are you still employed or something along those lines? Now it's not always that bad. I am over dramatizing this, but take it to that level. And then like, now, since it's not the end of the world, bring it back down to, hey, you know, part of how you wrote the code is that you, you know, you didn't put your open brackets on a new line instead of on the same line. And then it's just basically, those are kinds of things. It's like, oh yeah, that's right. That's the coding standards for our team. That's what we agreed upon is it's going to do this. Or it could be things like, hey, you know, you put a comment end on this and it just says, you know, the function add two numbers just adds two numbers. It's like, okay, well, you just repeated the comment. You really didn't give me anything useful about like, why the heck are we doing that? Or something like that. And you don't have to go write books on comments. I'm not going to tell you that. In particular, those kinds of things, when we're in a code review, when we're talking about designs and some of the stuff that we put together, realize that the whole point is communicating something, communicating your idea, the requirement, the design, the thoughts, the logic that the computer needs to utilize to go do the task. And other people will touch that code at some point. You got to let the baby out of the nest. You got to like, get them, let them get away. And so if they don't understand it, then that's going to be a challenge. They may miss on it. They may miss something or they miss may miss use something. And so the whole point of these things is for you to communicate. And if they aren't hearing, if they're asking questions, if they're poking holes in what you're doing, then it could be that you aren't perfect and that you have something that you missed, or it could also be that you have not, maybe, maybe your comments weren't clear enough. Maybe there's things that you, there's assumptions you made that you're not supposed to have made. And so the goal needs to be, instead of getting, you know, uppity about it and taking it personally, is take a step back, listen to what they're saying, and then try to explain to them. Now, the flip of this is when you are reviewing somebody's code and critiquing somebody else's stuff is one, you have to, you have to allow that maybe your critique is missing something. So if they're critiquing you, if you're critiquing somebody and they're like, well, you know, this is not, you know, they're trying, they're basically saying, well, yeah, you're critiquing this comment, but that comment, me, is tied to this other thing over here. And they're like, oh, okay, well, I need to go look at this overall thing. Or maybe, especially code reviews, it'll be like, there's these assumptions and you don't see them because it's inside of a bigger system. And so it's saying, well, I think you really need comments here and you need to explain this. Well, allow that maybe there's something that you missed that that is addressed elsewhere. And this is something actually very near and dear because Michael and I are working on a pile of content right now. And we've done this many times where I'll come in and look at it and say, well, you forgot to say this, or he'll come in and say, well, you forgot to say that. And then it'll be, oh, wait, no, it's covered in this other place. And then a lot of times the conversation becomes like, okay, how would I know that? If I see that, if I don't find it where I'm looking for it, how would I know that? How can I better do that? Which is where you and us become better developers because it really is about, for example, our users. So if somebody's, you know, QA comes in and says, I can't understand your user interface, then it may be that the user won't understand the user interface. So we need to be maybe more direct or we may need to change things or make things more smooth or more clear. So if you take this as a, just assume, and I know it's hard because we as developers can be very abrasive at times. We can be very much like, boom, this is it. This is the way it is. You're wrong. I'm right. We live in the world of absolutes way too often for what we do, but that is how we are. And so like take it with a grain of salt, realize that, yes, there are a few people that aren't, but most of us are pulling in the same direction. We are trying to make better software and make ourselves better. And so listen to that feedback. And then when you're giving it, give that feedback in the mind of I'm trying to help give my opinion to see if it can maybe make you better. Assuming that also with the knowledge, it may be that that point you're making may not make them better. It may be that there's something there that's like, yes, that would be faster way to do the code, but this is easier to read or something like that. It's just like, remember it is not black and white. Remember that we are all coming to this with different experiences. And the best way for us all to become better developers is to not only give, but also to receive criticism with the context around it. So we understand that's that word we use all the time, that three other word, the why. Why is it that this is being brought up so we can grow and become better developers? Now, Michael's over there going, why, why, why won't you just let's just stop and let me talk. And so now I'm going to do that. Go right ahead. Thanks for up. So you've covered pretty much the whole concept of the code review and the good and bad with kind of the concepts around doing the reviews, being the reviewer. I kind of want to give an example of why we're having this discussion today because in real life this happens so often and I see it almost tear down developers sometimes and it can cause a lot of frictions on your team. And typically what happens is usually on easy tickets or small code changes, it's not a problem because you're only looking at a few lines of code changes. And typically those usually are maybe, oh, you misspelled something or some, the critique is very minimal. But when it comes to those larger code changes where you've spent days or weeks trying to articulate a solution to the problem at hand, what happens is you have probably spent 30, 40, 50 hours. Chugging through figuring out how this code works, how this feature works. You've got it working and you're like, great, it's done. I've checked all the boxes on the ticket. Now I push it out there for the code review and suddenly I'm now being hammered by, oh, this is wrong. This is wrong. Change this. This happens. And the whole point of the code review is you're supposed to get that feedback. You want that feedback. But typically what happens is if you say, hey, my change is ready and you immediately start getting feedback, do not look at the comments. Walk away because you're in the mindset of this is done. There's nothing wrong with this. And you start getting that and then you start arguing. You start responding and then they respond back and you kind of get into this confrontational mode. Not always, but I've seen it more times than not that there's a lot of friction there. It's like, well, no, why are you questioning this? Why take a step back? Go back to our challenge of take a break. Once you say, hey, my code is ready for review, walk away. Maybe don't even look at that till the next day. Now, unfortunately, we are under software deadlines. Our code has to get released. Hopefully your code is not being pushed in on the last day of the spring. If that's happened, then you unfortunately are going to have to sit there and take the pill. You're going to have to take what comes. If you are at the end of a sprint, my recommendation is maybe throw open a chat window or open up a, you know, like a Slack screen share or a zoom call and say, hey, we're at the end of the sprint. Instead of us just going back and forth on confrontation, we're trying to figure out the code review. Let's do it as a team. Let's just go through and walk through the code. What's there and kind of flush this out real quick. Now, if you're early enough in the process, go through the normal channels, just push it up, walk away for a little bit, and then get the feedback and come in. One of the big things is your coworkers or even you are going to be reviewing code based on your company's current coding standards, what your team has committed to, what you want from your code base. The other thing people should be reviewing your code for is readability. Will I understand this change six months from now when I have not looked at the code and don't know what the hell it's supposed to do? A lot of times you'll get feedback where, yes, this feature works, but you've essentially added three, four or five layers into this one method that should be split out to three or four methods. And sometimes, you know, it makes sense to do, sometimes it doesn't. Typically, I like the rule of thumb is a method or a function should be one unit of code. It should perform one task. Now, if you have some options in there, like if this, if that, sure, okay, that might be in one place. You may not need to break that out into different functions, but code complexity is one of the biggest problems with code reviews because the person reviewing it has to assume that they're going to be looking at this or having to make a change to this in the future. And they need to understand what it is that's there so that they can unravel it, make the change and move forward. On the flip side of that, and I am because I'm a QA tester by heart, testing is another feature with code reviews that should be performed. If you have a piece of code, there should be a unit test to go with that change to test it. If you don't have that, you're probably going to get dinged on that and expect it. Because if you get to the end of your code review and you have written no unit tests, unfortunately, if you're in my software shop, I'm going to be digging you left and right on that. But it's going to be in a critique way where, hey, great, your code may look good, but where are the tests to go with this? How did you test this? And typically that's where some of the questions come from in the code review. And that can put you on edge because it's like, oh, now I have more work to do. So here's a tip before I give it back to Rob is before you say you are done, commit your code, walk away for a little bit or commit it, pick it back up the next morning, go through your code repository, look at all the code highlighted that you changed. Look at it. Just take a fresh eye on it and say, hey, is this too complex? Is the wording right? Do I have enough comments? Once you've done that and you think it's good, then do, hey, review my code. That will save you probably 90% of the feedback you're going to get. You may catch just with that fresh eye reviewing your code. I've done that more than once. And what I like is when I do that, I typically find that, oh, I missed a test or, oh, why do I have like this switch case that is so complex in this one method? This should be a separate function column. So those kinds of things will one, help improve your code to make it more easily readable for your coworkers. And three, it keeps the code maintainable. And hopefully at the end of the day, your blood pressure stays down. Rob? I think one of the keys there is the, and this is going to get into our challenge, is the accepting that it's not there. And it's how we accept criticism. Self-criticism, now we can be very hard on ourselves sometimes because I don't know how many times I've been like, oh my gosh, I can't believe you put a code in there. I can't believe you put a comma instead of a period there. Oh shoot, it's another typo or whatever it is. It can be hard on ourselves, but we take it better because we're like, because we know how good we are or whatever it is. And it's because we know our intent is to make it better. And so the idea of walking back through our code and looking at it with a critical eye, in particular, I think one of the key things there as Michael said is stepping away because we're going to get into solving this problem, writing this code, solving this problem. And there's this big, big golden chalice called done that we have when we are done with it. So we have gone through, we've solved our problem and now we got our big trophy that's like done. And it's really hard to put that trophy back down and say, wait a minute, I'm not going to take the trophy right now. I got to go back and work on this a little bit more. But doing so will help us make better code because it's going to be, now let's step away and we can still hold our little golden chalice, whatever we want to do with done, but look back into and say, okay, done, but not really done. Because I want to look back now and see if I can, how can I improve it? Because we almost always can in some way, form or fashion. So go with it at that idea of, yeah, that's good. It's complete. It is done. It does what it needs to do. But can I find some ways to do it better? Or are there things here that now when I've stepped away and come back that I realize, oh, that was really obvious to me when I was right in the middle of it. But now that I'm not, I need to change how I do that. I need to talk about that in some way or change some variable names or put some comments around it or split it out into a function. Because I don't know how many times, maybe it could be how I do it, but I don't know how many times I've gotten into writing a method and it's five or 10 lines. And the next thing I know is I'm working through all of the different variations of solving it. It's now 400 lines. And there's something where it's like, wait a minute, I can probably refactor that and clean that up. Now, sometimes I can't because sometimes it's just nasty problems. But a lot of times there's something in there, in particular, now that I've stepped back out, that I may see where I repeated the same section of code three times, that it's very obvious that I can make that a function. So the kinds of things that these are the things that make us better developers. It's not that we can sling code left and right because a lot of us can. It's that we can sling code left and right and then we can step back and take a look at that and find ways to do it better. That hints the better part of building better developers. And that's a challenge that I'm going to put to you this time. Every day for the next seven days, when you get to the end of the day, take some of the code that you've written or maybe all the code you've written and take, you know, we'll say limit it to 15 minutes, probably just five or 10 minutes, walking through your code. If you can have something where you've done a commit and you can see a nice, here's everything to change, like Michael said, that is the best way to do it. Look just at the code you've changed and just read back through it. And with the idea of when I do this, I want to change at least one thing. I want to make at least one improvement. It may be as simple as adding a period to the end of a sentence on a comment or something. But it's like, I am going to make some improvement to this code. You don't have to take a lot of time. Just five, 10 minutes would be perfect. Just get in the habit of doing that. Because I think when you do that for yourself all the time, it makes you more appreciative of the second or third or eighth set of eyes when you get into code reviews, where people are like, hey, you know, you missed this or did you consider this? Or hey, this isn't quite clear. Those kinds of things. It's like having a proofreader or an editor that you have in all these other areas of the world, all the writers and stuff like that. It's the same thing for our code. In a similar vein, but I will allow you a little bit of a break, send us an email at info at developer.com and let us know what your thoughts are. What are some of the things, what are some habits you've got? Some things that you would like to hear about? Maybe some recommendations for some habits to build? What's your experience with some of the habits we've had? Like I said, I'm going to be okay if there's typos, if there's grammatical errors. You don't have to put a second set of eyes on this one. We will just love that comment and that's all. Unless you want us to critique it and then we'll go send it out to Grammarly and let it tell you all the different ways that AI thinks you can write that better. And don't push it through AI. Just crank something out. If you can copy and paste it in AI and hit send and send it to us, we will be okay. We need to practice having our feelings hurt if that's what's going to happen. Help us grow to become better developers. Give us that feedback at info at developerneur.com. Leave us comments out on the podcast wherever you listen to podcasts out on YouTube at developerneur channel where there's this and so much other content out there. You can also contact us. We have a contact form on developerneur.com. Got a Facebook page. You can reach out to us there. Our contact information is in various places there. You can follow us on X at developerneur. However, you get us a feedback, we would love to hear it because we're here not only for us to become better developers and speakers, but for you to also become better developers. And so now I'm going to challenge you to go out there and do that. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the developerneur podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.