I could ask this question all the time, whether in person or online, or in different formats, the question, what does it mean to write good code? We've covered it on this show, and the question is intentionally simplified. Of course, there are many different definitions and many different ways of forming this question. What does it mean to write good code? What does it mean to write? Maintainable code, readable code. In fact, I recently was on the platform hash node, and I answered this question there as well. I want to answer this through the lens of a heuristic, a useful heuristic for you to use. That's what we're going to do in today's episode. My name is Jonathan Cutrell, and you're listening to Developer Tea. My goal in this show is to help driven developers connect to their career purpose and do better works. They can have a positive influence on the people around them. Today's episode is a practice episode. It is as practical as it gets, and hopefully this heuristic is going to be useful to you. This is going to be a shorter episode for today. We've been doing a little bit longer episodes recently, so we're switching things up so that you can listen to this episode much faster than our more recent episodes. So I do want to go ahead and talk about today's sponsor very quickly. Today's episode is sponsored by Linod. Linod has been sponsoring Developer Tea. Basically, since we started this thing, with Linod, you can have Linux running in the cloud in just a few clicks. Basically choose your distribution, your resources, and your node location, and then click go. You're able to access your Linod just in just a few minutes. Quite literally, it's a very simple process, but that's not all that makes Linod unique necessarily. Linod is unique because it is built by developers, and they have extra tools on top of what just a normal cloud service provider would normally give you. For example, you can log back into a locked out server using their LISCH tool. This is a tool that allows you to access your server, even when you accidentally lock yourself out of it by screwing up a configuration file or something like that. You can also network together multiple Linod instances using the node balancer tool, and you can do some deep analytics to understand the performance of your servers using their long view tool. There's tons of other options in services that Linod provides, and they go all the way into even providing professional dev operation services for you. Go and check out what Linod has to offer. They're going to give you $20 worth of credit to use towards any of their services or plans today by heading over to spec.fm slash Linod. Use the code Developer Tea 2018 at checkout to get that $20 worth of credit. Thank you so much again to Linod for sponsoring today's episode of Developer Tea. Oh, and by the way, with Linod, you can get started with just $5 a month. That's their entry level plan. Again, spec.fm slash Linod. We're talking about a simple heuristic. This is one of many heuristics, by the way, to answer this question, what is good code? Really it's a subjective question to some degree. There are ways of measuring good code, but it's going to come down to your individual situation. But specifically from the perspective of maintainability. Most people, they compromise on maintainability more than any other particular metric. That's because maintainability is perhaps the hardest metric to optimize for. Of course, I think it's important that we recognize that the code must do what it's set out to do. It must be correct. This is a key factor for any code. Certainly it is not good code if it's not accomplishing what you set out to accomplish with the code. That's kind of a black and white checkbox that you can strive after to begin with. But when we're talking about maintainability, there's so many different factors that go into maintainability. For example, is the code readable? Is it well tested? Is it something that I could hand to another person that hasn't seen the code and they can relatively quickly get used to using it or get used to working with that code? The heuristic that I want to give you is a very simple one. That's one that's based on a very human response to code. That is fear. Fear is something that gives us direction. It gives us nudges to keep us out of trouble, keep us out of hot water. The types of hot water that we want to stay out of as humans, first of all, start at survivability. We want to be able to survive. When we go down that chain, as we progress through things that are easy to survive, the fears become more about our continuity to thrive or continuity to increase our chances of survival. That means thriving. For today's discussion, thriving means keeping your job. Thriving means being well received by your peers. The heuristic I want to talk about is being afraid to change code. This really human emotion of fear can drive our behavior when we are working in a code base. Before you write this off as disconnected, of course, you're not thinking about survivability and thriving whenever you're looking at a code base. You almost certainly have approached code and decided not to touch it. You did not change something in it because you were afraid that something was going to happen. Something bad would happen. Like, for example, it would break. Of course, code breaking doesn't really threaten you. It doesn't really threaten your survival. But it's actually the effect of that code breaking that you're afraid of. In other words, if people know that you broke the code, then that may threaten your ability to thrive. It may threaten your ability to get a raise, for example, or to continue working on projects that you enjoy working on. It may threaten your autonomy. It may threaten the perspective that other people have of you as a good programmer. What we often do is we avoid changing code because we are afraid of it. What can we do to fix this? We can create code that doesn't insight that fear. This is maintainable code. Code that is easily changed. Code that when you approach it with a new thing in mind, with a change in mind or with a bug fix that you have been assigned to or some other reason you want to change the code, that you can fairly easily without much friction, without much fear go in and change that code. Some of this can be mitigated from an organizational standpoint. For example, you are not going to be nearly as fearful of changing code that doesn't really have any consequence attached to it. You are not going to have as much of a fear because the consequence not being there really means that there is no threat. There is no threat to your survivability, no threat to your thriving, no threat to your autonomy, to your social status, no threat to changing code that nobody cares about. Some of this is organizational to remove those threats, remove those consequences and allow a breaking code to be an okay thing in your organization. Of course, this actually threatens the organization's ability to continue surviving and thriving. If those breaking changes, if that lack of fear is not also paired with a requirement to find the solution to actually go through and fix things. So the real answer here is kind of an all of the above answer. We need to change our organizational structure and incentives to allow for failure so that people are not afraid to change things and they are not afraid to accidentally fail from time to time. But we also need to change our code base so that failure as a result of change is less common. This is seemingly simple but it turns out to be kind of the whole point of best practices and principles and object-oriented design to make maintainable code. Now another piece of this puzzle is not just creating code that you aren't afraid of changing but rather that other developers are also not afraid of changing. And this happens very often. There's someone who knows everything about a particular project or a particular part, you know, a class for example, maybe there's a mega class that you've written in your code. And there's one person who has kind of always owned that particular piece of code and anybody who has questions about it, they go to that person and it's all kind of kept in their minds. This is a bottleneck and it can become a problem and there's an illusion of quality or of maintainability because this person does indeed know so much about this piece of code that the company is still able to be productive. The problem is this is ultimately a bottleneck, right? In this scenario, falls apart whenever that key person goes on vacation or if they get sick or perhaps they decide that they want to work at a different place. So now you are left with code that has knowledge about that code is locked up in somebody's brain and you no longer have access to that person. So writing maintainable code, writing good code means distributing the information about that code amongst multiple people, right? So there's lots of ways that this plays out, but the heuristic is the thing that's the key important detail because if you can figure out what, if you can dig up what is causing you to be afraid of changing this code, that's going to be different for every organization. That's going to be different for every person. For example, maybe the reason you're afraid of changing this code is because that particular code is using an algorithm that you have never studied before, right? This is probably an uncommon reason, but still certainly possible. You haven't studied this particular algorithm and whenever it was written, you know, the person who wrote it knew that algorithm well. They had studied it. Well, this transfer of knowledge needs to happen or you need to replace that algorithm with something that you do understand. Or commonly you're going to see code that has abstractions, layers of abstractions that aren't documented or otherwise are strange, poorly named sometimes. Sometimes the abstractions are just too deep for whatever the problem at hand is. So it's not clear what's going on in the code. And luckily these problems have been encountered and subsequently they've been designed around multiple times in the past. So I encourage you to read about design patterns, read about refactoring patterns, read about anti-patterns. These are all things that are going to help you write more maintainable code that you are not afraid to change. Thank you so much for listening to Developer Tea today. Thank you again to Linode for sponsoring today's episode. Head over to spec.fm slash Linode and use the code Developer Tea2018 at checkout for $20 worth of credit. Thank you so much for listening. If you're enjoying these episodes by the way, you can provide value back to me by taking just a few minutes to open iTunes and leave a rating and review for the show. This is the best way to help Developer Teacontinue doing what we do and help other developers find the show. Thank you again for listening and until next time enjoy your tea.