What do you do as a developer? This may sound like kind of a dense question, something that may have some obvious answers and some not so obvious answers. You may hear some quippy versions of this on social media, like my job as a developer is to make people happy, or my job as a developer is to guess until I'm right. But none of these fully capture the wide gamut of things that we do as developers. And as it turns out, coding is typically only part of our jobs. And in fact, much of the time, coding is the output of the rest, the bulk of what we do. So that's what we're talking about in today's episode. This is a continuation of our Habits of a Successful Software Engineer series. And today we're going to share two different habits. My name is Jonathan Cottrell, and you're listening to Developer Tea. This show exists to help driven developers find clarity, perspective, and purpose in their careers. In our last episode, discussing Habits of Successful Software Engineers, we talked about the fact that successful software engineers are not only the ones who are the most successful, but they're also the ones who are the most successful. And so today we're going to talk about how successful software engineers seek feedback as a habit. Not just any feedback, not just specific feedback, but also they're looking for feedback that is unstructured. They're ready to receive those messages wherever they're coming from. But they also understand that not all feedback is perfectly clean. Sometimes we get noisy signals from our environment. Today's episode is, and today's habits, are very closely related to this idea of noise in communication. And so much of what we do as developers centers around communication on its own. So I encourage you to go back and listen to the episodes we did recently on communication, the communication models, the theory of communication. We talk about all of those fundamental elements of communication. But in today's episode, I'm going to talk about how successful software engineers seek feedback as a habit. And I want to share these basic habits with you. So the first habit that I want to share today is seeking to write with clarity and brevity. Seeking to write with clarity and brevity. In some ways, the boundaries of clarity and brevity give us a sense that we need to pack our words with meaning. We need to choose them carefully. To meticulously craft messages that we're sending to other people. Now, in some cases, this is more important than others. But successful software engineers know that all communication is important to some degree, especially communication with our co-workers and with our stakeholders and customers. So let's talk about these boundaries a little bit more thoroughly. With clarity. Now notice that we're talking about writing because writing is a fundamental skill for developers. This is true in almost every knowledge working area. Many of us can communicate with other people in informal settings to a degree where we understand each other. Most of the time, in-person communication naturally has a higher bandwidth. We're able to see and communicate more with our nonverbal signals. And that's a great part of the process. So let's talk about how we can and our tone and inflection, even our gestures with our hands. These are things that you can't really get from just writing. Now, if you know someone very well, then often you can kind of visualize them talking, and you get a sense, an intuitive sense, for their tone once you've read enough of their writing. But much of the time, our co-workers haven't spent enough time with us to get that intuition. So we need to learn how to write clearly, because much of our work, it exists in a written form. And a lot of the work that we do is not just for today, but it's also for three months from now. Or maybe it's for whenever we are no longer working on that project. Maybe we're at a different company, or we've moved to a different place in some way or another. We may be out for the day. So the written, kind of recorded work that we do, it's incredibly important for successful software engineers to develop this habit of constantly seeking clarity and brevity. So clarity in our writing. What does this mean? It means that we are communicating to a specific audience with a clear message that both identifies what we mean as well as what we don't mean. Often this... This really entails adding important details to your message. As an exercise, I'm going to provide a handful of examples of someone asking another person to bring them the cup that they want. And you'll see that there are varying degrees of clarity and brevity in these requests. As a side note, this probably wins the award for the most bizarre 30 seconds in a podcast that you're going to listen to today. And certainly the most 30 second... The most bizarre 30 seconds in the history of developer tea. But nevertheless, let's go ahead and get started. Please bring me the cup. Please bring me the cup from the kitchen. Please bring me the blue cup from the kitchen. Please bring me the blue cup from the left counter in the kitchen. Please bring me the cup from the left counter in the kitchen. Now, these are obviously contrived examples, but how do you know which of these is the most clear while also being the most brief? Of course, brevity on its own isn't enough. And clarity on its own may result in too much detail, an impractical amount of detail. And in these examples, as it turns out, there's no way for you to know what the appropriate level of clarity is. of clarity versus brevity is because you don't know, for example, is there another cup in the kitchen? By adding all of the qualifying terms based on what this person wants, which is for the person to bring them the cup, if you add a bunch of unnecessary qualifiers, you may be being very clear, right? You may be providing a lot of clarity, but you're not necessarily providing brevity. It's not necessary for you to explain where the cup is or what color it is if it's the only cup. Again, these are contrived examples, but imagine how much of this kind of thinking you can do as a developer working with code, working with ambiguous subjects. This is something that is very important because clarity is incredibly important. Without clarity, you may waste a bunch of time building things that you ultimately shouldn't build or working under miscommunications, right? Working in a state where things are not really certain. So it's important to focus on clarity. And then as you begin to build messages with clarity, you can also learn how to make those clear messages brief. So the first habit of successful software engineers for today's episode is that they always seek clarity and brevity in their writing. We're going to talk about the second habit right after we discuss today's sponsor, Linode. 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 the location of the node. Linode is also offering dedicated CPU instances. These are designed for consistent, high-performance computing needs like video encoding, game servers, or even busy application servers. As a new customer of Linode, you will get $20 worth of credit to use on any of their services. You can build pretty much anything on Linode. You can have distributed applications, hosted services, websites, even your own continuous integration and delivery environments. I highly recommend that youijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij basically for free. Go and check it out. Head over to linode.com slash developer T. That's linode.com slash developer T, all one word, and use the code developer T 2019 at checkout. Again, that's developer T 2019. That's the code you'll use at checkout to get that $20 worth of credit. Thank you again to Linode for sponsoring today's episode of developer T. The second habit that I want to discuss of successful software engineers is the incessant question of context. What is my current context? And this isn't a simple question. Really what you're asking is the work that I'm doing right now or the rest that I have right now. Why does it matter? Why am I doing what I'm doing right now? Why am I doing what I'm doing right now? This second. And beyond that, being able to look at that context from an objective perspective and determine what should change or not change about whatever's happening. So this is very similar to the ability to write clearly, right? Understanding the context of the message is critical to being able to write clearly with clarity and brevity. Understanding the context of a given feature. Or of a proposed testing solution or of a new technology. These are all things where context is really critical. It's kind of inescapable as a decision making metric. Successful developers. And when I say successful during the series, I don't mean that they succeeded once or that they have a job. I mean, serially successful developers, developers who, who have either a long career behind them or a long career in front of them. These serially successful software engineers. Sorry for the excessive alliteration. They have these things in common. And context. Constantly seeking context is one of those habits. And this habit is kind of a foundational habit. It's not something that you add on later. It's something that you create from the very beginning, constantly asking, what is the context? Understanding context is how you generate the right kinds of decisions. If you rely on a static way of making decisions, eventually you find the edges of that. And very often this happens faster than we expect. If you only rely on best practices, that's going to fail you at some point. context is critical for pretty much every human process that we have. Working, communicating with each other, resting. We have to understand our context. Thank you so much for listening to today's episode of Developer Tea. I hope that this was a challenging episode. And I hope that you walk away feeling empowered to start developing these habits for yourself. Thank you again to Linode for sponsoring today's episode. Head over to linode.com slash developer tea to get started today with $20 worth of free credit. Use that code developer tea 2019. It's developer tea 2019. If you're enjoying this episode and you don't want to miss out on future episodes, then I encourage you to subscribe in whatever podcasting app you currently use. Thanks so much for listening. And until next time, enjoy your tea. Bye.