You already know that you need skills to be a developer. These are things that you work hard for. You spend time learning and practicing and failing. Beyond just the skills that you need, and we're including soft skills here too, there's still more to the job than a massing of a bunch of skills. You could be a very talented developer, but if you're not able to translate those skills into daily action, then the skills don't really matter. So we're going to spend a few episodes of Developer Teatalking about the habits of successful software engineers. And this isn't going to be only one kind of engineer. This isn't just for backend or just for front end. So we're going to cover a lot of ground, and there's going to be some abstract conversations, but we're going to try to use as many concrete explanations or examples as possible so that you can connect to this and start to kind of shape your list of habits. My name is Jonathan Cutrell, you're listening to Developer Tea and my goal on this show is to help driven developers find clarity, perspective, and purpose in their careers. And if you've been listening for very long and paying attention to the intros of the show, then you might notice that we changed that goal a little bit. Previously, the goal was stated as to help driven developers connect to their career purpose and do better work so they can have a positive influence on the people around them. And we still care about that. We still want to empower Developer To find something that they care deeply about and empower them to do better work as developers. But we've added to this goal. We've added the concept that there's more to being a developer and being a human than constantly seeking after some singular purpose. Because that is too reductive. It doesn't give us a chance to experience things that are totally different in life. It may even feel like a rule. And that's not the goal. The goal of this show instead is to inspire Developer To open up, not close down. So hopefully this new stated message captures that intent. And hopefully those of you who were listening because you connected with the old goal, that old message, you still feel the same connection. So we're talking about this idea that your talent or your skills really realize their value when you put them into action. And more importantly, not just a single action. You can't show off your skills once and then write on that for the remainder of your career. Wouldn't really be rewarding for you either. So what we're talking about here is consistent action. And the things that are consistent for humans are the things that we do almost automatically. The things that we do by default are habits. And often those habits are supported by the systems that we surround ourselves with. They are perhaps influenced by our small kind of mini cultures, the company that we work for or the family that we're a part of. And our larger cultures, maybe the city or the state or the country that we participate in. Even the virtual cultures that we're part of, like an online community, even the people who listen to this podcast, that's creating a particular type of culture. But habits are not all imposed on us. We have the ability to develop our own habits. If you want to look into the process of developing habits, encourage you to check out the book Atomic Habits by James Clear. This came out last year and proposes quite a lot of research that has been done around the concept of habit and how we build habits as humans. And I encourage you again to become a student of this because whatever you repeat over and over and whatever you repeat regularly, as in more often than not, the results of those repeated actions are going to kind of overtake whatever your other actions may be. You're much more likely to design your life based on your habits than on individual actions. So as developers, once we have kind of studied this building of habits, which we can talk about in another episode, then what habits should we build? What habits should we develop? This is what we're going to talk about in today's episode and in a couple of future episodes of the show. This isn't going to be a back-to-back series. It's something that we're going to talk about with some breaks in between so we can learn a little bit more about what successful software engineers, what their habits are. So that's what we're talking about in today's episode. We're going to cover a couple of habits in today's episode. But first I want to talk to you about Linode. Linode is today's sponsor. With Linode, you can instantly deploy and manage an SSD server in the Linode Cloud. You can get a server running in just a few seconds with your choice of Linux distribution, resources, and node location. Linode is now offering dedicated CPU instances. What would you use this for? Well, dedicated CPU instances are designed for consistent, high-performance computing needs. For example, if you wanted to encode video or maybe run a game server or if you have a very busy application, this would be an excellent use case for a dedicated CPU. All new customers right now of Linode get a $20 credit. And pretty much anything you can imagine building, you can build it on Linode. You can have distributed applications, hosted services, websites, even your own continuous integration and continuous delivery environments. Linode features native SSD storage, a 40 gigabit internal network, and industry leading processors. It can pick from any of Linode's nine worldwide data centers and they have two more data centers opening in Canada and India this year. Get started today with a $20 credit by heading over to Linode.com slash Developer Tea and use the code Developer Tea2019 that's the number Developer Tea 2019 at checkout. Linode.com slash Developer Tea. Thanks again to Linode for sponsoring today's episode. So we want to talk to you about one very important habit today and that's why we're only doing one. There are some kind of sub habits of this particular habit, but successful software engineers seek feedback. This is the habit that I want to focus on today. Successful software engineers seek feedback. Now, feedback can be from the machine, but the most important feedback that you're going to get is from the people that you work with and the people that you work for. Pretty much anybody who is influenced in some way by the work that you do. So it could be the users of your application. It could be the other developers on your team. It could be the stakeholders in whatever the product is that you're building and anyone who is surrounding that work, you can get feedback from them. And there's different types of feedback. For example, the most basic type of feedback is a kind of retrospective look into the past and as you are looking into the past or describing the things that you did and then trying to understand whether those were good things or bad things. It's very important when you do this and by the way, this is something that a lot of people don't do, but successful software engineers do have a habit of doing is not applying only good or bad labels to things. For example, a successful software engineer will accept that maybe they don't know if a decision was good or bad or maybe a decision was good and bad to try to categorize things only into two different categories is likely an inaccurate representation of reality, but it also may lead you to try to draw conclusions where there's not enough information to draw conclusions from. So this is a very basic type of feedback. When you and the others that you're working with, whoever they are, looks at something that was done and they provide some kind of information about it, some kind of judgment about it. Typically, this kind of retrospective feedback is what I would categorize as execution feedback. Think about execution feedback as feedback on the what. Imagine taking a snapshot of reality before and after the work was done or perhaps before and during the work was done. The idea here is you're not a human that is participating in the work, but instead you're looking at the results of that work and you're trying to decide are the results good, bad or maybe it's more complicated than that. Maybe we don't know yet, right? This is execution feedback. There's another kind of feedback though and successful software engineers, especially the very successful software engineers, focus perhaps as much or more on this type of feedback. That is emotional feedback. What do my actions make others around me feel? Both emotional and execution feedback can be delivered in formal or informal ways. Formal ways are structures that elicit that feedback. Think about the kind of meetings that you may have with a manager and the surveys that you send to users. All feedback is constantly being provided to us. That feedback once again can come from a machine. This is more execution feedback. It can also come from daily interactions with our co-workers and watching users use the product. It doesn't have to be labeled feedback for a successful software engineer to gain value from it. Just that feedback is as simple as someone saying thank you, but sometimes the feedback is much more complicated. For example, you may have some intuitive sense that there is conflict brewing between your teammates. This kind of feedback, this unspoken feedback, unstructured feedback, is often where we get things wrong. In a previous episode, we talked about communication. We talked about the models of communication. One of the important aspects of any kind of communication is the idea of noise. Noise can distort the feedback that we receive. When we have unstructured feedback systems, for example, when we're trying to judge each other's emotional states based on behavior. This is a very noisy environment to gather feedback from. So successful software engineers recognize when the feedback they're receiving is noisy. This is true both for the emotional feedback and the execution feedback. Sometimes we don't have all of the information we need to solve some kind of problem. Maybe there's a bug in our software. We don't have everything that we need, so the report of the bug may have a lot of noise along with it. Ultimately successful software engineers develop the habit of seeking feedback and then responding to it. Not only do we take feedback, but we decide what to do about that feedback. The more systematic you can make this, the more likely you are to make it. To embed those new behaviors into your daily habits. If you can say, I will stop doing X and start doing Y. This is a commitment that you make. When you receive some kind of feedback, you can make this commitment either to yourself or to the person who's providing that feedback to you. This constant refinement of your habits is what will make you more likely to succeed as a developer. Thank you so much for listening to today's episode. Thank you again to Linode for sponsoring today's episode. You can get $20 worth of credit to go and get started with your Linode projects, whatever they are. You can build pretty much anything on Linode. Thanks again for listening to today's episode. If you've enjoyed the episode and you don't want to miss out on future episodes like this one, including more in this series, the habits of successful software engineers, encourage you to subscribe and whatever podcasting app you are currently using. Thank you so much for listening. And until next time, enjoy your tea.