In today's episode, we're talking about the habits of successful engineers.
There's more to being a developer and person than constantly seeking a single purpose. In today's episode of Developer Tea, we're talking consistent action that improves our goals and systems that we use on a day-to-day basis and challenges our thinking.
Instantly deploy and manage an SSD server in the Linode Cloud. Get a server running in seconds with your choice of Linux distro, resources, and node location. Developer Tea listeners can get a $20 credit and try it out for free when you visit: linode.com/developertea and use promo code: developertea2019
P.s. They're also hiring! Visit https://www.linode.com/careers to see what careers are available to you.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
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.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
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 amassing 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 Tea talking about the habits of successful software engineers. And this isn't going to be only one kind of engineer. This isn't just for back-end 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 Cottrell. 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 improve. We want to empower developers 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. Sometimes that is too reductive. It doesn't give us a chance. It doesn't give us the ability 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 developers 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, that 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 ride on that for the remainder of your career. Wouldn't really be rewarding for you either. So what we're talking, 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, our 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. And then the virtual cultures that we're a 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, I 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, 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, 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 topic. 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 a number of features. Native SSD storage, a 40 gigabit internal network and industry leading processors. You 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 T and use the code developer T 2019. That's the number developer T 2 0 1 9 at checkout. Linode.com slash developer T. Linode.com slash developer T. Thanks again to Linode for sponsoring today's episode. 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 a little bit of a pain in the ass. 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, you're 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. And 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. Informal 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 coworkers, and watching users use the product. It doesn't have to be labeled feedback for a successful software engineer to gain value from it. Sometimes that feedback is as simple as, someone's email, someone saying, thank you. But sometimes the feedback is much more complicated. For example, you may have some intuitive sense, that there's conflict brewing between your teammates. And 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, and one of the important aspects of any kind of communication, is the idea of noise. Noise can distort the feedback that we receive. And so 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. And so successful software engineers recognize, when, the feedback they're receiving is noisy. And this is true, both for the emotional feedback, and the execution feedback. Sometimes, we don't have all of the information we need to, for example, solve some kind of problem. Maybe there's a bug in our software, and we don't have everything that we need. And 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 embed those new behaviors, into your daily habits. If you can say, I will stop doing X, and start doing Y. And then, you can say, I will stop 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 to, and get started, with your Linode projects. Whatever they are, you can build pretty much anything on Linode. Head over to linode.com, slash developer T. Use the code developer T, 2019. That's developer T, 2019, at checkout. 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, I 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.