Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking about coding without fear. But first I want to talk about today's sponsor, Leno.com. You can instantly deploy and manage SSD servers in the Leno Cloud. Leno is, they're the masters of Linux servers. Essentially, you can run a private Git server. We'll talk a little bit more about that later on in today's episode. I want to jump right into the topic of coding without fear today. On a recent episode of Developer Tea, I told you to leave code better than you found it. I listed a few ways of doing that. I'll include a link to that episode in the show notes. In fact, I had a conversation about that episode with somebody online and they talked about leaving code the way it is because of the fear of introducing bugs. This is a very commonly held belief that if we leave code the way it is, if it doesn't expose any bugs currently and we don't change it, then we are less likely to introduce new bugs. But I think we should challenge the notion that we shouldn't code, we shouldn't change code, we shouldn't make it better, we shouldn't update comments or refactor the code for fear of introducing bugs. I think that that is the wrong perspective because instead of making things better, we're simply leaving them in the state that they are hoping that they continue to work. The way that I think about this is we're towering things on top of each other and as long as it stays balanced, we don't want to put anything else on top of that shaky tower. Unfortunately, we eventually have to change that code. Eventually we have to add new things to that code or we have to deal with the bad parts of that code at some point or another. In today's episode, I want to give you a few tips for how you can begin to code without fear. This is really just some best practices for dealing with change, for dealing with flexibility, the necessity of flexibility. I have four tips for you today and the first one is that test coverage, your major test coverage should be for the most important paths, the users of your application travel. Let me say that again, the most robust part of your test coverage suite needs to be for the most important paths, the users of your application travel. What this does is if you introduce a bug, then if you have test coverage for those most important paths, then you have most of the critical things covered. What this allows you to do is introduce bugs that are less critical, even if you don't have test coverage for those things, you at least are not breaking the critical paths of your application. What are critical paths you might ask? The answer is different for every single application, but some may be the ones that are fundamental to the business. For example, checking out, you should never introduce a bug and ship a bug that breaks a checkout process because typically checkout is a fundamental business need. If you don't have checkout, then the business comes to a grinding halt. Another example is if you are on the web and your homepage goes down, this is the fundamental thing that you need to allow for people to see. Another great example is user login. Most of these things can come naturally. When you think of the most important things that a user does in your application, login, buy things, see the homepage, see the primary pages, maybe send a message or receive a message, these are very fundamental pieces of what your application probably does. Tasks that may be less important like archiving old items or reaching into the backlog of things, things that are typically done very seldomly by a user. Users are going to be less important and typically if you introduce a bug in those areas, that bug isn't going to get a lot of traffic and you can offload the negative side effects of people hitting that bug to some level of customer service. This is in a traditional business model where customer service is actually dealing with the bugs that people experience in your application. Let's jump on to tip number two. That is to create code that invites change and minimizes side effects. We could do an entire series of episodes on this subject because there are so many different practices that go into this. For example, avoiding global state, naming your variables well, these are things that help avoid side effects. If you want to look into functional programming, for example, some of the ideas behind avoiding too much mutation and too much trying to control state, these are ideas that can help you move towards a more flexible, change-oriented codebase. The fundamental idea here is that your code should be able to be changed and tested without having to think that maybe what you just did is affecting something way off in another section of your code. Of course, sometimes that is not a reality and we have to deal with those bugs, but creating an application that follows some of these best practices will help you get to the state of being able to trust that your code doesn't have side effects. I'm going to put a link in the show notes for flux architecture. This is a recently popularized architecture. It's basically a methodology or a concept for data flow in your application. This is one of the things that you can look at to kind of get an idea of how you can head towards a more flexible codebase, one that invites change and one that avoids the negative parts of side effects. I have two more tips for you guys today, but first, I want to talk about linode.com today sponsored. Linode allows you to instantly deploy and manage an SSD server in the Linode cloud. You can get a server running in seconds with your choice of Linux distribution, resources, and the node location, the physical location of the node itself. They provide hourly billing, a monthly cap on all the plans and add-on services, for example backups, node balancers, and long view. And you could run something like a get server on Linode. They give you root access. You get full control. You can run VMs. You can run containers. Pretty much anything you can do in Linux on your local machine. You can do that on Linode. Linode has also been kind enough to provide an unlimited number of signups using the code developer T10. So go today to linode.com slash Developer Tea and use the code developer T10 to get $10 credit towards a brand new linode account. Go today to linode.com. Thanks so much to linode for sponsoring today's episode of Developer Tea. So the next tip that I have for you today is to never introduce vigilante code. Now what is vigilante code? Well, it's code that only one person knows how to deal with. It's code that only one person understands. So if you introduce this vigilante code into your system, then only that one person knows how to manage it. So what are types of vigilante code? Well, one example is a overly clever solution to a problem that could otherwise be solved with another solution that is more accessible to people who aren't familiar with whatever the clever solution is. Another great example is when a person uses a particular language or framework that the rest of the team is not yet familiar with to solve a sub problem, a small problem inside of a project. And so when somebody else from the team encounters that code, they see something brand new that they've never seen before. They've never encountered. And they have to go and learn about whatever that language or framework is to actually even work on that code. So introducing vigilante code into your process into your code base is going to end up in having more bugs introduced because only one person is able to maintain that code properly. And if somebody else comes in and tries to fix a bug or better that code in some way, and they don't understand it fully, well, now you're dealing with a situation where somebody who is normally a good developer in their domain, somebody who knows JavaScript, for example, really well, is trying to fix something in JavaScript, the one copy script file in a given project, and they don't know copy script very well. It's much more likely that they're going to introduce a bug into the copy script file than they would introduce a bug into plain JavaScript. So the rule of thumb here is to only write code that at least one other person fully understands to the level that you understand it. My last tip for you today is to simply accept the fact that bugs come with a territory of writing new code. And you need to create processes that handle these bugs in some maintainable way. You shouldn't think that adding new code is as simple as just adding that code and walking away. It needs to be tested, it needs to be verified, and you should expect that sometimes new code will unfortunately add bugs. And the reason for that is because bugs are a product of code. Bugs don't happen on their own, they don't creep into your code without you knowing it while you're asleep. You write the bug. And improving code isn't optional. Leaving code better than you found it is better than continuing to pile onto that mess of a tower that's about to fall over anyway. Introducing minimal amounts of code can help prevent these issues, but refactoring isn't just a fad. It is something that reduces your future workload massively. It increases clarity in your code base and exposes bugs earlier rather than later. So it's important that you refactor, create processes around refactoring, and don't change code unless you know you have the time to also deal with any bugs that may arise as a result of changing the code. And you need to create a process for dealing with those bugs. You can't just simply go along and say, no, don't change it, don't change it because we're afraid. You need to code without fear. And the only way to code without fear is to be ready when the bugs come because they will come. Nobody writes software without writing bugs. And you absolutely have to improve your software. You can't leave software the same way you found it. You must. You must leave it better than you found it. It's the only way to make your process more efficient and it's the only way to improve code as you go throughout a project. Thank you so much for listening to Developer Tea today. I hope that this has been a challenging but also an inspiring episode for you to go forth and make processes that make your code a little bit less scary. I'm actually recording this on Halloween, which is appropriate for the topic, I guess. But I hope this ignites a conversation amongst you and the people that you work with and your friends and your family even about coding without fear, creating processes that reduce the fear and deal with the fact that you're going to introduce a problem into that system. Thank you so much again for listening. Thank you to today's sponsor, Linode. Remember, you can get $10 off on a brand new Linode account by using the code Developer T10. That code will be in the show notes, which you can find at spec dot F M. Make sure you subscribe to Developer Tea. If you don't want to miss future episodes of Developer Tea, you can do that in any podcasting app that you listen to. And if you want to help the show out, if you think that these episodes are helping you out, if we are providing you value, then you can help us out. You can kind of pay us back by going and leaving a review on iTunes. This is the most important thing for the health and the longevity of Developer Tea. If you want to stick around, then leaving us a review is the best way to help the show out and help other people just like you find Developer Tea. Thank you for listening to today's episode and until next time, enjoy your tea.