In today's episode, we'll talk about vantage points or thoughts to ponder or lenses that we can look through to view our careers and goals from time to time and get a better grasp on the meaning for what we're doing in development.
In today's episode, we'll talk about vantage points or thoughts to ponder or lenses that we can look through to view our careers and goals from time to time and get a better grasp on the meaning for what we're doing in development.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
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.
Most of our careers are fast-paced. We don't have a lot of time to stop and think about what we're making, about the material of code, the substance, what it is that we're actually dealing with. And so it's easy to kind of disconnect from that kind of thinking, the philosophy of what we're doing. And so in this episode, I want to take a moment and shift perspective a little bit. My name is Jonathan Cottrell, and you're listening to Developer Tea. And my goal on the 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. So what do I mean by the material of code? What exactly is it that we're creating? Are we creating something that we're not using? Are we creating something that we're not using? Are we creating documentation? Are we creating relationships? Are we moving bits around on a computer or perhaps on a array of computers? Or if you work with a network-connected device of some sort, then perhaps on a very large number of computers that you're changing bits on. What is it exactly that we're making? In today's episode, I want to discuss a few different kind of perspective shifts. Think about these as a very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, very big, step back, but it may be personally valuable to you to do this. It may be useful to you so that you can get a better grasp for the meaning in what you're doing. And again, it's not something that you necessarily have to do all the time. So I want to take a moment in today's episode and do that step back. Talk about three kind of different perspectives on code. And this won't just apply to code. It's going to apply to most things that we interact with as humans, most things that we're responsible for cultivating to some degree. Before we jump into these three perspective shifts, I want to take a moment and do something that we haven't done on the show, at least from what I remember, and read a review from a listener. Reviews are very important. We don't have a sponsor today, so I'm kind of doing this in place. Our sponsor, because reviews are incredibly important. They're kind of the raw feedback that I get from the people who listen to this show. I've read emails before, but I don't know that I've read reviews. And this review is on iTunes. It's left on October 10th. It's from Quarter Tonality. Quarter Tonality says, this has quickly become one of my favorite podcasts, and it's about so much more than coding. It's about learning and philosophy and productivity. In fact, if you aren't even a coder at all, I'm sure you'll still get a ton out of this podcast. They're brief, with a lot of insight packed into each episode. We're subscribing most definitely. Thank you to Quarter Tonality for leaving this review. And thankfully, this is also a five-star review. This is hugely helpful. And I've talked about this a lot at the end of the episodes usually, but these reviews truly are how people decide whether they're going to listen to a podcast or not. And as it turns out, it's also how iTunes determines what to show developers. That, amongst other things, their algorithm, of course, is not necessarily public, but we know that reviews are really helpful in spreading the show. So thank you so much to those of you who have left reviews. We actually have 138 reviews and 246 ratings on iTunes right now. And that's just a huge amount. So I'm very thankful to those of you who have taken the time to do that. It is a huge help to the show. Okay, let's get into our three perspective shifts in today's episode. Three ways of looking at your code perhaps a little bit differently. And the way that these are constructed is kind of as a substitution. A way that you might think automatically, and then a substitution for that way of thinking. And you'll see how this works in just a second. So the first shift that I want to talk about is the temporal nature of code. You may believe that you're going to be able to code in a way that you're not able to do. But the thing is, your code is timeless. That it doesn't have a life cycle. That because it is kept in a machine, that it's permanent. That once it comes into existence, there's not really a death for that code. There's no transformation for that code. That it is kind of a permanent fixture. And we can think about our interactions in the world and even the physical objects that we use. But we can think about the fact that we're not able to come in contact with that aren't perceivably alive. We can think about them in this way. That the physical decay doesn't necessarily affect them. But the perspective shift is that somehow, at some point in the future, your code will change. What your code is hosted on will change. How it's used. The context that it's in. These are things that will change without the context. These are things that will change without the context. These are things that will change without the context. These are things that will change without the context. These are things code ever itself changing. The way that people perceive it. The people who are reading it. In this way, it kind of philosophically changes. Not at the bit level, but instead, its meaning, its place in the world, and its significance, its impact. These things will all change over time. And eventually, for one reason or another, your code will no longer exist. Your code will have some kind of a life cycle. And that's what we're talking about. And that's what we're talking about. It's a kind of death. Of course, we can't really empathize with our code. It's not alive. It seems like it's a part of who we are. And so, it feels like it's something that we can leave as a legacy. But instead, if we can view our code as something that is temporal in nature, like most things that we interact with, then we can change the way that we attach ourselves to it. Instead of attaching ourselves to it, we can change the way that we attach ourselves to it. And so, if we can change ourselves to it as if it is our legacy, we may detach ourselves from it and view it more as a fingerprint. Something that can be wiped away, or that will shift over time, that may be covered up, or may be marred in one way or another. This temporal nature of our code, it can change the kind of buy-in that we have when we write it. A second perspective shift that we can adopt, we may believe that our code is a representation of a belief. Now, you have to kind of peel back the layers on this one, that the code is a representation of a belief. And what this may mean is that it's a belief that this is the best way to do something. It may be a belief that this is the most effective decision that I can make for business. This is probably not a phrase that you would use in an everyday conversation that your code is a representation of a belief, but it is something that we operate on on a regular basis. For example, we may attach ourselves, again, attaching ourselves to our code and kind of actively campaign for that code to be accepted into a code base, for example. This is kind of what we do when we open a pull request and then people provide comments and maybe we provide justifications. That our code is representing the belief for what should be done in a given context. The perspective shift is that our code can represent, instead of a belief, simply something that we want to try. This is an experimental mindset and it's rooted in this very simple concept that everything that we do and everything that we are is a work in progress. If we believe that we're supposed to submit code that is an accurate representation of everything that should be true, if we're supposed to submit code that is something that we want to try, then we're supposed to submit code that is an accurate representation of everything that should be true. If we believe that we're supposed to submit code that is an accurate representation of everything that should be true, based on some well-formed and polished belief, then we've kind of taken this perspective that we've arrived. We've figured out how we should be, how we should write code, how the business should operate. So we develop opinions over time and we develop them through trial and error. We develop them through learning and through collaboration. And this is what our code represents. At any given point in time, it represents where we are in our development. If we believe that we're supposed to be finished, that we're supposed to have arrived, that we know what we're supposed to know as a developer, then our code stands as a trophy, a representation of that knowledge. But if instead we adopt the perspective that we are a work in progress, that we're always learning, then our code represents experimentation. It represents trying something, a theory. When we take this perspective, we attach less of our identity or less of our pride to the code. And instead we view it as exactly what we said in the first kind of perspective shift. We view it as a temporal thing. It's very possible that this code will change, that this code will die. The last perspective shift that I want to bring up is one that allows us to think about the future. And that is the future. And that is the future. And that is the future. And that is the future. And that is the future. And that is the future. And that is the future. A lot of developers share, perhaps accidentally. When we first start learning code, we have a sense of pride, perhaps. I know that I had this experience. Many other developers have it. And some of it is a side effect of maybe a cultural stereotyping, something that has certainly been portrayed in a lot of media, movies, that kind of thing. That developers understand that they're not the same. They're not the same. They're not the same. They're not the same. They're not the same. They're not the same. They're not the Now, we have the ability to kind of see with this X-ray vision. To understand code is somehow superhuman or inhuman. If instead we viewed our job as developers to bridge the gap rather than highlight it, if we view code as a communication tool, rather than a secret language or a privileged kind of in-club communication tool, if instead we view it as a human communication tool and we invite people in, then perhaps we can change the way we think about what it means to be a developer altogether. Instead of it being a unique job that is only suited for the people who can grasp this complex thinking, we instead create a culture, we accept a culture that has open doors, that treats code like language, like the communication tool that it can be. This perspective... This perspective has the potential of perhaps increasing our empathy for beginner developers and for non-developers who don't understand what's happening. It may have the effect of changing the way we design languages and maybe even the way that we develop documentation. It can change the way we onboard new developers into projects that they've never worked on. Having the perspective of code, as a communication tool, forces, once again, detachment. We no longer put our job security in the hands of this kind of elitism, the feeling that we know code and therefore we're in the elite group of people who can get it. Instead, we have to focus on a different type of value, perhaps a better type of value. Now, you can see that this is a very different type of value. Thank you so much for listening to today's episode of Developer Tea. I hope you will take some time to imagine these perspective shifts, these different ways of thinking about code, thinking about your career, thinking about the way that you interact with this material. Thank you so much for listening. Once again, thank you to those of you who have left a review on iTunes. Those are incredibly valuable, both to me, to understand what you are thinking about the show and to give me some feedback, but also for other listeners who are concerned about the show. Thank you so much for listening to today's episode of Developer Tea. I hope you have found the show valuable. If you have found the show valuable, then I would love it if you would share that information with others in an iTunes review. This is hugely helpful for the show. Thank you so much for spending the time to listen to today's episode. Until next time, enjoy your tea.