Vox

Leitura de 14 min

The Business of Good Code

Summary

This episode of Developer Tea focuses on defining what constitutes ‘good code’ from a practical business perspective. Host Jonathan Cottrell argues that while definitions may vary depending on context, there are three fundamental markers that characterize quality code in most projects.

The first and most important characteristic is that good code must be understandable to humans. Cottrell explains that code serves two purposes: to perform functions for computers and to be managed by humans. If code isn’t readable and comprehensible to developers, it might as well be compiled to binary since it loses its value as maintainable software. He emphasizes that writing understandable code requires intentional practice, even for experienced developers.

The second characteristic is that good code should be easy to change. Using the analogy of car maintenance, Cottrell illustrates how well-designed systems allow for straightforward repairs and upgrades. He connects this to the first point—code that’s hard to understand will inevitably be hard to modify. The episode touches on object-oriented design principles like the Single Responsibility Principle as frameworks for creating adaptable code.

The third characteristic is that good code is well-contained. This means code should minimize external dependencies and side effects, making it clear what environment it operates in and reducing reliance on global state. Well-contained code helps developers understand what they’re looking at without needing extensive context from other parts of the system.

Throughout the episode, Cottrell acknowledges that these principles are situational and depend on factors like the code’s expected lifespan and purpose. He encourages developers to develop intuition about when to apply different levels of scrutiny to their work, and promotes continued learning through resources like object-oriented design study.

Recommendations

Educational-Resources

  • Object-Oriented Design Principles — Mentioned as important frameworks for creating code that’s easy to change and maintain.
  • Single Responsibility Principle — Specifically referenced as a key object-oriented design concept that helps make code adaptable; previous Developer Tea episodes on this topic are recommended.

Training-Programs

  • Refactor U — Sponsor offering a 10-week JavaScript bootcamp with career services, based in Boulder, Colorado; provides GI Bill approval and diversity scholarships.

Topic Timeline

  • 00:00:29 — Introduction to Good Code — Jonathan introduces the episode’s topic: defining what constitutes ‘good code’ from a business perspective. He acknowledges that definitions vary by context but promises to outline three fundamental markers that characterize quality code in most projects.
  • 00:01:26 — First Characteristic: Understandable to Humans — Explains that good code must be readable and comprehensible to humans, not just functional for computers. Cottrell argues that code serves dual purposes—performing functions and being managed by developers—and emphasizes that writing understandable code requires intentional practice beyond mere technical execution.
  • 00:05:47 — Second Characteristic: Easy to Change — Discusses how good code should be designed for modification, using car maintenance as an analogy. He connects this to understandability—code that’s hard to read will be hard to modify—and mentions object-oriented design principles like the Single Responsibility Principle as frameworks for creating adaptable software.
  • 00:08:20 — Third Characteristic: Well-Contained — Describes how good code minimizes external dependencies and side effects, making its environment and dependencies explicit. Cottrell warns against over-reliance on global state, which can create maintenance challenges, and emphasizes that well-contained code helps developers understand what they’re working with.
  • 00:10:25 — Summary and Contextual Application — Recaps the three characteristics of good code and acknowledges that their application depends on situational factors like the code’s purpose and lifespan. Cottrell encourages developers to develop intuition about when to apply different levels of scrutiny to their work.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2016-07-25T07:00:00Z
  • Duration: 00:12:23

References

Podcast Info

Transcript

[00:00:00] Hey, everyone, and welcome to developer team. My name is Jonathan Cottrell. And in today’s episode, we’re talking about the business of good code. Today’s episode is sponsored by refactor you, you can reinvent yourself with refactor use full stack JavaScript boot camp, we will talk more about what you can do at refactor you later on in today’s episode. But first, I want to jump into this

[00:00:29] topic of the business of good code. What exactly is good code? Well, this isn’t going to be the

[00:00:39] only definition you ever use. So remember that as with most good questions that we ask ourselves,

[00:00:45] the answer is, it depends. But for the average project, we can define good code by a few metrics.

[00:00:53] And also just so happens that these things are what make the business case for good code.

[00:00:59] So today, we’re going to outline three basic markers that you will see in good code. By no

[00:01:07] means is this list comprehensive, but it should give you an idea about what you can start to look

[00:01:12] for when you’re evaluating other people’s code or your own code. And when you’re writing your own

[00:01:19] code. The first and in my opinion, the most important characteristic of good code is that

[00:01:26] it’s understandable to a human, you can read it as a human. There are two reasons code exists,

[00:01:33] the basic fundamentals of why do we have code, the two reasons are, number one, that it performs

[00:01:41] some function, it actually does something with bits, right? It represents something, it models

[00:01:48] something, it does something. For example, if you are a web application developer, then the code

[00:01:56] is, you know, modifying database structures, maybe it’s, you know, creating some kind of

[00:02:02] information presentation, markup in HTML, and then the browser is taking that and it’s presenting it

[00:02:08] to the user. These are all the functional things that your code does. But the second reason code

[00:02:14] exists is so that it can be managed by a human. The functional side of code is kind of a given,

[00:02:21] right? Good code, of course, must function properly.

[00:02:26] But if you can’t understand what is happening in the code, when you read it,

[00:02:31] then it no longer really needs to exist as human readable code at all, might as well be compiled

[00:02:37] to the binary version of that code. And sometimes this actually does happen, some piece of code

[00:02:42] becomes what we would consider complete, it’s never going to be changed again in the future.

[00:02:48] It’s never going to be, you know, modified from the state that it’s in today. So we might as well

[00:02:53] just go ahead and compile it down to its binary.

[00:02:56] Right? And get rid of the original human readable code. But remember, code is written for humans to

[00:03:03] understand and for computers to execute. So good code is understandable. And this may seem intuitive

[00:03:12] to us as humans. And as we’re writing our code, we may understand the single piece of code that

[00:03:20] we are writing in that moment. But even with years and years of experience, you will come to learn

[00:03:26] that writing code that other humans can understand and writing code that you can understand in the

[00:03:32] future, it takes a lot of practice and a lot of intentionality. You can’t just write code and

[00:03:38] expect it to be understandable later as well. So that’s the first characteristic of good code,

[00:03:45] it must be understandable to human. Other people, other developers should be able to read the code

[00:03:52] and understand what is happening. If they have reasonable experience,

[00:03:56] whatever language you’re writing in.

[00:03:58] We’re going to take a quick sponsor break to talk about today’s sponsor refactor you and then we’re

[00:04:03] going to talk about the other two characteristics and markers of good code. So today’s sponsor is

[00:04:10] refactor you they are a full stack JavaScript boot camp. If you are learning to code online,

[00:04:16] but you’re hitting a brick wall refactor you is an immersive full stack JavaScript boot camp

[00:04:22] dedicated to the learning needs of aspiring web developers

[00:04:26] looking to reinvent themselves. refactor you is a 10 week JavaScript training boot camp

[00:04:33] with a dedicated career services team. They’re based in the booming tech city of Boulder,

[00:04:38] Colorado. And they have tons of great opportunities. For example, they were just

[00:04:43] approved for the GI Bill. And they also have diversity scholarships available for each cohort

[00:04:49] and developer T listeners can get a 20% tuition discount. When you mention,

[00:04:56] developer T just go to spec.fm slash refactor at refactor you students learn from world class

[00:05:04] peers and instructors while working on real hands on coding projects. Go and check it out spec.fm

[00:05:11] slash refactor. You can get a 20% tuition discount when you mention developer T. Thanks so much to

[00:05:17] refactor you for sponsoring developer T. So we’re talking about the business of good code today.

[00:05:24] And the first characteristic of good code is that it’s a business of good code. So if you’re a

[00:05:26] good developer, you’re going to want to understand the code that you’re writing. And the reason we

[00:05:30] need to have code that’s understandable to a human should be relatively obvious, right? The easier it

[00:05:36] is for another developer to understand the code that you’re writing, the easier it will be for

[00:05:41] them to start working on that code. And that’s what our next point is about. Our next characteristic

[00:05:47] is that good code is easy to change. Good code is easy to change. Let’s think about code for a

[00:05:55] moment. Let’s think about code for a moment. Let’s think about code for a moment. Let’s think about

[00:05:56] a car. The car’s functions are typically pretty well documented, right? We have a manual that we

[00:06:03] can keep in the car. We can go and look different parts of the car up. Perhaps most importantly,

[00:06:09] what do we do when something goes bad? Some system or some part fails. Well, we can relatively easily

[00:06:17] Google the part and replace it. We can order one and it’ll be at our doorstep in a few days. We can

[00:06:24] also take the car to a mechanic and replace it. We can also take the car to a mechanic and replace it.

[00:06:26] They can perform that work for us. We can even upgrade that part to a higher performance version

[00:06:32] in some cases. In other words, when it comes to cars, things are relatively easy to change,

[00:06:38] aren’t they? They’re relatively easy to replace. When something goes wrong, it’s pretty much a

[00:06:45] plug and play to fix the problem. When we write code, are we thinking about the importance of

[00:06:52] our future changes or our future failures?

[00:06:56] Some of this is certainly an overlap with the first point that our code needs to be understandable

[00:07:00] to humans. Obviously, it’s going to be difficult to change if it’s difficult to understand. But

[00:07:06] ask yourself about potential changes in the future to this code. For example, when you write a number

[00:07:12] in your code, you should be asking yourself, is it possible for this number to change? And if so,

[00:07:19] maybe you should write that code slightly differently. Maybe move that number to

[00:07:22] a different spot in your code.

[00:07:26] Or move it to a configuration option. You’ll come to learn that making code easy to change

[00:07:31] isn’t just a one-shot solution. The principles of object-oriented design are shaped around this

[00:07:38] primary concept, the concept of making code easy to change, easy to fix. I recommend that you take

[00:07:46] some time to look deeper into object-oriented design ideas, such as the single responsibility

[00:07:53] principle. We have some of these things

[00:07:56] in various episodes of Developer Tea. I will leave a link in the show notes to, for example,

[00:08:01] our single responsibility principle episode, just to get you started down that path.

[00:08:07] We have one final characteristic to talk about today for good code, the business of good code.

[00:08:14] And that is number three, well-contained. Good code is well-contained. This is something that

[00:08:20] you will learn as you study object-oriented design as well. But let’s go ahead and start.

[00:08:26] Unpack a little bit of that here in today’s episode. Well-contained code simply means that

[00:08:32] you see what you need to see to understand the code you are reading. Hopefully you can see a

[00:08:37] theme here. Good code is ultimately going to be code that is understandable. And understandable

[00:08:44] code means that you can see what you need to see to understand it. It is well-contained.

[00:08:49] If the code has external dependencies, for example, it tells you that by requiring those

[00:08:55] dependencies explicitly. You can see what the environment that the code is running in.

[00:09:03] That is important. If you’re looking at a piece of code and you don’t understand that environment,

[00:09:08] then you’re going to have a hard time understanding where different functions or

[00:09:12] methods are coming from, right? So if the code has external dependencies, it will tell you that

[00:09:18] by requiring those dependencies explicitly. The code is written so that side effects in other

[00:09:25] systems are minimized. In other words, the code that is executing in this file has little or no

[00:09:33] effect on code executing in other files. And the use of global variables or global state

[00:09:40] is minimized so that leaking logic between different files doesn’t occur. We don’t really

[00:09:47] want to depend on global variables that can be changed or non-existent depending on the

[00:09:52] execution of this particular file.

[00:09:55] This file being executed, global state has been shown time and time again to cause typically to

[00:10:03] cause problems in code. And it’s a little bit difficult to manage global state. There are a

[00:10:09] few exceptions to this rule, but typically they have to do with something like scripting when you

[00:10:16] have a small script. And generally you can even avoid global state in those situations as well.

[00:10:22] So the three characteristics that we talked about

[00:10:25] today, once again, they are not comprehensive of what it takes to write good code. But the three

[00:10:32] characteristics we talked about today are number one, good code is understandable to a human.

[00:10:38] Number two, good code is easy to change. And number three, good code is well contained.

[00:10:46] Thank you so much for listening to today’s episode of Developer Tea.

[00:10:50] I hope it will inspire you to write better code and to study a little bit more about the

[00:10:55] what it means to write good code. As we’ve said over and over, there are so many parts of coding

[00:11:03] and software development that they depend on your situation. They depend on what the job of that

[00:11:09] code is. And so it’s important to understand that all of these things that we talk about,

[00:11:14] they are situational. They’re going to change based on your situation. And it takes some time

[00:11:20] to develop an intuition for what level of scrutiny, what level of focus, and what level of

[00:11:25] do you put on a given piece of code? How long lived is that piece of code, etc. There’s a lot

[00:11:31] to talk about here. Of course, we will talk about it more in future episodes of Developer Tea. And

[00:11:37] if you don’t want to miss out, make sure you subscribe to the show in whatever podcasting

[00:11:42] app you use. Thank you again to Refactor U for sponsoring today’s episode of Developer Tea.

[00:11:49] Refactor U is a 10-week JavaScript training boot camp.

[00:11:54] They are dedicated to learning how to write good code.

[00:11:55] Learning needs of aspiring web developers looking to reinvent themselves. And they are offering you

[00:12:02] a 20% tuition discount when you mention Developer Tea. Go and check it out. spec.fm slash refactor.

[00:12:10] Thanks so much for listening to today’s episode of Developer Tea. And until next time, enjoy your tea.

Visão de gráfico