Updating Developer Tools: Why It Matters More Than Ever

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our episodes, our season that is with AI. We're taking two seasons back, walking through the topics and we are throwing it out to AI and seeing what AI says and see, we'll have some conversations around that because sometimes it's spot on, sometimes it's not. First, I am spot on, always time, always when I'm talking about this, except for just right now. My name is Rob Broadhead. I am one of the founders of development who are also the founder of RB Consulting. At RB Consulting, we basically help you work your way through your technology junk drawer. We've got so much stuff out there these days. There's so many solutions, so many applications. They all need to talk together. There are varying versions and all that. We spend a lot of time, decades now, in the technology world and we help you. We sit down with you. We do a technology assessment. We figure out where you're at. This is partially also about your business and where do you want to go so that we can figure out a custom recipe for you to move forward with a roadmap, a technology roadmap that leverages technology the best way it can. And now you don't have to worry about anymore. You're actually spending money to make money and not worried about some big load stone that you have around your neck called technology or sprawl. We do integration. We do implementation, simplification, automation, innovation. All of those things are part of our tool chest. However it is that we can get you best from where you are to where you want to be. Good things and bad things. I'm going to combo it because today has been a perfect good thing, bad thing. Recently, last few weeks, months now, I guess, I've had issues with one of my cars. It's not worked well. And so finally we're like, all right, we're going to take it into the shop because we've got a big trip coming ahead that we're going to be driving the car for a while and we want to make sure it's up to speed. No pun intended. We take it in and it turns out that it's like what nobody wants to hear is basically drive train issues. It's the like, it basically thing needs to be rebuilt. Engine needs to be rebuilt. That sucks. That would be bad news. And the fact that we don't have a car. Good news is it's actually under warranty. There was a lawsuit related to this thing. Everybody got an extended warranty. We are just under the mileage so that the extended warranty will still hold out for us. So we're going to go have this thing rebuilt for us and it's not going to cost us anything because it's covered under the warranty. So instead of it being like, you know, a hundred miles over the limit, we're actually just underneath it. This is going to be pretty awesome. Not even close to over the limit is Michael and he is going to go ahead and introduce himself. Hey everyone. My name is Michael Milash. I'm one of the co-founders of developer NURB, Building Better Developers. I'm also the founder of a company called Envision QA, where we help startups and small teams deliver high quality software faster through software testing, automation and agile development practices. At Envision QA, we're passionate about bridging the gap between innovation and quality. Whether you're building your MVP or scaling a large production system, we provide the technology leadership and testing strategies to help you succeed. Let's see. Good thing, bad thing. I guess it's kind of mixed. I kind of touched on it a while back. Our TV downstairs was acting up on the fritz, similar to what you were going through. And we came back from our river house, sat down. Renee wanted to sit down and watch the Mexico race and turned the TV on and it just, the little light indicator just kept flashing. It never engaged, didn't do anything. It was dead. An hour of that, it was toast. Good thing, we went to Best Buy and she walked around and on the wall they had one TV left that she absolutely loved. It was the right price and we will have it delivered next week. Sometimes everything works out for you. That's a bonus. And that's one of the blessings of being here in the mighty United States, I guess we'll call it because you can buy crap on basically every single corner. It is amazing how many, even in this day, how many still big box retailers are out there. So if you need something, yeah, you can always Amazon it. And we are so spoiled by that. Wow, I recently had somebody that took two weeks to come to me. I was like, what the heck is wrong with this? And it's like, oh yeah, this is actually how things normally work when you don't Amazon it. That is not a free plug for Amazon. Actually, it is a free plug for Amazon. If you guys want to pay us, that would be awesome. Thank you. Now moving on. So this episode, we're going back to the episode that was called Updating Developer Tools, Keeping Your Tools Sharp and Efficient. Once again, if you haven't noticed, the title itself basically came from AI. So pardon that. It just accidentally paused our stuff. It's too many buttons. Anyway, so it came back with not the fluffy thing it did last time. It's just basically like here are several key points and themes that will resonate with your audience of developers and side hustlers. So AI thinks you guys are going to be resonating. So hopefully this will work. We'll see how it goes as far as what we did as well thinking through these things. So core message, why tooling matters. Efficiency equals profitability. Limited tools cost time, create friction and slow down delivery, especially harmful for side hustlers with limited hours. Wow. I don't think that we covered that in this episode. I think we have talked about this in many ways in the past though. And that is really, really a key thing. I'm going to start with this because I have worked with a lot of people that have come out of either come straight out of college where they have like their limited tool set and that's it. They really aren't exposed to tools. They're more like command line stuff and things like that. Some you'll get like an IDE, but they really have not really utilized it. So things like debugging, usually they're not really comfortable with the debuggers. A lot of the auto-generated stuff that are in there, even if you like to use Visual Studio code that can run across, I don't know, countless languages, if you use the right plugins, you can do a lot strictly in the IDE and just get going. It'll spin up. You can spin up containers, all that kind of stuff. The modern IDs are really, really stinking powerful, particularly coming from someone who goes back to like the Emacs and compile G++, GCC days and stuff like that. This is really, I think, something that we don't spend enough time on in schools. And I think too often, this is where actually to me, this is a little bit of that coding developer, coder developer split, is that if you get too tied down to your tool and now you're five, 10, 15 years into it, you're going to miss out on newer tools and some of the things they can do. I will confess that I've been in that situation for a long time. I was stuck with the same Eclipse STS stuff that I'd used for years and years and years. It worked fine. It covered what I needed to. But I went over to IntelliJ because of a project I was on and it was like, all right, I'll go jump into this new IDE and really liked it. Not to mention the fact that because I had dealt with other IntelliJ tools, it really worked well in the wheelhouse that I was in. So I think, and that's where I think it's the creating friction and slowing down delivery. I think one of the keys is not only that you are using modern tools and staying up to date. Don't fall behind and work on Visual Studio 2010 when it's now 2025, but also as a team, I think it is very, very useful to have everybody just homogeneous tools across the board because you don't have to worry about throwing something out of a repository and then you check it out and now it's got all this extra crap that you don't need or somebody changes libraries for their IDE, but it doesn't get changed for your IDE. And I will get off my soapbox right now and I'm going to let Michael, because I know you have some thoughts on this as well. I want to throw this out to you. Yeah. So the whole IDE thing, we'll just start with that since you were kind of on your soapbox on that. Giving your team, I like the idea of everyone using the tools they're comfortable with, but the problem you run into with that is if you're dealing with larger corporations or larger teams, sometimes you run into issues where, well, you have this guy using Visual Code, he's running into a bug. Well, how do you debug it if the tools aren't really helping them? But yet over here in Eclipse or IntelliJ, oh, hey, we have this nice debugger. Sometimes the right tool or the right IDE really is what helps you. Sometimes it's better to just maybe do a hackathon maybe once a quarter or twice a year just on development tools or whatever it is that helps you and your company grow. Play around with it. Pick a solution like, hey, we need a continuous integration pipeline. We don't have that. Or our current one is slow. Let's go play around with this team, go play with this one. This team go play with this one. Come up with a solution and let's see if it solves our problem. Just be careful, though, that you're not trying to find a solution for something you don't have and then you try to hammer, square peg, round hole. Don't pigeonhole yourself. Make sure you're finding the right tools for the job. But when it comes to tools, we've been around forever. I don't want to call us dinosaurs, but I remember Lisp and having to write my own programming language back in college on a silicon graphics machine that doesn't even exist anymore. They got bought out by Oracle years ago, or Sun and now Oracle. Tools change. Languages change. It's ever changing. Get into something and never change. Always try to keep up with software updates, SDK updates. We're on a project right now dealing with Python. Well, Python's already gone through two major version changes just while we're on this project. Make sure that what you're working on stays compliant, especially if you're dealing with banks or whatever industry you're in. You could get into trouble very quickly because, oh, I'm two or three years behind in my technology and suddenly I'm now running into OWASP issues. I'm running into Sorbanes-Oxley. I'm running into issues. Be careful with that because it's not just your tools, but it could be external factors that are opening you up and your teams up to other potential problems. Before we move on, I really want to jump on the idea. I love the idea of a hackathon where it is IDE-specific or tool-specific. I think that'd be a really cool hackathon thing to do, particularly to take people that aren't in a certain tool or moving into a new language. It's not just a different language, but a specific tool to really show how that can work and you'd probably get some pretty cool sponsors based on that as well. The other thing that I wanted to mention was something that I've now forgotten, unfortunately, dealing with different tools and things of that nature. Since I've forgotten it, I guess we can move on. Here, I'll take back on with that. With your tools, especially if you're Visual Code, you mentioned Eclipse, IntelliJ, there are plugins that all these IDEs use. Plugins are another thing to be very careful of to stay compliant with and keep them updated because if you don't upgrade your IDEs enough, your plugins could break or they may not work as you continue to go forward. Be careful with plugins, be careful with your IDEs, but always try to stay compliant and current. The best example of this, you mentioned that your experience with Eclipse waned over time and you went to IntelliJ and it's like, oh, wow, hey, this is great. But yet, I was on a Spring project and I actually found that the Spring Eclipse build was better than the IntelliJ build when it came to debugging the server information. It just, for some reason, the Eclipse IDE was just so much easier to look at and play with. But as far as the coding side, though, IntelliJ was great. I actually found myself jumping back and forth between different IDEs for different features within them to get my job done faster. And I do think that's part of it. We all get connected more, we're more comfortable with what we know. So it is helpful for us to be out of our comfort zone at times. The other thing I was going to mention is the idea of having regular brown bag sessions or something like that where you talk about a new IDE, the latest improvements on one, plugins that you've used and you've had good experience with. Those kinds of things I think are very valuable. Better tools, better code. Modern tools often encourage better practices, cleaner code and faster feedback loops. I'm not even going to mess with that one. Sharpening the saw, staying updated is like keeping your blade sharp. It's a professional habit, not just a nice to have. We've actually just talked about that. Main talking points, signs it's time to update. Let's see how this one goes. Slow performance or crashes, lack of support for new standards and languages, poor integration with modern tooling. For example, GitHub actions and Docker team or community has moved on. For example, jQuery versus React. Now I think all of those are critical, are red flags to say, hey, maybe you need to move on or update or upgrade or things like that. I would say that one of the best, depending on where you're at, again, because sometimes you're stuck with what you're stuck with. You're in an industry that's going to be behind the curve. I would point to that last point about team or community. You don't always want to be the joiner, but you do want to look at what are the up and coming technologies, languages, frameworks. For example, JavaScript has a billion frameworks, it feels like. React versus Node versus Angular versus all of this stuff. And then especially when you start pulling in Flutter and Bootstrap and all these things that are like they're the varying languages or libraries and frameworks that are out there. There's a lot out there. It is worth it to stay current in what you've got, but it's also particularly if you are at a point where you can make a change to take a look at what's out there and see if it's time to change. JQuery has been around for a long time. And yes, there's a billion examples and stuff like that, but maybe that's not where you need to be. Maybe it's not, let's not write another PHP, JQuery type application instead. Let's move forward and have a nice little API where there's PHP and if you really like that language or maybe it's like now use Node for API server, you use React as your front end. Maybe you want React Native because you want mobile. I don't want to get into the religion part of the languages, but I do think that's very important as I think the community that is out there is a key portion of your decisions and should be part of your red flags because if you're doing something and people are not supporting it anymore, then you probably need to walk away from it. If everybody's going away from it, but it still has huge community support, then you're probably okay to continue. Thoughts on that? Yeah, the first thing that comes to mind is like Java 8. Java 8 is old, but it is still supported. It's still there. It's not something that's going away anytime soon. I mean, I think it's got like a few more years of like end of life before it hits end of life, but I will follow up with that. So I'm not going to go to it because you really touched on a lot of the good points in this. I'm going to touch on the bad points. Moving new things is great. Staying current is great. Keeping up with the trends is great. Moving your project to something that is bleeding edge or looks like, oh, this looks like a great technology. Check GitHub. Check wherever you're at. How old is this technology? How well is it supported in the community? From a testing standpoint, I will tell you I've been on many, many projects where people are like, oh, well, karate is great, or cucumber is great, or test and G is great. They go through cycles. But the funny thing is 80% of all testing frameworks were thrown at me. I would go out to GitHub, oh, there's like two people, two supporters, two people working on the project. You do not want to go to something that has a very, very, very small community. Not yet. It may be cool to learn. It may be cool to just play around with it. But there are reasons that, you know, Java works. There's reasons that Node works. There's reasons that React works. They have very large communities. They're very well supported. And you can basically throw a book at anything, you know, throw a dart. You're going to hit a site somewhere that is going to help you get what you need to get your job done. So just be very careful with where you go with some of these technologies. I agree 100% that there's some very good points there, things to think about when you're moving. In the interest of time, I'm going to jump ahead a little bit to evaluating new tools. We're sure to wrap up with this because I think while they, AI also kicked out categories of tools to regular review. I think we more, I'll fly through these. IDEs and code editors, version control tools, testing and QA tools, build systems and CICD. Jenkins, I'm looking at you. Package managers and dependency managers. Actually, Ant, I'm looking at you. If you're using that, or worse, containerization and environment management like Docker and stuff like that. So the one I want to talk about, evaluating new tools. I want to sort of leave you guys with this thought. So here's some things that gives us four bullet points. So if you're evaluating new tools, ask, does it solve a real pain point? We've talked about this quite a bit. Try before full adoption, start with a side project. Always, always, always, always. You get like a proof of concept. Michael loves to use the kitchen sink app as his baby. Those kinds of things. Just put something together to see how hard is it to do this or not with this technology. Check for an active community and documentation. Oh, documentation of some sort. You've got to have a balance between cutting edge and stable. You don't want to be so leading edge that you end up struggling with all this stuff when you can just wait a while and let somebody else struggle through that. A bonus point I will actually provide because I've been playing around with this lately is you can actually, in a lot of cases, take an app, depending on how you've got it, especially if it's a Hello World, a smaller app, and you can throw it into an AI engine until it's recreated in a different framework, a different language. And that will help you sometimes to sort of do a quick step into that language to see what it looks like because now you're going to take something that you know and convert it into that new language. I would recommend if you could do that manually, if you can do it yourself, that's even better. But if you want to do it, if you're if you're short on time, then do it that way. Michael, you're going to throw something out there. Just a little asterisk with that. Make sure you do not put any proprietary code in the AI because AI will own it. That's true. Try to avoid like passwords, usernames, some things like that. You know, the things that you don't want the rest of the world to see. Don't put it in there. It's just like if you don't want your pictures showing up on the Internet, don't take those pictures and upload them to the Internet. There's those kinds of things out there. That being said, we're going to wrap this one up. We have not gotten all the way through it, but we got through a couple of cool points as once again, it's amazing. It's really fun watching how AI thinks through some of these topics. And as we have said so many times, there are a lot of good books, a lot of good sites, a lot of good podcasts out there, and you're going to find a lot of the same thing. So it does come down to making sure that you like these are these are common knowledge. Basically, this is common sense kind of stuff. So utilize it. If you see it from eight or nine different sources, it's probably reliable enough. Even if they all made it up, maybe they made it up and it's got some sort of it's it's working for people. So good things to think about. Another thing you can think about is how to use your email better. Like send one to info at developernerd.com and just see are you able to send emails and we will confirm. Hey, we received that email. Let us know what you think. Any suggestions you have, comments, requests. If you want to be a guest at some point, we would love to talk to you about that because we still have that is a an opportunity, even though we're like cranking through this and AI is our weekly guest right now. We may take a break and pick somebody else up along the way. As always, I'm not going to go through all the places you can reach out to us. Just if you see us, feel free to leave us some back at some sort of update comments, like us, all that kind of goodness. As always, 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. Thank you.