There's a lot of discussion around what you should bring with you when you begin a career as an engineer, but rarely do people talk about what to leave behind. In today's episode, we're going to talk about 4 things you should leave behind when you choose to be a developer.
Build internal tools, remarkably fast. Connect to anything w/ an API. Drag-and-drop React components. Write JS anywhere.
Check them out over at https://retool.com/devtea
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
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. Specifically, 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 Cottrell. You're 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, and 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, and that is just as damaging. But if we can... If we can control the desire, the desire is the thing that motivates our actions. And so 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 or 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. And it's a damaging belief because it causes us to build entire systems. Around trying to predict and prevent bugs from occurring. Now, that'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 and 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 and one of those things is that even though you may catch let's say 80 of the bugs that uh 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 some amount of 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 opportunities cost of building those systems we were talking about to try to you know engineer our entire organization around bug catching our job is not to be a bug catcher so 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 and 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 crud 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 should be focused on products and we're going to talk about that in a little bit so let's get started so the first thing that we're going to talk about today is the build and maintenance of those apps right 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 so 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 a hundred times over they all pretty much need to connect to the data source and then with some code to function on that data source right 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 you're going to need to build your own app uis for your whole whole 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. And 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. And realistically, you're going to be on that pathway indefinitely. And that kind of inspires the next two things. The first one is the belief that there is a perfect environment for you to be able to do what you want to do. There's 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. And that stack works really well for them. And 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, it doesn't build itself and it doesn't exist as some kind of autonomous entity, right? You are working with the tech stack. And if it doesn't fit you or if it doesn't fit the thing that you're trying to do, then it doesn't matter what someone says about it at a conference or on Hacker News, right? So 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, 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 or we can accept the fact that the job that we have, we're working with a tool that maybe has some downfalls, right? It has some weak spots. It has some weak spots. It 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. Now 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. And to illustrate this point, I want you to do a kind of mental exercise. This is just a thought experiment. Imagine that you have your job today, right? You have your job today, but that we've somehow removed the idea that you have a job today. Remove 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? Now it's important to understand that there are people, people who are hired just to be coders. But this is a fragile job. It's a job that could easily be replaced. And 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 kind of 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. Right? Imagine taking that tool away. What is left in your skill set? Focus on developing those things as much and perhaps even more than your coding skills, because they're going to pay you back in spades, 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. A brand new sponsor. Head over to retool.com slash devtea. That's R-E-T-O-O-L dot com slash D-E-V-T-E-A. This episode and every other episode of Developer Tea can be found on spec.fm along with other incredible shows. They're built specifically for you. Shows like React Podcast and Tools Day. Go and check it out. spec.fm. 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 also go and check out the other shows 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. Thanks so much for listening. And until next time, enjoy your tea.