Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I'm going to be talking about leaving things better than you found them. When I was a kid my dad took on a lot of random odd jobs as favors for our friends and our family and the people around us. He would fix lawn mowers, he would fix cars, washing machines and he would even fix computers. And every time he took on a job he would wash it or he would paint it or he would improve it in some way. And I never really understood why he would go out of his way to do something more than what he had told the person he was going to do. So I asked him and he told me that he always makes it a point to leave things better than he found them. Now of course this is something that I thought my dad originated as a young child but now I know that this is a part of being a good human being. This is just a part of being a conscious and aware person who does good in the world. So I want to share with you what I think are some ways of leaving code better than you find it. And of course this helps you out not only just because it makes you a better person by leaving things better than you found them but because this isn't just a favor that you're doing someone. This is the code that you will be working on in the future and other people that work with you will be working on in the future. So if you want to become a better developer you should always leave code better than you found it. In other words when you go into fix a bug of course you need to fix the bug but make it better. Make the code better than just simply fixing the bug. Make the code fundamentally a little bit better. Okay so I'm going to go over five ways. This is going to be very short very quick. Five ways that you can leave code better than you found it. Number one make it shorter. Now this seems kind of obvious to some people who have been doing this for a long time but the best code is the code that you can delete. In other words the best commits that you make at the end of the day are the ones that make things simpler and usually simpler means shorter. It means more concise. Now this isn't always true. Sometimes you can obfuscate code by trying to make it short and clever and this isn't what you want to do. That is something that you can do as a practice to try to understand the syntax of a given language but practically short code that is confusing is worse than longer code that makes sense but if you can make something shorter and more understandable then that is a great way to leave code better than you found it. Number two make it make sense. If something confuses you when you read it then you shouldn't leave the code simply having understood it and then leaving it for the next person to have to wade through it and try to understand it. You should make that code make sense. Now there are a couple of ways to make it make sense. One is to change it, maybe change the variable names or perhaps actually change the functions that are being run or something like that. Change it in such a way that it makes sense or you can comment the code and that is actually number three. Update the comments in the code. This is very simple if there are comments in the code that have become out of date. For example a to do comment if you finish whatever that to do is telling you needs to be done. Remove the to do. A very simple way of making the code base better is to make sure that when you leave it the comments are up to date. Number four write a great commit message. If you aren't using source control yet then that is actually more important than all five of these go ahead and adopt source control. I recommend get because that's pretty much everyone's go to choice at this point. But start using source control as soon as possible. Once you start using source control make sure that when you change code you write a great commit message. Now there are a lot of resources out there to tell you how to write a good commit message. The basic guidelines are make sure that you are verbose about what you have done. Subscribe to things that you have done and give some sort of justification. Now usually there are two parts in a commit message. One is like a summary which is kind of the short, keep it brief version of that commit message. The other one you can go pretty long on. I would recommend doing that especially if you've made a significant number of changes. But at the very least make sure that that summary is descriptive enough so that somebody going back through your get log messages isn't just seeing a bunch of messages that say updated the homepage. Explain a little bit more about what you updated in the homepage for example. In the final way and perhaps one of the easiest ways to make code a little bit better this is something that's approachable even as a junior. If you don't know how to for example make code shorter or if you don't know what comments need to be updated the very least you can do is make the code conform to some sort of standard syntax standard format. Now the way that you can determine what format that is is to go and look at other code in that code base. If this particular file for example is mixing single quotes with double quotes maybe it's mixing different types of indentation clean that stuff up and it makes code more readable it makes it more predictable and when you're writing code in the future it makes it a little bit more uniform. There's not some kind of idiosyncrasies with certain parts of the code base. Instead it is uniform it is readable and people who approach the project later will appreciate that little bit of polish that little bit that you made better when you touch the code. Ultimately this comes down to writing code changing code for the future you or the future other person who is going to be changing that code right. You want to make things better for the next person that comes along leave something better than you found it. Leave everything better than you find it. Thank you so much for listening to today's episode of Developer Teaou may have noticed that we didn't have a sponsor but today's episode was brought to you by spec. You can visit us at spec.fm Developer Tea is a part of spec network and there are a bunch of other podcasts and content providers that you need to check out on spec as soon as you can. Make sure you subscribe to Developer Teain iTunes. I will leave a link in the show notes which you can find by the way at spec.fm. That link will take you directly to iTunes, subscribe and leave us a review. If you enjoy Developer Tea and you don't leave a review then you can help us so much by telling other people that you enjoy the show on iTunes. It takes just a few seconds. Leave a review. It is the biggest way to help Developer Teaout. Thank you so much for listening to Developer Tea and until next time, enjoy your tea.