As we often do on the show, in today's episode, we're going to discuss a concept that extends beyond development. And we're going to bring it into focus as it relates to your life, your job as a developer, the work that you do. This concept is present in many different religions and philosophies, whether those religions are theistic or not. Regardless of your values, regardless of your beliefs, this concept could have a positive effect on your work, on your development work. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to help driven developers like you connect to your career purpose and do better work. So you can have a positive influence on the people around you. In today's episode, we're discussing the concept of non-attachment, sometimes called detachment. And this word is incomplete because there's so many other words that describe this. One word might be apathyia. This was a Greek word that is used by a couple of religions related to this concept. But let's take out any religious background at all for the sake of the discussion. What exactly is detachment? What is non-attachment? First, I want to tell you a story that you're probably familiar with. Hopefully you'll see yourself in this story. There was a senior developer that was talking to a junior developer. And the junior developer had brought some code to the senior developer. And the senior looks at the junior developer's code and starts to provide some feedback. The feedback ultimately has the junior developer thinking that they're going to need to rewrite major portions of this code. And the code wasn't very long, 100 lines or maybe 150 lines, something like that. But the junior developer had spent quite a long time on this code. They'd gone back and forth, tried a bunch of different things, failed a lot along the way. And ultimately they arrived where they were through a lot of pain and toil and a lot of work, a lot of investment on their part. The senior developer didn't know this, of course, but was looking at the code for essentially what it was, providing feedback for what they saw in front of them. From the senior developer's perspective, this code was exactly what it was. There was no context of the amount of work that had gone into it. And so the junior developer begins to kind of protest against this feedback. The junior developer looks at the senior developer and says, well, you don't know how much time I've spent on this, how much this means to me and how long I thought about this code. This is a picture of attachment. We'll come back in just a moment and kind of finish out this story and learn how we may be able to detach in useful ways. But first I want to talk about today's sponsor, DigitalOcean. DigitalOcean is the easiest cloud platform to run and scale your applications. This is pain free development with DigitalOcean from effortless administration tools to robust compute storage and networking services. DigitalOcean provides an all-in-one cloud platform to help developers like you and your teams save time when running and scaling your applications. With DigitalOcean, you get predictable and affordable pricing. You also get industry leading price to performance ratios. So it's not just about reducing your pain. It's also incredibly affordable. Pricing is consistent for month to month and it's consistent across regions at any usage volume and you get these bonuses. Like for example, monitoring and alerting are included with DigitalOcean. If this wasn't enough to convince you to go and check it out, then DigitalOcean is going to throw down $100 worth of credit on the table for you to pick up. That's totally yours. $100 credit by heading over to do.co slash t. That's do.co slash t e a. Thank you again to DigitalOcean for sponsoring today's episode of Developer Tea. So this senior developer is talking to the junior developer and giving them feedback, explaining to them how they may make their code better. They may improve it towards their common goals. And this isn't the first picture of attachment in human history, certainly not in our time, but also over the course of pretty much as long as humans have been able to communicate. We are not in control of everything that happens to us. That's true even before we had communicated language. We can simply not control everything that happens to us. Sometimes we can't control how long we have to spend on code to produce ultimately something that still needs more improvement. And so we end up in these scenarios where we want one thing, but reality is producing something different. Call it whatever you want, use whatever term you want, but the current situation for this junior developer who's talking to the senior developer is that they don't have the code that the senior developer would kind of sign off on. The code is not yet there. And so regardless of what has happened, regardless of what is in the past, the code would still need work. The code still has room for improvement. If you listen to the show for very long, then you may have heard us talk about something called the sunk cost fallacy. And this plays heavily into our attachment issues. This isn't the only reason we become attached to things, but in this case, if you have two different perspectives looking at this code, one that has seen and endured all of the pain that it took to produce this code and another perspective that hasn't seen that pain, then the value placed on that code is likely to be very different. Our nature values the experiences that we've had and we keep these mental accounting ledgers, the amount of time I've invested in something must make it worth more. Very often as developers, this is simply not true. And so our attachment issues, the things that we kind of put our identities next to our signature, the things that we care about deeply, that we can't always necessarily directly control. Those can be sources of pain, of bias, of poor decision making, of an unwillingness to learn to improve and ultimately they can make us deeply unhappy, resentful people. This is not where we want to end up. And so we have to work all of the time to identify things that we are attached to. We have to work all of the time to fight our egos as Developer To avoid situations where we're so married to our own opinions that we end up losing. We end up not accomplishing the goals that we want to accomplish. We end up not learning the things that we want to learn and very often we end up isolated and stagnated. These are things that none of us really want and yet we perpetuate these things by feeding our attachment. We allow our attachment to grow rather than consistently trying to detach. So how can we detach better? Well, we talked about ways that we can check our egos, we can constantly practice this. Of course, maintaining a mindful outlook on your work, on your own behavior, this is incredibly important to being able to detach. Attachment is something that kind of happens automatically. So for the things that happen automatically, you as the person that is kind of operating in this automatic way, you have to put some kind of trip, some kind of interruption into that automatic behavior. Something that will trigger to allow you to recognize when it's happening. So maybe you can make a conscious decision in that moment rather than making an unconscious automatic decision. And there are many ways that you can practice mindfulness. Some of them are your own practice, like for example, meditation. Other things like asking someone around you to hold you accountable, to call out behaviors that when you're thinking about it, you don't really want to participate in, but sometimes you automatically do. Establishing procedural ways to instill mindful behavior. This would be things like code review and having rules for your code review, having a culture that you've developed around reviewing code that intentionally kind of forces negative feedback to make its way into your normal everyday procedures. But ultimately, perhaps the most important thing you can do on a regular basis is remind yourself that you're not the only one. The world is not revolving around you. The universe is not revolving around you. Your job is not simply there to serve you. It's easy to kind of automatically believe this, where wired to survive, and where wired to make ourselves the most important part of our own stories. But if we can climb out of our own heads for a moment and try to zoom out, try to think about things that go beyond us. For example, take a moment and try to imagine what the world was like before you were here. And what the world will be like after you're gone. Your workplace will be like when you've moved on. When you realize that everything is temporary, then attachment kind of melts away, kind of dissolves, becomes dissonant with the way that you see your work, because you know that your work is temporary. And to attach yourself to something that is temporary, that's not really a good idea. That feels more dangerous. It feels risky. So instead, you can zoom out and recognize the temporal nature of pretty much everything that you experience, all of your work, all of the things that you do, and detach from that. Allow them to be what they are. Remind yourself as the junior developer, that the code that you write, no matter how good or how bad it is, you will move on from it. And remind yourself as a senior developer, that when you're providing things like code review, and really you can provide code review at any stage in your career, but as a senior developer, when you're providing code review, remember that things, once again, are temporal and pass this on, try to remember that there is some active detachment that needs to occur for everyone. And encouraging junior developers who are looking up to you as the senior developer to not put their worth into their code, to not get so attached to it that they're afraid to change it. That's the kind of advice that you can get from a true mentor. Someone who cares about you more than they care about your performance. They care about you beyond your performance. Detachment is important across the board. It's important for us as developers. It's important for people who are managing product, for example, anybody who's dealing with clients, because you will experience frustration, loss, you will experience absolute and utter failure. Most people will experience some kind of catastrophic failure, things that we may never see coming until they're already passed, until they've already happened. We will experience these things. And if we allow ourselves to attach to those failures, then we unfortunately can't look forward. We can't improve. We can't move on. So I encourage you to practice active detachment, active non-attachment, active apothea, whatever word you want to use and whatever philosophy you come from, practice this moment of letting your ego die. Thank you so much for listening to today's episode of Developer Tea. I realize this is a little bit of a heavy episode, but hopefully you were inspired by it. And hopefully this is helpful for you. Those of you who are struggling with, for example, your own failures. This actually can be an uplifting thing to allow yourself to detach from those failures. And also, by the way, detach from your successes as well. Thank you so much for listening to today's episode. Thank you again to Digital Ocean for sponsoring today's episode. You can get a hundred dollars worth of credit by heading over to dio.co slash t that's dio.co slash t e a. Thank you so much for listening and until next time, enjoy your tea.