There's a lot of discussion about what you should bring with you when you start to learn a given subject. When you go to class or when you begin a career as an engineer. In today's episode, we're going to talk about the exact opposite. What to leave behind. Typically, I want to address the beginners who are listening to this episode. Young developers, when I say young, I just mean at the beginning of your career as an engineer, young developers who are just now starting out. In today's episode, we're going to talk about four things that you should leave behind. My name is Jonathan Cutrell. I'm listening to Developer Tea and my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. We're going to jump straight into the four things. What to leave behind as a new developer. Four things to let go. Four things that you might be carrying without realizing it. These are obviously not physical objects. If you've listened to the show even once, then you know that we tend to talk about things that are evergreen. These abstract ideas, the principles that you can carry with you that are going to apply in 15 years from now. The first thing that I want you to leave behind, and you may be very attached to this one. This one's a hard one to start out with. The first thing I want you to leave behind is the desire to control every outcome. The desire to control every outcome. Now, it's hard to leave the desire behind. We're specifically addressing this because I want you as a driven engineer to work on the desire itself. We may have the belief that it's possible to control every outcome. That is just as damaging. But if we can control the desire, the desire is the thing that motivates our actions. If we no longer want, if we no longer strive or target controlling the outcome, and instead we target something different, which we talk about on plenty of other episodes on this show, if instead, for example, we target refining our process or refining our iteration on experimentation and learning as we go. If those are the things that we intend to control, then the outcomes become something that we can observe rather than control. That's the shift that I want you to make. Instead of trying to control an outcome, imagine your mental shift going away from control and towards observation. The second thing that I want you to leave behind as a new engineer is the feeling that you should have caught every unexpected bug before it happened. This feeling is a sense of guilt or maybe a sense of duty. The idea that every bug that you are responsible for, whether it comes from your code or from a team you're working on, could have been caught, this can be a very damaging belief. It's a damaging belief because it causes us to build entire systems around trying to predict and prevent bugs from occurring. It's not to say that we can't catch any of them. Of course, a lot of our best practices are built off of the idea that we can exercise the various pathways that are in our code in ways that should, hopefully, produce some kind of foresight, trigger those errors before they go out, before they're shipped to our customers, before they're shipped to users. But there is a line. This is really a theme in this episode. The idea that things are difficult to control and there are very few absolutes in your career. One of those things is that even though you may catch, let's say, 80% of the bugs that will eventually show up in your code or eventually could show up in your code, there's another 20% and that number is arbitrary, by the way. There's another amount of bugs that are going to eventually show up and you're going to have to deal with them after they've made it to your users. This is frustrating, but it can also be liberating. When we think about the bugs that we need to catch versus the ones that we're trying to catch just because we've labeled it as a bug, then we can start to consider other opportunities and the opportunity cost of building those systems we were talking about to try to engineer our entire organization around bug catching. Our job is not to be a bug catcher. That is something I want you to leave behind. That title of bug catcher, the idea that you're going to catch every bug before it goes out, that's just not going to happen. It shouldn't. We're going to take a quick break and talk about today's brand new sponsor, Retool, and then we're going to come back and talk about two more things to leave behind as a beginner engineer. Retool is the fastest way to build internal tools. Now, if I'm being honest, most engineers don't love building internal tools. Some of us do, but apps like admin panels or basic crowd operations, customer support, inventory management tools. These are not the reasons why we got into being engineers. We'd rather focus on products, but every business runs off of internal tools like these, and the one really wants to deal with the headache of the build and perhaps more importantly, the maintenance of those apps, because there's always these requests that come in. They're very specific to a given use case, and it feels like those projects are never done and they tend to be underappreciated for that matter. When you think about it, internal tools are almost entirely comprised of the same building blocks. Tables, drop downs, buttons, text inputs. These are all things that we see in all of those internal tools, and that we've built 100 times over. They all pretty much need to connect to the data source, and then with some code to function on that data source. This is pretty straightforward. This is exactly how retool can help you. Retool gives you a drag and drop interface, so you as the engineer can build internal app UIs in hours rather than days, and spend more time building features that your customers will see. Spend more time on your products. It connects to any database or any API. For example, to pull in data from Postgres, you just write a SQL query and then drag a table onto the canvas. You can also write JavaScript pretty much anywhere inside of retool to manipulate the data in any way that you would like. Go and check it out. Head over to retool.com slash devt. That's retool.com slash d-e-v-t-e-a to get started today. Thanks again to retool for sponsoring today's episode of Developer Tea. There's two more things that I want you to let go of, to leave behind on your pathway to becoming a software engineer. Realistically, you're going to be on that pathway indefinitely. That inspires the next two things. The first one is the belief that there is a perfect tech stack waiting to be discovered. This is an easy thing to believe because there are people who have bought in very deeply to a given tech stack. That stack works really well for them. Perhaps when they write a blog post or they do a podcast or they go and speak at a conference, they talk about that stack as if it's kind of a one size fits all solution or as if it's the pinnacle of computer science. But the truth is that there is no one perfect tech stack. How can this be? When we're told this over and over and over that we're supposed to be refining our tools and building new ones and abstracting on top of those and getting better and better. The truth is that your tech stack is only part of the equation and you are a huge factor in that equation. Think about it for a second. You are a part of the tech stack. The tech stack doesn't build itself and it doesn't exist as some kind of autonomous entity. You are working with the tech stack. If it doesn't fit you or if it doesn't fit the thing that you're trying to do and it doesn't matter what someone says about it at a conference or on hacker news. You're not going to find the perfect tech stack and that should also feel liberating. It's a little bit disappointing because it'd be nice if we all agreed and we just went in one direction and we could find a tool that just works for everyone magically but it's not going to happen and that can be liberating because we can let go of that constant pursuit and be okay. We can choose tools that we like. We can choose tools that are safe where we can accept the fact that the job that we have or working with a tool that maybe has some downfalls. It has some weak spots. That doesn't necessarily mean the end of the world. It certainly doesn't mean that your engineering organization doesn't see the light. Once you are able to accept the fact that there's not a perfect tech stack, then you can work towards making the one that you have more valuable. I have one final thing that I want you to let go of and this really is an underpinning theme of this podcast entirely and that is that coding is not the job. Let go of the illusion that coding is the job and understand that there is so much more to being a software engineer than just writing code. To illustrate this point, I want you to do a mental exercise. This is just a thought experiment. One that you have your job today, you have your job today, but that we've somehow removed the responsibility of writing code from your plate. You no longer have to write the code. You still have to go through the same thought processes that you had before. You still have to think through all the same scenarios. You have to understand the people that you work with. You still have to work with the same stakeholders, etc. How would your job look different? What would change about your job? It's important to understand that there are people who are hired just to be coders. This is a fragile job. It's a job that could easily be replaced. If you're just now starting out in your career, especially if you have many years theoretically in front of you in your career, then focusing on just coding is not the pinnacle of what you'll do in your career. It certainly will be a part of it. But imagine that your coding is only one tool in a very wide array of tools that we already just mentioned. Imagine taking that tool away. What is left in your skill set? Just on developing those things as much and perhaps even more than your coding skills, because they're going to pay you back in space, not just in money, but certainly in relationships and in personal fulfillment. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Retool for sponsoring this episode of Brain New Sponsor. This episode and every other episode of Developer Teacan be found on spec.fm, along with other incredible shows that are built specifically for you, shows like React Podcasts and Tools Day. Go and check it out. Thank you so much for listening to this episode. If you've enjoyed this episode or another episode of Developer Tea, the best way that you can show your appreciation for the show is to go and leave a review. You can leave a review in whatever platform you use to listen to podcasts that allows for reviews, iTunes or Google Play, for example. This is a huge way that you can help other developers like you find Developer Tea and you can provide feedback and appreciation to us. And ultimately, this is one of the best ways you can help us keep the lights on on this show. So, until next time, enjoy your tea.