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. 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 Cutrell 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 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. But sometimes we get noisy signals from our environment. Today's episode is in today's habits, very closely related to this idea of noise and 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 kind of fundamental elements of communication. But in today's episode, 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 coworkers and with our stakeholders and customers. So let's talk about these boundaries a little bit more thoroughly. Clarity, writing something 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 non-verbal signals 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. And much of the time our coworkers 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. We were 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 really entails adding important details to your message. As an exercise, we're going to provide a handful of examples of someone asking to 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 seconds, 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. 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 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 clearer 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 a 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 learning developers get an account on Linode or some Linux environment that is remote. This was some of the most important learning that I did was on my own Linux server. So I encourage you as a developer, if you don't have access to one and you're in the learning environment to go ahead and get one of these. Linode is providing you $20 worth of credit in the enterprise for a Linode server is only $5 a month. You get four months basically for free. Go and check it out. Head over to Linode.com, slash Developer Tea. That's Linode.com, slash Developer Tea, all one word, and use the code Developer Tea2019 at checkout. Again, that's Developer Tea. 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 Tea. 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 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 the context is really critical. It's kind of inescapable as a decision making metric. Successful developers. And when I say successful during this series, I don't mean that they succeeded once or that they have a job. I mean, serially successful developers, developers 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 Teato get started today with $20 worth of free credit. Use that code Developer Tea 2019. It's Developer Tea2019. 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.