Boost Your Developer Efficiency - Automation Tips for Developers

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season, season 21 of the Building Better Developers, Developer podcast, where we're here to just help actually ourselves and you become better developers with ourselves. It's sort of just bouncing ideas off, thinking through what we've learned and making sure that we, I guess, catalog it a little bit for yourselves. Hopefully we're helping to share our successes and even our failures so that you can lean more towards the successes and have less failures of your own and fail in new and unique ways because that's what developers do best. I am Rob Brodhead. I'm one of the founders of Developineur. On the other side, you are? Is Mike Maltz, another co-founder, developer and founder of Envision QA. And so you notice I'm like turning the fire up a little bit. I'm not even helping him with his introduction now. So if he forgets his name, that's on him. Not on me. I just like I'm pushing him, making him a better developer because if you know your name, you're a better developer. That being said, let's get into this episode. I want to talk about shortcuts and things that we can do to help ourselves be more productive and a better developer. We do this a lot for others. This is part of our benefit. Our value is that we're coming in and looking at processes and systems and finding ways to automate and to improve and to performance tuning and all of that stuff. And maybe like the plumber that's got a leaky faucet at home. I wonder how often we do that for ourselves. If you're like me, not enough. If you're more like me, then you at least do regularly take an inventory and say, hey, here's some things I can do. Much like what we do for our customers. If we see a customer, if we're working in a company and we see somebody doing something that it just pains us to watch them do it. Either they do it over and over and over again and it could easily be automated or it takes forever and there's a way that maybe we can automate that to allow them to walk away or to speed up the process to do performance tuning and things of that nature. Now I think the easiest way to get into helping yourself is look at just like we do with our customers, look at what you do on a daily basis. What are some of the things like the repetitive tasks that you do? And then what's some opportunities then because they all basically are, what are some opportunities to improve those? Now they can be things that vary from, and we've talked about this before, like on the email side of stuff, the app stuff. Emails, if you don't use filters, labels, rules of some sort, start today. Just if you pick one. If you just go in, look at your inbox and you say, I could apply a rule to two emails that would save me time on those. And that could be like organized emails, like I said, I could apply a rule to two emails that would save me time on those. And that could be like organizing them, replying to them, whatever it is. Just, you can do this in probably five, 10 minutes a day. Just do it for a while. The next thing you know, your emails just going to disappear. You're going to be in a lot better shape. I've preached this before. I will preach it again right now is that you should do that. But on the development side, because we've talked a little bit about your processes and stuff like that, but think more about your development side. What do you typically do on a day when you develop? Well, what are some of the things that most developers are going to run into? Is there some sort of status reporting that they do every day, whether it's setting up for a standup or at the end of the day, you know, there's some sort of thing like that that they're doing that status reporting may also be heaven forbid, putting useful comments on your code commits and things of that nature, which is another one. We commit code or should be committing code fairly regularly. That includes maybe working with version control. So maybe you need to do that. You look at things like you maybe you're creating branches on a regular basis. If you have a branch for every task, every ticket, and you're working multiple tickets a day, then you could be easily creating multiple branches per day. Merging. Everybody would love to automate merging as much as possible. Some of its builds, it's it may be just, you know, maybe you're compiling code. Maybe you're having to copy code out to a dev server or something like that. If you don't have you may have, you know, see ICD may have like pipelines and all that kind of stuff in place. But if you don't, then maybe you should build some or maybe you could use some, you know, some scripting to help you out with that. Particularly I find this early on when I when I get a new customer and I've got a new project, if it's a and I'm talking like brand new. So this is I'm not taking somebody else's stuff on because although even then, if I'm taking somebody else's stuff on and they've built these things out, awesome. I'm going to use whatever tools they have to build process stuff for myself. If I make something new, one of the first things I'm going to do is I'm going to have a I'm going to have a sequel. If it's a database thing at all, I'm going to have a sequel script. That's like how do I create my basic users, crazy basic tables, stuff like that, depending on what the app is, I may be able to or the environment that may be part of it is it maybe does some of that stuff for me. But there's like there's always that foundational stuff you have to add. I'm almost always going to build something. I've got a build dot XML and script that I have used, tweaked, modified over the years many, many times. And it basically gives me my it's with a single command. I've got things like being able to clone stuff out of get really easy copy, you know, commit stuff in to get pull it back out, copy it out to a server somewhere, package it all up into a nice little car ball and throw it somewhere. All of those kinds of things that typically is not tough as a developer. It's like I'm going to write I'm going to type out five or six commands maybe. And but depending on what your directory structure is and stuff like that, it may take you 15 or 20 seconds. And if you're running it several times a day, it's just it's less prone to error to be a little faster to do it. And that's what we're looking for for these kinds of tools. And before I toss over, Mike, I'll suggest things like ant or you can use some of the more nicer tools like Maven and things like that. You can have some tasks that are built into there. You can also use like go back to go old school with Unix. You can use said and awk and some of those kinds of things. If you're Windows, you can use power scripting and batch stuff. Make use of these things. Shell scripts. If you're on any Unix environment, shell scripts, make use of these things because it will speed you up and it will save you, particularly when you're doing things like IP addresses and server names and file paths and all that kind of stuff. You're like, did I put it on this level or did I put it over there? Was that a three or two at the end of the IP address? And also just the typos when you're typing it, just those simple things you can probably you're probably going to skip it, but it is one of the things you could probably sit down in five or 10 minutes, do it, and then it's done. And now you've got it and you're ready to go. So now I'm going to toss. I'm going to do it and be done and toss it over to Mike. Let's see. What are your thoughts on these and where do you want to go in this conversation? So I want to add on to your shell script comment there for a second. So one of the things that I constantly run into is every time I come into a new environment, a new machine or a new company, and I have to set up a new development environment. The first thing typically you run into is what freaking compiler do I need? If you're dealing with Java, Java 8, Java 9, Java 10, Java 12, do you have multiple environments? So creating a interactive shell script is actually even more fun because you can write a shell script, for instance, for Java that covers all the flavors of Java. And you can even set it up to install the versions of Java you need for your particular machine, set up your environment, and then boom, you're done. It's like next time you're at a terminal or command line, instead of setting up your system environment, you can just run the shell script and say, you know, set Java environment or set Java version and pick the version number and boom, you're done. Your entire environments configured, set up, ready to go. Following that into your code. So one of the tips I want to talk about is more kind of clean code or those utility files as we're writing code. So like Rob mentioned, he creates and scripts to do the builds to customize his environments. The other thing you can do is as you're writing the code, make sure you use tools like SonarLint where as you're writing the code, they'll say, oh, hey, you know, this may be a potential issue. The other thing is as you start seeing repetitive tasks, make sure you pull those out and put them in the correct place. Put them in utility files. You know, Apache has been great at doing this for years. You know, we have the commons libraries. You have all these string utilities. Same thing happens at the system level. Linux has a lot of command line tools just like that, where you can actually run things at the command line that will search files, they'll edit files. Look at what you're doing every day. Quickly, Google chances are there is a utility tool out there for you to do it either at the command line or within whatever development environment or language you're using. Now take that one step further. So what Rob was talking about at the beginning with the databases and bringing all those SQL scripts to set up the environment, the same thing can go on the backside when you go to test your code, because chances are you're doing a lot of repetitive tests to make sure that the code you wrote works. Make sure you write unit tests to test that code. If you see yourself testing, write a freaking test that will do it. So all you have to do is push a button. Hey, it's tested. That way six months from now when you forget what you were doing to test and you're trying to remember, you just push a button. Hey, OK, this test, this works. Move on. When you're going to web environments or mobile developments, it's even more important to take those repetitive tasks and script them. Either use things like Selenium WebDriver, Selenium IDE, Appium, write the scripts that walk through step by step how the application is supposed to work. And then you can just run that and make sure it works, which also turns out to be a roadmap for how you should write the code. So if you start out writing the script and how it's supposed to work from a user perspective, you can then automate those tasks as you're writing the code to the script. So again, that kind of leads to the requirements. The other flip side to this is in today's environment, make sure to utilize some AI tools like ChatGPT, Copilot, BART, or whatever it's called these days. These tools also help you with essentially Google search. If you're stuck and you need to ask a question, try asking one of the AI tools. Chances are they'll give you some bit of information. It may be the answer. It might not be, but it might also give you an idea on what to go Google next or ask AI some additional questions to kind of flesh out where you're trying to go or collect your thoughts on the particular problem you're working on. That's, I had one more and it just kind of blew away. Oh yeah. The thing to think about too is make sure you utilize other tools for communication. You know, we've talked about these before, but use things like Slack, Teams to communicate with your other team members and your customers. You can also take a lot of tools like Jenkins, Confluence. Let's see. The other one, Bitbucket. You can put these plugins into Slack or into a lot of your messaging tools that will give you updates when things get done. So for your continuous integration, continuous development, these are other tools and tricks you can use to kind of cut down on constantly having to go monitor things. Something breaks. Hey, it sends you a message out to either an email or to your message queue. The two things I want to add to this is, we haven't really touched on yet. One is templates. Reuse the heck out of the stuff that you use. Don't be afraid to take like your ideal status report, your ideal email, your ideal form letter for this, that and the other and turn it into either turn it into a template or just keep it as a template that you can copy and paste. And then just you copy it and then just fill out your information. That kind of stuff. It is amazing how much that will help you out, particularly if you've got something you're doing on a regular basis, like a weekly status report or release notes, things like that is have a format and a style that's all set up, and all that kind of stuff so that you just come in, you plug in your content. Eventually, maybe you've got something that plugs the content in for you. And then you've got all of that work and polish gets to just reused, be reused, be reused, be reused. Now, also, I don't want to, I want to move on before we talk about going back to like shell scripting and some of those kinds of things. You can also, this is again, this is that being a better developer is take some of these utility moments, we'll call them, and use them as an example or an exercise to try a new language. This is where I don't know how many times I have started off new languages, doing command line stuff that was, it was utilities. When I first learned Java, way, way, way, way, way back in like literally last century, I started with some command line stuff because there were a couple of things that Java did okay. And it worked with it. This is it already had, I think it's from version one. I think it already had the operating system stuff to some level involved. So I built like a little like, you know, directory crawler for Windows because it didn't have anything that was very good at that point. And some things like that. And then moving forward, a lot of times I'll do like things like, you know, file movers and loggers and document parsers and things like, like log readers. Those are the kinds of things that are perfect for, you know, whether you want to learn, you know, if you want to do command line Java or if you want to do Python or if you want to do C sharp or whatever it is. Because these utility tasks are going to hit the common things that you need to learn for that language. Your, your looping structures, your collections and arrays and things like that. Your logical related stuff, file input and output, potentially even keyboard input and output or build a little GUI around it. Those sorts of things are just perfect for you to cut your teeth on a new language with a tool or an application that's actually going to be useful to you. And it's going to be sort of cool when you, especially if you're sort of new, it's really cool when you get into that interview where you say, well, you know, I was learning to Ruby and I had this problem that I was trying to solve, or I was trying to copy some files around and then, then compile them. But then there was a second thing and I had to pull a log file in and blah, blah, blah, blah, blah. And then they're like, oh, that's pretty cool because you had a problem. Yo, I got a problem and you know, I'm going to solve it like vanilla ice the heck out of that thing. And you did it in a new language and you get to like, it's you can make sure you did comment in a well, well built, you know, code and all that kind of stuff. It makes it the perfect portfolio kind of application for you to use. We could go forever on this. I'll give you some closing thoughts and we'll wrap this one up. Yeah. So one additional thing, because you kind of made me think of this also consider if you do a lot of repetitive tasks in your environment, doesn't necessarily have to be your development environment, but even your operating system, like we mentioned, mail filters, look at doing macros or write little automated tools. That will do repetitive tasks for you. This also leads to our development environments and a lot of ID ease allows to write little scripts or macros within them that allow us to do code completion. So we can type two or three letters, hit a set of keys and boom, there's a section of code that we would repetitively have to type a lot of text. So if you see a lot of things that you do a lot, look at creating little templates or code completions to simplify your test. So you're not seeing they're having to write all this boilerplate code all the time. One additional thing to that is also make sure to look at what third parties, IDE plugins, whatever are for your development environments that could also act as code completions or ways of simplifying or shrinking down the amount of code that you have to write. Yeah, I agree. That was something I'd forgotten about. I used to do that all the time and back in the day before IDEs have built a lot of this stuff was I had a stock Java file. There was just a dot Java file and it had some comment stuff like a header block and a couple other pieces that was just like it was a stuff I found myself writing all the time. So instead of a little macro, I just copy and paste and that was where I started with is I'd go, you know, I'd have the generic, you know, disclaimers and all that kind of crap. And then it did all that. And particularly if you know, when you got back when there was back when there's like a lot of shareware sites and stuff like that, there were always these little like, you know, like there's read me texts and stuff like that, that it always made sense to have that usually now it gets generated by a tool. But back beforehand that was and if you if it's something that you haven't reached that it has reached that maturity of whatever it is that you need, then definitely by all means do that because it's going to save you time. And it's like it is it's something allows you to refine it over time and get better with it. That being said, we have refined the heck out of podcasting and yet we're still working on it. We're still trying to get better every day, just like you're trying to get better as a developer. And the best ways to do that is shoot us an email. Give us some feedback info at developer.com. Check us out on Facebook. Check us out on LinkedIn. Check us out on the developer.com site. You can check us out on YouTube. And if you check us out on YouTube, you'll get great bonus content like what I'm going to throw at these guys and gals just moments from now. But not for you because we're wrapping up the podcast and you're going to have to go check it out. You can go out developer nor YouTube dot com slash developer nor hate to leave you that teaser. But that's how we roll sometimes. 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 to develop a new 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.