I get asked 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 Hashnode, and I answered this question there as well. But I want to answer this through the lens of a heuristic, a useful heuristic for you to use. And that's what we're going to do in today's episode. My name is Jonathan Cottrell, 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 work so 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 Linode. Linode has been sponsoring Developer Tea basically since we started this thing. With Linode, 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. And you're able to access your Linode just in just a few minutes. Quite literally, it's a very simple process. But that's not all that makes Linode unique necessarily. Linode is unique because it is built by developers, and they have extra tools on top of what they're using. So if you're a developer, you're going to want to have a little bit of of a look at what just a normal cloud service provider would normally give you. For example, you can log back into a locked out server using their Lish tool. This is a tool that allows you to access your server even when you accidentally kind of lock yourself out of it by screwing up a configuration file or something like that. You can also network together multiple Linode instances using the node balancer tool. And you can do some of the same things with Linode. 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 Linode provides, and they go all the way into even providing professional dev operation services for you. Go and check out what Linode 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 Linode. Use the code developer T 2018 at checkout to get that $20 worth of credit. Thank you so much again to Linode for sponsoring today's episode of developer T. Oh, and by the way, with Linode, you can get started with just $5 a month. That's their entry level plan. Again, spec.fm slash Linode. So 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 own. So if you're a good code user, you're going to want to know what individual situation, but specifically from the perspective of maintainability. Most people, they compromise on maintainability more than any other particular metric. And 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, right? So certainly, if you're a good code user, you're going to want to know what you're doing. And if you're a good code user, you're going to want to know what you're doing. So 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? So the heuristic that I want to give you is a very simple one. And it's one that's really kind of based on a very human response to code. And that is fear. Fear is something that gives us direction. It gives us kind of 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 survival. And then we want to start at survival. And then we want to start at survivability. We want to be able to survive. But when we go down that chain, as we progress through things that are easy to survive, the fears become more about our continued ability to thrive, our continued ability to increase our chances of survival. And that means thriving. And for today's discussion, thriving means keeping your job. Thriving means being well received by your peers. And that means being well received by your peers. And that means being well received by your peers. And that means being well received by your peers. And that means being well received by your peers. And so 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. Now, 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, decided not to change something. 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, doesn't really threaten your survival, does it? 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 thrive. It may threaten your ability to thrive. It may threaten your ability to thrive. 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. And so what we often do is we avoid changing code because we are afraid of it. Now, what can we do to fix this? Well, we can create code that doesn't incite that fear. And 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. Now, some of this can be mitigated from an organizational standpoint. For example, you're not going to be nearly as fearful of changing code that doesn't really have any consequence attached to it, right? You're not going to have as much of a fear because the consequence not being there really means that there's no threat. There's 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. And so some of this is organizational to remove those threats, remove those consequences, and allow 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 those, that lack of fear is not also paired with a requirement to find this 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 the code. We need to change the code. We need to change the code. We need to change the code. We need to change our organizational structure and incentives to allow for failure so that people are not afraid to change things and they're 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. And 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? And 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. And 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, there's lots of ways that this plays out. But the heuristic is the thing that's the key. Right? And so that's why I think it's important to think about this in a very 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, it'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. At least you may have taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and taken it and 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 DEVELOPERTEA2018 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 Tea continue doing what we do and help other developers find the show. Thank you again for listening. And until next time, enjoy your tea. See you soon.