« All Episodes

Three Perspective Shifts for Philosophical Engineering

Published 10/19/2018

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.

Get in touch

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

🧡 Leave a Review

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.

Transcript (Generated by OpenAI Whisper)
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. So it's easy to 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 Cutrell and you're listening to Developer Tea. And my goal in 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 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 maybe vantage points or even as thoughts to ponder. You don't necessarily have to accept these as pure reality. But instead, think of them as lenses that you can look through to see your code a little bit differently from time to time. It's not always necessary and perhaps it may even be detrimental to your career depending on your goals to think philosophically, to take that bigger view and take a 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 were 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 of 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. It's 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 your code is timeless. But 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 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 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 it's meaning, it's place in the world and it's significance, it's 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 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. 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 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 maybe 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. And maybe 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. And this is kind of what we do when we open a poll 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. And 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 based on some well-formed and polished belief, then we've kind of taken this perspective that we've arrived. That we 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. When 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 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. But developers understand something that other people don't, that 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 Developer 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 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. Using the perspective of code as 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. This is a better 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 considering what podcasts they should spend their precious time listening to. So 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 you to show. Thank you so much for spending the time to listen to today's episode and until next time, enjoy your tea.