Performance Tuning

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We're continuing our season where we're looking at the glass being half full. We're looking at the bright side of things. The things we're looking at the bright side of are the things that generally are annoyances to us, possibly head scratchers all the way up to banging your head against the wall kind of issues. These are things that you may have your own opinions of them, I'm sure. Depending on how you're wired, what you enjoy about your job, some of these may mean more or less of a pain in the rear seeing them on a regular basis. However, whatever the case is, we're going to highlight some of the positives in these common tasks. This episode, we're going to look at performance tuning. This is by itself something that has a pretty strong positive coming out of it. When you're sitting there doing any kind of cleanup, refactoring, tuning of your code, then you're making it better. You're making it cleaner, more scalable, easier to maintain, run faster, probably to some level each of those. There is a balance amongst them. It may be something that you don't think of as being necessarily a bad thing, but it can be a very challenging task to do. It can be one of those that actually goes on for a rather large period of time because you can't always quantify changing these three lines of code gets us X performance increase or changing around how we structure this data is going to get us a 10% increase or whatever it is. You don't usually have those numbers until potentially after the fact. That would be if you put together a nice baseline, you had some solid numbers, you made your change and you're able to do an A-B comparison to show the improvement. You don't know that that improvement is there. You don't know what the changes are necessarily until you do it usually. There are cases where we have a pretty good idea of where we did something foolish. It'll be a quick fix, a quick change. Because these projects, these tasks tend to be more research oriented. You have to really look at the code. How's it running? What's going on? How does it step through? Are there some loops we don't need? Are there values we don't need? Is there memory being consumed that shouldn't be? There's just a lot of variables involved that can make these very daunting tasks, maybe not as negative as some of the other things we've talked about. But I would think in a lot of cases, it's not something we necessarily look forward to. However, when we look at the silver lining for this particular task, this type of work, I'm going to avoid the ROI version of it, of the obvious positive. If we do it right, we have code that runs better, runs faster. I want to focus on the process itself. You will see that there's some themes in some of the positives that come out of the various topics. We're a little over a dozen and a half different topics at this point, different things that we've been, challenges that we're running into. In the positive sides, I think you'll see there's a recurring theme. That one hits here as well, which is the gist of it is what doesn't kill us makes us stronger, or no pain, no gain. The fact that we learn by being challenged, by being stretched. Performance tuning is definitely one of those kinds of exercises, one of those kinds of tasks. It's one thing to write code. have to go back and rewrite the code to make it faster. I'm trying to remember, and I don't think that there was a point when I was going through my academic learning period, college and some of the things like that that I did to learn the program. But initially, when I was officially formally taught versus all the stuff that's really just been self-learning, reading books, things like that, I don't really remember other than one class where we ever were asked to refactor or improve our code. There's this stepwise way that sometimes we were taught things where you would improve it by doing maybe the simplest approach. Then along the way, you learn that, oh, there's this function or method or library you can use that makes it easier to get here or makes it cleaner. Or we write the code and we improve it by adding unit tests on, something like that. But not performance tuning. The exception was, and really it's a variation on this theme, and that was when we did, I think it was a data structures actually, or maybe it's algorithm. Actually, I guess it must have been algorithms class. We talked about sorting methods. We talked about bubble sort and hash and all the different, again, I can't remember, maybe not all of them, but we talked about quick sort and shell sort and all these others that I don't necessarily remember how probably half of them work, maybe more than that. But we had that comparison. It was in effect, that was sort of what we're doing is take a very simple sort, maybe a bubble sort, something very brute force, and then go back and fix it or tune it by taking a different approach. We spent quite a bit of time actually, weeks analyzing and rewriting and doing things to get a good sense for what sorts worked best in which situations, what were the pros and cons of these different approaches. When we were done, granted it's been a while so I've forgotten a lot of that, but when we were done, we had a very, for a while until it faded, we had a really good idea of how to approach sorting problems. I think that's what we get when we're asked to do tuning in general, not that we're better at sorting problems, but that in the process, the challenge of taking a look at our code and trying to squeeze every last drop out of that code, we understand it better. We understand the problem better, the process better. A lot of times we will analyze it in a way that will understand the data better so we may be able to get some, maybe take some short cuts based on assumptions about the data. That are maybe the reasonable assumptions or safe assumptions to make. There's a lot of learning that goes on in the tuning process. When you think about it, if you've done this and hopefully you've got some experience where you've been asked to rewrite or improve some bit of code, when you go back and look at it, there's very little time spent actually on the code usually, or writing new code. It's really spent learning how the code you have works and then analyzing the, we'll say that I guess the recommendations or your attempts at performance tuning. If assuming you don't get it right the first time that you're doing some tweaks here and some tweaks there, then think about most of the time spent is analyzing, is learning what is the data that is going through this process. How is it being processed? Where is time spent during this processing? What steps are the, I will call them the expensive ones, and which are the ones that are practically free? It takes essentially no time to get them done because that's usually what's going to happen is we're going to find the fat or slow steps and that's where we're going to, most likely going to get the biggest improvement. We're going to see what we can do. Hey, if we can skip that step completely, even better. That's a general tuning is we are really focused on learning the code that we are tuning, whether it's our code or somebody else's. So that's in itself a pretty big positive is, and it's one that I think that is not tracked or on resumes enough by a lot of us is that that's a, being able to look at some code and understand it is actually not an uncommon task for us to do. There's a lot of times, if you go to one company and you work forever, work there forever, that's fine. You may not see this as much, but if you don't, if you bounce around every few years, you do another job, then you're going to have to see code that was written by other people probably that was designed by other people. Even if you're at the same employer, you may be on different projects, you may move around, maybe you do maintenance, maybe you are doing some new development, maybe a little both, but it's, I would say impossible or really close to impossible to have a modern IT career and not have your responsibility or task to you at some point, the ability to analyze and assess somebody else's code. And we do that really even when we're doing probably when you're doing Google searches for how to get task X done. It's like, Hey, I heard this guy mentioned quicksort. Wonder how I would do a quicksort in whatever it is, Java. So you Google quicksort Java, you'll find some examples of code, you'll put some in there, but you'll be taking a look at it and say, okay, well, how does this really work? So I can use it for my needs. So we do this task quite a bit. This learning what other people have done, understanding, analyzing, reading for understanding code written by other people. tuning in itself is a crash course of a sense in doing so. I mean, it may even be our code, but it's still helps us have that experience and build habits so that we can review, assess, really analyze and improve on code, you know, better and faster because like at most things we're gonna assume the more we practice, the better we get at it. So like most of these things that we've talked about, this is a situation where it is a challenge. Yes, we accept that. That's a challenge. But one of the big outcomes is that by getting through this challenge, by succeeding, by overcoming this challenge, we have improved ourselves. We have better skills. We have some more experience that we can lean on. And we're in a sense refining some skills that normally we wouldn't because maybe if you're writing your code day to day, you don't have to go back and take a look at it. You don't have to build too much on top of other people's code. You could actually go quite a while before you really have to exercise these, we'll call them the code analysis muscles. Another big plus, particularly when you're earlier on in your career, these sort of projects actually are the sort of niche projects. They're not super rare. It's not like you're never gonna run into a performance tuning kind of project, but you don't hit them every day. And usually the people that get to do them or that are assigned to them are either the very senior staff or the people that basically jump up and say, hey, I've done this before. They provide past experience. So that's a huge plus when you get into a situation where you need to do performance tuning. That's why I said it early on. I said, this is something that I think we need to put on a resume more often. sort of a story around a tuning task that you did or tasks that you have done. Because this is actually, I think one of those things that is in more demand than people recognize because it's not often, unless you're out on like Upwork or something like that. And it's a specific project that says, hey, we need somebody to tune X code for this platform or whatever it is. A lot of times what you'll find instead is you'll have these jobs, wide ranging positions. These could be usually not entry level, but definitely mid-level, senior level, architects, designers, even managers in the software development space. And this I think actually occurs quite a bit in the network spaces too. So if you're that network hardware side of IT, then you probably run into this as well. Is that it's not necessarily a prime requirement of that position. But if you have a discussion in an interview, you'll often find that code review and assessment, performance tuning, things like that are at least nice to haps. I think these are the kinds of tasks that often will essentially fall between the cracks when somebody puts together a job description. But when you bring it up, when you can point to either on your resume or elsewhere through an interview process that you can point out that, hey, I've worked on this before, I've done performance tuning, I've picked up other people's code and made it work better. Those are the kinds of things that I don't think get at. It's not like a direct question very often, but it is a great way to open a door in an interview or a project proposal. And of course, like I said, it's amazing how many project requests I've come across that are effectively performance tuning. And you find out that they can be open a very long time. I've seen them be reposted many times because somebody will do it and they think it's no big deal and they're wrong and it's a bigger deal. And so it ends up essentially failing. And then that customer, that client reposts later saying, okay, we need to find somebody that understands this better. So if you do happen to get into a situation where you can learn this, where you can become comfortable in the tuning space, then there may be a lot of work for you ahead. I don't have a long list of positives with performance tuning, partially because I took the most obvious one off the table. But I really wanted to focus on this more as something to embrace as a, I want to say fun challenge, but definitely a useful challenge, a worthwhile challenge. And even though it can be very disheartening even at times, because you can be stuck in performance tuning stuff that can last for quite a while. You may think, hey, I'll be able to get this done in a couple of days. I'll make a couple of changes. This will be going along fine. And you find out that it isn't. The understanding that you or somebody else had of that system is not as complete or thorough as it needs to be. And this is becoming more of a, I guess we'll say of an issue as you have these more complex systems, particularly when you've got these things built on multiple layers of software. The tuning is a challenge because you may, let's say you've got three layers of a platform. If you're up at the top layer, you can do only so much, but then you're going to be limited by the other two layers. But maybe it's open source or something where you can then go in to the next layer down. And so you make some changes there, but maybe that doesn't quite do it. So you have to go to the next layer down and make some changes there. And so there's a lot that can go on. There's a lot of learning that can go on as part of a tuning project. And it also can be very time consuming. So if you end up in one of these kinds of situations where that's something you're assigned or you're looking into, realize that yeah, it's challenging. But as I said earlier, no pain, no gain. You think about yourself becoming the Arnold Schwarzenegger of performance tuning and code reviews because you spend so much time and you've got such great code assessment muscles that get developed. So being said, I guess time for the challenge of the week before I take this completely off the rails. Challenge of the week is when was the last time you had to do performance tuning? If you haven't, then the side challenge is just in the week ahead, take a look at something you've done and see if you can make that code run better, tighter. It's very much a good exercise for us to go through on a regular basis because there are mental muscles that are used during this process that I don't think are used as much in our usually in our day to day coding. So I think this is a challenge worthwhile. If you've done one recently, what did you learn from it? Take a look back at it from a what are the positives that came out of this besides writing faster code? And I think you'll be amazed at it. It really is a very rewarding task to have to be assigned to go through. And that being said, as always, I hope that this podcast was rewarding to go through. And as you go forward, that you have yourself a great day, a great week, and we will talk to you next. Thank you for listening to Building Better Developers, the Developer Nord podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernord.com. Just a step forward a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Nord. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Nord site. You can also find it on Amazon, search for Rob Rodhead, or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week, and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernord.com if you would like more information. Now go out there and have yourself a great one.