Decluttering Your Code and Digital Life

Welcome to Building Better Developers, the Developer Noir 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 when we're talking about the developer journey. We are here at Developer Noir, also Building Better Developers, which hopefully is going to happen to you as you go through your developer journey is that you're going to start, you know, young and wide eyed and all that kind of stuff. And you're going to get old, but you're going to know a lot of crap because that's only I guess that's the benefit of being old as somebody other than just now you have all kinds of new pains every day when you get up. I am your pain for the next little bit here. One of the two. My name is Rob Broadhead. I am a founder of Developer Noir, also a founder of RB Consulting, where we do software solutions. We look at simplification, automation and integration to find ways to take your technology sprawl, simplify it and give you a solution that works, which funny enough is going to be very similar to the kind of topic we're going to hit. Before I introduce Mike, I do want to mention because sometimes I mix it up today, we're going to focus on cutting the clutter. We're going to talk about as a developer, we're going to talk about like the clutter, not like necessarily around your desk. All that may be something that comes up, but really more like the developer clutter that you have to deal with. Before we get into that, we'll tease a little bit and we'll send it out to Mike to introduce himself. Hey everyone. My name is Mike Amalash. I'm one of the co-founders of Developer Noir. I'm also the founder of Envision QA. So if you're small to mid-sized business or a clinician looking for software, custom software or just need help figuring out what you currently have, we do software assessments and we also pride ourselves on quality software. We write a lot of software built on integration tests, unit testing and system testing. Clutter, clutter, clutter, clutter, clutter. Boy, our lives would be so much easier if we didn't have clutter. And this is particularly code. Oh my gosh. And this is where it's a perfect like dovetail into a recent project I saw. It was described as, and we've talked about these sort of like nightmarish type things, is that it was originally built and I guess I can give some of the specifics of it. It won't matter to it. It was originally built in like Python 1 or version 1 or 2, which for those of you that aren't Python people, that has not really been like that. That's a long, long time ago, like 10 plus years ago. But then it's somewhere along the way got upgraded to Python 3. They also somewhere along the way upgraded their user interface and a couple of years ago is when they did this and they did it. I don't remember what they said, but it's basically like, you know, pick your, your CSS library. If they did, they did it all in this new CSS library and they don't like that. So they're going to throw that out, but all the code is still there and it hasn't been completely ported over along the way. They also had two or three other like half started runs and doing some features that the code is still there, but it's not complete. And now it sits in version control, but even that, it sounds like there's like a couple of different branches and they're not really sure which branch they're on. That would be an example of clutter. And this is where I want to talk code in particular, because this is something that I think is a, it really is like a developer habit or standard. And it is about keeping your code tight and clean. In particular, when you're in development mode and you're, you're writing stuff and then you realize maybe that you don't need it or that, you know, like you've got a big section of code and you realize I'm going to simplify that. I'm going to refactor it into something smaller. I know a lot of people, I know in several developers that never delete everything, anything, comment, comment, comment, comment, comment. That is a total nightmare to go through. You have no idea unless you've actually maintained your type of code and had to pick it up and go search for something like, for example, is because most searches are going to just be text based searches. And so you're going to go search through code for this stuff and you're going to find this method like 18 different times and it's all commented out. And you're going to go, what the, what is it? Where's the one you're having to dig through it? Version control will allow you to go back to that. You don't have to comment it out to save it. If you feel that strongly about it, pull it out, shove it into a little text file that is like my critical snippets or something like that. And then you're off and running. I do this with database work. I do it all the time. I have these long SQL files that all they are is all these different like queries and weird stuff that I've done for that client, that database. So I can go back to it. And sometimes I have notes around it so I can go track it. I don't need to like shove it into some big script and have it all commented out. Delete the code. Don't sit there and then have these big comp, particularly functions. Oh, it drives me nuts. Yeah. This big function it's commented out, particularly if you use multi-line comments where you can have like a, you know, a slash asterisk and then there's nothing. And then there's a slash asterisk somewhere at the end. And you got to go find that. Now granted, if you use an IDE user, you can find that stuff, but still it's a pain and it gives you like files grow to these huge things. Don't be afraid to delete it. If you're using version control properly, then you're going to be okay. That stuff will disappear. Likewise, extra files. I don't know how many times I've like, I've gone in and I've taken a, you know, like maybe there's an HTML file and I'm going to play around with it. So I'll make it, you know, test copy or I'll, I'll do something to be like, I'll rename the file and I'll have it there. If you leave those things sitting around, it drives people nuts. It is ridiculously. That's not how you version control. Do not version control by doing like index one, index two, index three, index four, because nobody knows what the top number is. I have, I worked in a project that that was what this guy did. And sometimes he had version two and sometimes it was version three. And sometimes he would just do V2, V3, V4, V5. You never knew what the top number was and they would be mixed. So the V2 file would call a V5, which would call a V3, which would call a V4. And it was all just too painful. So there is some clutter that you can definitely make some changes on. It's clean up the crap that you're not using. Don't be afraid to use, like if you use Git, don't be afraid to use Git ignore and don't store all that crap out in the repository. If it's not needed or bonus material, if it's private information, don't put it out in your GitHub repository. Keep that stuff in the Git ignore. So you shouldn't have like your, you know, your local passwords and stuff like that. Yeah, you can be like me and be lazy occasionally and say, okay, here's a development database and I'll give you this information. But generally speaking, that should not be there. Shove that stuff out into a settings file or something that you deal with locally. And then you don't have to worry about like, for example, a security breach because somebody breaks into your code out on GitHub. I'm going to step off of my soapbox because I was like, I just got a little bit into a tear there and I'm going to let Michael like take it, take us down a notch and a little feedback on that. And then what's a like, what's a clutter that gets your head all about to explode? Because apparently that's the direction I've taken. So much to unpack. It's really funny that you mentioned that. So the first thing that comes to my mind are possible additional solutions to that. So you mentioned, you know, make sure you commit your code into GitHub. There's things of code reviews, other things look at using like SonarQ, SonarLin, any type of code static review tool. They'll highlight things like that. They'll say like, hey, you have all this code out there that might not be used or dead code. Remove it. If you have source control, make a comment when you commit your code that, hey, I'm removing this for now. It's still in history. You also don't need to keep your branches kicking around. So I guess I have two kind of soapboxy things myself. So the big clutter, the first clutter that comes to mind with Git or with any source control is a lot of managers like to keep old branches out there because they want to keep the conversation history of the changes that went on within a source code. I don't know about you, but I can't remember what I did three months ago. And typically code moves so fast that code from a month ago, that stuff doesn't matter anymore. You're beyond, you're past that. Get rid of that stuff. Make sure when you do commit your code, you commit with solid comments in your commit. And when you merge that code in, that goes with it. You have a history. You can view the source code history. There's all your notes. So don't keep your source, you know, don't keep all those branches around forever. It also takes up space and your DevOps people will be very thankful if you manage that and maintain that well. So kind of following on that soapbox of comments and like dead code being around in, you know, making our lives hell. The additional piece, so the flip side of that is copying and pasting code all over the place. I have worked on so many projects where this one method is in six places doing the exact same thing in six places. Ready utility file, call the utility file once. So, a project I'm currently working on with spreadsheets, we have certain reports that we do. And the logic right now is every report has a different set of sheets. But in reality, we actually have a template sheet for each sheet that's being reused by these different reports. So what we really should be doing is writing a template sheet for like a summary and then extending it for each report and reusing it that way. I ran across this because trying to write the unit test and integration test, I found I had to write six different tests on six different classes that did the exact same thing. So when you're trying to find the logic for something and something's not working, oh, backwards, but everywhere else it was right. So now you're going to all these places. Well, this is right. It makes life hell to try and track down a problem if it's all over the place. The other problem with copying and pasting is you might be copying bad code into another project or into another class. So be very careful with the whole copy paste thing. If you need to make a copy, step back and think to yourself, is this a utility? Is this a parent class? Is this a standalone object or even its own project that or you can move to a module and call a module for multiple projects. Look at streamlining it that way. And the last thing before I throw it back to you, Rob, is as you're going through this, not only avoid the copy paste, but avoid the long methods or the long functions. Write clean code. If you start walking through and you find a method does four different tasks, write that into four methods or four functions. Each function is a different task and then you call the methods that you need. That way you never know because that function, that one task could be reused for something else. So therefore again, you're not duplicating code all over the place. But if you don't separate those into separate methods, you don't know because you're hiding that logic within this big nasty method. What are your thoughts on that, Rob? I think with those, I'm going to go ahead and just, I'm going to let that sit because it is, those are all like very good. Those are excellent points. I do want to switch a little bit out of the code realm when we talk about clutter. And two things that I think are very common now is tab clutter, is people have browsers open and you've got 400 tabs. And also it's, we'll call it, it used to be desktop clutter. You could sit down to somebody's desktop and they would have 400 icons sitting up on that desktop. But now we also get it with our phone or our tablet where you'll have all these applications. And you'll be scrolling through like page after page after page of icons and apps and being like, hey, I need to go to this. I need to go to that. Where is it at? How am I going to get there? There are all kinds of methods to reduce that clutter, whether it's as simple as put it all in, put these things into folders. So you have like maybe on your phone, maybe you have your work folder, your personal folder, your workout folder, your hobby folder, that kind of stuff. Put those apps in there. So at least you're not having the scroll, scroll, scroll, scroll, scroll. Same thing on your desktop. I know that it's easy to have a desktop that's full of shortcuts. And you know that like over here in the top left is always where that one thing is or down there in the bottom right is where that one is. But as soon as something happens with your desktop icons, the best example is when like the sort changes. So they were all sorted by maybe not at all. And now some of these somewhere along the way, you sorted all those things by name. And now it's blowing your head up because you don't know where that icon is anymore. So you're having to search for all this stuff. Use folders, use a better organization because it really is. It's just like your actual desk. Just throwing a bunch of crap out there and then going to find it. Yes, there may be method to your madness. But if you have folders or something like that, some sort of grouping, it will make the method your madness a lot easier for you to get through. Don't beat your head over where did I put that? Where did I put that? Where did I put that? Once you've found that that's an issue, put it aside like earmarks some time to go clean that stuff up. And again, it is it's really it's reducing clutter, reduce the clutter of your icons, reduce the clutter of all those tabs that you have open every time you open a browser. One of the things that we've lost because now machines pretty much can stay up almost all the time was the idea used to be in the day that you would get done with your workday and you would shut your machine off. And the next day you would turn your machine on. And so you had to worry about boot times. And you may still do that somewhere. But there are a lot of places where it don't where we don't. And that allows us bad habits of having 400 different applications up and all these other things that it's worth it. Like, again, if you haven't defined it in the day, which you should shut stuff down, close stuff up, things like that, to just get yourself in the habit of decluttering your digital life as well as your physical life. Last thoughts from you? Yeah. In addition to that, declutter your desk and your desktop. If you are in like health care, you have to worry about HIPAA and things of that nature. The clean desk policy is not just a habit. It's becoming mainstream. So if you are in an office, keeping stuff off your desk is pretty much key to ensuring that privacy, private information isn't lifted or stolen or inadvertently seen. And now you've got a legal issue. Additionally, the last thing I would like to touch on is within the idea of organization and kind of clutter. One of the additional things we come across is your idea of boot times, right? Having to reboot and shut down your computer. The other thing to think about as you are testing your software or you are building software, think about writing tests or testing stuff. Make sure you clean up after yourself. So if you're going to insert a whole bunch of test data into a table, make sure you also have delete statements to delete that test data back out when you're done so that you don't basically you leave your test environment in the same state it was before and after you test it. This also allows you to test different things. You can do load testing, systems testing and some other features there. But just kind of be cautious and think about that whole continuous integration, continuous deployment. Also think about cleaning up after yourself within your scripts and your tests. Data clutter is probably one of the most painful things to go through. And it definitely can it can really slow down development environments and things of that nature. I don't know how often I've worked with situations like we need a way to like do a delete or you can't delete data than an archive or something because you you'll get daily dashboards and stuff that suddenly have or not suddenly but grow and now they've got thousands and thousands of records and the whole thing is slow because you're you're hitting all of that data all the time and you need ways to like you know ignore some of it whether it's delete it, clean it up, filter it, things like that. That being said, you don't need to delete, clean up, filter or anything else the stuff we said. You should just go ahead and just like sit back and just consume it. How does that taste? It should taste pretty good because we're suggesting that you declutter your life and find some simplification. Trust me a little bit of work on this. If you're at all like me it actually becomes sort of addictive because you realize that you put a little bit of time in and now you saved a whole lot of time and the next thing you know you're like well what if I put a lot of time in maybe I'm going to save so much time I'm going to start getting younger again or something like that. There is magic in declutter just getting rid of the clutter and realizing how much easier and simpler your life your tasks become at that point. For example, that would free up time so that you can send us comments and feedback and things like that and you can do that at info at developernoir.com. We have a forum out there on developernoir.com so you can send us information there. You can leave us comments whether it's at wherever your podcast wherever you gather podcasts and listen to them out on YouTube on our YouTube channel. You can check out school.developmentnoir.com. We also have comment forums there. You can sign in and give us feedback as well as there. Go out to our site blog articles. We have comments turned on all that good stuff so you can give us feedback and let us know what you like what you don't like and recommendations for future topics that you might have. That being said we're ready to bring this one to a close. We are not done with the season. We're just like chugging along here like you know roughly I don't know a third ish maybe through with it so we got plenty to come. We're going to continue that developer journey as you guys do as well as you're continuing your journey we're going to talk about these things that we've hit hit on and even some things that we see coming up. However it is you have the rest of your day going coming up so once you go out there and have yourself a great day a great week and we will talk to you next time. Thank you for listening to Building Better Developers the Develop-a-Nor 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.