Who owns the code that you write? I don't mean literally or legally, of course, if you are hired to write code, then depending on whatever your contractual terms you are hired under, it's very likely that the company that you write the code for owns the code that you write. But conceptually or perhaps philosophically, who owns the code that you write? That's what we're discussing in today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you connect to your career purpose so you can have a positive influence on the people around you. And in order to do that, in order to connect to your career purpose, you have to connect to the reality that you are not the only one in your story. We said this on the last episode of Developer Tea. You are not the only person that matters in your purpose driven career. If your entire purpose is centered only on you, then it will quickly fall apart. You will realize very quickly that very few other people are going to exist in order just to make your thing happen. So it's important to recognize that very early on because what you're going to find out is that if you have a purpose that is self-centered, then the biggest advocate you have is yourself. But if you have a purpose that is collective-centered, in other words, it brings other people in and it magnifies their best interests as well, then suddenly you have other advocates. You have your co-workers as advocates, or even better, you have your customers, the people that you actually interact with in a business sense, they become your advocate instead of being antagonistic towards your customers or antagonistic towards your co-workers. You now are kind of fighting for the same thing. And so I ask this question again, who owns the code that you write? You see the reality is as developers, we have strong opinions, very often we develop our opinions sometimes for very good reasons. We've experienced some kind of issue in writing our code in a particular way and we don't want to experience that issue again. It was painful. It took time. It ended in an error or maybe we just don't even like that particular style of that particular language. We don't like the way that it looks. We don't like having to write that code with tabs instead of spaces, for example. And all of these preferences, all of these things that we bring to the table when we're writing code, they really give us a false sense of ownership over our own code. We're going to take a minute to talk about today's sponsor and then we're going to come back and talk about a better way to think about ownership when it comes to code. Today's episode is sponsored by Linode. Linode allows you to instantly deploy and manage an SSD server in the Linode cloud and you can get a server running in just a few seconds with your choice of Linux distribution, resources and no location. Linode is going to empower you as a developer to listener with $20 worth of credit. That's basically a $20 bill. It's equivalent to four free months on their one gigabyte of RAM plan. That's a $5 month plan. So normally you be paying $5 month, of course, with $20 worth of credit, that means you get four months for free. They have 10 data centers worldwide. They have block storage available in Newark, Fremont, Dallas, Atlanta, Frankfurt, London, Singapore and soon to be released in Tokyo. They have native SSD storage on their servers and they all run on a 40 gigabit network on top of Intel E5 processors. The state of the art for the server business. And of course, the best features are usually the simplest ones. With Linode, you get Linux in the cloud. So you basically get full control of a high powered Linux machine for only $5 a month, starting at $5 a month. Of course, they have high memory plans. Those start at 16 gigabits and they have a seven day money back guarantee. Get over to linode.com slash Developer Teato get started today. Use the code Developer Tea2018. Check out for that $20 worth of credit. Once again, that's linode.com slash Developer Tea. Thank you again to linode for sponsoring today's episode of Developer Tea. It's not all that surprising that we view our code with some level of ownership. Some level of I won't call it obsession, but craftsmanship pride. There are a lot of words that we can use for the kind of method, the opinions, the practical opinions that we have about the way that we write our code. And so it comes as no surprise that we end up struggling over these opinions, particularly when someone has a strong, but different opinion from us. But what if we framed our code in a little bit of a different light? What if instead of viewing our code as the product of a craft, we viewed it as maybe a production, a performance? What if instead of viewing our co-workers as people who are also practicing the same craft or maybe invading our workshop where we're practicing our craft? What if we viewed them as audience members? Now, in some ways, this analogy doesn't really hold up because, of course, they are also working on the same thing that we are working on. But in other ways, it definitely holds up because we are building something that is intended to be, we're producing something that is intended to be consumed by those other people. Our code is being read by other developers. So it's important to understand that when another developer is reading your code, they have the critics viewpoint. In other words, it's not the performer's job to determine whether or not the performance went well. Of course, a performer can self-evaluate and they can practice. They can continue to hone their craft, but ultimately, it's the people in the audience who will decide if the performance went well or not. It's the people in the audience who pay for the tickets. It's the people in the audience who consume the performance. In the best case scenario, you'll have a performance that satisfies both the performer and the audience. The performer feels that they have done their best performance, their most authentic performance, their highest level of craftsmanship has been put into that performance. And the audience enjoys the performance thoroughly. In most cases, both sides give and take. And when it comes to your coworkers, you have to realize that more than being a group of craftsmen working on your individual crafts, you're more like maybe a symphony or a band. You're working on your collective craft. And there has to be some level of agreement or at least consensus. If you choose as your sole part of that band or as the individual instrumentalist in the symphony, if you choose to do things your own way, you're probably going to make the rest of the band sound bad. You're probably going to ruin that performance to some degree. And even your own satisfaction level will probably be pretty low because although your personal standards are being met, you're certainly out of sync with your collaborators. And so working as a developer looks very much like compromise. Unless you're writing code for a personal project and unless that code truly is only owned by you, only going to be read by you and only going to be maintained by you. In every other scenario, in professional scenarios in particular, how you write your code is not really totally up to you. And this doesn't mean that you can't bring your opinions to the table. And we aren't talking about going along with a poor performance. Instead this means that collaboration and understanding that the other people who are consuming your code, who are reading it and who are having to work in it, that their voice is important, but their opinions are important. That if they believe that your code, for example, is complex, well, complexity, similar to beauty, is in the eye of the beholder. This is why it is so important that when you begin on any project, when you join any team, that you remember that your ego will probably get in the way. Your opinions, your experiences, what has built up over time to make you believe what you believe can become an enemy. Not only an enemy to the project or to your success, but an enemy to your career and an enemy to your collaborators. Your developers understand that good code is more like harmonious performance than workmanship. It's more about creative consensus than it is artistic expression. It's more about understanding the needs of others than it is satisfying their own needs. I'll challenge you today as you work on whatever team you're on, as you work on whatever project you're working on. Imagine what it would be like if you withheld your opinion. Not forever, and certainly not to say that your opinion is a bad thing, but instead, so you can practice the art of listening to the opinions of others. Meaning that harmony and being in sync is not about always following the metronome perfectly, but instead sounding good together. Working in collaboration with each other, even when you don't have the perfect process nailed down, even when your code isn't necessarily perfectly optimized. If your team is working in harmony, that is far more important than the subjective perfection of your code. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Leno. Leno just giving you $20 worth of credit to get started on their services. Head over to linod.com slash Developer Tea. Remember to use the code Developer Tea2018. That's all one word and check out for the $20 worth of credit. If you enjoyed today's episode and you don't want to miss out on future episodes just like this one, go ahead and subscribe before this episode ends. Go ahead and subscribe in whatever podcasting app you're currently using so you don't miss out. Thanks for listening and until next time, enjoy your tea.