Building a Strong Developer Toolkit - Enhancing Skills and Productivity

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 season of growing better developers. We're on the developer journey. We started way back at Hobbiton or whatever it is and we're on our way to Smog's Lair. It's been a while since I read that, so if I got it wrong, I think it was the Shire is where they started, but that's okay. Nevertheless, try not to geek out too much. I am Rob Brodhead. I am one of the founders, sadly so, one of the founders of developer and building better developers. Also a founder of RB Consulting where we help you wrangle those dragons of technology and we help you through integration, simplification and automation, find ways to actually like focus that energy, to take all of that stuff out there, all of the time, the effort, the data entry and all the stuff that goes into using technology and leveraging it for your business and find a way to streamline that stuff and give you a better return on investment for the time and the money that you put into your tools. I'll go ahead and do the good thing, bad thing. I'm going to go with the really simple bad thing is, and this is maybe a little bit of a cautionary tale. Right before I was doing all of this, I was all lined up. I was going to do this little demo for a customer. I'm going to record all the stuff and be like, you do step A, step B, step C, boom, boom, boom, boom. When I got to step two and I was like, I should probably cut it off here, but I was like, no, I'm going to go a little bit further. And I went a little bit further and bam, right into a bug. There was something that was like something wrong. Something was like, you know, it turned out to be something very simple that I did. But nevertheless, be careful with those kinds of things. It's better to do stuff in a bite sized chunk. Good stuff. Oh, this one may be near and dear to your heart. We have had a customer, a project that we've been working on. And one of the things we need to do is deal with Facebook meta. We have its API integration stuff with the Facebook meta place. We aren't doing anything crazy. It's not a Facebook application. It's not really anything other than we just want to use the API to access publicly available data. We're not trying to get something off of a user. Anything should be super simple. We have spent three weeks, I think now trying to work through the whole approval process to make sure that we cross our T's right, dot our eyes properly and label and categorize our applications so that they actually understand what we're doing and say, oh yeah, go for it. And, and approved us. And we finally got approval after all of these like headaches and they would send us stuff that was totally useless information to say, here's how you could approve it. You could submit it better. And it had nothing to do with our application. So their process, very painful. We got through it. Big V, big victory, more of a victory. So you now get to listen to Michael and his good and bad thing and his introduction of himself. Go for it. Hey everyone. My name is Michael Milosh. I'm one of the co-founders of developer NURB building better developers. I'm also the founder of Envision QA. We're a new rebranded company from a large consulting. We help small to mid-sized businesses and clinicians build software tailored to you, what your business needs are. Instead of you buying all these cookie cutter software packages that are out there that may give you part of what you need and maybe not. And you have to build all these manual process. We eliminate that. We help you automate your processes. Good and bad for the week. The good I have taken the step back. I'm finally taking a vacation and getting some nice R&R. Thankfully. And the weather decided to participate. So we're finally not as hot as we have been. The bad side. Wife just found out she has to go travel for two weeks. So I will be a bachelor for two weeks with a bunch of animals to deal with and kids. And it's going to be a scheduling nightmare. But hey, if I follow our own practices, I should be fine. There you go. This episode, we're going to talk about basically get into. We've talked about like having your own personal repositories or having like your quiver of arrows. And how do you get technology in there? How do you grow? How do you become a better developer? How do you build these skills? Well, one of the things is now instead of just want to talk about this episode, it's not just general skills like, hey, I'm going to go out and I'm going to learn to program code and C or cobalt or Java or Ruby or blah, blah, blah, whatever the language is. It's really about which goes back to it's about problem solving. It's about having tools and utilities and ways for us to more quickly get the job done. Now, one of the ways, one of the the most I think like complete ways to help yourself learn something better, to learn some really cool problem solving, to improve your, your general ability to get stuff done and productivity levels is actually code generators, anything you can do that is either using a template of some sort and then just using that to just like bam, bam, bam, crank out the tasks that we do every day, which is you will see these in a lot of IDEs, they'll have their little source generate and it'll do things like get all my getters and setters or just throw template comments everywhere so that I've got boilerplate for my classes or adjusting like parameters and some things like that that are just very common tasks that you go through the AI tools that are out there. Now you'll see that where it's like, it knows because we do this a billion times, it knows that you're about to create a class and then walk through all of the properties of the class and assign a value out of that or copy it from another one or whatever it is. And you'll see AI will just be like, bam, you've got all your code and you'll have to double check it because it will guess some of your properties wrong. But generally speaking, those kinds of things, those repetitive things that we have are excellent candidates for us to learn how to use a tool better, but also to scratch our own itch, to make sure that the next time we do task X, we're going to be able to do it faster. These are the utilities that are very helpful for us to have for our own purposes. Also, to use if you want to have a, for example, like a GitHub public repository that you can show off your skills, those are great tools to throw out there. Now, if you're building something that's like super secret, it's like really awesome. You don't want to do that because you don't want to release all that. You want to go make your commercial product and do your side hustle. But if it's a, especially a little tool, utility kind of thing, that's a common task, simple stuff like the things that I remember when I started out, it was things like just finding files within a bunch of directories or finding files of a certain size or like one I had, it was literally just a little tool that allowed me to spin through a huge text file and do some very simple manipulation. Things like I wanted to take a, back in the day when space was a bigger issue, I wanted to take like a, you know, a 2 gig file and just go through and wipe out every third row from this big nasty CSV so I could get it to something that was more manageable or things that you can do. Like there are tools out there and some of you that are yelling, you know, Unix does all of that. Okay, fine. Yeah, I get that. It does to some extent, but maybe instead of, yes, you can do that. You've got like a little shell script that goes and does the, you know, the awk or the said stuff that you would normally do to do all of that processing. Also, you can do this in things like Java or Python or C or pick your language of choice. And it's a way for you to play around with that language to show off your skills. It's going to be a small bite size kind of thing, which makes it really easy to like knock it out of the park, have really good comments, be really intentional about how you name your variables and how you comment along the way and how you package it. And maybe if you have a read me or things like that, all of that stuff is a great start for your personal repository or your, as Michael likes to talk about your kitchen sink app, where it's just like, these are the things, these are the tasks that I'm going to do or that I run into on a regular basis. And so I want to be able to have a quick way to get that done. And this is actually even useful. I've found if you jump languages. So if you have like, let's say a series of things that you did in Java, there are all these like basic code snippets that are, this is how I solve this problem. This is how I solve that problem. Here's an example of me doing this. And maybe you can run it in Java and you can do it in a small way, but also maybe you use that as a template. So now I'm going to go to C sharp. Well, it's like, well, all right, I'm going to just pick up that Java code, drop it into a C sharp app. It's not going to compile, but I can look at that. And it basically now gives me, you know, my step by step approach. Okay. This doesn't work. How do I do this in C sharp, which becomes an easy thing to throw out into a search engine or go look it up in a reference, however it is, so that you can then translate into whatever that, you know, that language is, or you may even be able to just look at existing examples and walk through the code and go, oh, this is how we do it in this language. And the next thing you know, you've been able to quickly do maybe some very complex problem solving in that new language or that new environment. Thoughts on that, Mike? Boy, you brought back some memories. I know I talked about kitchen sink apps a lot and like the utilities, you know, especially if you're in Java, you know, you have Maven, you've got all these third party tools out there and Apache commons and things for that for a lot of utility classes, you know, like how you manipulate strings, for example. A lot of this to me, I kind of went through this process years ago, back in the nineties, when the web first got popular, we had to start learning HTML. Back then the internet was still in its infancy and you couldn't really, Google wasn't a thing. You really didn't have something that you could go look up all these tools. So way back when I was learning HTML, I actually wrote something very similar to what is W3C schools today, which is a website of nothing but examples for like HTML, CSS, JavaScript. And typically today I call that a kitchen sink because as you're building these code libraries, as you're writing things, as you're learning things, you're going to write specific functionality that is going to be very powerful to you to be reused in other applications. For example, in one project, you might actually have to encrypt customer data. So now you have to write an encryption tool. Well, that encryption tool, if you follow best practices is probably going to be an encryption tool that can be reused again and again and again. Other things like string manipulations. Now, again, I mentioned, you know, if you're using Java, you probably should be using the Apache common libraries for this, but you could write your own string utility class to determine how do you lowercase uppercase, how you strip out special characters. But the other thing is this utility class could be a specific functionality. It could be, Hey, this is how we handle strings for banks. This is how we handle strings for like Epsodic, or this is how we handle strings for ASCII. So you could actually build these utility classes for specific functions. Not only is that good for a kitchen sink gap, but this could also be your own way of tapping into the Apache orgs library or other utility libraries that are open source and shared by the community. So you can also get your name out there in the industry. Some other things I've run into, like Rob mentioned, the boilerplate code. I talk about test automation all the time. One of the biggest annoyances is a lot of the frameworks that are out there for building testing require a ton of boilerplate. And if you do the boilerplate or if you follow it correctly, you're essentially duplicating code for every single test that you do within your application. Well, one of your kitchen sink apps could be how do I generate that test and build a framework for doing this within a specific Selenium or test ng or cucumber. That way you go into the next project, you push a button, boom, there's all your test cases. You don't have to reinvent the wheel. And finally, the other thing I really love about this idea is with containers. So now we live in a world where we have cloud base, we have containers, we have Docker, we have Kubernetes. So now you can actually build a kitchen sink app that can be deployed for anyone and can be expanded, reused. So you could build a mail server using SendGrid, compose it, build it, drop it in your kitchen sink. Now you don't need to put customer proprietary information in that, but you now have this little kitchen sink utility that, oh, I need a SendGrid app. Click boom. I now have a fully functional environment to test with or to configure. Or sending email to a specific client or customer. So there are other ways you can do this within your kitchen sink app to not just build utilities, not just, you know, navigate the boilerplate code, but you could actually build your own custom utilities. You can contribute to the open source industry, the open source communities. You could create something innovative and kind of give it your freeware. Hey, here's an introduction to this. Check it out. And then maybe bring them to your site to sell them the actual software. And finally, build custom environments. So you can go from one environment to the other by a push of a button. You build these configurations out there, you reuse them, and then you just tweak them as you need them. So it's a lot about automation. I know we talk about AI a lot because AI is getting popular, but the thing is AI is not quite there yet. I still test it every now and then say, Hey, build me X and I'll get something close, but nine out of 10 times I have a utility or I have a kitchen sink app that does it better. So while you may rely on AI to get started as you get better, as you're building your skills, look at best practices. AI isn't always there yet, but it's a tool. Use all the tools in your toolbox to make sure that you're moving forward. You're getting better and you're always pushing the envelope, always trying to find that next best thing so that you're not getting stale and you're always learning, you're always looking for that next thing. Rob? You touched on something that we haven't really gotten too much into, but I think is really useful, particularly in the container world. And it's something I've actually gotten. So I do more often now, granted I've done it a lot of times by just having like an AWS EC2 server up and I have it set up, but it's configuration. In particular, common configuration things, for example, most of us probably at some point have had to use Apache and configure to virtual host. Most of us at some point have probably configured Apache with a virtual host and had a typo in there or something that wasn't the right, you know, we had like a some of those uppercase instead of lowercase, something like that. Just those ridiculously annoying little configuration problems that can cost us days and create incredible headaches. It is really useful to have as part of our kitchen sink app, something that runs like a complete, you know, soup to nuts things that runs, particularly in a container, because then we can do stuff like say, okay, I'm going to take that thing and I'm going to see what happens if I like, for example, bump it up to the new version of PHP or Python or whatever it happens to be, or Apache or the operating system or the database. Where am I going to hit problems with that? Or potentially it's like, where is it? My problems are just, I didn't type the configuration string properly, or I didn't get that key right or something like that versus this is actually something where it's like, it's a code issue. It's those kinds of things. I've had a lot of those. It's amazing how often I will get into it and I will have multiple servers. This is even as part of development where I'll have multiple servers available. And I'll go hit it with a database and then I'll go post it, you know, have a different database or a slightly different snapshot of data, like the data that works over here. And now when you do it over here, it doesn't work. And I'm like, well, it seems like it should work. And then if you just copy the data over, you realize that, oh, it's only data. That's a different thing. It's not one of those other things we could talk about. It's like, how do you, it's really, it's isolating the problem. And if you have a stable static environment of stuff or your utilities, whatever they happen to be, your tools, it allows you to have something that gives you like a foundation to work off. Things like string manipulation or searches within strings, particularly if you get into the road of like red, you know, red regular expressions, regexes and stuff like that. They could be really annoying basically. Now some people are, you know, regex masters and you've got all this stuff. But for most of us, you use it here and there, but you don't use it enough that you really have maybe some of the ins and outs of things like how do you, how do you find an email string, you know, somebody or a phone number when the phone number could have dots or dashes or parentheses or things like that. You know, there's, there's these things that we're starting, particularly if you go into the world of like data scraping and stuff like that, or even. Just trying to clean data in a free form database where people have entered things 18,000 different ways, finding that data and cleaning it up and things like that, it's really nice to have those utilities where you have a known quantity, you have something that you know works for maybe X problem. But now that you've maybe tweaked that problem or massage that problem a little bit more, then you're trying to write that solution. At least you can go with one that's like, you know, what's 90% there or 80% there. It's like, okay, this works for these cases. So at least I know that's right. So if I'm, especially if I'm having to write all new stuff or in a whole different environment, I have a, it's really, it's like in my own little unit test or my own sanity test to say, does this at least cover what this thing does? Am I actually making an improvement? I may be, maybe going a little off track there, but the configuration stuff is such a headache. It is such a challenge in so many cases where it's just like, this should be up there and I should be able to spin this up in five minutes and two hours. You're still walking through it because you're trying to figure out which file, which letter or where is there a space or where did you, you know, like those little things that it's nice to have something, you know, this works. So you can go verify that and then you can just do a diff from that. And the one that you created things of that nature, uh, closing thoughts on that. Yeah. The only thing I would tack on kind of with our conversation from last time is as you do this, as you build these, these kitchen sink gaps, these get hub repositories, the code, you know, portfolios for yourself. You know, if you build these, you're not just going to want to let them sit out there. So once a quarter, once a year, maybe every six months, you're going to want to constantly go back out and make sure that it works with the latest versions. Because typically if it's something you put in there, it is a complete piece of code. It's a complete unit of functionality that as long as you keep it updated, the next time you need it, you just go pull, you know, it's going to work. Boom. You're working. You don't have to reinvent the wheel every time. Like I said, you find something to do encryption or email, put it out there. Next time you need to do email, just go pull it in, kick it off and you're done. Uh, tweak it, you know, and if you write these well and you write them clean enough, you make them module. You can even make it to where you just pass in the configuration or some parameters and you're going to get what you want from it. So it's again, it's a very compact piece of code. And that honestly is where you can turn those things. This could eventually become a little moneymaker for you. That was one of the, one of the early companies I worked for. We had a bunch of tools that had come out of, uh, we built software, but we also had consultants and there were tools that the consultants used. And there were tools that we use as part of our development. And we got together at one point and actually turn that into a product in itself. That was just a suite of tools that you could use to improve your development experience in that, in that technology on that platform. So there's a lot of ways that this stuff can benefit you, particularly as Michael said, if you're constantly going back to that thing and reusing it, every time you do it, you may find like a little bug or a way to improve it or something like that, and eventually you have something that maybe has been. You know, trialed, you know, trial by fire multiple times. It's really tried and true. It's been proven in a lot of different environments. And now you have something that is, you know, maybe a rock solid little library to either, you know, as itself sell us like a little, you know, add on somewhere, or maybe it's a piece of it's a start into a, a larger, you know, solution or product same way. We like to take your emails and those little things that you give us and all that little advice and turn that into bigger things like an episode or maybe even an entire season. So please show us an email at info at developer.com. Leave us comments here, wherever you get your podcast, if you're listening to this or here, if you're on YouTube, which you can always go to the YouTube channel, develop a newer, you can see these and so many other things we've been around for, I think five or six years, maybe it's probably more than that. Now we have literally hundreds of, from, you know, 15 minute, minute snippets to 30, 60 minute full on presentations and things like that. It's a lot of information out there. That's all in the YouTube world. You can also find it out on the, at development or.com. We've got links to all of that kind of stuff, not to mention blog articles and all kinds of other funness, literally over a thousand articles out there and links to data, to content, to examples. And you can also go to, if you, if that's too much, you can go to school.development or.com and you can find some much more focused classes. Some of them are free. Some of them aren't, but some, some material there to just like, maybe get to know some of these things a little bit better and figure out where you want to go next, maybe get yourself off of your plateau that you have reached. That being said, I want to respect your time. And so wrap this one up, 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 developer 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.