Detailed Notes
The latest episode of Building Better Developers, Season 23’s “Building Better Habits” series, dives into one of the most sensitive yet vital aspects of personal and team growth: giving and receiving criticism. Rob Broadhead and Michael Meloche explore how developers can better approach feedback loops in professional settings, mainly focusing on code reviews—a microcosm for the challenges and rewards of constructive criticism.
*A Challenge for the Week* Rob and Michael leave listeners with a practical challenge: for the next seven days, review your own code at the end of each day. Please spend a few minutes identifying one thing you can improve, whether it’s cleaning up logic, simplifying comments, or reorganizing a function. This habit enhances your skills and prepares you to give and receive feedback more effectively.
*Stay Connected: Join the Developreneur Community* We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Read More... https://develpreneur.com/criticism-and-code-reviews-building-better-developers-one-habit-at-a-time
*Additional Resources* * Turning Feedback into Future Success: A Guide for Developers (https://develpreneur.com/turning-feedback-into-future-success-a-guide-for-developers/) * Code Reviews – Build Habits And Best Practices (https://develpreneur.com/code-reviews-build-habits-and-best-practices/) * Embrace Feedback for Better Teams (https://develpreneur.com/embrace-feedback-for-better-teams/) * Breaking Things Down for Success: How Developers Can Build Better Habits (https://develpreneur.com/breaking-things-down-for-success-how-developers-can-build-better-habits/)
*Follow-us on:* * https://develpreneur.com/ * https://www.youtube.com/channel/UCZOuFN_LhczvGyT2KSItH_g/featured * https://facebook.com/Develpreneur * https://twitter.com/develpreneur * http://linkedin.com/develpreneur
Transcript Text
[Music] we we are live or whatever it is not live we are recording at [Laughter] least all right I was thinking this time um something we mentioned I can't remember what your initial suggestion was um but I took note as basically like taking criticism it's like how to like work with criticism within your your work world as a developer and how to get a little better I got to figure out I've got if we do that I have from basically now until get towards the end of the episode to figure out what the challenge is going to be related to that um I have to figure out a good way to do that but I think that's a good little area for building better I think that's one of the things we have to do is we have to live in that world of give and take and talk about our ideas in a way that they can be improved um and also it's actually I guess it's also to me it's a little bit giving it as well is like you where to like how to do it and things like that constructive criticism giving and taking I think potentially would be a good granted it's a bit we could probably write books on it but it's one of those it's like that at least means we should be able to try to light over here see if I get a little better um maybe yeah we'll try that oops get my mic out of the way a little bit there um yeah because this came from the discussion we had about like code reviews because like when you're giving criticism on a code you oh you know you need to make this change or maybe you could do this better almost 90% of the time the person receiving that gets defensive yeah I think that is it I think that was where you started it with was the code reviews and that's uh that's a good idea as well bring that that's a good example of it um and maybe that's the challenge will be like get your code reviewed every day for seven days and see what happens um but yeah that's what I say we do that for this first episode does that sound that make sense yeah I like that one well cool then then I'm going to just Dive Right In and do the little three two one well hello and welcome back we are continuing our season of building better habits conveniently enough we are building better developers we are develop andur I am Rob Broadhead one of the co-founders of develop andur 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 uh the one that I'm really I charged about or whatever that's really starting to work is the Pomodoro thing is we talked about just do one a day and then I said well I've I've moved it to two a day I may in the week or two ahead move it to three and the nice thing finding in this is that I'm limiting the pomodoros that I do I bu instead of trying to get like 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 it's almost like a gimme so if I do two pomodoros that's basically you know 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 like you know hone in home in on like what is it that I'm working on what is it that I want to focus on so I'm really like the pomodoros uh 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 I've got multiple servers that I I administer 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 like check for updates make sure that log files haven't blown up um you do like I've got regular backups so 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 you know basically compress or you know gzip some files and delete some of the older on and I was like you know what I could probably make this a lot easier on myself if I just utilized delete everything once it gets more than 7 days old or something like that and so on each of the servers I just I like I added a nice little KRON tab job little Cron job that like runs at 3: a.m it just says blow away the the stuff that's too old so I don't have to worry about those specific files getting too big and it's 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 you know a month or something like that then thing doesn't things don't back up now 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 you know 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 don't unell even the simplest of automations is 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 like talk about is like the good thing is is these challenges and actually embracing them even though uh which probably some Of You' have done that was a the automation challenge is something from you know weeks ago and I went through it and 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 to 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 uh bad thing is um it's sort of this was one I was think sort of a good and a bad bad thing is I gu 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'm 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 Works 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 of 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 M and with the co-founders of developing herb building better developers 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 midsize 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 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 uh briefly talk about some of the challenges I've been working on so still working on the Pomodoro Technique I finally got the pronunciation of that correct after saying it enough times I guess uh been I'm actually up to about three to four times a day working with that uh along with that it has helped me kind to focus on some of the other challenges like uh taking breaks so I've gotten into a very bad habit of sitting down and the next thing I know is 3 4 hours later I haven't moved from my desk at all which is really been taking a toll my body I've been getting stiff you know we're not springing 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 uh is somewhere else uh good thing bad thing uh good thing uh 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 at my business more so I'm 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 uh bad thing uh thanks to wonderful laws in that in this country getting your checks deposited and cashed on time from the uh Banks can become a challenge when checks are a little bigger than you normally expect so wonderful uh 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 everybody take a deep 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 H hire a house inspector and they come back and they say it's great it's awesome they need get your money back it's a code review is same thing there should be some level that of 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 follow you check followed all the checkboxes and stuff like that or it could be that you wrote three lines of code and it's like okay yeah it's not how hard could how how hard would it be how impossible would be to actually mess that up but usually you're gonna 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 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 cre 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 goodlook 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 your level is as a 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 COD old 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 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 maybe that I I think I may have come up with our challenge for the week we're right there um 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 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 and so 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 is how we always did it at this company and you hear that and you go how in 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'm I am over drama izing 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 um you know part of how you wrote the code is that you you know you didn't put your 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 um 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 you or something like that and you don't have to go write books on comments I'm not going to tell you that but in particular those kinds of things when we're in a code review when we're talking about designs and and some of this stuff that we've put together realize that the whole point is communicating something communic ating your idea the requirement the design the thoughts the 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 they may miss something or they miss May misuse 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 there assumptions you made that you're not supposed not supposed to have made and so the goal needs to be instead of getting you know up 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 you're critiquing this comment but that comment means is tied to this other thing over here and they're like oh okay well I need to go look at this over 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 things where it's like 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 or 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 you know if I if 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 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 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 it's we 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 the grin it's not really is it 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 the knowledge that maybe 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 easy 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 uh the context around it so we understand that's that word we use all the time that three L 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 just stop and let me talk and so now I'm going to do that go right ahead thanks Rob 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 review e 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 hand by oh this is wrong this is wrong oh change this oh oh oh oh 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're you start getting that and then you start arguing you start responding and then they they respond back and you kind of get into this confrontational mode not always but I've seen it more times than not that you there's a lot of friction there it's like well no why are you questioning this why take a step back you know 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 Sprint if that's happened then you unfortunately are going to have to sit there and take the pill you know you're going to have to take what comes if you are at the end of a a Sprint my recommendation is maybe throw open a chat window or open up uh you know like a slack uh 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 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 co-workers or even you are going to be reviewing code based on your company's com uh 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 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 you know unravel it make the change and you know move forward on the flip side of that and I 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 dinging 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 at 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 call so those kind of things will one help improve your code two make it more easily uh readable for your co-workers and three it keeps the code maintainable and hopefully at the end of the day your blood pressure stays down Rob I want to I think the 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 uh 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 comma instead of a period there or 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 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're done with it so we have gone through we've solved our problem and now we got our big little 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 do have 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's it could be how I do it but I don't know how many times I've gotten into a a 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 times 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 could 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 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 codes you've written and take you know we'll say limited to 15 minutes probably just five or 10 minutes walking through your code like if you can have something where you've done a commit and you can see a nice you here's everything that changed 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 just 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 third or eighth set of eyes when you get into code reviews where it's 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 always like it's like having a a proof reader or an editor that you have at all these other world you know 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 is send us an email at info 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 uh maybe some recommendations for some habits to build what's your what's your experience with some of the habits we've had and like I said I'm 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 the AI thinks you can write that better uh and don't don't push it through AI just like crank something out if you can copy and Bas 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 so just like help us grow to become better developers give us that feedback at info developer.com lead us comments out on the podcast wherever you wherever you listen to podcast out on YouTube at development develop andur Channel where there's this and so much other content out there you can also contact us we have a contact form on developer.com got a Facebook page you can reach out to us there our contact information is in various places there uh you can follow us on X develop Andor however you get us a feedback we would love to hear it because we're here not only for us to become better 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 bonus material so one thing I'd like to add to the discussion we had is as you're doing the code review be careful with your comments make sure that when you give the critique that you're staying within the focus of the ticket one of the biggest things I find with code reviews is sometimes you get into scope pre and if you start get going down that rabbit hole it may be time to create a new ticket in the backlog to make a future change make sure that what you're doing is within the focus of the ticket and the change that's being requested because you don't want to start adding features or new functionality to something that the customer is not going to know about based on the current change I would agree I think that's I think that's my my bonus as well is uh scope creep is but it's also it's um reality check is there there's times that we go in particularly if you're dealing with uh production code or you know enhancements to stuff that's been built over a long period of time and things like that there probably is some technical debt involved and there's a time and a place so it may be like Michael said it may be something you're like hey this could be done better or hey this doesn't comply with our current standards but it may be that this is not it's really fixing that is not within the scope of this it's like we're fixing a specific bug we're not re you know we're not refactoring this thing and so understand that there may be situations and and where your comments are 100% valid but completely rejected because that doesn't fit the scope we can't do that right now so in those cases is you know be understanding that oh okay that makes sense where're you're just fixing this thing but then f as Michael said maybe it's another bug you know it's another ticket you have to create or another bug or another piece of technical debt or something like that or it may just be as little as you need to add this piece of code to the long list of items that need to be fixed for whatever per you know whatever the new standard is and I see this a lot like I said I I've been through a lot of applications and work with a lot of companies where they said well this is how we used to do it and we have all this code and it does it this bad way and now we're trying to do it this good way and we're changing the new stuff but the old stuff's still there and so it's finding out time when do you have the availability and the option to actually fix that the the core Thing versus I just need to do a a quick fix and get it into production and move forward ideally we never do the just like slap it you know slap a Band-Aid on it move forward but we all know that we do not live in an Ideal World and there are those situations where we just have to like grin and Barrett and say yep that's another one of those it's frustrating it's annoying but somewhere down the line we're going to get to it that will wrap this one up and we will be back we are nowhere close to the end of this season so thank you again for for listening feedback is is always welcome thumbs up thumbs down however you do it comments in particular any kind of like really content that we can work with is hugely helpful to us and I think helpful to you because then we're going to be able to either anonymously you know say hey somebody told us this or we can give you all full credit for it as well and say you know Bob from bosanova whatever the heck that is said this and we can throw that into a a future episode because we want to just keep making sure that we're giving stuff that is useful to you go out there be useful to those around you have a great day and we will talk to you next time [Music]
Transcript Segments
[Music]
we we are live or whatever it is not
live we are recording at
[Laughter]
least all right I was thinking this time
um something we mentioned I can't
remember what your
initial suggestion
was um but I took note as basically like
taking criticism it's like how to like
work with criticism within your your
work world as a developer and how to get
a little better I got to figure out I've
got if we do that I have from basically
now until get towards the end of the
episode to figure out what the challenge
is going to be related to
that um I have to figure out a good way
to do that but I think that's a good
little area for building better I think
that's one of the things we have to do
is we have to live in that world of give
and take and talk
about our ideas in a way that they can
be improved um and also it's actually I
guess it's also to me it's a little bit
giving it as well is like you where to
like how to do it and things like that
constructive criticism giving and taking
I think potentially would be a good
granted it's a bit we could probably
write books on it but it's one of those
it's like that at least means we should
be able to try to light over here see if
I get a little better um maybe yeah
we'll try that oops get my mic out of
the way a little bit there
um yeah because this came from the
discussion we had about like code
reviews
because like when you're giving
criticism on a code you oh you know you
need to make this change or maybe you
could do this better almost 90% of the
time the person receiving that gets
defensive yeah I think that is it I
think that was where you started it with
was the code
reviews and that's uh that's a good idea
as well bring that that's a good example
of it um and maybe that's the challenge
will be like get your code reviewed
every day for seven days and see what
happens
um but yeah that's what I say we do that
for this first episode does that sound
that make sense yeah I like that one
well cool then then I'm going to just
Dive Right In and do the little three
two one well hello and welcome back we
are continuing our season of building
better habits conveniently enough we are
building better developers we are
develop andur I am Rob Broadhead one of
the co-founders of develop andur 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 uh the
one that I'm
really I charged about or whatever
that's really starting to work is the
Pomodoro thing is we talked about just
do one a day and then I said well I've
I've moved it to two a day I may in the
week or two ahead move it to three and
the nice thing finding in this is that
I'm limiting the pomodoros that I do I
bu instead of trying to get like 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 it's almost like a
gimme so if I do two pomodoros that's
basically you know 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 like you know hone in home
in on like what is it that I'm working
on what is it that I want to focus on so
I'm really like the pomodoros uh 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
I've got multiple servers that I I
administer 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 like check for
updates make sure that log files haven't
blown up um you do like I've got regular
backups so 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 you know basically compress or
you know gzip some files and delete some
of the older on
and I was like you know what I could
probably make this a lot easier on
myself if I just
utilized delete everything once it gets
more than 7 days old or something like
that and so on each of the servers I
just I like I added a nice little KRON
tab job little Cron job that like runs
at 3: a.m it just says blow away the the
stuff that's too old so I don't have to
worry about those specific files getting
too big and it's 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 you know a month or
something like that then thing doesn't
things don't back up now 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 you know 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 don't unell even the
simplest of automations is 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 like talk about is like the good
thing is is these challenges and
actually embracing them even though uh
which probably some Of You' have done
that was a the automation challenge is
something from you know weeks ago
and I went through it and 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 to 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 uh bad thing is um it's sort of
this was one I was think sort of a good
and a bad bad thing is I gu 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'm 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 Works 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 of 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 M and with
the co-founders of developing herb
building better developers 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
midsize 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 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 uh briefly talk about
some of the challenges I've been working
on so still working on the Pomodoro
Technique I finally got the
pronunciation of that correct after
saying it enough times I guess uh been
I'm actually up to about three to four
times a day working with that uh along
with that it has helped me kind to focus
on some of the other challenges like uh
taking breaks so I've gotten into a very
bad habit of sitting down and the next
thing I know is 3 4 hours later I
haven't moved from my desk at
all which is really been taking a toll
my body I've been getting stiff you know
we're not springing 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 uh is somewhere else uh good thing
bad thing uh good thing uh 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 at my business more so I'm 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 uh bad
thing uh thanks to wonderful laws in
that in this country getting your checks
deposited and cashed on time from the uh
Banks can become a challenge when checks
are a little bigger than you normally
expect so wonderful uh 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
everybody take a deep 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 H hire a house inspector and
they come back and they say it's great
it's
awesome they need get your money back
it's a code review is same thing there
should be some level that of 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
follow you check followed all the
checkboxes and stuff like that or it
could be that you wrote three lines of
code and it's like okay yeah it's not
how hard could how how hard would it be
how impossible would be to actually mess
that up but usually you're gonna 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 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 cre 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 goodlook 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 your
level is as a 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 COD old 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 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
maybe that I I think I may have come up
with our challenge for the week we're
right there um 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 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 and so
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 is how we always did it
at this company and you hear that and
you go how in 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'm I am
over drama izing 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 um you know part of how you
wrote the code is that you you know you
didn't put your 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 um 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 you or
something like that and you don't have
to go write books on comments I'm not
going to tell you that
but in particular those kinds of things
when we're in a code review when we're
talking about designs and and some of
this stuff that we've put together
realize that the whole point is
communicating something communic ating
your idea the requirement the design the
thoughts the 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 they may miss
something or they miss May misuse
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 there
assumptions you made that you're not
supposed not supposed to have made and
so the goal needs to be instead of
getting you know up 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 you're
critiquing this comment but that comment
means is tied to this other thing over
here and they're like oh okay well I
need to go look at this over 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 things where
it's like 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
or 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 you know if I if 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 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
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 it's we 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 the grin it's not really is
it 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 the knowledge that maybe 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 easy 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 uh the context around it so we
understand that's that word we use all
the time that three L 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 just stop and let
me talk and so now I'm going to do that
go right
ahead thanks
Rob 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
review e
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 hand
by oh this is wrong this is wrong oh
change this oh oh oh
oh 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're you start getting that and then
you start arguing you start responding
and then they they respond back and you
kind of get into this confrontational
mode not always but I've seen it more
times than not that you there's a lot of
friction there it's like well no why are
you questioning this why take a step
back you know 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 Sprint if that's happened then
you unfortunately are going to have to
sit there and take the pill you know
you're going to have to take what comes
if you are at the end of a a Sprint my
recommendation is maybe throw open a
chat window or open up uh you know like
a slack uh 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 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 co-workers or even
you are going to be reviewing code based
on your company's com uh 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 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 you
know unravel it make the change and you
know move
forward on the flip side of that and I 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 dinging
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 at 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
call so those kind of things will one
help improve your code two make it more
easily uh readable for your co-workers
and three it keeps the code
maintainable and hopefully at the end of
the day your blood pressure stays down
Rob I want to I think the 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 uh 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 comma instead of a
period there or 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 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're done with it so
we have gone through we've solved our
problem and now we got our big little
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 do have 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's it could be how I do it
but I don't know how many times I've
gotten into a a 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 times 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 could 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 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 codes you've
written and take you know we'll say
limited to 15 minutes probably just five
or 10 minutes walking through your code
like if you can have something where
you've done a commit and you can see a
nice you here's everything that changed
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 just
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
third or eighth set of eyes when you get
into code reviews where it's 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
always like it's like having a a proof
reader or an editor that you have at all
these other world you know 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 is send us
an email at info 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 uh maybe some
recommendations for some habits to build
what's your what's your experience with
some of the habits we've had and like I
said I'm 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 the AI thinks you
can write that better uh and don't don't
push it through AI just like crank
something out if you can copy and Bas 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 so just like help us grow to
become better developers give us that
feedback at info developer.com lead us
comments out on the podcast wherever you
wherever you listen to podcast out on
YouTube at development develop andur
Channel where there's this and so much
other content out there you can also
contact us we have a contact form on
developer.com got a Facebook page you
can reach out to us there our contact
information is in various places there
uh you can follow us on X develop
Andor however you get us a feedback we
would love to hear it because we're here
not only for us to become better 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 bonus
material so one thing I'd like to add to
the discussion we had is as you're doing
the code review be careful with your
comments make sure that when you give
the critique that you're staying within
the focus of the ticket one of the
biggest things I find with code reviews
is sometimes you get into scope
pre and if you start get going down that
rabbit hole it may be time to create a
new ticket in the backlog to make a
future change make sure that what you're
doing is within the focus of the ticket
and the change that's being requested
because you don't want to start adding
features or new functionality to
something that the customer is not going
to know about based on the current
change I would agree I think that's I
think that's my my bonus as well is uh
scope creep is but it's also it's
um reality check is there there's times
that we go in particularly if you're
dealing with uh production code or you
know enhancements to stuff that's been
built over a long period of time and
things like that there probably is some
technical debt involved and there's a
time and a place so it may be like
Michael said it may be something you're
like hey this could be done better or
hey this doesn't comply with our current
standards but it may be that this is not
it's really fixing that is not within
the scope of this it's like we're fixing
a specific bug we're not re you know
we're not refactoring this thing and so
understand that there may be situations
and and where your comments are 100%
valid but completely rejected because
that doesn't fit the scope we can't do
that right now so in those cases is you
know be understanding that oh okay that
makes sense where're you're just fixing
this thing but then f as Michael said
maybe it's another bug you know it's
another ticket you have to create or
another bug or another piece of
technical debt or something like that or
it may just be as little as you need to
add this piece of code to the long list
of items that need to be fixed for
whatever per you know whatever the new
standard is and I see this a lot like I
said I I've been through a lot of
applications and work with a lot of
companies where they said well this is
how we used to do it and we have all
this code and it does it this bad way
and now we're trying to do it this good
way and we're changing the new stuff but
the old stuff's still there and so it's
finding out time when do you have the
availability and the option to actually
fix that the the core Thing versus I
just need to do a a quick fix and get it
into production and move forward ideally
we never do the just like slap it you
know slap a Band-Aid on it move forward
but we all know that we do not live in
an Ideal World and there are those
situations where we just have to like
grin and Barrett and say yep that's
another one of those it's frustrating
it's annoying but somewhere down the
line we're going to get to it that will
wrap this one up and we will be back we
are nowhere close to the end of this
season so thank you again for for
listening feedback is is always welcome
thumbs up thumbs down however you do it
comments in particular any kind of like
really content that we can work with is
hugely helpful to us and I think helpful
to you because then we're going to be
able to either anonymously you know say
hey somebody told us this or we can give
you all full credit for it as well and
say you know Bob from bosanova whatever
the heck that is said this and we can
throw that into a a future episode
because we want to just keep making sure
that we're giving stuff that is useful
to you go out there be useful to those
around you have a great day and we will
talk to you next time
[Music]