Object-Oriented Programming

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. After a brief, brief pause, we are continuing and actually wrapping up our season on object-oriented programming and the practical approach to it. This is also going to be the last episode for a while. I'm going to go on a possibly extended hiatus. We'll just sort of see how it goes, and we'll talk about that towards the end of this. As far as the wrap-up is concerned, really there's just one more and one overarching thing that I want to be clear on as far as object-oriented design and how we do it better. And that is the design part of it. We need to actually take the problem, assess it, put together a solution, and then assess that solution. Take a look a little closer at the steps involved and where there may be opportunities for reuse or generalization of a step that would then allow you maybe to reuse that in the future. Now, in your initial implementation, you don't have to actually go all the way with an object-oriented implementation essentially. What you may do is put some notes maybe here and there and throw a couple of comments or to-dos that essentially say, hey, this is specifically for the solution we need right now or the problem we're solving right now. However, if we want to make this general in the future, here is an opportunity to do so. That is perfectly valid and may in some cases be a great way to do things like a one-off or maybe if you have to do a minimally viable product. If you're in Agile, any kind of an Agile, you know, scrum, cyclical kinds of thing, that is very valuable. Don't be afraid to come in initially and say, all right, we're going to brute force our way through it, but make sure that you're thinking through that as you do and you note that. Whether there's a, you know, maybe there's a technical document that you're tying to that code or more likely and usually easier, put it in the code. Put it in maybe at the top of a code block or in a, if it's a function or if it is a some, maybe some additional methods or planning for additional methods. Put those things in there. Use a little to do something like that that will be easy to find. And then, you know, maybe even make that a, you know, go ahead and throw a little ticket out there if you've got a ticket system that says, hey, we're doing this right now. However, in the future, this is something we want to fix. That is perfectly legitimate and worthwhile. If you're not in the mindset, we'll say, of doing the design for that solution right now, you can do that as well. Put a little bookmark placeholder kind of thing for yourself and say, I just need to get this done right now. However, I do want to return back to it. And that documentation is huge because the next person that comes through, whether it may be you or somebody else, and particularly, you know, somebody comes back and if it's going to be you six months from now or somebody that hasn't really seen it, they're going to be able to see some of that documentation and where you were headed or where you had stuff that you know is not ideal. That it's either, you know, usually you want to avoid hard coded, but maybe it is some sort of a, maybe not hard coded values, but essentially a hard coded solution where you make some assumptions that you maybe shouldn't be or that if you don't make those assumptions and you adjust the code, you can find a general solution as opposed to a specific solution. Don't be afraid to notate that stuff. That helps immensely. And it may be something actually just, you know, maybe that's something we talk about in some future season is just code commenting, just documenting stuff because that is something that I think we all fall short on. And if we build those habits, it will help. And if you have a slick object oriented design or solution, documentation is even more important. It really does help the next person to do so. And that's all I really want to focus on from that is just take the time and it does, it takes a little more time to craft a solution, but then also to do that additional assessment of the design. But it is worth it. Nine times out of 10 at least, if not 99 out of a hundred, it's worth it to spend a little more time on the design, slow down a little bit on your, your move to implementation and really think through what you're doing. I think you're going to find that your, your ability to create reusable code is going to improve and actually the quality of the code you create is going to improve. Now the, I guess part two of this one, I'm going to take some time off and this is actually a, could be a learning experience in itself. At this point we're sitting, this is actually episode 489 overall of a developer podcast. Part of me wanted to get to 500 at least, and maybe it's someday I will, but it's a good way to point out that sometimes rather than get to an arbitrary goal, particularly if it's arbitrary, maybe it's just time to change gears. And that's sort of what I'm doing right now is I've looked at stuff and I've decided that I'm going to, one, running out of, I don't have the content at the top of my head that's something that's saying, oh, this is the next season I want to do. Although I did just come up with the comment thing, but I want to get a little further ahead and get a couple of seasons worth of content in my head before I dive back into it. So there may be a soft relaunch somewhere down the road. I would assume probably at least a month or two before I come back to it. And part of the switch is I really am enjoying doing more of the tutorial stuff that's over on our YouTube channel. You can find links to it out on the developer site. You can also see some posts related to it on a developer nor I think you can track it down and if not, that's one of the things I'm going to be doing is updating the site a little bit, making sure that I've got the links very easily found for where some of our other content and assets are. I want to focus a little more on the coding side for a while. So I'm going to basically put this aside so I have more time to do those tutorials and also to pay the bills and get all the day job kind of tasks done because it has gotten back to a pretty busy schedule. So that's in itself a little bit of a lesson to be learned is although we talk regularly about periodic pauses and assessments, taking a look at where you're at, what are you doing? Do you want to continue? Do you want to change gears? Do you need to invest more in one thing or another? But sometimes you'll get to a point where you realize that this is not exactly what I want to do or this is not exactly moving the ball forward in the direction I want it to be or this is something I've done for a while and now it's like, I've done it, I'm ready to move on. As I said, you can set arbitrary goals and there's nothing wrong with that to say, hey, I'm going to do this for three weeks, three months, two years, 10 years, whatever it is, or 10 times or 100 times or a thousand times. But those things should be enough for you to understand whether it's the right choice or not. And if you realize it's not the right choice sooner rather than later, it's okay to bail out. You can say no, you can quit early. Think about it, if you order a meal and you're like, oh, this is a great meal, I want to eat every last bite of it. And halfway through you find out it's bad, it's not what you expected to be, it doesn't taste good, it's not prepared right or whatever. Stop, don't keep going. You don't have to keep going. So whatever it is you're on, maybe this is a sign to say, hey, there's this thing I'm doing that isn't good or isn't fun or isn't helpful or whatever its reason for doing that. It's not profitable, whatever it happens to be. And then you can turn around and say, you know what, I'm going to stop. Why put good time after bad when you can take other things and invest in something that's maybe of more value at one way or another for you? And so that's where I've sort of gotten to this. Well, one, I did hit the end of the season. I sort of have gotten to where I wanted to be on the object oriented programming. And rather than just do a bunch of intermittent sessions that we've done in the past, I really want to spend some time going back to that design idea a little bit. Instead of diving in and just doing a season, I want to have a couple of them and maybe put a little more rhyme and reason to how this progresses in the future. If it does, that may be that I don't come back to this for a year. I don't know, because there are other things out there that take time that are sort of on my radar. And maybe we put another book together and things like that. The tutorials, something to keep an eye on. We are focused on Django and Python right now. That's just been a fun thing to work with. And I think the next series basically that we're going to do out on YouTube is going to be working our way through Python certification. And I can't remember if it's Python and Django. I think it's just Python certification. I think we may just walk through step by step what they have on the syllabus and how to do it and examples of it. Now, if you have any suggestions moving forward, because doing a podcast without guests, anything like that, and having to come up with your own content is not always the easiest thing. So suggestions are highly welcome. If you love this, if it's going to bother you that you don't have this on a regular basis, that's fine as well. Shoot me an email. info at developer.com with suggestions, whether for this or for some of our other stuff. Things that we cover in the mentor sessions, which you can probably see. You can see some of those. If you go out to the Vimeo channel, vimeo.com slash developer, you go out there, take a look at it. Look at developer. You can search YouTube if you just search for developer. the whole D-E-V-E-L-P-R-E-N-E-U-R, you'll find it. You'll find our channel. We've got, oh, I don't know, a lot. I think we've got a hundred different episodes of stuff in there across probably a half dozen to a dozen different topic categories and sort of series of information. And that's getting updated every week. We have new stuff going out all the time. So because of that, I said we're going to pause the podcast for a while. I want to make sure that I brought that up instead of just sort of stopping it just in case. So it's not suddenly like, oh, hey, where'd that go? And three or four months down the road, like, man, I remember seeing that a lot. And it seems like it's been a while since they dropped episode. So we're going to wrap up this season, season 14, wrapping up the object-oriented programming piece. If there's a season 15, then stay tuned to the channel. Check it every so often. We'll mention it when we kick it back up, I'm sure, back out on the developer-nour site. And odds are we'll probably come back around to it at some point because this is a great way for us to share content, get things out to you guys, and help all of us just try to get a little better day by day. Every day, work on becoming a better developer. Challenge of the until we meet next time, become a better developer. Do what you can. Get the momentum going, set up the steps that you need to do, the routine, whatever it is that helps you move forward to become a better developer. And as always, go out there and have yourself a great day, a great week, a great unspecified time period until we meet again. And we will at some point talk to you then. Thank you for listening to Building Better Developers, the Developer-Nour 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 developer-nour.com. Just a step forward a day is still progress, so let's keep moving forward together.