Level Up Your Development Workflow: Declutter with AI for Better Focus and Cleaner Code

Welcome to Building Better Developers, the Developer 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. We are Building Better Developers. We are the Developer podcast. We welcome you as we now have AI like everybody else in the world. We're going through, not like everybody else in the world, we're going to go through a couple of seasons back and we are taking those prior topics, shoving it into AI and discussing what comes out. So far it's been really interesting. There have been some new things. There's also been some things that are the drum beats that we steadily are sharing with you guys. So I think that also some validation of some of the areas that we hit on and some of our topics. Before we get into it, I need to introduce myself. My name is Rob Brodhead, one of the founders of Developer Noir. Also the founder of RB Consulting, where we help you clean up your digital mess. And even if it's not a digital mess, we help you plan how best to leverage technology. We sit down with you. We walk through what are your business plans? Where are you at? Where do you want to go? And then we utilize our decades of experience in technology and help you craft a roadmap forward so that you're going to be in good shape today in six months, even six years from now, hopefully. Because technology does change pretty quickly. We do that through simplification, integration, automation, even innovation. If you need some game changer built, we will work with you on that. Check us out at rb-sns.com and you can see some of our past projects and things like that. We also have new surprises coming in the future as we are revamping our site currently. It's not really awesome, but as we're going through this work, we've got some freebies and other stuff that may be very useful for those of you on your entrepreneurial side. Bad thing, bad thing. Bad thing is I was out of town traveling, being the road warrior, remote nomad, digital nomad that I can sometimes be. And so I was going to go grab lunch the other day. And I went out to grab lunch and I've got one of those like no key, but just like push button starts on the car and the car did not stop. Did not start actually even. Didn't stop, but it also did not start. It turns out that it was the starter was broken. The bad thing is that when they a week before had been replacing pretty much the entire transmission, they also decided to somehow crack the starter, caused us lots of problems. Hilarity did not ensue. The good thing is that was so covered under warranty and I had a couple other car related things I needed to do. So it's like, okay, I guess while I'm sitting in a loaner and while I'm waiting for them to get that stuff fixed, I might as well get those other things knocked off my to do list. So I did get a couple things done, but it was not exactly at the time and the manner that I chose. The time and manner that I choose to have Michael introduce himself though is right now. Go for it. Hey everyone. My name is Michael Milosh. I'm one of the co-founders of developer NURB building better developers. I'm also the owner of Envision QA. We help startups and growing companies build better software by improving how they test and release their products. Our focus is on reducing risks, spending and delivery, speeding up delivery and making sure technology doesn't get in the way of growth. You can learn more at EnvisionQA.com, E-N-B-I-S-I-O-N-Q-A.com and you know, reach out. We're more than happy to help. Good thing, bad thing. Oh, good thing. Good thing. Me and my wife just celebrated our 17th anniversary, 18 years of being together. We went to Nashville, had a great time. Bad thing. It rained the whole freaking time. Even though we did disconnect from our devices for a few days, sitting at the pool, we basically looked like us sitting under the overheads, staying as far away from the pool as possible because of all the lightning. But at least we got away, spent some quality time together. So good and bad in a nutshell for that weekend. So diving in, this time around, we are going to take the version of the prior episode that was called Decluttering Your Code and Digital Life. And I asked Chet VT, as I often do, I was like, hey, give us some topics, give us some ideas. And of course, because it's polite and a little bit too friendly sometimes, it probably does a little drinking or something like that on the side. But it's like, absolutely. Here's a tailored version of Decluttering Your Code and Digital Life specifically for the development or podcast. A little bit focused on helping developers level up, not just in skills, but in mindset and habits, which is a nice little thing that it picked up. And not sure why it generated that, but that's pretty cool. Really a neat little thing that I'm noticing in this is it's gotten a lot better in its storytelling, essentially, that you will get from Chet VT if you're using the latest version. So it is definitely something to explore much as we're doing. So title, we've got subtitle Sharpening Focus by Cleaning Up the Tools and Code that Distract You. Pretty cool subtitle. They provided me actually this time a little intro, host prompt slash opening. We haven't had this one before. So let's see if this sounds familiar. Welcome to the development or podcast where we help you build not just better software, but better developers. Today, we're focusing on something that doesn't show up in your IDE, but absolutely shows up in your performance, clutter. That's a pretty cool little prompt and a start. Hopefully you guys are all pumped up now. Statement one, decluttering your code, write like a pro, read like a human. Key talking points. Good developers write code, great developers delete it. Clean up dead code and stale to-dos. Excessive comments that don't help. Unused files and legacy logic. Use automated tools, black, prettier, easy, ESLint, Flake8, et cetera. Modularization, simplify long files or complex classes. Think legibility first. Developer tip, make cleanup commits part of your weekly practice. Wow. This is something we actually were just talking about, I believe it was yesterday, definitely last couple of days about how code has its own sprawl that it does. It is very easy, particularly when you're getting into an application that you're... Particularly, I think agile, we do this a lot where you're getting there and you're really having to push to get a lot of features in. You're trying to get a lot of stuff done. You're trying to improve your velocity. But as part of that, you're maybe not... Essentially, you're solving the problem first and you're not giving yourself time to come back around and clean up the solution. It's very common. I know a lot of us do that. The first thing you do is you write your code and you say, okay, I've solved the problem. I'm taking the right inputs and I'm giving the right outputs. But there are usually better ways to do it. And also, we don't always write it pretty, we'll say, for lack of a better word, the first time around. We are all, I think, guilty of maybe comments that don't no longer make sense. Some of us will comment out code that we're like, oh, I think I'm going to use this. And then we don't. But then we leave the commented out code in there. And there may be to-do's. We're like, to-do, oh, go back and figure out what the heck this number means. Things like that. We need to make sure that we're regularly going through. This is that thing called technical debt. I'm a huge believer in, yes, make cleanup commits a regular part of what you do. But I'm also a realist that knows that there are times that we get into where we just don't get that done. It is definitely worth it to periodically go down that little rabbit trail of, hey, these things aren't white 100%. I want to clean it up using your Lint tools and things like that. Static code analysis, we've talked about it. Those kinds of tools are very valuable in just highlighting a bunch of stuff, particularly if you're in a, for lack of a better term, like a brain dead period, where you just don't want to write code, but you still need to be productive. This is not busy versus productive because it actually is productive to go through and clean some of those things up, to delete some of the code that you don't need. Sometimes it is literally just repackaging. I know you don't want to get too far into it because you don't want to lose your productivity. You don't want to clean up code versus create functionality and features. However, there is a lot of value in spending a little bit of time saying, hey, I put 4,000 lines of code into this function. Maybe I should break it up into something smaller. Maybe there's a class I should create things like that. I'll stop there and toss it over to you because I know you also have opinions on this and bad habits such as I do. Yeah. I tend to like refactoring code a lot more than you do. Just because I like the readability factor for testing, because the more you can break the code down, the easier it is to write tests for those individual sections of code. The bigger the method, the bigger the class, the harder it is to really test the functionality and really understand what the heck it's supposed to do. If you're over three or four lines of code, chances are you're probably getting too long. Or if you have multiple statements, you definitely need to break it out into separate functions or methodologies. The only other thing I'll touch on this because we are a little connets on time today is not only with code reviews and refactoring code. I like the idea, good developers write code, great developers delete code. Cleaning up, refactoring, shrinking the code really, again, emphasizes what it is that the software is doing. You focus on what a section of code is doing. You can write good, solid testing for it. And if you do it right with comments, adding comments to those sections should be a no brainer or better yet, write very clear code that self-documents itself. Basically your code variables, your method naming, your class name, basically tell you what it's doing. And you should almost be able to read a line of code and basically be reading a sentence. I want to touch on that testing part of it because I do think that is a huge, um, you know, fingers in glove kind of thing is it's like, if you focus on really doing good unit tests, I think by nature, as Michael described, is you're going to write smaller chunks of code because you're not going to, if you're sitting there and you're having to write unit tests for 400 lines of code and all different things, and then you're going to realize that there's a lot of stuff that could go wrong in that code that you can't specifically get to. You've black boxed it too much. So there's all this stuff that either you're going to have to kick out hundreds of different error codes and stuff like that, or you break it up and then you can unit test those little pieces. I found that that is a really good motivator for us to write smaller, you know, more easily identifiable chunks of code. And honestly, not only does it make it easier to test, it makes it easier for us to write stuff that actually works because now you're not having to deal with as many ins and outs and combinations and permutations of stuff. You know, if it's as, if you can break everything down to it, you know, I send a value in and it either kicks out a zero or a one, then it gets really easy to test that and to find out where it breaks. If you've got something where whatever I send in, it could send out, you know, four billion different possibilities, you're not going to be able to test all of those. So your code coverage also is going to be impacted by how complex or simple you write your code. I know it's very difficult at times. I also have problems. I know where you don't want to copy, you know, essentially copy objects around and stuff like that. And it can become a performance issue, but where I get too far off on it, I think that is something that we should keep in mind. Go ahead. Last thing to that too is not only that, but it can also impact your team's productivity because if your code gets too long, code merges can become a problem because you're making small changes to large sets of code when instead you should be making small changes to small sections of code. That actually, wow, that's that is actually a really good one is that what's going to happen is then you're not having to figure out how your code interacts with everybody else's because even if you're all in one file, if you've done it in small units, it's probably your unit of work that you're merging in and it becomes a lot easier. You're not stepping on people as much. Second to it says, decluttering your workflow, fewer distractions, faster development. Key talking points. Tabs are the new junk drawer. Use a tab manager or commit to 10 tab max. Killer disable unnecessary tools, browser extensions, visual VS code plugins, streamline terminal terminal tools, aliases, dot files, command runners like just or make have a dedicated dev folder structure. Don't live in your home directory slash downloads. The fewer decisions you make about where to find something, the more decisions you can make about how to build something. This is a I'll call it a pro tip or something like this. This is something I ran into early on and very quickly in like probably my first year or two of development. If you see how I organize documents and stuff like that that are not code that are not specific to a product, you know, to projects and things like that, I end up I have a lot of like the junk drawer kind of stuff. There's a lot of those kinds of things out there. However, if you look at the stuff that I actually use all the time, including like mail, definitely my code structure and the tools that I use. I have worked on those and refined those over years. I always have no matter what machine, I have a certain folder that I have all of my code in. I have that structure set up on a project that I can very easily clone because I use get almost everywhere now. Actually, I guess I do everywhere and I've got so I've got it very well set up so I can just clone stuff into there. I jump into my project folder. Those things have very much I have a standard that I use now granted, you know, if you work with other people, they're going to have slightly different standards. You may have to make some adjustments. But along with that, I do my best to stick to whatever the language is. Their typical directory structure. That's one of the first things I'm going to look at is like what should I use so that it is industry standard or something along those lines. I also, yes, I'm going to date myself a little bit, but I'm also a heavy user of shell scripts and ant in particular because I've just worked on that for so many years. It's very easy for me to copy that over and use it to do a lot of the file manipulations and things that I do. And actually with using chat GPT and some other stuff, I've been able to actually very quickly in a couple of cases convert my my ant tasks and scripts into like, for example, Python. So I've got something that is now just part of the language I'm working on. So there's a lot to be said. There's like covered in these couple of items. It really is useful to keep ourselves focused into particularly if you bounce project, if you've got big projects for a long period of time and then you move on to another one, you know, you're working for six months and you're on to something new. And particularly if it's a different line of business, definitely different, you know, code environment, things like that. Take a look at those plugins and some of those other things, because it may be that you've got a lot of crap in your ID that you really don't need. Same thing as, you know, that goes to our favorite reviews mail all the time, build some rules, shove stuff in folders, and then you don't have to worry about as much thoughts on this. Yeah, again, I'll be brief because of time. But one of the biggest things I've talked about all the time and Rob hears this all the time is kitchen sink apps. If you are a developer, you are writing code, you're probably working in multiple different environments. If you focus on a kitchen sink app, you are basically building a master project for all as a source of reference for everything you do. Very easily, you can kind of clone that and make a directory structure to kind of follow that. Or even in your kitchen sink app, create folders for your different projects, for your different things like documentation, wikis. And you really keep it all in one place. You keep that in source control. If you ever make a mistake, you can go back, you can change it, you can see what you're doing with it. And if you go from one project to another, you have your structure, kind of your best practice way of doing things that you can take with you anywhere you go. And pro tip, these are usually fun little kitchen sink apps can be a good interview strategy to show off what you have done in the past in a job interview. So I'm looking at the next two segments it has. This one actually broken down into four segments. And I think because we'll see, I'm going to go with segment four first, which is sort of the wrap up because I think there's some good points there and then we may come back around. Segment three that I may be skipping, it may be bonus material, is decluttering your digital brain context switching as costly. It's a great conversation point, but there's also some neat little bullet points there. More specifically, let's jump into four, which is the first one. And then more specifically, let's jump into four, which is build it into your developer rhythm. This right away, I look at this, this really feeds into the GTD approach of stuff of like coming in every week, do your stuff, get to the end of the week, wrap up what you did, close it up, tie it up, and then be ready. Look forward to the next week and make sure you've planned accordingly. Make decluttering a habit, not a rescue mission. At the end of each week or sprint, archive old branches, delete orphan to do's, restart your machine, spend 10 minutes refactoring even without a feature request. What you remove matters just as much as what you add. I think that, you know, we talk about like incremental changes and stuff like that. We talk about your 15 minutes a day. I think those are all excellent items to put on that kind of a to-do list. Maybe that is, maybe that becomes, we haven't had a challenge ourselves, or maybe the challenge this one has been 15 minutes a day, just 15 each day, and probably, I would say, just focus most days on the refactoring. Just pick a project or pick a file, something like that. Do a little bit of refactoring. To restart your machine, I think like once a week or something like that, even if you're like me and you have Unix-based machines, it is not a bad thing to do. It does help you and I do, you know, be warned. Maybe something that the first time you do it, you're like, oh crap, I've got a lot of crap. I've got to change. But if you do it regularly, then you'll automate the things you need to. Deleting orphan, you know, to-dos and archiving old branches is great cleanup. I think that's something you maybe do once a week. As you do that, another thing I would recommend is to do as much as you can. Do like a system backup and just take that and throw that somewhere that's not on your machine. Even if you like thumb drives these days or the little external USB drives and stuff like that, you can get them for under a hundred bucks. You can get multiple terabytes of data. You can easily copy stuff out there. I highly recommend it along with all of the other backup times of things that are out there because it just helps quite a bit for you in case something does go wrong. The other thing I would do would be, you know, be a bonus would be go to inbox zero is sweep through your email and get rid of all the crap that you know you're not going to do because you said you were going to do it Monday and now it's Friday and you still haven't done it. Might as well clean that up. Thoughts on the developer rhythm? Yeah, the big thing here and I do this at least once a week is I try to go through. Yes, I have email rules, but I still try to double check my junk folders, my inbox, just double check everything's there because sometimes stuff does get deleted. If you were on multiple machines, laptops, iPads, iPhones, tablets, whatever, you could accidentally hit delete on one and remove it from all. And you've just lost a very important email. Check those at least once or twice a week. You know, batching is a great thing. The other thing is make sure you have some type of time machine or backup, be it Dropbox. Like Rob said, you know, thumb drives, but get something that can be reoccurring. Like if you have a Mac time machine works with most thumb drives, most external drives, but get something that is routinely done that essentially does it without you having to babysit it. And that way, in case something does happen, you have a way to go back and not lose what you've been working on. We will wrap it up, but I do want to throw these out. The segment three was decluttering your digital brain. Contact switching is costly. The key talking points, turn off non-essential notifications. Create focused interruption free time to code. Use time boxing, 25 minutes cleaning code, 25 minutes feature work, calendar audit. Remove recurring meetings or tasks that don't move you forward. Protect your attention like it's your best asset because it is, is their little quote. This goes back to the Pomodoro thing that I talked about so much last season that that was where the 25 minutes very much was a part of it. But I think there is so much benefit given to us when we do that interruption free, focused work, particularly as developers. I did not, there's a lot of times I did not actually turn off notifications. I wish I had, I will be doing it as I move forward. I think that is a habit to get into. It's probably going to serve you more than anything else. I've gotten done a lot to get away from like phone and other distractions, but turning notifications off would be a huge next step and I highly recommend it. Um, parting thoughts for wrap this one up. Yeah, not just a notification, it's wearables too. If you have anything that chimes dings, turn it off, take it out of the room, get rid of it. If you find yourself being anxious, that's probably why I get rid of those distractions, gets rid of those notifications, find focus and quality time. One other thing too, is if you find you get yourself distracted, turn on something like white noise or just a low level noise, not rock, not something, just something to kind of draw, you know, kind of bleed out that distractions so that you can stay focused on what you're doing. That is, uh, that's something I've added that has been hugely beneficial over the years. Uh, when I started out, I used to have like, I'd have, you know, TV run in the background. I've done podcasts. Um, they really white noise and some of those focus related apps and music is, uh, by far, uh, been a lot more productive for me. Uh, and that's the key is like, get in, get it done. And then you can go out and do all the rest of the things in your life. Like send us an email. You can choose an email info at development or.com. We'd love to hear from you and get your feedback, your suggestions, recommendations, what you like, what you don't like. Also, you can check us out on the YouTube channel, developer. We've got plenty of, we've got years and years of content. It's amazing how much stuff we've got there. Developing or.com. We've got also over a thousand, I don't even know how far over, but well over a thousand articles out there, blog articles of varying sorts. Um, and hit us up on Facebook. We have a developer page on X at developer. Um, you name it, we're out there. And if you name it, we're not out there. Let us know when we'll find a way to get out there. Probably. Um, but also anywhere that you listen to your podcasts, wherever you get them, leave us feedback. And if you somewhere go find somewhere that you're not able to find us, let us know. We'll make sure we get signed up there as well, because we just want to be out here helping you guys out as much as possible. That being said, we're going to wrap this one up. So go out there and have yourself a great day, a great week, and we'll talk to you next time. Thank you for listening to building better developers, the developer 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.