Letting Go of the Past

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are getting near the end of our season, well on our way through 20 and soon we will be in season 21, just a few weeks away from that. This episode is a special topic. We are going to talk a little bit about letting go of the past. And this is something that as we get to right now, we're sort of at the beginning of a year and people look back at the year behind and do the, we've talked about retrospectives and things like that. One of the things that I've run into a lot and is, I think a lot of us have seen this, and is also a challenge for businesses, is essentially the, hey, that's always the way we've done that. Or this is something that's worked for me in the past. And this may be a process, it could be a procedure, it could be a piece of software, it could be some sort of pattern or template that you use. And it is definitely worthwhile to periodically take a look at what you're doing and just reevaluate it. Because it makes sense to keep doing X, whatever that is, or to keep using it, or even to keep using it in the same way. Now, this is really a vital thing for us to think about because as developers, I think particularly after we get past our first few years of being a developer, there is a point where we are settled in, let's say. We have our tools, we basically understand what's going on. Yes, we're solving new problems every day, but we're sort of solving them the same way. We're looking at stuff and saying, hey, this is something that looks like, let's say, this looks like a hammer, or it looks like a nail. I have a hammer, I'm going to go ahead and use the hammer on this nail. Now, in particular with our tools, our IDEs, our development environments, whatever it is that we use, they advance. There are new versions. Likewise, there are new versions of our languages. There are new features. There is new syntax. There are whole new things and features and functions that we can use to solve our problems that maybe weren't there six months or a year or five years ago. And it's important for us to periodically do that, we'll say, assessment of where we are, what we're using, and how we're using it. Because there are people out there that are working to make our lives better, to make us more productive. Now, this could be in the form of, particularly these days, a plug-in or something like that, that some developers somewhere saw a need and they went out, created it, put it out there. It may even be free. And that's what's been amazing to me is when I look at some of these tools, which is actually now most of the development environments have some sort of a plug-in, whether you're using Visual Studio Code or Eclipse or any of the others that are out there, the JetBrains families of stuff, they have plug-ins. And those plug-ins are, yes, sometimes they're supported by the vendor. A lot of times they're not. There are third-party things that are out there and there are risks in using those. It may be that they aren't that good. But like everything else, test it out. Give it a shot. Take a look at what's out there, particularly these areas where you've got a store or a library or something that you can search. For example, just because I've recently used it a couple of times, would be Visual Studio Code. You can look at their extensions, their plug-ins, and you can search. You can say, I want to find everything related to SQL or Java or Python or PHP or C Sharp or you name it. CSVs. You name it, there are going to be some plug-ins are going to show up on that search. And if you spend a little time reviewing them, you might find something that suddenly fits exactly a need that you have. Now this is on a very simple case. A plug-in is pretty easy to use, pretty simple to find actually in most of our tools. Now a new tool or a new site, that's going to be a little more complicated. However, it again goes back to this idea of at least I would say every year, probably better to do it about every six months, assess where you're at. What is it you're doing? How do you do it? What are the tools that you use? And look at it with an eye of is there maybe something better? Is there something new out there that I can pick up that I can use that will help me be a better developer? This includes, and we've talked about this a lot, is new languages, new technologies, new frameworks. For example, AI, you may have heard about this thing. It's been pretty big. A couple of years ago, nobody really talked about it. But maybe now is the time for you to take a look at some of the tools that have come out that have embraced this AI revolution, we'll call it. Likewise, the cloud has become very, very stable. Cloud-based tools and software as a service kinds of solutions that are out there, five or 10 years ago, maybe were a little more shaky or a little weren't as reliable as you'd want them to be, or they maybe just didn't exist. Because as people have gotten comfortable with that platform, we're now seeing more and more of that. I'm not sure how far back you have to go, but these days as a developer, everybody's used GitHub. It's out there. People use Git all the time. It's very common. It's very popular. I haven't seen a project that is not in Git of some sort, whether it's GitHub or Bitbucket or one of those in years. Whereas go back five, probably closer to now 10, seven to 10 years ago, there's a lot of places I went that still use Subversion, SVN, had been around forever. They just stuck with it. It was there. And it is just not a very fun version control environment to be with, particularly once you get used to the distributed ones like Git or Mercurial or some of those. So take a look, not just, and that's a good example, version control tool can be a big change because if you move to a new one, you probably are going to lose history. Who knows what else you're going to lose in doing it, plus you're going to have all new tools and stuff like that. So that would be the example on the other end, basically of plugin, quick and easy. You can test it. No big deal. Actually only affects maybe one developer. Version control tool can affect the entire team, the entire organization. So a little different on the risks that are involved. However, some of these things, it is worth the risk. If you're still building flash applications, probably worth the risk for you to go see what else is out there to solve the problem that flash did for you 15 years ago or 400 it was that you built that application. And it looked really good at the time. It looked very much like the wave of the future and then disappeared. And there are several of those things out there where what you chose at the time may have been exactly the right thing to choose at the time. But now time has marched on. Things have moved on. I find organizations all the time that fall into this. We had a tool, it worked. We put business logic and data and things like that into it. And sometimes they find out too late, but a lot of times they sort of say, hey, this is starting to get clunky. This is starting to cost us. It takes too much time. It's not what it needs to be. I see better tools out there. Those are the kinds of things that we need to be doing as well as developers, as people that are on that entrepreneurial technology side of the bubble or the table, however you want to look at it. People with those skills, we should be the ones that are keeping an eye out. That doesn't mean we have to try every product. That doesn't mean we have to go through and do a review of every new thing that comes across. It does mean that particularly in our sphere, in our area that we're working, we should be checking stuff out from time to time. We should have an idea of what's out there. That doesn't mean we know everything. Because you can do things like listen to podcasts, check out technology sites, go to vendor pages. If it's whether it's like a Microsoft or Oracle or Java or somebody, or sorry, Oracle or one of those because Oracle is Java. But IBM or whatever your tools are, whatever your main site is, even if it's an org. So if it's like one or two, there's a lot of them, of the Python sites or the PHP sites or the various JavaScript frameworks that are out there. Check those things out because you will see usually some of the new products that are available. You'll at least see maybe news articles related to them, particularly if you're dealing more with like blog sites and podcasts of things of that nature, is it is much more likely for these things to come up. And those are perfect because then it's, oh, hey, I haven't heard of that. I'm going to go check that out. And I do that even on not very technical podcasts. A lot of the entrepreneurial podcasts I've listened to over the years, even business podcasts I've listened to, they will mention sometimes products that I'm like, oh, I haven't heard of that. I'm going to go check that out. And it's usually pretty easy because it's productname.com or something along those lines. Or just do the product name search. Unless it's a super common name, then you're going to be able to, you know, probably be able to track that down and say, huh, I wonder if this is something that's useful to me, my organization, my customers. So don't get too bogged down in this works for me. I know it's easy sometimes. You're just like, you know what, I'm busy, got a lot of work to do. I don't really have time to go look for new tools, but just like we're selling our customers a lot of times on, hey, yeah, it may cost, it'll get to get you from point A to point B. But when you get to point B, you will more than make up in productivity, time, other resources what it costs you to move from point A to point B. We should, as well as being evangelists of the, hey, technology is moving forward. We can use technology, leverage that to make your life easier. That's why we want to be better developers is we want our customers to be better at what they do. In a similar sense, we need to drink our own Kool-Aid in a sense, you know, or however you want to look at it is we need to also say, what's out there? Are there ways that I can be more productive, more effective, create higher quality code, create it faster, solve more problems, scale, make it easier to maintain my code? All of those things that are factors or even pieces of what is it, what does it mean to be a better developer? What does it mean to do better? Well, we've got all these different ideas and those ideas, a lot of them, the way we get to that point is we do things differently and we maybe do it with a different tool on a different platform. So by definition, almost, if you want to be better, you can't have the answer of that's the way I always did it, or it's always been that way. Whenever you tie yourself to the past like that and say, Hey, this is what happened. This is what worked yesterday, last year, 10 years ago, it still works. Then you're basically setting yourself up to failure because if you get to the point where that thing that's always worked now breaks, a lot of times there is no path from where you are to what actually works. And I have great painful stories to tell of customers that I've experienced where they did that. They waited until they were on an unsupported platform and it was on an unsupported operating system and they didn't even have the, they didn't have a way to go rebuild or get a current version of the development environment that their solution was built on. They may not have access to the code, they don't have access to developers, they don't have access, like all of these problems that basically are a, Hey, you are trying to do something that literally cannot be supported. There literally may be zero ways to migrate your data depending on what you have. And so it's like, okay, you can stop where you are and be, you know, die as a business or you can essentially reboot the entire thing on a whole new system. And that is not what anybody wants to hear. And honestly with us, that's not what we want to do. We don't want to be in a situation where you are a COBOL programmer after the Y2K issues. Yeah, that was great. And that was the only reason that that worked out was because of the fears around Y2K and because people took some shortcuts way before. Ever since that, ever since those little projects finished up, and if you don't know what that is, just go ahead and Google the letter Y, the number 2K, you know, bug, error, scare, pandemic, panic, whatever, and you'll find stuff about it. But essentially what happens, you had all these systems written in COBOL and everybody is like, Hey, COBOL is great. We're always going to use it. It's always going to be here. And then it wasn't. It's still there. Yes, there are niches. I get it. Don't send me an emails that say, Hey, I'm perfectly happy doing my COBOL, but most people aren't. So most of the people that were doing COBOL, granted, now most of them are getting to retirement age, but if you were just starting out your career in the mid to late 90s and you were jumping on the COBOL train because, Hey, that's what everybody else at that organization did, you are not doing COBOL right now, most likely. You somewhere along the way were forced into something else because you had to learn something else to get a job. And that's where we have to be ahead of the curve enough so that not only we can help out our customers and even our careers so that we know, you know, we have an idea at least of what's out there. And we also are, you know, at least have got like a first couple of steps. So if some, if there's some big technology change, like whatever our programming language or environment or whatever disappears, that we're, at least we've got some ideas of where to go next. Better yet, we've already played around. We've got maybe some experience in those things. We've built a couple of applications or we've done some projects in whatever that new technology is. That's where we want to be. We need to be ahead of the game like that. We want to be in a situation where we're not caught going, Oh no, I've got to learn something right away. It's just like getting a new job. You don't want to be looking for a job when you don't have a job. If you're going to change jobs, you would much rather be looking for that new job while you have a job. And that way you're not as quick to just jump on the first job that occurs unless your job, current job really, really, really is painful instincts. In which case still you're in a situation where you're essentially running from something instead of running to something. And as better developers, that's what we want. We want to be leading. We do not want to be behind the curve. We do not want to be sitting there trying to drag our customers back so that we can be comfortable in our technology. Instead we want to be pulling them forward and doing it not because this is the way we always did it or because we just, if we can't move off of this, then we're out of a job or something like that. But instead that we're moving them forward saying, Hey, I see what you're doing. It's great. It's working for you. However, have you tried this? It will make it better, faster, easier, all of these positives. That's where we need to be. We need to be on the positive side of this where we are moving customers or our employers or whoever it is, we are moving them forward because we're saying, Hey, look at this list of positives. Look at these pros that we have for moving to this thing. As opposed to here's all of the cons that we're trying to overcome. Instead of the negative of, Hey, you know, it's risky or something like that. Instead it's, Hey, yeah, it's risky, but here's all the benefits. It is worth the risk. You don't want to be a situation where you say, yeah, it's really risky, but you don't have a choice. Your systems are dead. You you're just trying to pick the least horrible option right now. That is not where you want to be. That's not where you want your customers to be. So as you're thinking about the year ahead and what am I doing, whether you're listening to this in January or even in July, whenever it is, when you're looking forward and you're assessing where you're at, make sure that part of that is that you are also releasing the past, we'll say. At least you're not hitched to the past. Yes, there are things in the past that worked well and maybe are still, they still make sense, but question that. Don't assume that because it worked well three months ago that that's still the best way to go or six months ago or a year ago. Every so often question that, take a look at it and say, you know, just in any kind of retrospective where you say, Hey, is this the best way? Do I know if this is the best way? If I don't know, what are the things I need to do to educate myself so I can, you know, firmly say, yep, this is what we need to do, or here's at least, you know, at least here's the alternatives and here's the pros and cons related to that. Here's the risks and the rewards that we may have going to these alternatives. Don't get yourself or your customers or your employer, your organization in a situation where you have to say, we have no choice but to change. Yes, it may, it may be that it's bad management decisions and they keep pushing it off and kicking it down the road and all of those things until it's too late and you get to that point, but you don't want to be the person that has been, you know, just joyfully going along until that point saying, Oh yeah, everything's great. This is awesome. You want to be offering options and offering the, the warnings for lack of a better term that, Hey, this thing that we're doing will not last forever. This is the likely lifespan if we know what that is. Sometimes we do because sometimes we know, Hey, this operating system, this product is going to be sunsetted in a year, in two years and five years, whatever that is. So if you know, now granted, you know, people, organization may extend that, but that should be a line in the sand where you're looking at it and saying, Hey, we are deeply rooted in this technology and we know that they are right now saying it will sunset in two years. The support will stop in two years. That means you better make sure that you've got somewhere on your plan, a way to get off of that or move to a new version or whatever it is within that two years. Don't get caught by surprise. And suddenly it's like, Oh, that's right. Nothing works anymore. You want to be ahead of that game. And that's part of what they rely on us to do. That's why they quote, pay us the big bucks is because we need to have our finger on the pulse to some extent of technology and where it's going and what's out there. So we can give them sound advice on here's what we can do. Here's what we need to change. Here's where we need to evolve. Because when you do that, you're really starting to add value into the organization. You're not just writing code. You're not just solving a couple of problems. You're solving problems for today and for tomorrow. Hope you enjoyed this special topic. If you have any questions, shoot an email at info at develop and order.com. Always happy to do that. If you have any requests, whether it's for a season or a special topic or a question or anything like that, hey, if you even want to be a guest, feel free to reach out to us. We get a fair amount, but if it's something that fits, then go for it. Please don't say that you're a huge fan that you listen to all of our episodes and then completely tell us the wrong thing and say, I love all of your podcasts about Smurfs or something like that that has nothing to do with any episode we've ever had. But 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-Noor 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. Please check out school.develop-a-noor.com. That is where we are starting to pour a lot of our content. We've taken the lessons, the things that we've learned, all of the things that make you a better developer, and we're putting it there. We have a range of courses from free short courses up to full paid boot camps. All of these include a number of things to help you get better, including templates, quick references, and other things that make us all better developers.