What is the story of your code?
What does your code explain both in the code and outside of it?
In today's episode, we're talking about the reason for making the coding decisions that we choose to make.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
What is the story of your code? That's what we're talking about on today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in this show is to help different developers like you find clarity, perspective, and purpose in their careers. When I say the story of your code, what does that mean to you initially? How it came to being, certainly, but what exactly your code tells? What does your code explain both in the code and beyond it? It's important to recognize that all code, every piece of code you write, will have a story where it came from, why was written that way, why certain decisions were made, even if those decisions were made quickly, maybe made with your gut, versus arduous thinking, that is still a story. And here's the critical factor that I want you to understand for today's episode. And this is a short episode today, something for you to kind of meditate on and think about as you move throughout the rest of this week. The stories that you have around your code continue to accrue as time moves forward. So let's say you're writing in an object-oriented programming language, something like Ruby or Java, and you build up these names, these named conventions, classes, these objects, instances of classes, and you create an idea, some kind of mental wrapper around a bunch of values, maybe some primitive values or relationships to other things. And it's important to recognize that that idea is necessary to grasp what's going on in your code. But it's also important to recognize that the idea has more meaning than the code gives it. Think about that for a second. The idea has more meaning than the code gives it. A class means more to the person that is writing it than it means to the computer that is interpreting it. This is necessary to understand because it means that we name our classes, for example, in ways that constrain the way we can think about them. And so the narrative of our past code in many ways, constrain or helps define the narrative of our future code. You can imagine that if you were to rename every class in your code base that you might come up with a different structure entirely. And perhaps more importantly, a lot of those relationships you might have to rethink. Additionally, it's very likely that you have concepts that are named one thing, but are referred to as something different, or at least they're understood by you as the programmer or other engineers on your team as something different than what they're named. Perhaps there's more meaning that is imbued on that object. Maybe that meaning is living in slack conversations, or maybe it's living in your own personal memories or conversations that you had, or maybe it's in documentation. But we tend to overload the code that we write with more information and that story exists somewhere else, somewhere beyond the code. So there's two simple pieces of homework here for this episode. The first is to consider what that story is, what is the history of the code? How did it become the way that it is today in whatever project you're working on? And then secondly, it makes sense to consider where that story lives. Where do you go if you want to understand the story of the code? What you'll find very quickly is that there's not just one story. That everyone has a different experience with the code base, and in many ways the code is a snapshot of those various experiences. While one engineer may have fought for a long time with a particular class in the code base, another engineer may not have ever touched that class. Or maybe they wrote the original class. And now there's some kind of interpersonal dynamic as a result of those two people interacting with that code in that particular way. Take time to consider what the stories are. You're telling yourself about the code. Take time to consider what the stories are about the objects that are in your code base. And if it's not object oriented, there are still other things that are in your code base, processes, functions, definitions. All of these things that we add, we add meaning to, and we go beyond what the computer can understand. The culture surrounding your code is important to consider. Thanks so much for listening to today's episode of Developer Tea. This episode and every other episode of this show can be found at spec.fm. But of course, if you don't want to miss out on future episodes of this show, and I encourage you to subscribe and whatever podcasting app you're currently using to listen to this. Again, if you missed the announcement last week, we have decided to move to two episodes of this show per week. Previously, we were doing three episodes per week for a little over five years. We've decided to change pace so we can change the creative process a little bit. So hopefully you are enjoying this new cadence. Thank you so much for listening to this episode. Today's episode is produced by Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.