Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit one of their most practical topics: decluttering your code and workflow. However, this time, they incorporate AI tools like ChatGPT into the conversation to help developers enhance their development workflow.
🎧 Key takeaways: • Why great developers delete code, not just write it • How to clean up your IDE, tabs, and tools • Using ChatGPT and AI for smarter refactoring • Weekly cleanup habits that improve focus and reduce tech debt • How to protect your time and attention from context-switching chaos
Whether you’re buried in technical debt or looking to improve your daily coding flow, this episode is packed with tips to help you work cleaner, faster, and smarter.
⸻
🧰 Tools & Topics Mentioned: • ChatGPT • ESLint, Prettier, Flake8 • Pomodoro Technique • Kitchen Sink App Strategy • Git Branch Cleanup • IDE Plugin Management
⸻
📬 Let’s Connect: Do you have any feedback or questions? Please email us at [email protected] Visit https://develpreneur.com/ for more episodes and resources
Follow us on: * https://develpreneur.com/ * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://X.com/develpreneur * https://www.linkedin.com/company/develpreneur/
⸻
🔔 Don’t forget to like, comment, and subscribe to level up your dev game every week!
Transcript Text
[Music] chat GB. Now you're recording. Okay. I thought you wanted me to. Oh, yeah. I thought it was already recording. Oh, no, it was not. Reset. reset while you're while you're at the table for that a little differently. Yeah. So over the weekend, uh there's been some news about uh Open AI losing some top talent to Google and um Meta Facebook. And in the last like 48 hours, the Facebook ads I'm seeing now for uh AI classes, AI newsletters, all that crap is so anti- chat GPT, it is insane. It's like, "Oh, if you're over 40, you need to be if doing these, don't use chat GPT. Oh, if you're over this, you It's like literally within 48 hours, like the marketing campaign began." And it's like, "Okay, I'm about done with meta now because Facebook is just like killing me with these ads. It's like every other swipe it's like, uh, go away." Yeah, they get a little annoying for sure. Okay, let's see. Yeah, I thought that'd be a nice little tidbit since we are using AI this season as we discuss our topics. Yeah. So, a challenging thing is that my display apparently No, it is. Oh, wonder why. Oh, this is too big. That's my problem. Like trying to figure out stuff. Oh, yeah. Howdy everybody. Sorry that we hit record and I didn't even say hello. I'm being rude today. Um, trying to get my little chat GPT window up here so I can actually read it. And let's see. Let me get some water in case I need that at some point. Okay, let's see. So, we get to dive right in again. Once I can get my little tear adjusted here a little bit. Here we go. Here we go. Clear the throat. All that goodness. Um, let's see. So, yeah, this time we're going to hit on decluttering your code in digital life and whoops. Finding balance, the importance of pausing and pivoting in tech. Okay. Well, this should be interesting. I've already shoved stuff into chat GPT. So, I guess we can just dive right in and let's see where this one goes because I'm a fan it's going to be just like the others. Oops. Let me do two things. Let me make sure that Cool. It is charging my battery and I am going to focus. Do not disturb for an hour. Oh, yeah. Bonus point. I had to break your do not disturb. I guess it was yesterday. Just as you were gonna go into a call, you hit do not disturb and I was trying to get a hold of you to be like, "Hey, what's the passcode for the Zoom for this?" And it's like, "Michael is, you know, has blocked notifications. Do you wanna, you know, do you want to break through it?" I was like, "Yes, yes, bug him." Anyways, so I was like, "Oh, you did the proper thing." But that also blocked me theoretically would have blocked me from being able to get to you. So fun times. All right, we're just going to dive right into it. 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 uh not like everybody else in the world. We're going to go through a couple seasons back and we are taking those prior topics, shoving into AI and discussing what comes out. Uh so far it's been really interesting. There have been some new things. Uh 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 Broadhead, one of the founders of Developer, also the founder of RB Consulting, where we help you clean up your digital mess. Uh 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 and 6 months, even 6 years from now hopefully. Uh cuz technology does change pretty quickly. We do that through simplification, integration, automation, even innovation. If you need like a you know some gamecher built, we will work with you on that. Check us out rb-sns.com and you can see some of our past projects and things like that. Uh we also have new surprises coming in the future as we are revamping our site. Uh currently it's not really awesome, but as we're going through this work, uh we've got some freebies and other stuff that may be very useful for those of you on your entrepreneurial side. Good thing, bad thing. Uh bad thing is I was I'm out of town uh traveling being the uh road warrior remote nomad, digital nomad that I can sometimes be and uh 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. Uh did not start actually even it didn't stop but it also did not start. Uh turns out that it was the uh starter was broken. Uh 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. Uh the good thing is that was still 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 the laner 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 Malash. I'm one of the co-founders of Developer, 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 risk, spending and delivery, speeding up delivery, and making sure technology doesn't get in the way of growth. You can learn more at envisiona.com, environqa.com. And, you know, reach out. We're more than happy to help. Good thing, bad thing? Good thing uh me and my wife just celebrated our 17th anniversary. Uh 18 years of being together. Uh we went to Nashville. Had a great time. Bad thing it rained the whole freaking time. Uh even though we did uh disconnect from our devices for a few days. Uh 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 uh you know spent some quality time together. So good and bad in a in a nutshell for that weekend. So diving in this time around we are going to take the version of uh the prior episode that was called decluttering your code and digital life and I asked chatbt 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. This 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 in digital life specifically for the developer podcast that's 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. Um really a neat little thing that like I'm noticing in this is it's gotten a lot better in its uh storytelling essentially that you will get from chat GBT if you're using the the latest version. Uh so it is definitely uh 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. Uh they provided me actually this time a little intro uh host prompt/opening. We haven't had this one before, so let's see if this sounds familiar. Welcome to the Developer 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. Segment 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 uh dead code and stale to-dos, excessive comments that don't help, unused files and legacy logic. Use automated tools, black, prettier, easy, eslint, flake, etc. Modularization. Simplify long files or complex classes. Think legibility legibility first. Developer tip. Make cleanup commits part of your weekly practice. Wow. Um, this is something we actually were just talking about. I believe it was yesterday definitely in the last couple days about our how code has its own sprawl that it does. It is very easy particularly when you're getting into a uh an application that you're and particularly I think agile we do this a lot where you're getting there and you're like 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 you're essentially you're solving the problem first and you're not giving yourself time to come back around and clean up the solution. Uh it's very common. I know a lot of us do that. The first thing you do is you write your you write your code and you say, "Okay, I'm 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 uh no longer make sense. Uh some of us will comment out code that we're like, 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-dos. 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 I'm a huge believer in yes, make like 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. Uh it is definitely worth it to periodically go down that little rabbit trail of hey, these things aren't quite 100%. I want to clean it up. Using like your lint tools and things like that, static code analysis, we've talked about it. Um, 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 deadad period where you just don't want to like write code, but you just want to, 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. Uh, sometimes it is to it is literally just repackaging. I know it's you don't want to get too far into it because you don't want to uh lose your productivity. You don't want to, you know, clean up code versus create functionality and features. However, there's a lot of value in spending a little bit of time saying, "Hey, I like, you know, 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. Uh, I tend to like refactoring code a lot more than you do. Um, 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 if statements, you definitely need to break it out into separate functions or uh methodologies. The only other thing I'll touch on this because we are um a little kess on time today is not only with code reviews and you know refactoring your code. I like the idea, you know, good developers, you know, 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 namings 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 and glove kind of thing is it's like if you focus on really doing good unit tests I think by nature as Michael you know 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 blackboxed it too much. So, there's all this stuff that either you're going to have to, you know, 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 coma combinations and permutations of stuff. You know, if this is 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 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 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. Uh I also have problems I know where you you don't want to copy you know essentially copy objects around and stuff like that and it can become uh a performance issue but before I get too far off on it I think that is something that we should you know you should keep in mind. Uh go ahead. One last thing to that too is not only that uh 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 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 you know 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 uh segment two 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 kill or disable able unnecessary tools, browser extensions, visual uh VS code plugins. Streamline terminal terminal tools, aliases, files, command runners like gist or make uh have a dedicated dev folder structure. Don't live in uh your home directory/d downloads. Uh the few 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. Um, if you've seen how I organize documents and stuff like that that are not code, that are not specific to a pro, 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, uh, including like mail, uh, 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 uh, clone because I use git almost everywhere now. Um, 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 uh along with that, I 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 uh 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 chatgbt and some other stuff, I've been able to actually very quickly in a couple of cases convert my uh 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 a lot covered in these couple of items. Um it really is useful to uh you know keep ourselves focused and to uh 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 6 months and you're on something new and particularly if it's a different um line of business definitely different you know u 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 IDE that you really don't need uh same thing as you know that goes to our favorite we've used mail all the time build some rules stuff in folders and then you don't have to worry about as much thoughts on this yeah uh again I'll be brief because of time but one of the biggest things I talk about all the time and Rob hears this all the time is kitchen sync apps if you are a developer you are writing code you're probably working multiple different environments if you focus on a kitchen sync 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 sync 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 the wrap-up because I think there's some good points there and then we may come back around. Segment three, then I may be skipping. It may be bonus material is decluttering your digital brain context switching is 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 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 end 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-dos, 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 a to-do list. Uh maybe that is maybe that becomes we haven't had a challenge ourselves or maybe the challenge in this one is spend 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 u 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 it is not a bad thing to do uh it does help you and I do you be warned. Uh it may be 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. U deleting orphaned, you know, to-dos and archiving old branches is great cleanup." Uh I think that's something you maybe do once a week as you do that. Another thing I would recommend is to do a uh as much best you can do like a system backup and just take that and throw that somewhere that's not on your machine. Um even if you like thumb drives these days or the you know little external USB drives and stuff like that. Uh you can get them for 100 under under 100 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. Uh 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. uh thoughts on the developer rhythm? Yeah, the the big thing here, and I do this at least once a week, is I try to go through uh 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 are 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 uh make sure you have some type of time machine or backup be it Dropbox like Rob said uh 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 got a 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. Uh 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 tens attention like it's your best asset because it is their little quote. Um, this goes back to the Pomodoro thing that I talked about so much uh last season that uh 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 interruptionfree focused work particularly as developers. Um I did not very there's a lot of times I did not actually turn off uh notifications. I wish I had I will be doing it as I move forward. It is definitely I think that is a habit to get into is probably going to serve you more than anything else. Um I've gotten done a lot to get away from uh like phone and other distractions, but turning notifications off would be a huge next step and I highly recommend it. Um parting thoughts before we wrap this one up? Yeah, not just notification but 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. Get rid of those distraction. Gets rid of those notifications. Find focus and quality time. Uh, 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 running 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 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 shoot us an email [email protected] we'd love to hear from you get your feedback your suggestions recommendations what you like what you don't like uh 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. Development.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 xdevelopure. Um, you name it, we're out there. And if you name it and we're not out there, let us know and we'll find a way to get out there probably. Um, also anywhere that you listen to your podcast, 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. Bonus material. Uh one of the big things is well you might have to deal with different environments, different tools, different softwares from company to company for yourself. Pick a lane, pick like Jira, you know, pick something to keep track of all this in one place. Don't try to manage multiple repositories like Bitbucket, GitHub, um Teams. Pick one lane, stick to it, get everything in it, keep it organized, and kind of go with that. If you try to manage multiple things, you're adding chaos to your organization. Just keep it simple, keep it clean, and let the businesses be disorganized, and you just try to bring order when you go work for them. Uh, this very much speaks to what I started out when I was talking about technology sprawl and things like that. Is that like that is something that we are all we all have to watch. uh it's very easy to uh adopt a certain tool for a while and then utilize it because that's you know maybe what your customer is using or your boss or something like that and then you move on to something else but now you've got some of that stuff left over. I think that is part of the uh part of what I'll throw out there sort of a challenge here is that do that 15 minutes of cleanup and if that 15 minutes of cleanup may be moving stuff off of old systems. I I took about a week uh not too long ago actually and myself I had stuff in Bitbucket. I had stuff in GitHub. I chose one and I basically just pulled everything down and moved it all over to the other repository so that I could get stuff all in one place and reduce my uh my tools and even some of the tabs that I had open on my uh on my various browsers. So I think that's a a great way to go is just make that uh migration of your old stuff, you know, part of your, you know, daily or at least at least weekly cleanup. Even if you start with like 15 minutes on a Friday to do some cleanup, um I highly recommend it. If you're an employee that it's the easiest thing to be like, you know, you get towards the end of the day, you're watching a clock, you're like, "Okay, I need to, you know, get my hours in or something like that." Then take that 15 minutes and do some clean up. Do something that's productive and allows you to be more productive moving forward. I'm going to allow you to be more productive right now and go out there and get to the rest of your day. We're going to be productive and we're going to start working on the next episode. So see you next time around. Thank you so much for being here and we will talk to you next time. [Music]
Transcript Segments
[Music]
chat GB.
Now you're recording. Okay.
I thought you wanted me to.
Oh, yeah. I thought it was already
recording. Oh,
no, it was not. Reset. reset while
you're while you're at the table for
that a little differently.
Yeah. So over the weekend, uh there's
been some news about uh Open AI losing
some top talent to Google and
um Meta Facebook. And in the last like
48 hours, the Facebook ads I'm seeing
now for uh AI classes, AI newsletters,
all that crap is so anti- chat GPT, it
is insane. It's like, "Oh, if you're
over 40, you need to be if doing these,
don't use chat GPT. Oh, if you're over
this, you It's like literally within 48
hours, like the marketing campaign
began." And it's like, "Okay, I'm about
done with meta now because Facebook is
just like killing me with these ads.
It's like every other swipe it's like,
uh, go away."
Yeah, they get a little annoying for
sure. Okay, let's see. Yeah,
I thought that'd be a nice little tidbit
since we are using AI this season as we
discuss our topics.
Yeah.
So, a challenging thing is that my
display apparently No, it is.
Oh, wonder why.
Oh, this is too big. That's my problem.
Like trying to figure out stuff. Oh,
yeah. Howdy everybody. Sorry that we hit
record and I didn't even say hello. I'm
being rude today. Um, trying to get my
little chat GPT window up here
so I can actually read it.
And let's see. Let me get some water in
case I need that at some point.
Okay,
let's see. So, we get to dive right in
again. Once I can get my little tear
adjusted here a little bit.
Here we go. Here we go. Clear the
throat. All that goodness. Um, let's
see. So, yeah, this time we're going to
hit on
decluttering your code in digital life
and whoops. Finding balance, the
importance of pausing and pivoting in
tech. Okay. Well, this should be
interesting. I've already shoved stuff
into chat GPT.
So, I guess we can just dive right in
and let's see where this one goes
because I'm a fan it's going to be just
like the others. Oops. Let me do two
things. Let me make sure that Cool. It
is charging my battery and I am going to
focus. Do not disturb for an hour.
Oh, yeah. Bonus point. I had to break
your do not disturb. I guess it was
yesterday. Just as you were gonna go
into a call, you hit do not disturb and
I was trying to get a hold of you to be
like, "Hey, what's the passcode for the
Zoom for this?" And it's like, "Michael
is, you know, has blocked notifications.
Do you wanna, you know, do you want to
break through it?" I was like, "Yes,
yes, bug him." Anyways,
so I was like, "Oh, you did the proper
thing." But that also blocked me
theoretically would have blocked me from
being able to get to you. So fun times.
All right, we're just going to dive
right into it. 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 uh not
like everybody else in the world. We're
going to go through a couple seasons
back and we are taking those prior
topics, shoving into AI and discussing
what comes out. Uh so far it's been
really interesting. There have been some
new things. Uh 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
Broadhead, one of the founders of
Developer, also the founder of RB
Consulting, where we help you clean up
your digital mess. Uh 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 and 6 months, even 6 years from
now hopefully. Uh cuz technology does
change pretty quickly. We do that
through simplification, integration,
automation,
even innovation. If you need like a you
know some gamecher built, we will work
with you on that. Check us out
rb-sns.com
and you can see some of our past
projects and things like that. Uh we
also have new surprises coming in the
future as we are revamping our site. Uh
currently it's not really awesome, but
as we're going through this work, uh
we've got some freebies and other stuff
that may be very useful for those of you
on your entrepreneurial side. Good
thing, bad thing. Uh bad thing is I was
I'm out of town uh traveling
being the uh road warrior remote nomad,
digital nomad that I can sometimes be
and uh 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. Uh did not
start actually even it didn't stop but
it also did not start. Uh turns out that
it was the uh starter was broken. Uh 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. Uh the good thing is that was
still 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 the laner 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 Malash.
I'm one of the co-founders of Developer,
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 risk, spending and delivery,
speeding up delivery, and making sure
technology doesn't get in the way of
growth. You can learn more at
envisiona.com, environqa.com.
And, you know, reach out. We're more
than happy to help. Good thing, bad
thing?
Good thing uh me and my wife just
celebrated our 17th anniversary. Uh 18
years of being together. Uh we went to
Nashville. Had a great time. Bad thing
it rained the whole freaking time. Uh
even though we did uh disconnect from
our devices for a few days. Uh 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 uh you know spent some
quality time together. So good and bad
in a in a nutshell for that weekend.
So diving in this time around we are
going to take the version of uh the
prior episode that was called
decluttering your code and digital life
and I asked chatbt 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. This 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 in digital life specifically for
the developer podcast that's 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. Um
really a neat little thing that like I'm
noticing in this is it's gotten a lot
better in its uh storytelling
essentially that you will get from chat
GBT if you're using the the latest
version. Uh so it is definitely uh
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. Uh they provided me
actually this time a little intro uh
host prompt/opening. We haven't had this
one before, so let's see if this sounds
familiar. Welcome to the Developer
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.
Segment 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 uh dead code and stale to-dos,
excessive comments that don't help,
unused files and legacy logic. Use
automated tools, black, prettier, easy,
eslint, flake, etc. Modularization.
Simplify long files or complex classes.
Think legibility legibility first.
Developer tip. Make cleanup commits part
of your weekly practice.
Wow. Um, this is something we actually
were just talking about. I believe it
was yesterday definitely in the last
couple days about our how code has its
own sprawl that it does. It is very easy
particularly when you're getting into a
uh an application that you're
and particularly I think agile we do
this a lot where you're getting there
and you're like 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 you're
essentially you're solving the problem
first and you're not giving yourself
time to come back around and clean up
the solution. Uh it's very common. I
know a lot of us do that. The first
thing you do is you write your you write
your code and you say, "Okay, I'm 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 uh no longer make
sense. Uh some of us will comment out
code that we're like, 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-dos. 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
I'm a huge believer in yes, make like
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.
Uh it is definitely worth it to
periodically go down that little rabbit
trail of hey, these things aren't quite
100%. I want to clean it up. Using like
your lint tools and things like that,
static code analysis, we've talked about
it. Um, 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
deadad period where you just don't want
to like write code, but you just want
to, 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. Uh, sometimes it is to it is
literally just repackaging. I know it's
you don't want to get too far into it
because you don't want to uh lose your
productivity. You don't want to, you
know, clean up code versus create
functionality and features. However,
there's a lot of value in spending a
little bit of time saying, "Hey, I like,
you know, 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. Uh,
I tend to like refactoring code a lot
more than you do. Um, 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 if
statements, you definitely need to break
it out into separate functions or uh
methodologies. The only other thing I'll
touch on this because we are um a little
kess on time today is
not only with code reviews and you know
refactoring your code. I like the idea,
you know, good developers, you know,
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 namings
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 and glove kind of thing
is it's like if you focus on really
doing good unit tests I think by nature
as Michael you know 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
blackboxed it too much. So, there's all
this stuff that either you're going to
have to, you know, 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 coma combinations and permutations
of stuff. You know, if this is 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 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 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. Uh I also have problems I know
where you you don't want to copy you
know essentially copy objects around and
stuff like that and it can become uh a
performance issue but before I get too
far off on it I think that is something
that we should you know you should keep
in mind.
Uh go ahead. One last thing to that too
is not only that uh 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 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 you know 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 uh
segment two 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 kill or disable
able unnecessary tools, browser
extensions, visual uh VS code plugins.
Streamline terminal terminal tools,
aliases, files, command runners like
gist or make uh have a dedicated dev
folder structure. Don't live in uh your
home directory/d downloads. Uh the few
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. Um, if
you've seen how I organize documents and
stuff like that that are not code, that
are not specific to a pro, 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, uh, including like
mail, uh, 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 uh,
clone because I use git almost
everywhere now. Um, 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 uh along with that, I 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 uh 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 chatgbt and
some other stuff, I've been able to
actually very quickly in a couple of
cases convert my uh 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 a lot
covered in these couple of items. Um it
really is useful to uh you know keep
ourselves focused and to uh 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 6 months and you're
on something new and particularly if
it's a different um line of business
definitely different you know u 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 IDE that you
really don't need uh same thing as you
know that goes to our favorite we've
used mail all the time build some rules
stuff in folders and then you don't have
to worry about as much thoughts on this
yeah uh again I'll be brief because of
time but one of the biggest things I
talk about all the time and Rob hears
this all the time is kitchen sync apps
if you are a developer you are writing
code you're probably working multiple
different environments if you focus on a
kitchen sync 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
sync 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 the
wrap-up because I think there's some
good points there and then we may come
back around. Segment three, then I may
be skipping. It may be bonus material is
decluttering your digital brain context
switching is 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 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 end 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-dos, 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 a to-do
list. Uh maybe that is maybe that
becomes we haven't had a challenge
ourselves or maybe the challenge in this
one is spend 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
u 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 it is not a bad thing
to do uh it does help you and I do you
be warned. Uh it may be 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. U deleting orphaned,
you know, to-dos and archiving old
branches is great cleanup." Uh I think
that's something you maybe do once a
week as you do that. Another thing I
would recommend is to do a uh as much
best you can do like a system backup and
just take that and throw that somewhere
that's not on your machine. Um even if
you like thumb drives these days or the
you know little external USB drives and
stuff like that. Uh you can get them for
100 under under 100 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.
Uh 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. uh
thoughts on the developer rhythm?
Yeah, the the big thing here, and I do
this at least once a week, is I try to
go through uh 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 are 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 uh make sure you have some type
of time machine or backup be it Dropbox
like Rob said uh 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 got a 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. Uh
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 tens attention like it's
your best asset because it is their
little quote. Um, this goes back to the
Pomodoro thing that I talked about so
much uh last season that
uh 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 interruptionfree
focused work particularly as developers.
Um I did not very there's a lot of times
I did not actually turn off uh
notifications. I wish I had I will be
doing it as I move forward. It is
definitely I think that is a habit to
get into is probably going to serve you
more than anything else. Um I've gotten
done a lot to get away from uh like
phone and other distractions, but
turning notifications off would be a
huge next step and I highly recommend
it. Um parting thoughts before we wrap
this one up?
Yeah, not just notification but
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. Get rid of those
distraction. Gets rid of those
notifications. Find focus and quality
time. Uh, 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 running
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 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 shoot us an
email [email protected] we'd love to
hear from you get your feedback your
suggestions recommendations what you
like what you don't like uh 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.
Development.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 xdevelopure.
Um, you name it, we're out there. And if
you name it and we're not out there, let
us know and we'll find a way to get out
there probably. Um, also anywhere that
you listen to your podcast, 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.
Bonus material.
Uh one of the big things is well you
might have to deal with different
environments, different tools, different
softwares from company to company
for yourself. Pick a lane, pick like
Jira, you know, pick something to keep
track of all this in one place.
Don't try to manage multiple
repositories like Bitbucket, GitHub, um
Teams. Pick one lane, stick to it, get
everything in it, keep it organized, and
kind of go with that. If you try to
manage multiple things, you're adding
chaos to your organization. Just keep it
simple, keep it clean, and let the
businesses be disorganized, and you just
try to bring order when you go work for
them.
Uh, this very much speaks to what I
started out when I was talking about
technology sprawl and things like that.
Is that like that is something that we
are all we all have to watch. uh it's
very easy to uh adopt a certain tool for
a while and then utilize it because
that's you know maybe what your customer
is using or your boss or something like
that and then you move on to something
else but now you've got some of that
stuff left over. I think that is part of
the uh part of what I'll throw out there
sort of a challenge here is that do that
15 minutes of cleanup and if that 15
minutes of cleanup may be moving stuff
off of old systems. I I took about a
week uh not too long ago actually and
myself I had stuff in Bitbucket. I had
stuff in GitHub. I chose one and I
basically just pulled everything down
and moved it all over to the other
repository so that I could get stuff all
in one place and reduce my uh my tools
and even some of the tabs that I had
open on my uh on my various browsers. So
I think that's a a great way to go is
just make that uh migration of your old
stuff, you know, part of your, you know,
daily or at least at least weekly
cleanup. Even if you start with like 15
minutes on a Friday to do some cleanup,
um I highly recommend it. If you're an
employee that it's the easiest thing to
be like, you know, you get towards the
end of the day, you're watching a clock,
you're like, "Okay, I need to, you know,
get my hours in or something like that."
Then take that 15 minutes and do some
clean up. Do something that's productive
and allows you to be more productive
moving forward. I'm going to allow you
to be more productive right now and go
out there and get to the rest of your
day. We're going to be productive and
we're going to start working on the next
episode. So see you next time around.
Thank you so much for being here and we
will talk to you next time.
[Music]