Detailed Notes
Code consistency is more than formatting — it’s the key to building clean, scalable, and collaborative software. In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit why consistency matters, how AI tools can help, and practical steps for adopting standards that stick.
What you’ll learn: • The hidden cost of inconsistent code • How code consistency improves quality and teamwork • Tools to enforce standards across teams • Common myths about coding standards • A simple developer challenge to get started
👉 Like, share, and subscribe for more insights on building better developers and better software.
*Follow-us on:*
* [email protected] * https://develpreneur.com/ * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://x.com/develpreneur * https://www.linkedin.com/company/develpreneur/
Transcript Text
[Music] Go. Recording in progress and we are good. May I have to look. This thing's like a little bit bright in my eyes. I'm trying to if I want to do this or if I want to be like Let's see. I don't know if this is going to be any better. Um, see if we crank it down a tad. Yeah, you're kind of deal with what I'm doing. I had to turn a lamp on because I got a shadow on one side. >> Yeah, that's sort of where I'm at is I've got like me. Okay, I'll get back here a little bit and let's see. So, went and dug through uh our free Slack thing has got like our big old posts disappeared so I had to go back but I found it found where the episodes were and all that kind of stuff. We are doing coding standards understanding their importance in software development and I decided to go back to chat GPT this time just mostly because I decided to go back to chat GPT. So, um I guess we're just going to dive in. We'll just like take off with this sucker. And so, we'll do our little ths. Uno. Hello and welcome back. We are continuing our season. We're getting near the end, but we are still continuing forward and we are talking about couple seasons back we went through a lot of u goals and and suggestions for developers and now we're doing it with AI. We're throwing it out to chatbt asking it what it thinks and we're having some pretty good conversations along the way. Who are we? Well, we are the developer podcast. We are building better developers is also known as I happen to be Rob Broadhead, one of the founders of developer. Also founder of RB Consulting where we are we are a organization that helps you do technology better. Um, our goal is to step in, explain, help you explain what your business is, make sure we go through your processes, things of that nature, and then we're going to help you find a, you know, craft a road map basically is find a way to take you from where you are to where you want to be. And we're going to use technology to get there because once you have your processes defined and nailed down, then you can do things like simplify, automate, innovate, integrate. You can do all these things that allow you to change those processes around in a way that they become uh faster to, you know, faster to get done, more efficient, and then of course that allows you more time to work on your business and also make your customers very happy, which makes everybody happy. Good thing, bad thing. Uh good thing is is I've got a new, for those who haven't seen it, I've got a new little mic that I'm testing out. The bad thing is is that my setting that my setup that I'm working on as a uh mobile person and being able to just do this anywhere, haven't completely got it nailed down yet because Zoom has some stuff that it doesn't like to do, which is one of the things we use for our recording. And uh I'm going to have to work on that and figure out or I may just have to load some crap onto my phone so that I can be very uh phone ccentric. uh but someone who is not phone ccentric although he is out in the middle of nowhere doing this. Michael go ahead and introduce yourself. >> Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of Building Better Developers, also known as Developer. I'm also the owner and founder of Envision QA where we help businesses run better by making sure that their software works the way it's supposed to. Whether you're managing customers, selling online, you know, running a clinic, we make sure that your software is reliable. Uh it runs efficiently and is easy to use. We do that by helping you um you know, improve your customer experience, uh more focused on growth and remove those headaches that might be in your software. And we do that by starting by getting to know your business. We kind of get in the trenches with you. We spend time really getting invested, understanding your business, understanding your processes, and try to figure out what your goal is. What is your why? What is it that you're trying to do? And then from there, we recommend the right solution, whether it's building a custom tool, fixing what's broken, or automating your testing. End of the day, we help you prepare for a smoother launch or better uh improvement with your customers. Ultimately, our goal is to take care of the tech behind the scenes so you can focus on your business and not worry about your software. Let the software do its thing. You take care and focus on your business and making money and making your customers happy. If you want to learn more, check us out at envisionqa.com. Good thing, bad thing. So, we are recording this today on September 4th, and today is the launch of Hollow Night 2, Silk Road. And if you've been watching the news, it launched at 10:00 today and it pretty much took down every single game shop out there. So, I have not been able to download it yet because the stores are unreliable. So, that's the bad thing. The good thing is once it is reliable and I can get the software, I'm going to be able to play some new Hollow Knight 2 Silk Road hopefully tonight. Well, good. I am not going to be playing that because I didn't even play Hollow Night one. So, that's one of those things. I'm behind the times, but I'm not behind the times on this topic. So, this time around, we're going to talk about coding. The original topic's title was coding standards, understanding their importance in software development. And we went back to chat GPT this time. This is actually chat GPT5 uh that we're working on. I think we early on we had a couple that were 4.5. We're now doing a little playing around with five, just seeing how AI evolves. And uh this one starts out with the episode flow. It's giving us a little flow of it. Hook one to two minutes. Start with a relatable story. It loves to start with a relatable story. Uh, imagine you inherit a project, open the code, and every file looks different. Indentation, naming, even how errors are handled. How much time would you waste just trying to understand the style before you even get to the logic? Connected to the audience. Developers who want to grow their careers must not only write good code, but write code that's understandable and maintainable. Before we even jump into the next section, I want to I want to say that I've actually found AI is really useful in these kinds of situations. If you sort of once you spend a little bit of time looking at the code, u I have found some ways that you can you can get AI some of these tools to say, hey, this is how I want it to be structured. These are some of my standards. And it can actually give you a pretty good starting drop point on becoming consistent because trust me, you you don't want to leave the mess. You want to clean the the code up that you're touching. That's just bonus material. Moving on. Defining coding standards. Three to four minutes. Explain what coding standards are. A set of agreed upon conventions for style, formatting, and structure. Examples: naming conventions. Camel case versus snake case. File organization. commenting documentation pro p practices and learning how to speak English properly and error handling patterns. Now I think the these things can get like some people can feel like this is a little too much red tape. It's too much administrative stuff. Things like that. There's there's complaints because developers are like darn it I gotta go make my code align with whatever the standards are. >> That's all fine and Danny. I know everybody wants to be all creative and do code their way, but when push comes to shove and you're trying to look through code and figure out what it's doing, if there's not a consistency to it, then it's going to be harder to read. I like error handling patterns in particular. That's like one that drives me nuts when it's inconsistent and it has c it causes problems like you would not believe when you get into like production and things like that. So if you're the person that's like, "Oh, I'm just going to like print something out to the console versus somebody that's using, you know, log forj or whatever that version, whatever the main logger is for your language or the person that's always shoving it out to messages that show up on your, you know, flow through and then show up on the interface or they get kicked back into some database table and get logged there." Actually, all of those things are fine, but pick one. be consistent because it is really difficult when one section of code does one and another se section of code does something else and then they don't always sync up because now they're doing it different ways and then the and even the messaging early early on when I was a developer one of the things one of the couple of the apps actually I worked with is they had every single message laid out there was like a clued file of some sort an ini file or whatever it happened to be whatever format it was and like every single message in the system lived there. A lot of times there's errors. So you'd have an error code like a number and then you'd have a message and a number and a message. It seems a little old school and stuff like that, but it is actually really darn effective because then it's like always use the number. Always grab that thing. You can use a lookup table in a database. There's a lot of different things you can do, but messaging and notifications in particular, it is so critical to be consistent. And it's even more so to do the notifications and messaging that the users see because if they're looking all over the place and they're not seeing it right and sometimes it shows up and sticks around and sometimes you have to hit okay and sometimes it disappears after 3 seconds and sometimes it has an alert noise and sometimes it doesn't. People don't know what the heck's going on and they're just going to say it's broken. I think I saw something but I'm not sure what I saw. They're going to ignore it. They're not going to give you useful feedback of it. I'm going to step off of my soap box now, but that I think is one of the areas that we overlook way too often and we need to make sure that we cover that like in code reviews and things like that. Michael, time for you to step up on that soap box. >> So, right off the bat, file organization. It annoys me if and I want go into an organization and they've got code that is not organized because you know most programming languages have some type of file structure organization that you need to follow and if you're not following that having new developers come onto a project can be extremely difficult. The other problem is if you don't have an agreed upon file organization, if you have things like containerization or things like that where you have specific paths for things, if you have your project one way and someone else has it another way, if you try to deploy to these containers, you're going to have to do custom configurations for where are the files located, where are you deploying them, you know, what is the path where a file is, you know, is it source, you know, if you're doing Java, you got simple Maven, so you have standards that you have to follow to build a project. If you have a straight up just plain old Java application, you don't necessarily have a standard. You can do whatever you want for package naming structures and things like that. And that can be extremely difficult if you aren't all in agreement. The other thing is commenting and documentation practices. So many companies don't aren't really good at commenting or documenting their code. They either have it external to the code or they have it a little bit in the code but it's not wellmaintained. They may have read me files. At the end of the day, get used to writing documented code. And by that I mean literally write in plain English. Write your code in a way that if you read the statement, you should almost be able to read and know what exactly your code is doing. It doesn't have to be 100% pure English, you know, because those could get long, but you can abbreviate enough or camelc case things enough that you can understand what the code is doing just by reading the code. And then you don't need all these explicit or explicit uh additional documentation or comments in your code. But still, if you add something that has a specific meaning and it's not clear, document it. Add a line comment. Six months from now, you're not going to remember what that is. And it's not like I know some people struggle. So like well it's all this complicated stuff that I'm doing. It's like then break it down. So it should be steps of like I do X and then I do Y and then I do Z and then those can be function call. So yeah maybe within those old functions or those methods you've got you know five or 10 lines of code that do something. But it should be like a nice unit of work and then you can just describe what it is. You don't have to get super detailed down to each line, but as long as those groupings have something, then you're off and running and you should have something that's going to be far more readable and you will thank yourself in the future along with everybody that touches your code. So, moving along, why they matter. Uh, we've already started on these a little bit. Uh, it says spend 6 to8 minutes on this. Let's see how this goes. Team communication standards are like a shared language. Reduce cognitive load. Developers don't have to decipher stylistic quirks. Maintainability, easier debugging and onboarding new team members. Avoid tribal knowledge locked in a single dev style. Quality and consistency. Consistency improves readability. Tools, llinters, formatterers. Enforce quality automatically. Professionalism and growth. Employers expect clean, consistent code. Following standards makes you stand out as someone who understands the bigger picture of software engineering, not just coding. I'm going to go right basically right to that last one because I think that's one of the things is that as a coder and that's I see this so often. There's so many projects I've picked up that that's the that's the problem is the person that did it or maybe it's a couple people that did it. Uh sometimes it's like a chain of people that did it but they were all individual developers. You can look at it and see that it was written by different people. I have been in situations where it's like it was horrible. It was like it was not only written by different people, but they used completely different libraries. They had a completely different approach. And so you have this big nasty bloated code that covers all of these, you know, five different ways people were doing things and you're never really sure which works. It's almost impossible to pull something out because you're like, well, if I eliminate that, I'm not sure what I break and what I don't. And it just becomes a complete nightmare. Part of being a developer, of moving into being a better developer, is being able to do so in a a not sitting up in your ivory tower approach is doing it in a way that you are now much more a man of the people or of that kind of thing. It's you're part of the team that you're saying, "Hey, we're going to do this together and it's going to look like it was done by a team or a single person." And it's just like if you hear somebody that you hear a band and everybody's playing different songs and different styles, it could be a jam session and it could be really cool, but it's probably not because even a jam session there's still there is a there is standards within that. You're not going to hear a jam session that is like a waltz, somebody rapping, somebody playing jazz, somebody else doing hard rock, somebody else doing soft rock. you know, there will be different instruments and they're doing their own little thing, but there is some sort of cohesiveness to us. That's the same thing we want. We don't want to be just a bunch of random people making noise. We want to actually come together as a band, we'll call it, or as a, you know, as a group and build something that has that cohesive feel to it. It is so so much easier to maintain something like that. It is easier to find bugs with something like that. It is easier to scale something like that. So that is where you become a professional developer versus somebody that can just write code is when you can do it and do it within a a team aspect and follow some of those standards instead of just doing your own thing. Once again, I'm just stepping on soap boxes today. So I'm going to get back off and let's see what your where do you want to go with this one? Oh, my soap box is going to be the uh combination of the tools and clean and consistent code because one of the biggest problems I have in almost any software shop I work in is when you hire on new people or you combine teams or your teams grow from one or two people. If you are not enforcing llinters and formatterers and having good you know source repositories and you are essentially managing how you want your code committed, how you want it formatted. If you do not use these llinters and formatterers and everyone has a different IDE and they're writing code however they want. When you go to commit to your code repository, it's going to tell you that every single line in the file has changed when you change one line. And it gets increasingly difficult over time to manage code review know what the hell is really going on with the code per revision really if you are not using a llinter today start Google has a whole library out there for just about every IDE it's a good one to just start with um because if you go with that one regardless if you got visual code intelligj um you know python whatever They have a llinter for everything and it works with just about every single IDE on the market. So you can pretty much say, "Hey, go if we're going to stick with Google, go grab the one for your language, install it in your tool and stick with it." Even if you say are using Java and you have like Eclipse and Intelligj and Visual Code, even if you use the default liners that come with those idees, each one could be slightly different causing problems. So just pick one, pick a particular format and apply it to everything. So don't rely on the individual tools. And then lastly, just make sure you document this in a wiki or you know your basically your uh coding standards so that everyone is on the same page and when you bring new people on, make sure that that is one of the first things you do when you onboard them. I will just follow up on that because I I did not mention this before, but I think it it very much dubtales what you said is the whole idea of when you commit stuff in and it does a comparison, it's going to say everything's changed. What's worse is when you're having to actually merge stuff because one, you're not going to see the changes, but more importantly, if you don't have a standard style and approach, then you're not it's it is that much harder to merge code because you're looking at stuff, you're going, "Well, I I'm not sure if this works. I'm not sure if this fits here and that fits there." And particularly then if you start to merge code that is different styles, you can have all sorts of issues with it. And I have I'm just speaking from experience. I have cussed at many a person sometimes myself even in doing some of these things where it's like okay we've got to like let's get it straight and using things like llinters and that are static code analysis those tools are worth their weight in gold to help make sure that you get that stuff in place and just and you spend the time set up the hooks to make sure that when people are committing that those things are going through there code reviews that kind of stuff make sure that those things are happening it will make a difference and you will thank yourself. Uh common obje objections and counterpoints 3 to four minutes on this one. Uh standards killed creativity. Creativity should go into solving problems not inventing new brace styles. Uh it slows us down initially maybe but in the long run it saves time for the whole team. Every project is different. Yes, but standards should evolve with context. Think of them as living guidelines. um having written in the last year or two numerous standards and guideline documents um and actually a lot of times they different organization different team sizes and stuff like that but there is definitely a a common thread through them and one of the things that is I think that we haven't touched on yet is that uh standards can help us write better code that can help us write stuff that is more efficient that is easier to tune that takes advantage of uh the language, the environment and things like that. If we stick to these standards, it not only makes our code tighter, but then it allows us to it it has us work within a a structure that then other people have a better idea of what to expect from code they're not even looking at. There's certain things that you're going to expect. For example, an API. If every endpoint on the API is written by a different developer in a different way, then you're going to get all kinds of weirdness. You're going to get some that want JSON and some that don't and some want XML and some don't and some kick out an error code and some don't and some have six different messages and one has it all in one big text that you have to parse. These things are I'm I'm I'm taking it to the extreme a little in that example. However, it's not that different from what we're dealing with. I I have worked in now last few years in particular several projects where we have not enforced stuff enough early on and that we've brought things in. We've merged some stuff. If you start bringing AI into the picture, it's not going to be standard compliant 99% of the time. And then what ends up happening is you have to like look at stuff and goes, "What the hell is this? What why is this done this right? And then you have to go clean it up and you have to say, "Okay, let's go make it look like this other stuff." Uh you will also run into all kinds of problems if you're not doing this. If you're in one of these uh evolving environments, which is almost everybody now cuz you may have Java that is now, you know, it's not standard. Uh you're doing something that's been, you know, was 18 versions back and it's like no, nobody should do that anymore. Uh Python is like that. They're constantly evolving their stuff. React, like all of these things. Ruby, they've got all these libraries and all these tools and you're going to end up in your own little version matching hell if you're not paying attention and making sure that the standards are also being updated and work with whatever your your tool set and environment is. Thoughts on this one? >> So, I'm going to go with every project is different. Yes, but standards should evolve with content. So I have talked about kitchen sinks all over the place and have talked about you even mentioned you know you need to make sure you refactor you refine your code break out those large methods you know if every project is different yes however even if you have different languages if you are writing something with specific functionality and you objectify it correctly be it a like a message Q or a database your services layers you have different layers to software, different ways of doing things. If you define your standards correctly and you break out your files and the individual uh implementations of everything correctly, then you should actually have a code library that you can pull from for all your projects. Everything should be standardized across the board. So like one project talks to my SQL. Well, you could should be able to take that one piece of code and put it into another. you should not have to duplicate. Or better yet, you should be able to put that into a uh package and include that package into your next project and then you essentially have your shared library that's used in multiple places. Sometimes that's good, sometimes that's bad because you could have extensions of that, but you should be extending the code, not modifying the original code. If the original piece works, extend it if you need additional functionality. That way, you always have your core component. And then with that, you know, it it slows us down. It doesn't. At the beginning, it does because you got to get everyone on the same page. But very quickly, you're going to find that defining standards saves the day because 6 months from now, if you guys are all on the same page, everything is being coded the exact way. When you come in to another an old project to fix something, you should know where to go. You should not spend a whole lot of time hunting and pecking. What is a spaghetti code? Because you followed your standards. >> I have nothing to contribute on that one. We're gonna continue on uh partially from time and stuff like that because this one actually gets into some I'm going to it's a funnel area. How to implement standard 6 to 8 minutes. >> Uh it says start small. Pick a winter formatter. We've beat this to death. Uh adopt a widely accepted standard first like PEP 8 for Python, PSR for PHP, Google Java style. uh automate enforcement with pre-commit hooks, CI/CD integration as we've mentioned, review and code reviews, encourage don't police, we had episodes on that one. Uh document standards in a contributing MD file. As I'm going through this and looking at these now, one uh the standards I was talking about that I've done every single time I started with whatever a industry standard. So I've done several Python standards and I went right to Pepe. Uh actually use Google standards for several things. I've used Google. They've got stuff for Java, for CSS, for HTML, for PHP. I think I can't remember where all I got them, but all of those are out there and they really give you a good start and it's you should be doing it anyways. That's part of being a better developer is doing the stuff that is industry standard is the industry norms. If you're a doctor and you're following industry, you know, standards, you're probably doing pretty good. If you're just out there doing crazy stuff, you're probably killing people or something like that that you shouldn't. We're not likely to do it to that level. But those are things to think about. What I'm reminded in all this is back in the day uh many many many many years ago when there was this thing that everybody was a big part of in some way, form or fashion that was called sharewware. And there were all of these sites where you could go download software and do all this stuff. And a lot of these sites had standards for what you needed to include with your product if you were going to post it on their site. If you go like America Online just died not too long ago. They were one that did that. They had um and I can't remember what it was, but it was things like you had to have a read me. You had to have some sort of like disclaimer. You had to have an ownership thing. You had to have like all these little things. And all these documents felt like um you know red tape or something like that. But they are very they're very good about allowing somebody that gets this thing that downloads this thing to be able to understand where it came from, who to contact if they need help, what is the licensing around it, like what can they do with it, uh what should they expect from it, all that kind of stuff. And we I think got away from that too much. And I'm now seeing it again where like most tools, most IDs, they're going to if they create a project, they're going to build you empty files for all of this stuff that you should be filling out. So like the simplest thing is is when you next create your, you know, Java project out of the STS tool, look at the stuff that's there and like fill in the blanks. Don't cuz it is mindboggling when you've got something that doesn't have documentation but you've got a readme file that basically says give information for this application. This is what it should look like. These are the pieces of information. Like it walks you through it. It shouldn't take any time at all and then it doesn't exist. Uh I'm not even going to let you talk this time because we've we're starting to run out of time and I know we can keep going. So the rest of you guys get to listen. If you come back, check us out on the YouTube channel. You'll get to hear more from Michael. I'm sure he's chomping at the bit to give you some bonus material. But we are running out of time. So we're going to go ahead and do our obligatory. Send us an email at [email protected]. Let us know what you think, where we you'd like to see us go. If you have questions, I had a great question the other day that came through uh social media or something like that. really interesting uh topic that I think we're going to have to look at at some point and figure out how to switch some of these uh our point of view I guess around a little bit and um these things are what make us help you better. They they make us a better tool for you. So definitely send us your information, your your questions, your your feedback. Uh you check us out on developer.com. You can leave feedback anywhere there. You can leave it wherever you wherever the fine stores that you find podcast out on the developer channel on YouTube out in X we are at developer I think there's a Facebook page out there that's the developer Facebook book page I forget all the places but we're there all the things as they say as always I appreciate the time that you've given us and we're going to give you some back so go out there and have yourself a great day a great week and we will talk to you next time. So, I teased it. Time for the big bonus material. Where do you want? Um, let me read the next. I'll read the last bit and then I'm going to dive into that. That gives you just a little bit more to think about. Uh, the last thing was just called to action. Encourage listeners to audit their own codebase and adopt one improvement this week. Wow, that sounds like something we did for a season or two. Plug tools, resources, style guides, formatterers, llinter docs. The uh, tie back to the developer brand. Building better developers means learning to build better code bases, not just better features. That's a nice little tagline. Uh, extra add-ons. Guest angle. Invite a senior architect to share war stories about ugly versus beautiful projects. Check. We did that. Mini challenge encourage listeners to pick a file, run it through a llinter, and compare before and after. That's a neat little challenge. All right, your turn. Where are you going to add your value first? >> All right, so since we ran out of time, the one I'm going to tackle first is the automation. Automate enforcement with pre-commit hooks, CI/CD and integration. You know, we have talked about automation, automation, automation, automate all the time. This is a key piece to saving your sanity when dealing with coding standards. If you have any type of code repository, also check for llinters. You could automate all these things within your continuous integration, your pipeline. do it early, define it, and then tweak it as needed. But really, if you define it and stick with it at the beginning, you have ba basically set yourself up that everyone has to do it and no one can kind of slide through the uh the cracks. Following that, it is also good to define testing standards within your source guide because if you also say that for every piece of code you write, you need a certain amount of tests, tests can also help you enforce your code integrity as well as your coding standards. If you're not following your standards, chances are your tests are going to be failing or your tests are going to start looking very clunky and weird. And if that is the case, then you know that you're not following your standards correctly. >> I think I'll just briefly follow up on that because I think that is a um very often there's like people have their unit test and there's just things this do and they just like okay yeah we're going to add some tests to it if they if they're good enough to add tests. But if you divi find within that like certain things that you want out of your test for example that you need to have a unit test that verifies every possible outcome of your of your function or method you know success if there's multiple failure codes and things like that. If you include with it things like it has to be a matching failure code. There's some things like that that you can do that will enforce your standards from the from the get-go. And it is, as Michael said, it is so much easier to do that from the start and just make that a part of it. Yes, it it can be a pain. And when you want to eject it and say, "Nope, it's it's taken too much time later on." You're like, "Ah, we could have saved time, but you're better off not falling into that trap and instead doing it right from the start." And if you do have to somehow you scramble or whatever, fine. There's a little bit of pieces you didn't get done, but at least you got most of it done. And I guarantee you, you will thank yourself. and we will thank you if you give us any kind of feedback because we love that kind of stuff. Uh but for now, we're going to give you some time back and we're going to let you get back to your day. So, thank you so much for hanging out. We're not done yet. We got another episode coming up soon as you click on our stuff and depending on where it is may already be out there. We may be way ahead of you, but if not, you may just like take a nice little deep breath, relax, and we'll be back soon. No worries. Have a great day everybody. [Music]
Transcript Segments
[Music]
Go.
Recording in progress and we are good.
May I have to look. This thing's like a
little bit bright in my eyes. I'm trying
to if I want to do this or if I want to
be like
Let's see.
I don't know if this is going to be any
better.
Um, see if we crank it down a tad.
Yeah, you're kind of deal with what I'm
doing. I had to turn a lamp on because I
got a shadow on one side.
>> Yeah, that's sort of where I'm at is
I've got like
me. Okay,
I'll get back here a little bit and
let's see. So, went and dug through uh
our free Slack thing has got like our
big old posts disappeared so I had to go
back but I found it found where the
episodes were and all that kind of
stuff. We are doing coding standards
understanding their importance in
software development and I decided to go
back to chat GPT this time just mostly
because I decided to go back to chat
GPT. So,
um I guess we're just going to dive in.
We'll just like take off with this
sucker. And so, we'll do our little ths.
Uno.
Hello and welcome back. We are
continuing our season. We're getting
near the end, but we are still
continuing forward and we are talking
about couple seasons back we went
through a lot of u goals and and
suggestions for developers and now we're
doing it with AI. We're throwing it out
to chatbt asking it what it thinks and
we're having some pretty good
conversations along the way. Who are we?
Well, we are the developer podcast. We
are building better developers is also
known as I happen to be Rob Broadhead,
one of the founders of developer. Also
founder of RB Consulting where we are
we are a organization that helps you do
technology better. Um, our goal is to
step in, explain, help you explain what
your business is, make sure we go
through your processes, things of that
nature, and then we're going to help you
find a, you know, craft a road map
basically is find a way to take you from
where you are to where you want to be.
And we're going to use technology to get
there because once you have your
processes defined and nailed down, then
you can do things like simplify,
automate, innovate, integrate. You can
do all these things that allow you to
change those processes around in a way
that they become uh faster to, you know,
faster to get done, more efficient, and
then of course that allows you more time
to work on your business and also make
your customers very happy, which makes
everybody happy. Good thing, bad thing.
Uh good thing is is I've got a new, for
those who haven't seen it, I've got a
new little mic that I'm testing out. The
bad thing is is that my setting that my
setup that I'm working on as a uh mobile
person and being able to just do this
anywhere, haven't completely got it
nailed down yet because Zoom has some
stuff that it doesn't like to do, which
is one of the things we use for our
recording. And uh I'm going to have to
work on that and figure out or I may
just have to load some crap onto my
phone so that I can be very uh phone
ccentric. uh but someone who is not
phone ccentric although he is out in the
middle of nowhere doing this. Michael go
ahead and introduce yourself.
>> Hey everyone, my name is Michael
Malashsh. I'm one of the co-founders of
Building Better Developers, also known
as Developer. I'm also the owner and
founder of Envision QA where we help
businesses run better by making sure
that their software works the way it's
supposed to. Whether you're managing
customers, selling online, you know,
running a clinic, we make sure that your
software is reliable. Uh it runs
efficiently and is easy to use. We do
that by helping you um you know, improve
your customer experience, uh more
focused on growth and remove those
headaches that might be in your
software. And we do that by starting by
getting to know your business. We kind
of get in the trenches with you. We
spend time really getting invested,
understanding your business,
understanding your processes, and try to
figure out what your goal is. What is
your why? What is it that you're trying
to do? And then from there, we recommend
the right solution, whether it's
building a custom tool, fixing what's
broken, or automating your testing. End
of the day, we help you prepare for a
smoother launch or better uh improvement
with your customers. Ultimately, our
goal is to take care of the tech behind
the scenes so you can focus on your
business and not worry about your
software. Let the software do its thing.
You take care and focus on your business
and making money and making your
customers happy. If you want to learn
more, check us out at envisionqa.com.
Good thing, bad thing. So, we are
recording this today on September 4th,
and today is the launch of Hollow Night
2, Silk Road. And if you've been
watching the news, it launched at 10:00
today and it pretty much took down every
single game shop out there. So, I have
not been able to download it yet because
the stores are unreliable. So, that's
the bad thing. The good thing is once it
is reliable and I can get the software,
I'm going to be able to play some new
Hollow Knight 2 Silk Road hopefully
tonight.
Well, good. I am not going to be playing
that because I didn't even play Hollow
Night one. So, that's one of those
things. I'm behind the times, but I'm
not behind the times on this topic. So,
this time around, we're going to talk
about coding. The original topic's title
was coding standards, understanding
their importance in software
development. And we went back to chat
GPT this time. This is actually chat
GPT5 uh that we're working on. I think
we early on we had a couple that were
4.5. We're now doing a little playing
around with five, just seeing how AI
evolves. And uh this one starts out with
the episode flow. It's giving us a
little flow of it. Hook one to two
minutes. Start with a relatable story.
It loves to start with a relatable
story. Uh, imagine you inherit a
project, open the code, and every file
looks different. Indentation, naming,
even how errors are handled. How much
time would you waste just trying to
understand the style before you even get
to the logic? Connected to the audience.
Developers who want to grow their
careers must not only write good code,
but write code that's understandable and
maintainable. Before we even jump into
the next section, I want to I want to
say that I've actually found AI is
really useful in these kinds of
situations. If you sort of once you
spend a little bit of time looking at
the code, u I have found some ways that
you can you can get AI some of these
tools to say, hey, this is how I want it
to be structured. These are some of my
standards. And it can actually give you
a pretty good starting drop point on
becoming consistent because trust me,
you you don't want to leave the mess.
You want to clean the the code up that
you're touching. That's just bonus
material. Moving on. Defining coding
standards. Three to four minutes.
Explain what coding standards are. A set
of agreed upon conventions for style,
formatting, and structure. Examples:
naming conventions. Camel case versus
snake case. File organization.
commenting documentation pro p practices
and learning how to speak English
properly and error handling patterns.
Now I think the
these things can get like some people
can feel like this is a little too much
red tape. It's too much administrative
stuff. Things like that. There's there's
complaints because developers are like
darn it I gotta go make my code align
with whatever the standards are.
>> That's all fine and Danny. I know
everybody wants to be all creative and
do code their way, but when push comes
to shove and you're trying to look
through code and figure out what it's
doing, if there's not a consistency to
it, then it's going to be harder to
read. I like error handling patterns in
particular. That's like one that drives
me nuts when it's inconsistent and it
has c it causes problems like you would
not believe when you get into like
production and things like that. So if
you're the person that's like, "Oh, I'm
just going to like print something out
to the console versus somebody that's
using, you know, log forj or whatever
that version, whatever the main logger
is for your language or the person
that's always shoving it out to messages
that show up on your, you know, flow
through and then show up on the
interface or they get kicked back into
some database table and get logged
there." Actually, all of those things
are fine, but pick one. be consistent
because it is really difficult when one
section of code does one and another se
section of code does something else and
then they don't always sync up because
now they're doing it different ways and
then the and even the messaging
early early on when I was a developer
one of the things one of the couple of
the apps actually I worked with is they
had every single message laid out there
was like a clued file of some sort an
ini file or whatever it happened to be
whatever format it was and like every
single message in the system lived
there. A lot of times there's errors. So
you'd have an error code like a number
and then you'd have a message and a
number and a message. It seems a little
old school and stuff like that, but it
is actually really darn effective
because then it's like always use the
number. Always grab that thing. You can
use a lookup table in a database.
There's a lot of different things you
can do, but messaging and notifications
in particular, it is so critical to be
consistent. And it's even more so to do
the notifications and messaging that the
users see because if they're looking all
over the place and they're not seeing it
right and sometimes it shows up and
sticks around and sometimes you have to
hit okay and sometimes it disappears
after 3 seconds and sometimes it has an
alert noise and sometimes it doesn't.
People don't know what the heck's going
on and they're just going to say it's
broken. I think I saw something but I'm
not sure what I saw. They're going to
ignore it. They're not going to give you
useful feedback of it.
I'm going to step off of my soap box
now, but that I think is one of the
areas that we overlook way too often and
we need to make sure that we cover that
like in code reviews and things like
that. Michael, time for you to step up
on that soap box.
>> So, right off the bat, file
organization. It annoys me if and I want
go into an organization and they've got
code that is not organized because you
know most programming languages have
some type of file structure organization
that you need to follow and if you're
not following that having new developers
come onto a project can be extremely
difficult. The other problem is if you
don't have an agreed upon file
organization, if you have things like
containerization or things like that
where you have specific paths for
things, if you have your project one way
and someone else has it another way, if
you try to deploy to these containers,
you're going to have to do custom
configurations for where are the files
located, where are you deploying them,
you know, what is the path where a file
is, you know, is it source, you know, if
you're doing Java, you got simple Maven,
so you have standards that you have to
follow to build a project. If you have a
straight up just plain old Java
application, you don't necessarily have
a standard. You can do whatever you want
for package naming structures and things
like that. And that can be extremely
difficult if you aren't all in
agreement. The other thing is commenting
and documentation practices. So many
companies don't aren't really good at
commenting or documenting their code.
They either have it external to the code
or they have it a little bit in the code
but it's not wellmaintained. They may
have read me files. At the end of the
day, get used to writing documented
code. And by that I mean literally write
in plain English. Write your code in a
way that if you read the statement, you
should almost be able to read and know
what exactly your code is doing. It
doesn't have to be 100% pure English,
you know, because those could get long,
but you can abbreviate enough or camelc
case things enough that you can
understand what the code is doing just
by reading the code. And then you don't
need all these explicit or explicit uh
additional documentation or comments in
your code. But still, if you add
something that has a specific meaning
and it's not clear, document it. Add a
line comment. Six months from now,
you're not going to remember what that
is. And it's not like I know some people
struggle. So like well it's all this
complicated stuff that I'm doing. It's
like then break it down. So it should be
steps of like I do X and then I do Y and
then I do Z and then those can be
function call. So yeah maybe within
those old functions or those methods
you've got you know five or 10 lines of
code that do something. But it should be
like a nice unit of work and then you
can just describe what it is. You don't
have to get super detailed down to each
line, but as long as those groupings
have something, then you're off and
running and you should have something
that's going to be far more readable and
you will thank yourself in the future
along with everybody that touches your
code. So, moving along, why they matter.
Uh, we've already started on these a
little bit. Uh, it says spend 6 to8
minutes on this. Let's see how this
goes. Team communication standards are
like a shared language. Reduce cognitive
load. Developers don't have to decipher
stylistic quirks. Maintainability,
easier debugging and onboarding new team
members. Avoid tribal knowledge locked
in a single dev style. Quality and
consistency. Consistency improves
readability. Tools, llinters,
formatterers. Enforce quality
automatically. Professionalism and
growth. Employers expect clean,
consistent code. Following standards
makes you stand out as someone who
understands the bigger picture of
software engineering, not just coding.
I'm going to go right basically right to
that last one
because I think that's one of the things
is that as a coder and that's I see this
so often. There's so many projects I've
picked up that that's the that's the
problem is the person that did it or
maybe it's a couple people that did it.
Uh sometimes it's like a chain of people
that did it but they were all individual
developers. You can look at it and see
that it was written by different people.
I have been in situations where it's
like it was horrible. It was like it was
not only written by different people,
but they used completely different
libraries. They had a completely
different approach. And so you have this
big nasty bloated code that covers all
of these, you know, five different ways
people were doing things and you're
never really sure which works. It's
almost impossible to pull something out
because you're like, well, if I
eliminate that, I'm not sure what I
break and what I don't. And it just
becomes a complete nightmare.
Part of being a developer, of moving
into being a better developer, is being
able to do so in a a not sitting up in
your ivory tower approach is doing it in
a way that you are now much more a man
of the people or of that kind of thing.
It's you're part of the team that you're
saying, "Hey, we're going to do this
together and it's going to look like it
was done by a team or a single person."
And it's just like if you hear somebody
that you hear a band and everybody's
playing different songs and different
styles, it could be a jam session and it
could be really cool, but it's probably
not because even a jam session there's
still there is a there is standards
within that. You're not going to hear a
jam session that is like a waltz,
somebody rapping, somebody playing jazz,
somebody else doing hard rock, somebody
else doing soft rock. you know, there
will be different instruments and
they're doing their own little thing,
but there is some sort of cohesiveness
to us. That's the same thing we want. We
don't want to be just a bunch of random
people making noise. We want to actually
come together as a band, we'll call it,
or as a, you know, as a group and build
something that has that cohesive feel to
it. It is so so much easier to maintain
something like that. It is easier to
find bugs with something like that. It
is easier to scale something like that.
So that is where you become a
professional developer versus somebody
that can just write code is when you can
do it and do it within a a team aspect
and follow some of those standards
instead of just doing your own thing.
Once again, I'm just stepping on soap
boxes today. So I'm going to get back
off and let's see what your where do you
want to go with this one? Oh, my soap
box is going to be the uh combination of
the tools and clean and consistent code
because one of the biggest problems I
have in almost any software shop I work
in is when you hire on new people or you
combine teams or your teams grow from
one or two people. If you are not
enforcing llinters and formatterers and
having good you know source repositories
and you are essentially managing how you
want your code committed, how you want
it formatted. If you do not use these
llinters and formatterers and everyone
has a different IDE and they're writing
code however they want. When you go to
commit to your code repository, it's
going to tell you that every single line
in the file has changed when you change
one line. And it gets increasingly
difficult over time to manage code
review know what the hell is really
going on with the code per revision
really if you are not using a llinter
today start Google has a whole library
out there for just about every IDE it's
a good one to just start with um because
if you go with that one regardless if
you got visual code intelligj
um you know python whatever They have a
llinter for everything and it works with
just about every single IDE on the
market. So you can pretty much say,
"Hey, go if we're going to stick with
Google, go grab the one for your
language, install it in your tool and
stick with it."
Even if you say are using Java and you
have like Eclipse and Intelligj and
Visual Code, even if you use the default
liners that come with those idees, each
one could be slightly different causing
problems. So just pick one, pick a
particular format and apply it to
everything. So don't rely on the
individual tools. And then lastly, just
make sure you document this in a wiki or
you know your basically your uh coding
standards so that everyone is on the
same page and when you bring new people
on, make sure that that is one of the
first things you do when you onboard
them.
I will just follow up on that because I
I did not mention this before, but I
think it it very much dubtales what you
said is the whole idea of when you
commit stuff in and it does a
comparison, it's going to say
everything's changed. What's worse is
when you're having to actually merge
stuff because one, you're not going to
see the changes, but more importantly,
if you don't have a standard style and
approach, then you're not it's it is
that much harder to merge code because
you're looking at stuff, you're going,
"Well, I I'm not sure if this works. I'm
not sure if this fits here and that fits
there." And particularly then if you
start to merge code that is different
styles, you can have all sorts of issues
with it. And I have I'm just speaking
from experience. I have cussed at many a
person sometimes myself even in doing
some of these things where it's like
okay we've got to like let's get it
straight and using things like llinters
and that are static code analysis those
tools are worth their weight in gold to
help make sure that you get that stuff
in place and just and you spend the time
set up the hooks to make sure that when
people are committing that those things
are going through there code reviews
that kind of stuff make sure that those
things are happening it will make a
difference and you will thank yourself.
Uh common obje objections and
counterpoints 3 to four minutes on this
one. Uh standards killed creativity.
Creativity should go into solving
problems not inventing new brace styles.
Uh it slows us down initially maybe but
in the long run it saves time for the
whole team. Every project is different.
Yes, but standards should evolve with
context. Think of them as living
guidelines.
um
having written in the last year or two
numerous standards and guideline
documents um and actually a lot of times
they different organization different
team sizes and stuff like that but there
is definitely a a common thread through
them and one of the things that is I
think that we haven't touched on yet is
that uh standards can help us write
better code that can help us write stuff
that is more efficient that is easier to
tune that takes advantage of uh the
language, the environment and things
like that. If we stick to these
standards, it not only makes our code
tighter, but then it allows us to it it
has us work within a a structure that
then other people have a better idea of
what to expect from code they're not
even looking at. There's certain things
that you're going to expect. For
example, an API. If every endpoint on
the API is written by a different
developer in a different way, then
you're going to get all kinds of
weirdness. You're going to get some that
want JSON and some that don't and some
want XML and some don't and some kick
out an error code and some don't and
some have six different messages and one
has it all in one big text that you have
to parse.
These things are I'm I'm I'm taking it
to the extreme a little in that example.
However,
it's not that different from what we're
dealing with. I I have worked in now
last few years in particular several
projects where we have not enforced
stuff enough early on and that we've
brought things in. We've merged some
stuff. If you start bringing AI into the
picture, it's not going to be standard
compliant 99% of the time. And then what
ends up happening is you have to like
look at stuff and goes,
"What the hell is this? What why is this
done this right? And then you have to go
clean it up and you have to say, "Okay,
let's go make it look like this other
stuff." Uh you will also run into all
kinds of problems if you're not doing
this. If you're in one of these uh
evolving environments, which is almost
everybody now cuz you may have Java that
is now, you know, it's not standard. Uh
you're doing something that's been, you
know, was 18 versions back and it's like
no, nobody should do that anymore. Uh
Python is like that. They're constantly
evolving their stuff. React, like all of
these things. Ruby, they've got all
these libraries and all these tools and
you're going to end up in your own
little version matching hell if you're
not paying attention and making sure
that the standards are also being
updated and work with whatever your your
tool set and environment is. Thoughts on
this one?
>> So, I'm going to go with every project
is different. Yes, but standards should
evolve with content. So I have talked
about kitchen sinks all over the place
and have talked about you even mentioned
you know you need to make sure you
refactor you refine your code break out
those large methods you know if every
project is different yes however
even if you have different languages if
you are writing something with specific
functionality and you objectify it
correctly be it a like a message Q or a
database your services layers you have
different layers to software, different
ways of doing things. If you define your
standards correctly and you break out
your files and the individual uh
implementations of everything correctly,
then you should actually have a code
library that you can pull from for all
your projects. Everything should be
standardized across the board. So like
one project talks to my SQL. Well, you
could should be able to take that one
piece of code and put it into another.
you should not have to duplicate. Or
better yet, you should be able to put
that into a uh package and include that
package into your next project and then
you essentially have your shared library
that's used in multiple places.
Sometimes that's good, sometimes that's
bad because you could have extensions of
that, but you should be extending the
code, not modifying the original code.
If the original piece works, extend it
if you need additional functionality.
That way, you always have your core
component. And then with that, you know,
it it slows us down.
It doesn't. At the beginning, it does
because you got to get everyone on the
same page. But very quickly, you're
going to find that defining standards
saves the day because 6 months from now,
if you guys are all on the same page,
everything is being coded the exact way.
When you come in to another an old
project to fix something, you should
know where to go. You should not spend a
whole lot of time hunting and pecking.
What is a spaghetti code? Because you
followed your standards.
>> I have nothing to contribute on that
one. We're gonna continue on uh
partially from time and stuff like that
because this one actually gets into some
I'm going to it's a funnel area. How to
implement standard 6 to 8 minutes.
>> Uh it says start small. Pick a winter
formatter. We've beat this to death. Uh
adopt a widely accepted standard first
like PEP 8 for Python, PSR for PHP,
Google Java style. uh automate
enforcement with pre-commit hooks, CI/CD
integration as we've mentioned, review
and code reviews, encourage don't
police, we had episodes on that one. Uh
document standards in a contributing MD
file.
As I'm going through this and looking at
these now, one uh the standards I was
talking about that I've done every
single time I started with whatever a
industry standard. So I've done several
Python standards and I went right to
Pepe. Uh actually use Google standards
for several things. I've used Google.
They've got stuff for Java, for CSS, for
HTML, for PHP. I think I can't remember
where all I got them, but all of those
are out there and they really give you a
good start and it's you should be doing
it anyways. That's part of being a
better developer is doing the stuff that
is industry standard is the industry
norms. If you're a doctor and you're
following industry, you know, standards,
you're probably doing pretty good. If
you're just out there doing crazy stuff,
you're probably killing people or
something like that that you shouldn't.
We're not likely to do it to that level.
But those are things to think about.
What I'm reminded in all this is back in
the day uh many many many many years ago
when there was this thing that everybody
was a big part of in some way, form or
fashion that was called sharewware. And
there were all of these sites where you
could go download software and do all
this stuff. And a lot of these sites had
standards for what you needed to include
with your product if you were going to
post it on their site. If you go like
America Online just died not too long
ago. They were one that did that. They
had um and I can't remember what it was,
but it was things like you had to have a
read me. You had to have some sort of
like disclaimer. You had to have an
ownership thing. You had to have like
all these little things. And all these
documents
felt like um you know red tape or
something like that. But they are very
they're very good about allowing
somebody that gets this thing that
downloads this thing to be able to
understand where it came from, who to
contact if they need help, what is the
licensing around it, like what can they
do with it, uh what should they expect
from it, all that kind of stuff. And we
I think got away from that too much. And
I'm now seeing it again where like most
tools, most IDs, they're going to if
they create a project, they're going to
build you empty files for all of this
stuff that you should be filling out. So
like the simplest thing is is when you
next create your, you know, Java project
out of the STS tool, look at the stuff
that's there and like fill in the
blanks. Don't cuz it is mindboggling
when you've got something that doesn't
have documentation but you've got a
readme file that basically says give
information for this application. This
is what it should look like. These are
the pieces of information. Like it walks
you through it. It shouldn't take any
time at all and then it doesn't exist.
Uh I'm not even going to let you talk
this time because we've we're starting
to run out of time and I know we can
keep going. So the rest of you guys get
to listen. If you come back, check us
out on the YouTube channel. You'll get
to hear more from Michael. I'm sure he's
chomping at the bit to give you some
bonus material. But we are running out
of time. So we're going to go ahead and
do our obligatory. Send us an email at
Let us know what you think, where we
you'd like to see us go. If you have
questions, I had a great question the
other day that came through uh social
media or something like that. really
interesting uh topic that I think we're
going to have to look at at some point
and figure out how to switch some of
these uh our point of view I guess
around a little bit and um these things
are what make us help you better. They
they make us a better tool for you. So
definitely send us your information,
your your questions, your your feedback.
Uh you check us out on developer.com.
You can leave feedback anywhere there.
You can leave it wherever you wherever
the fine stores that you find podcast
out on the developer channel on YouTube
out in X we are at developer I think
there's a Facebook page out there that's
the developer Facebook book page I
forget all the places but we're there
all the things as they say as always I
appreciate the time that you've given us
and we're going to give you some back so
go out there and have yourself a great
day a great week and we will talk to you
next time.
So, I teased it. Time for the big bonus
material. Where do you want? Um, let me
read the next. I'll read the last bit
and then I'm going to dive into that.
That gives you just a little bit more to
think about. Uh, the last thing was just
called to action. Encourage listeners to
audit their own codebase and adopt one
improvement this week. Wow, that sounds
like something we did for a season or
two. Plug tools, resources, style
guides, formatterers, llinter docs. The
uh, tie back to the developer brand.
Building better developers means
learning to build better code bases, not
just better features. That's a nice
little tagline. Uh, extra add-ons. Guest
angle. Invite a senior architect to
share war stories about ugly versus
beautiful projects. Check. We did that.
Mini challenge encourage listeners to
pick a file, run it through a llinter,
and compare before and after. That's a
neat little challenge. All right, your
turn. Where are you going to add your
value first?
>> All right, so since we ran out of time,
the one I'm going to tackle first is the
automation. Automate enforcement with
pre-commit hooks, CI/CD and integration.
You know, we have talked about
automation, automation, automation,
automate all the time. This is a key
piece to saving your sanity when dealing
with coding standards. If you have any
type of code repository, also check for
llinters. You could automate all these
things within your continuous
integration, your pipeline. do it early,
define it, and then tweak it as needed.
But really, if you define it and stick
with it at the beginning, you have ba
basically set yourself up that everyone
has to do it and no one can kind of
slide through the uh the cracks.
Following that, it is also good to
define testing standards within your
source guide because if you also say
that for every piece of code you write,
you need a certain amount of tests,
tests can also help you enforce your
code integrity as well as your coding
standards. If you're not following your
standards, chances are your tests are
going to be failing or your tests are
going to start looking very clunky and
weird. And if that is the case, then you
know that you're not following your
standards correctly.
>> I think I'll just briefly follow up on
that because I think that is a um
very often there's like people have
their unit test and there's just things
this do and they just like okay yeah
we're going to add some tests to it if
they if they're good enough to add
tests. But if you divi find within that
like certain things that you want out of
your test for example that you need to
have a unit test that verifies every
possible outcome of your of your
function or method you know success if
there's multiple failure codes and
things like that. If you include with it
things like it has to be a matching
failure code. There's some things like
that that you can do that will enforce
your standards from the from the get-go.
And it is, as Michael said, it is so
much easier to do that from the start
and just make that a part of it. Yes, it
it can be a pain. And when you want to
eject it and say, "Nope, it's it's taken
too much time later on." You're like,
"Ah, we could have saved time, but
you're better off not falling into that
trap and instead doing it right from the
start." And if you do have to somehow
you scramble or whatever, fine. There's
a little bit of pieces you didn't get
done, but at least you got most of it
done. And I guarantee you, you will
thank yourself. and we will thank you if
you give us any kind of feedback because
we love that kind of stuff. Uh but for
now, we're going to give you some time
back and we're going to let you get back
to your day. So, thank you so much for
hanging out. We're not done yet. We got
another episode coming up soon as you
click on our stuff and depending on
where it is may already be out there. We
may be way ahead of you, but if not, you
may just like take a nice little deep
breath, relax, and we'll be back soon.
No worries. Have a great day everybody.
[Music]