How does our brain perceive code in our environment? How does our mind make meaning out of that code? That's what we're talking about in today's episode. My name is Jonathan Cottrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. A philosophical discussion can be had about the role of code in our lives, but first I want to set up some backdrop and a little bit of theory for this exploration today. For the sake of today's thought experiment, we'll accept the idea that humans have evolved over some very long period of time. The length doesn't matter all that much other than to say it's very long to optimize for survival. And that the vast maturity of that period. Was spent in a world that looked very different from ours today. This idea that the human brain has evolved for a world that seems to kind of lurk beneath the surface of our culture and all of our kind of social practices today. And that it's actually suppressed by our civilized instincts and the societal norms. This isn't a novel concept. This idea that, you know, Lord of, Lord of the Flies style somewhere lurking underneath all of this. There's more primal instincts, but this concept is useful for confronting some hard questions about how our brains perceive that code. And that brings me to my next point. For the sake of this discussion, we'll talk about two distinct concepts, the brain and the mind. Now, this is absolutely a physical philosophical minefield, and I want to be careful here in suggesting a dualist mindset as if those two concepts are truly distinct, but. Yeah. When I refer to the mind or the brain in this episode, you might substitute the concepts of conscious and subconscious thought. We're essentially talking about the raw processing of information, which is what the brain might be doing versus the meaning making of that information, which is what the intangible mind or consciousness might be doing. The thinking about that information that you've processed is that meaning making process. On the one hand, our brain. The brain processes information in that subconscious realm constantly, sometimes without our explicit consent. This is how we can accidentally convert, you know, a cell phone into a gun or a stick into a snake. This is particularly true for things that we see as threats. But on the other hand, we dream up our own realities in our mind intentionally. We imagine objects or situations that don't really even exist. And. Sometimes even can't exist. Our brains in some interesting backward fashion are subject to this kind of sensory input as well. What we imagine we process in many ways as if it was real, even if it isn't. A short dive into Google can give you some more scientific background on this, particularly if you look for the idea that our consciousness itself is a reprojection of the output of that raw processing of data. In other words, our mind is actually making up what it thinks our brain is processing, is experiencing. So if we are reprojecting actual reality, then it certainly seems plausible that our imagined realities could be processed as if they were real. And this is exactly what research shows. And it's how we can have things like memory substitution. We remember events from our childhood as if they had. They happened to us, but it turns out they happened to a close family member. And this happens because over the years we tell that story over and over, or that story is told to us over and over, and the actual memory begins to warp as we replay that over and over. It's kind of like a VHS tape that's been played too many times, but instead of getting scratches on the film, you're replacing characters. But I want to get us back on track here, out of that philosophical realm about consciousness, and instead talk about how all of this relates to how we deal with code when we encounter it. This is obviously pretty complex. So with this complex backdrop, let's talk about how this ancient brain of ours in our modern context, and frankly kind of confused mind trying to bridge the gap between those two, how we can bring code into the picture. We're going to talk about that chance encounter right after we talk about today's sponsor. Linode. One of the amazing things about developing expertise is that it often starts small. It may even start as something fun, play. As an engineer, you probably know by now that we as a community of people take play very seriously. And playing around with some code can lead to some really important outcomes, both for the industry and for your own career. And so if you don't have the proper playground to actually test your ideas out, you can be easily disadvantaged. Now, how do you make a good playground? Well, you start small, but then you make it easy to scale up. And that's exactly what Linode does. Linode's plans start at $5 a month, and they scale all the way up to super production services, basically. Think GPU plans for AI processing. And that's exactly what Linode does. You can build a dedicated CPU plan so that you don't have any steel between you and another one of Linode's customers. All of this is based on this idea that having root access to a Linux server is one of the most powerful tools you can have as a developer. But on top of that, Linode is offering incredible hardware and tools to access these servers. So things like a Python CLI, or of course, an API. So this playground that you have is really, really, really, really, really, really, really, really accessible to all of your existing tools and your wildest automation dreams. Go and check it out. Head over to linode.com slash developer T and use the code developer T 2020. That's developer T 2020 at checkout. Thanks again to Linode for sponsoring today's episode of Developer T. Wherever you are listening to this podcast, I hope you have a moment where you can pause and think, truly think thoroughly about this next question. And you've probably thought about it before if you've been an engineer for very long at all. What exactly is code? Take a moment and really think about it. Pause the episode if you can. Some quick responses to this question might be, well, code is just business logic and behavior that's encoded into bits of information that a machine can interpret and run. And this answer isn't wrong. In fact, it's... This is right, but it's incomplete. If it were purely an expression of logic, it seems unlikely that we would have thousands of programming languages. Moreover, we wouldn't have millions of bugs in our software. So that hints at the idea that code is not simply logic. It's also very human. So how can we expand on this definition? Perhaps code is a means of translating our best understanding. About logic into a format that can be processed by a machine. But this too is correct, but incomplete. How can we account for perhaps one of the most important parts of code? The fact that we're not just translating it for another machine, but we also need to be able to maintain that. We need other humans to be able to read it and reason about it. Code then is a means of translating our best understanding about logic into a format that can be processed by a machine and can still be understood by other humans. I bet you can see where this is going though. This too is incorrect, but incomplete. When we use code as a tool for software engineering, we also create knowledge about that code that exists beyond the bits. We have things like tests, or documentation, memories, and lore. All of this could probably be considered part of the code. Because... Where exactly is that code? It exists on multiple servers. There's no one place for it. When we talk about a codebase, it's easy to imagine multiple versions and a history. Some kind of social reality, social superstructure that keeps that code going. We also attach a lot of our own personal pride and meaning into code. A lot of people see coding as an art. A lot of people see it as an art form. And on the opposite side, there's rejections of these same ideas. And the rejections themselves can be seen as these kind of social artifacts. So it becomes increasingly clear that we could continue expanding this, the definition of what code really is, further and further out. But I want to bring it back to that processing brain. Because we've been talking mostly about the mind. All of these words are very abstract concepts. They're just words. They're concepts. But I want to get back to this brain encounter with code. You see, our brains have not evolved quickly enough to categorize even machines, much less the code that they write. So we can't say that code is a threat or that it's an ally, for example. Our brains don't really know how to process that. You can imagine an image processing neural network that is trained on billions of images. But... The important part is that the image set is the image that is the most important part. At the very least, evolution brings evolution and evolution brings evolution. At the very least evolution brings evolution and evolution brings evolution. At the very least evolution brings evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution cats now while that processing will be very good at recognizing cats probably if you throw a dog into the mix that neural network is going to try to categorize that dog as a cat the concept of dogs for all intents and purposes is and will for some time be foreign to that neural network and you would have to explain to the neural network that this is something different you're going to have to label that particular image as something different from what it knows it would be wrong to say that computer neural networks are a perfect picture of how our brain works this isn't a perfect picture of how our brain works far from it the brain is optimizing for many more things than a neural network would be but the analogy is useful because instead of training a network with really tight constraints we've had hundreds of thousands of generations of humans that were you know kind of trained that have only seen cats right we've only seen a limited set of things and only recently only within the last couple thousand thousand years have we seen even letters we've known language for a long time the verbal language that we have is very core to our humanity and one of the reasons why i do a podcast but we haven't had the concept of writing or transferring knowledge through some characters for very long at all in a formal definition that is essentially what code is it's a very constrained type of writing a constrained type of use of characters to communicate something but code isn't just a dog writing isn't just something that's new and similar to things that we're used to it's more like an alien species that is essentially invisible most of the time and also everywhere all at the same time. So we clearly have not evolved to understand the role of code in our lives. So how does our brain perceive code? Most probably it doesn't. It doesn't really know that it's different from the things that we've experienced for millennia before this. Or maybe alternatively, it perceives code as a type of communication. But in any event, this is why working as a software engineer is fundamentally about people and about social interaction. And as it turns out, it's why we tend to attach a lot of our meaning and our ego to the code that we write. We don't really see the shape of the meaning of that code until we give it meaning. We infuse it with something that we do know so that we can try to understand it. Of course, these are all theories and none of this is easily proven, but it does make sense that code is so difficult to understand that we create understanding socially. We build meaning out of our code and the social structures surrounding our code so that we can understand it better. So what is the practical takeaway in this episode? Well, the first takeaway is to dispense with the idea that we're not able to understand the code. We're not able to understand what code means. Additionally, if we try to cling to what we think code means, or our appreciation of a particular style of code, it's very likely that it has nothing to do with the code itself. And it probably has something more to do with our personal experiences surrounding that code. Once we understand this, we can also start to recognize that the important parts of our job are not just the code itself, but the whole process. And that's why we're job are less about the code and more about people. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Linode for sponsoring today's episode. Head over to linode.com slash developer tea to get started today. You'll get $20 worth of credit as a new customer that listens to Developer Tea. That's developer tea 2020 at checkout. Thank you so much for listening to this episode. If you thought this episode was insightful or valuable, even a little bit, then I would like to ask you to consider leaving a review on iTunes, letting other people know. And if you haven't yet subscribed, maybe this is the second or third episode that you've listened to. I would encourage you to make the decision to subscribe to the show today. Thanks so much for listening. Today's episode was produced by Sarah Jackson. You can find every episode of Developer Tea as well as a host of other wonderful podcasts that are enlightening and thoughtful and valuable. Ultimately, we'll help you level up in your career at spec.fm. My name is Jonathan Cottrell, and until next time, enjoy your tea.