The Business of Good Code
Published 7/25/2016
In today's episode, we talk about some of the characteristics of good code, and why it's so important for businesses to invest in good code.
Today's episode is sponsored by RefactorU, the 10-week JavaScript training bootcamp focused on developers dedicated to reinventing themselves. You can get 20% off of tuition by mentioning Developer Tea today! Head over to spec.fm/refactor to get started!
Transcript (Generated by OpenAI Whisper)
Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're talking about the business of good code. Today's episode is sponsored by RefactorU. You can reinvent yourself with RefactorU's full stack JavaScript bootcamp. We will talk more about what you can do at RefactorU later on in today's episode, but first I want to jump into this topic of the business of good code. What exactly is good code? Well, this isn't going to be the only definition you ever use. So remember that as with most good questions that we ask ourselves, the answer is it depends. But for the average project, we can define good code by a few metrics. And also just so happens that these things are what make the business case for good code. So today we're going to outline three basic markers that you will see in good code. By no means is this list comprehensive, but it should give you an idea about what you can start to look for when you're evaluating other people's code or your own code and when you're writing your own code. The first and in my opinion, the most important characteristic of good code is that it's understandable to a human. You can read it as a human. There are two reasons code exists, the basic fundamentals of why do we have code. The two reasons are number one, that it performs some function. It actually does something with bits, right? It represents something, it models something, it does something. For example, if you are a web application developer, then the code you're writing is modifying database structures, maybe it's creating some kind of information presentation markup in HTML. And then the browser is taking that and it's presenting it to the user. These are all the functional things that your code does. But the second reason code exists is so that it can be managed by a human. The functional side of code is kind of a given, right? Good code, of course, must function properly. But if you can't understand what is happening in the code when you read it, then it no longer really needs to exist as human readable code at all. Might as well be compiled to the binary version of that code. And sometimes this actually does happen. Some piece of code becomes what we would consider complete. It's never going to be changed again in the future. It's never going to be modified from the state that it's in today. So we might as well just go ahead and compile it down to its binary, right? And get rid of the original human readable code. But remember code is written for humans to understand and for computers to execute. So good code is understandable. And this may seem intuitive to us as humans. And as we're writing our code, we may understand the single piece of code that we are writing in that moment. But even with years and years of experience, you will come to learn that writing code that other humans can understand and writing code that you can understand in the future. It takes a lot of practice and a lot of intentionality. You can't just write code and expect it to be understandable later as well. So that's the first characteristic of good code. It must be understandable to human. Other people, other developers should be able to read the code and understand what is happening if they have reasonable experience with whatever language you're writing in. And we're going to take a quick sponsor break to talk about today's sponsor, Refactor U. And then we're going to talk about the other two characteristics and markers of good code. So today's sponsor is Refactor U. They are a full stack JavaScript boot camp. If you are learning to code online, but you're hitting a brick wall, Refactor U is an immersive full stack JavaScript boot camp dedicated to the learning needs of aspiring web developers looking to reinvent themselves. Refactor U is a 10 week JavaScript training boot camp with a dedicated career services team. They're based in the booming tech city of Boulder, Colorado. And they have tons of great opportunities. For example, they were just approved for the GI bill. And they also have diversity scholarships available for each cohort and Developer Tealisteners can get a 20% tuition discount when you mention Developer Tea. Just go to spec.fm slash Refactor. At Refactor U students learn from world class peers and instructors while working on real hands-on coding projects. Go and check it out spec.fm slash Refactor. You can get a 20% tuition discount when you mention Developer Tea. Thanks so much to Refactor U for sponsoring Developer Tea. So we're talking about the business of good code today. And the first characteristic of good code is that it's understandable to a human. And the reason we need to have code that's understandable to a human should be relatively obvious, right? The easier it is for another developer to understand the code that you're writing, the easier it will be for them to start working on that code. And that's what our next point is about our next characteristic is that good code is easy to change. Good code is easy to change. Let's think about code for a moment like we think about a car. The cars functions are typically pretty well documented, right? We have a manual that we can keep in the car. We can go and look different parts of the car up. Perhaps most importantly, what do we do when something goes bad? Some system or some part fails. Well, we can relatively easily Google the parts and replace it. We can order one and it'll be at our doorstep in a few days. We can also take the car to a mechanic and they can perform that work for us. We can even upgrade that part to a higher performance version in some cases. In other words, when it comes to cars, things are relatively easy to change, aren't they? They're relatively easy to replace. When something goes wrong, it's pretty much a plug-and-play to fix the problem. When we write code, are we thinking about the importance of our future changes or our future failures? Some of this is certainly an overlap with the first point that our code needs to be understandable to humans. Obviously, it's going to be difficult to change if it's difficult to understand, but ask yourself about potential changes in the future to this code. For example, when you write a number in your code, you should be asking yourself, is it possible for this number to change? And if so, maybe you should write that code slightly differently, maybe move that number to a different spot in your code or move it to a configuration option. You'll come to learn that making code easy to change isn't just a one-shot solution. The principles of object-oriented design are shaped around this primary concept, the concept of making code easy to change, easy to fix. I recommend that you take some time to look deeper into object-oriented design ideas, such as the single responsibility principle. We have some of these things covered in various episodes of Developer Tea. I will leave a link in the show notes too, for example, our single responsibility principle episode just to get you started down that path. We have one final characteristic to talk about today for good code, the business of good code. And that is number three, well-contained. Good code is well-contained. This is something that you would learn as you study object-oriented design as well, but let's go ahead and unpack a little bit of that here in today's episode. Well-contained code simply means that you see what you need to see to understand the code you are reading. Hopefully you can see a theme here. Good code is ultimately going to be code that is understandable. And understandable code means that you can see what you need to see to understand it. It is well-contained. If the code has external dependencies, for example, it tells you that by requiring those dependencies explicitly, you can see what the environment that the code is running in. That is important. If you are looking at a piece of code and you don't understand that environment, then you are going to have a hard time understanding where different functions or methods are coming from. So if the code has external dependencies, we will tell you that by requiring those dependencies explicitly. The code is written so that side effects in other parts of the system are minimized. In other words, the code that is executing in this file has little or no effect on code executing in other files. And the use of global variables or global state is minimized so that leaking logic between different files doesn't occur. You don't really want to depend on global variables that can be changed or non-existent depending on the execution of this particular file. How is this file being executed? Global state has been shown time and time again to cause, typically to cause problems in code. And it's a little bit difficult to manage global state. There are a few exceptions to this rule, but typically they have to do with something like scripting when you have a small script. And generally, you can even avoid global state in those situations as well. So the three characteristics that we talked about today, once again, they are not comprehensive of what it takes to write good code. But the three characteristics we talked about today are number one, good code is understandable to a human. Number two, good code is easy to change. And number three, good code is well contained. Thank you so much for listening to today's episode of Developer Tea. I hope it will inspire you to write better code and to study a little bit more about what it means to write good code. As we've said over and over, there are so many parts of coding and software development that they depend on your situation. They depend on what the job of that code is. And so it's important to understand that all of these things that we talk about, they are situational. They're going to change based on your situation. And it takes some time to develop an intuition for what level of scrutiny, what level of focus do you put on a given piece of code? How long lived is that piece of code, et cetera? There's a lot to talk about here. Of course, you will talk about it more in future episodes of Developer Tea. And if you don't want to miss out, make sure you subscribe to the show and whatever podcasting app you use. Thank you again to Refactor U for sponsoring today's episode of Developer Tea. Refactor U is a 10 week JavaScript training boot camp. They are dedicated to the learning needs of aspiring web developers looking to reinvent themselves. And they are offering you a 20% tuition discount when you mention Developer Tea. Go and check it out. Spec.fm slash Refactor. Thanks so much for listening to today's episode of Developer Tea. And until next time, enjoy your tea.