We all have the general belief, most likely, that experience speaks to skill. That those are positively correlated with one another. The more experience that you have, the more reliable your skills may be. And the more information, the more knowledge that you have, perhaps even the more intuition that you have. This is generally true as we experience things, we categorize and we filter and we file those experiences away so that when we recognize future experiences, we know what to do. And this is really kind of the process of learning. Learning is really based on your experiences. But experiences are not just about climbing a single ladder, right? That's what we're talking about in today's episode. We're going to talk about some of the ways that experience actually makes you a worse programmer. And what that means, both for you as an experienced programmer or for you as an inexperienced programmer. My name is Jonathan Cutrell and you're listening to Developer Tea. And my goal on this show is to help driven developers connect to their career purpose so they can have positive influence on the people around them. Today's episode does not have a sponsor and in lieu of that, I'd like to encourage you to subscribe in whatever podcasting app you use. Let's jump into today's topic about experience as you can experience. This is really kind of a fundamental thing that your brain does not just for developers, but for everybody and everything as you can experience, you start creating schemas. This is the way your brain works. It creates schemas. You begin to categorize those experiences that when you see something similar in the future, you have experiences to draw on. So you did an X in response to this particular situation that looks similar and Y was the result. And so if you were to do X in this situation, then you can likely expect something similar, something like Y. And as you gain more experience, your schemas become more detailed. They become more nuanced. They become more functional instead of looking at a situation and trying to categorize it, you start maybe looking at the features of that situation. The various aspects, breaking it down and creating kind of these sub-schemas, some of this I'm kind of making up, but you get the idea here. As we have experiences, we begin to catalog those experiences. You can think about this as kind of like a dictionary or a deeply nested structure in your brain with a very complicated and complex way of traversing that structure and acting on whatever it is that you find in the future. So these schemas are incredibly important. And most of what we do as developers is reliant on this structure, this experience, schema structure. But there are some drawbacks to it. As we gain experience, two things may happen that are drawbacks of that experience. The first thing that may happen is those pathways are traveled so often that we might put it on some form of autopilot. Those reactions almost become unconscious reactions. So you may have kind of these immediate if this then that responses to those situations. And again, this can be really valuable, but it can also limit you. When you may reach for an immediate solution because it's built in so deeply ingrained, someone with less experience may do something different. They may think a little bit slower about that particular problem, about that particular scenario, and then choose a different route than you would have chosen. So that's the first thing that may happen. You may go on autopilot. The second thing that may happen is very similar to the first thing. As you begin to build the schema out, you may leave out entire pathways that otherwise could and perhaps even should have been traveled. This concept is essentially like a blind spot. So even if you aren't totally on autopilot, you may have a classification of solutions for a given problem. And that classification doesn't really cover the whole spectrum. And so you end up with blind spots as a result of this. Your brain can't really create all of the possible pathways, and of course it can't. We can't expect our brains to do that. But as a beginner starts on this path, they don't have the schema built up. So younger developers, you're listening to the show, I encourage you to not be afraid of choosing different solutions. Of course it's important to recognize that there's a lot of value to be learned from people who have experience. But remember that your benefit as a young developer is that you are more apt to question why. Why are we choosing solution X over solution B? And when you ask these questions, you're slowing down your thought process and you're creating your schema more intentionally, rather than relying on your existing schema, you're forging new schema. So if you are an experienced developer, in order to kind of combat this issue where you may have blind spots, it's important that you do two things. And listen to the questions and the concerns of learning developers. If you're an expert, then having the questions reposed to you that you haven't asked maybe in even in years, these same questions, allowing those questions to be asked and considering the answers slowly, intentionally slowing down. And I would even recommend doing something like telling yourself out loud that I'm going to think about this thoroughly. I'm going to think slowly about this idea. This will allow you to challenge your schema. And it's important that you keep this learning mindset, not just because maybe your schema is wrong. That's not really the point. The point is that blind spots can cause problems as you collaborate with other developers. Especially if you're in a company where you have new people onboarding all the time, one of the reasons that new people often feel imposter syndrome as they come into a company regardless of their experience level is because other people in the company are fairly experienced with their way of doing things. And in fact, usually companies have a kind of way that the company does things. And so as you come in as a new developer for that company, it's easy to feel like an imposter if you don't know why things are done the way that they are. So experienced developers, if you are mentoring younger developers, especially if those developers are working in a collaborative role with you, encourage you to slow down and allow those Developer To ask why things are the way that they are. And young Developer To take advantage of this brand new field of new schema that you're creating in your mind. I encourage you to listen to more than one experienced developer. Get the opinion of multiple experienced developers. This will help you establish a wide base, a wide understanding to build your schema from. And it will help you avoid pigeonholing too quickly and ultimately creating even more blind spots. So, and keep in mind, I highly recommend that you stay focused on a very few things. As you're learning, especially as a young developer, I encourage you to stay focused, for example, on one language. Learn one good dynamic programming language of some sort, something like Python, Ruby, JavaScript, even Java. These are things that if you learn the basics, the fundamentals of programming with a well-established language that has a vibrant community, a lot of documentation online, a lot of projects that you can learn from. Any of those languages are going to do fine. But if you ping pong between multiple languages and you learn just a little bit of each one, eventually you're going to know some syntax, but you're not really going to know how to build anything of value in that language. So, I'm not saying to listen to every expert on what language to learn and then go and try to learn them all. Instead, listen to the opinions of multiple experienced developers. Especially if you can listen to the opinions of multiple experienced developers on the same topics. This will give you an idea of kind of the landscape of the various solutions that people have to the same types of problems. Once you start developing a wide schema as a young developer and as an experienced developer, once you start questioning your schema, what you'll realize is that you're always relying on other people. You will always have a blind spot. You'll never have a wide enough schema. You'll never be able to question your schema enough to eliminate all of your blind spots. And so your highest likelihood of success in finding and addressing those blind spots is if you can remember that your opinion will only take you so far. And in fact, any other single person's opinion will also only take you so far. Collaboration is about taking opinions and combining them together. Finding places where opinions collide and then working it out. This is what collaboration means. And so you have to check your ego at the door as a developer. You have to be aware that even though you have ten times more experience than a young developer, that the young developer's perspective is fundamentally less encumbered than yours because they don't have those built up schemas. As a young developer, you have to recognize that even if you see what you believe are flaws in the experienced person's approach, that they have a much more developed schema. And that ultimately gives them a high problem solving ability in most cases. And what this means, the outcome of this is that we have to rely on each other. We have to check our ego at the door, recognize that we all have different types of blind spots for different reasons. And then listen to each other, listen to our opinions, listen to the way that we are solving problems, listen to questions about why. Thank you so much for listening to today's episode of Developer Tea. To those of you who have left a review on iTunes, this is a huge help not only in helping me direct the show's content and to make this a more useful and valuable show for people who listen to it, but also to help other developers find the show and decide if they also want to listen to it. Thank you so much for listening. If you haven't subscribed, I encourage you to subscribe in whatever podcasting app you're using right now. Until next time, enjoy your tea.