How to Build Better Habits with Coding Standards

Welcome to Building Better Developers, the Develop-a-Nor 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 where we are building better habits. We are building better developers. We are Rob and Mike. He doesn't count right now. I do. My name is Rob Rodman. I am one of the founders of Develop-a-Nor. And I'm also a founder of RV Consulting, where we help you wrangle technology because, let's face it, it's not just hurting cats. A lot of times it's hurting feral, big-clawed, with steel spikes on their back cats. Technology can get out of hand very quickly. It can be very painful. There's a lot of issues that come with sprawl. Some of those are the kinds of things that only hit you at the end of the year because they hit you in the pocketbook because you've got wasted technology or shelf-ware that you spent all this money on. You've never been able to figure out how to really leverage it. That's what we do at RV Consulting. We help you make the most of your technology investments through integration, simplification, automation. We help you with your teams. We help you with your people. We find the ways to help you do a better job of leveraging that technology and navigating the crazy world that technology can sometimes be. For example, these days, you've got AI and all this kind of stuff popping up everywhere. It is a challenge to figure out what does that matter to me and if it does, how do I make that work? That's kind of stuff we work with you on. The rest of the people that are out there, we work with you right now. We're working on your habits. I want to talk about that a little bit. The habit pieces that I've sort of made my experiences with them. The first one is I'm going to hit it again as the Pomodoro one. Just keep on it. I've beaten on that, I think, often enough. Automation is another one that I've spent some good time on. The branding stuff is something again that is like, this is something that had sort of floated off my radar. It's very easy to do it. You get really busy. If you don't have something, just sort of like a daily check-in or at least a weekly with your personal brand and how do you set this up? Such simple stuff. It can be things like just look. If you have a website, look at your website and just read through it. You may want to do a little wordsmithing or maybe there's a color off or maybe there's something broken. The things that you do on a regular basis, like maybe your weekly status reports, maybe you want to clean that up a little bit. This is sort of a combination maybe of automation and branding and professionalism, but those are all there. A blog, doing a weekly blog or a daily blog where you just, maybe it's a weekly blog, but you spend five minutes a day building up that weekly blog. That kind of stuff really does add up and it is real easy for it to just sort of fade into the background because it's not something that we think about, I think, often enough until we're like, I need a new job. I got laid off or I need to create a new product idea or something like that. That's when we suddenly go into that mode. If we can keep it on a regular basis, it will help us out a lot. Good thing, bad thing. Good thing is we're getting to the end of the year. This is like, I always love the getting towards the end of the year because it's all about like looking back and actually spending a couple of minutes looking at what I got done during the year. A lot of times it's shockingly good. It's like, wow, I forgot that I was doing that back in January or February or March or whatever it is. I'm like, wow, look how far I've come with this stuff. The bad news is it's about the end of the year. So I've got a couple of things I really want to get done. And a lot of my year in planning is now ahead of me. And I've got a lot of wide open things that I've got to figure out. Like, how do I really want to do this? So yeah, it's the good part of planning, but it's also the bad part of planning or my good and bad. Final good thing is that, hey, I'm sitting here doing the podcast with my buddy Mike and now he gets to talk while I have a sip of tea. Hey everyone. My name is Michael Mulwash. I'm one of the co-founders and developer of NUR, also the founder of Envision QA, where we work with companies that are struggling with their software. Either they have built their own custom software or they're using pre-built tools that they've bought online or just through the stores. And it's not really working for them. We work with you through software assessments. We will help customize a solution that meets your needs and helps you improve productivity throughout your business. Getting to our kind of goals or challenges. I've been doing really well at the Pomodoro technique. I've spent a lot of time this week kind of looking at personal branding, updating my resumes, updating my sites like you mentioned. Also been working on my meeting prep time and trying to make sure I stay on task. One of the biggest challenges I've had with our challenges is taking breaks. I kind of got a lot going on. It's the end of the year and I very easily am finding myself even with the Pomodoro, I'm going 25, then I'm immediately going to another 25. I'm not really taking the breaks in between like I should be. So I need to work on that a little bit more. However, with that, I've actually found, again, my kitchen sink caps, kind of been cranking along pretty good. Automation ticking that off. I have an update to a project I've been working on where I'm actually going to automate some new little features so I don't have to do it manually anymore. That will save me time, less headaches. Also it makes the solution a little more self-sustaining and can kind of sit on its own. The other thing I've been struggling with, so this is going to be kind of my bad, is criticism. Kind of giving and receiving criticism. I've been in a couple meetings, working a couple projects, and when things are going good, things are positive. You're happy. You're excited. But when you kind of kick off a project or you're kind of getting into the weeds of a project and working with new teams or even old teams, you can kind of butt heads a little bit on designs and ideas. And sometimes what's meant to be just an idea or a suggestion can be taken critically or just kind of taken out of context. So I've been struggling with that a little bit, but that is one of my goals this week is to kind of get back on track, reset, and not repass the holidays, kind of just take a breath, work on taking breaks. Good thing I survived Thanksgiving. Daughter made a wonderful meal. Ate way too much, but hey, that's the holidays for you. You got to eat some good food and my daughter is a wonderful cook. So that was a good thing. So this episode, I want to talk about, well, basically we'll label this as coding standards. And this is at both a personal level and team level. I want to focus more because of building better develop. We'll start with us. We'll start with ourselves. And that's going to be where we're going to end up. Spoiler alert, that's going to be where we're going to end up with the challenge at the end of this. But I want to talk about what I want to talk about in coding standards is that it really is it's not as much about matching a specific standard. That's like the, you know, like the PEP for that's out there for Python or the, the Oracle's standards for Java or Google standards for every freaking language in the world, you know, and stuff like that. Now there is, I don't want to downplay too much of those things. Cause for example, like the Google standards are very important if you want to play in the Google world. There is a lot of stuff that is, there's a lot of that about having their standards and following their standards that will help you, your site, your customer's site, your employer's site in the search engine optimization world and things like that, because they want you to be clean or pristine or proper or whatever and how you do stuff. And the more that you follow their guidelines, the more, as far as we can tell, the better it's going to help your rating as a site, how they grade your site. Now, if you step away from that and, you know, so let's step back from the business considerations of that, but in general, having standards really does help you even within reading your own code. There's a lot we can do. Now some standards get very specific about that. If you go to like the, some of the notations and some of that kind of stuff that's out there where you can look at the name of a function, you can look at the name of a variable and things like that, and there's got, there's all kinds of information that's hidden inside that that's encoded into the name and the standard and how it's laid out. And that can be useful, but even if you don't get to that level, you know, you don't have to go down to like Hungarian notation level to be able to get something out of your, your, how you name and style things. So just the, the old school simplest thing is just indentation, is indenting things so that you know, for example, if you're in a function that all the code for that function is indented. Now, it may be nice that you've got something and a lot of the IDs that will take advantage of these things where it's like, if you've got opening and closing brackets, sometimes they'll like just, you know, collapse that so you can just see, oh yeah, this is in the mix of all this other stuff. You can do pretty printers and stuff like that that will try to format stuff. And if your code is janky, well, guess what? Your formatting will break. So it'll give you a good hint that, hey, I've got something out, you know, I've got a parentheses off or I forgot to close a quote or something like that. But just the things like, you know, like your standards so that you know, I'm dealing with a class instance versus a class definition. This is not like the class itself. This is actually an object instance or this is a local variable maybe versus a global variable or, you know, if there's something like that or a lot of times this is like, for example, this is a local variable to my method or my function as opposed to one of the parameter variables that was passed in. Things like documentation is so like, how do I comment my code so that you know where to look for your comments? Do I just jump to the top of a page of my file and I see everything there or I have trouble unmuting my mic and sometimes, you know, or is it something where you look down at like the function level or something like that? Getting these standards in place not only helps other people because they'll look at looks like it was written by, you know, somebody that knew what they were doing as opposed to particularly if you've got multiple developers, they've got different standards, it looks like a mess because it looks like 15 different people wrote the code. You never really know where to look, things like that. But it also helps ourselves. If I look back and it's actually sort of funny because I have evolved some of my standards over the years. They've changed and adjusted and a lot of it actually, a lot of times you can see what language I'm mostly coding in because that stuff spills out into whatever other languages I'm coding in at that time. And it can be challenging when I look back at stuff from 10 or 15 or 20 years ago and I'm like, oh yeah, that's right. I always put this thing here. I did that thing there. And it does go to like structure and all kinds of other stuff. It's you know, it's things like probably all of us have evolved from HTML, how we approach that as CSS and JavaScript to become more and more a part of that. How do we, and it's somewhat just like, where do we place like our JavaScript files? Where do we put our script tags and some things like that? It's all these little things that build up, build into our standards. And some of them, yes, are very much about most efficient way to do something, but a lot of it really is just aesthetic. It's just so when you look at it, it looks like code that you wrote. It's a little bit putting your stamp on it. And as a team, it's putting your team's stamp on it. So there's a lot of value in getting to those standards. I'm going to pass it to Mike before we talk a little bit more about like implementing those standards and getting into that. So what are your thoughts and some of your experiences in this world? Yeah, so you've kind of touched on all the code, like styling standards and that. I liked a lot of the examples. I want to take it slightly a little bit further than just the coding standards. So for instance, like over the years, I've worked a lot in health care and financial organizations, and it's not just coding standards we necessarily have to worry about. Sometimes our coding standards are actually impacted by industry standards like HIPAA, Sorbent, Oxley, Sox. And we have to actually not just have coding standards, but also make sure that our standards comply with, you know, with government and legal standards. But within that, you also, if you're depending upon what your application is for, so say you're building mobile apps or you're building applications that are for specific devices, also understanding the requirements or the standards for instance, deploying mobile apps to the Apple App Store or Apple App Store. You have to comply with their standards in order for your software to be able to be approved and show up on the Apple Store. So it's sometimes coding standards aren't internal to your company. Sometimes there are external factors to what standards you have to actually meet in order for your software to be published and actually get out to the public. Now flipping back a little bit back into the coding standards. One of the biggest things I like to talk about is always testing. But in this particular case, I want to focus on documentation. So you mentioned documentation. As we write our code, there's always a certain level of requirements, documentations, software requirements documents, test documents, things of that nature. When we typically write our code, we think about writing comments within our code. As developers, we're not always great at that, but typically there's some type of documentation in the code so that you know what the code is for. However, I like prefer to do the clean code approach where when you write the code, your standards are essentially that your code is going to be self-documenting. It's going to be clean code, meaning that your functions are going to be tailored to a single unit of work or some specific way that you write it is it's human readable and you essentially can just read the code and know exactly what that particular function or that particular class or object is supposed to do. That way you don't have to really run around and write all these comments everywhere unless there's some complexity to it that you need to highlight. For instance, oh, this needs to be in here to meet this particular standard or, Hey, we implement this to fix this bug. One thing I will throw out though, is if you are writing documentation or troubleshooting code, if you have spent hours troubleshooting something and it is a very elusive bug or something that is not very well, I guess, identified within the industry, for instance, if it's something you found and no one else has it, you've gone through like stack overflow, you've gone through user boards, you've gone through discord. If it's something that you are having a very hard time finding, if and when you do find the solution, make a comment about it. If you have a link that took you hours to find, but Hey, here's a solution. Two things. One, you could copy the link in and take a chance that it's still going to be there six months to a year to 10 years from now, or you can copy the blur, still provide the link, but copy the core piece of that, that, Hey, this bug was introduced because of this kind of give, you know, the cause and effect. Here's what we found or here's what the problem was. Here's how we solved it. And this is how we kind of went about to find it. Now, sometimes putting that in code can be cumbersome, but depending upon your documentation process, if you keep it at the code, chances are it will always be there when you need it, if you put it in a Wiki or on paper and some physical documentation that could get lost over time. So these are just some ideas within some additional ideas for your coding standards to kind of improve the process and keep your code clean, self-document and comply with those standards. So I'm going to go with the challenge this time around is what this is going to be painful to some of you, maybe all of us, because it does touch on one of the things I'm going to mention is the word everybody hates, which is comments. But your challenge for the week ahead is every day. Take a few minutes, like, you know, less than 15, five, 10 minutes. Look at some code that you're with, pick a file that you're working on or a couple files or folder or something like that. And review it based on whatever your standards are. What you're probably going to find is you're going to find some stuff where you're like, your names are not named right. You may have comments are missing for some of them, from some of your functions. Or maybe it's, you know, they're out of date a little bit, things like that. Let's really just look at it and say, do I follow my own coding standards? If you're like me, the answer is going to be a resounding no. And you're going to need to like go clean some of that stuff up. Now the, you know, the funny thing is like, as an example, I just recently spent a lot of time in standard documents across a bunch of different languages for a couple of different teams. And they were pretty consistent. But then when I turned around and was doing some coding, there were a couple of times that I caught myself after the fact, I was like, Oh crap, I didn't follow my own standard that I had like grabbed from it, my grand, I guess that somebody else took it from somebody else, adopted it and said, let's, this is what we're going to do. And then needed to clean my own code up. So this is something for you is to start thinking through those standards because it is, this is where it really does help us to build a habit. Cause we have to think about the standard when we're doing it. It does slow us down. If it's just how we do this, then it's going to make things a lot easier for us and for the team around us. Now, as far as the team is concerned is if you don't have standards documentation, then pick one, you know, you don't even have to spend five minutes. You can go search. Like I use Google before, if you go out and Google search or whatever your language, you know, your favorite search engine is go look for Google's coding standards. They've got a whole page. It's full of all of these different languages and what are the standards they use and how do they, you know, how they've got links to them and all that kind of stuff so you can pick the ones you use and just go, boom, we're going to adopt this and try to do that. Now you may also another great way to do it is pick one of these lenders that are out there that we've talked about before. A lot of them are built into your IDEs. You can set some stuff up here for references so that it will just go look and you're not going to get errors, but you will get warnings that say this does not follow your coding standard. Fix those. Just like pick a couple of those and go do them. A good example I'm just going to get very specific is if you're using Python, they have the PEP8 standards. All of the IDs basically can adopt to those. I did it just the other day. I spent 15 minutes walking through a couple of files, just looking at all the little warnings, I shut off the spelling errors because it doesn't think anything spelled right, even if it is misspelled. A lot of times it's like it's a false positive, but all the other stuff I went through and then just did a general cleanup. There's just, it's very helpful because there's a lot of things where I'm like, oh yeah, I should have done this differently. But sometimes it's also like very like, there's really, it's very rewarding to get to the end of a file and be like, this, the system says it's clean, says it was not, oh, it's sort of like if you use Grammarly, it's like if you really misspell and have bad grammar and then you get to a point where it gives you like a hundred percent and it's like everything's lined up and it's exactly how it should be, you get like a little, you feel like you're getting a gold star or a smiley face or something like that. So that's your challenge. Every day this week, spend a little bit of time looking at your code, reviewing it, and making sure that you are following your standards, your team's standards or something along those lines. And if you don't know what they are, then spend a little bit of time each day this week building out standards. It's very simple. It's stuff like how, what is the standard for naming file names, for folder structures, for variable names, for, you know, how do I put, where do I put my parentheses and loops and all of those sorts of how do I indentation? Is it two spaces, three spaces? Is it tabs? Is it all of that stuff? Just write it down and build if you don't already have a personal set of coding standards for yourself. Also bonus challenge, send us an email, email at info at developer.com. Let us know how you're doing with the challenges. What are some challenges you'd like to see in the days and weeks ahead? How are you doing as you get towards the end of the year? What are some things that you're looking forward to in next year? What are some things that maybe you need to address before this year ends out and we move into 2025? Those are all things that we'd love to hear from you guys about. Get some information, some feedback and see where we want to go next, where this can help us help you become better developers. You can also hit us up at, out on X at Develop-a-Nora. You can go to Develop-a-Nora channel at YouTube. You can go to developmentora.com. You can leave us like that, leave us information via the contact forms or comments, feedback on any of the blogs and other articles that are out there. Wherever you see, wherever you read, hear, seed, whatever, consume podcasts. We have stuff there so you can like leave a, leave us feedback there, leave us comments and ratings and whatever you want to do to give us some feedback there. We'd love to hear it. That being said, it's time for us to go out into our day. So 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-Nora 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.