Most of the time when we're writing code, we think about what the code is meant to do for us, we think of it as an offensive response to what we're solving, but what if we think of our code as a defensive strategy?
In code we are trying to construct, but we often leave out the consumers, machines and co-workers who are using the code we're writing.
How can we think in terms of human realities in our code?
Whether you’re working on a personal project or managing your enterprise’s infrastructure, Linode has the pricing, support, and scale you need to take your project to the next level. Get started on Linode today with a special $20 credit for listeners of Developer Tea.
Visit: linode.com/developertea and use promo code developertea2020
P.s. They're also hiring! Visit https://www.linode.com/careers to see what careers are available to you.
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.
Most of the time when we are writing code, we think about what the code has to go out and do for us. We think about it as an offensive attack against our problems. But what if we were to think about it from the other direction, from the position of defense? That's what we're talking about in today's episode. My name is Jonathan Cottrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. If you think about the way that we tend to write code or the intuitive way that we think about software engineering to begin with, it starts with something new. We build a new class and we add methods and we try to construct something that changes the environment. It changes. It changes the problem. It goes and accomplishes something. But what we often tend to forget is the environment that the code is living in. That environment is built up of many different things. It may be users, actual people or computers that consume the product or maybe even the service. Maybe you're upstream from other digital products, other APIs, for example, that use your code. But the environment. It includes a lot of other things as well. Beyond just the clients that might use our code, we can imagine the machine that is running our code. And we can jump up a level to the kind of situation in the world, the current events that are happening around the people who are using our products and our services. We can think in terms of physical realities. We can think in terms of conceptual realities. But we can also think in terms of the way that we think. But we very often forget that these things exist when we're writing our code to begin with. When we're writing our code to begin with, we imagine that the features that we're building are in a vacuum in a way. That we can define some kind of contract between us and the user that they will use it in a particular way. And that because we are creating the software to be used in that way, that it will be used in that way. Of course, on the realistic side, once we release our software, we find that those contracts tend to be broken. And the context that we imagined that our code would exist in tends to be much more complex than we ever planned for. So I want to help you shift your thinking about feature planning or about feature development, about software development in general. Shift it to think about both. The offensive moves. And the defensive moves that you can make as an engineer. In the same way that in any sport or game, if you solely focus on being aggressively offensive, in other words, if you are making all of the attacks, then you're not prepared for someone who makes a counter attack. You're not prepared for a situation that disables your offensive attacks. On the flip side, if you're only playing a defense. Then. You're not really ready to take advantage of opportunities when you see them arise. So we need both. We need offensive and defensive strategies and we need them to be integrated so that we can seamlessly switch between the two. So let's talk about our offensive strategy. In the beginning of almost any software development process, the offensive strategy is one of learning. You can imagine that your feature development is like a tracer. The concept of a tracer as it relates to software engineering refers to the practice of trying something very specific, maybe even very deep, but not expecting that initial shot to be everything that you need it to be. It more lights up the pathways around that particular concept. And most importantly, it provides grounds for learning for future iterations. In fact. In tracer work. You may end up throwing away everything that you're doing. This is entirely an offensive move. And it's intended to provide you a next step kind of hint, a way of moving forward. A critical characteristic of tracers is that they are intentionally small. They don't, they don't require a lot of planning. They don't require a lot of work to implement relative to what they would represent in the full scenario. So this is your first offensive move. And as you move forward, you adjust your strategy into response scenario. You start with that tracer to kind of learn the environment, the kind of context that your code will be running in. And then you respond to that. This is our iterative development. We respond to our environment and we slowly change things as we learn new information. That response is fundamentally what we're talking about. What we're talking about. When we say defensive strategy. That's what we're going to talk about right after we talk about today's sponsor, Linode. No matter what your strategy is, when you develop software, one of the most important things you can do is find things that are always safe bets. Linode is always a safe bet. That's because Linode starts at just $5 a month. And it's a very basic concept, the idea of Linux and the cloud, but Linode goes beyond that. In additional services that they provide. And you can go to linode.com. And you can go to linode.com. At the end of the day, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you may haveension, you just for you. There's no CPU steal. We're talking about context and environment in this episode, and Linode is providing you different types of environments that are specific to your use case. Whether you're a brand new developer starting out, which Linode provides you the Nanode plan, it starts at $5 a month. Or if you have a whole team that you need to support, you can use their cloud manager, for example, cloud.linode.com, or you can automate everything with their version 4 API or their Python CLI. Go and check it out. If you're a new customer, you can get $20 worth of credit towards your next project. Head over to linode.com slash developer T and use the promo code developer T 2020, all one word, developer T 2020 at checkout. That's linode.com slash developer T. Thanks to Linode for sponsoring today's episode of developer T. So when we are in response mode, what this means is that we are open to the world. We're open to the world. We're open to the world. We're open to the world. We're open to the environment and what it is telling us. The environment may not be trying to communicate to us. Let's be very clear. We are observing the environment. We're observing what's happening when we write code and release it. Perhaps, for example, the contracts that we hoped that our different clients, whether they're humans or computers, would follow, maybe they don't follow them. This is incredibly common and we need to be paying attention to the ways that they're not following those contracts. But here's the reality. If you want to become a better engineer, when you're thinking about your offensive strategy, it makes sense to think a few steps ahead. Specifically, designing your offensive strategy by integrating it with your defensive strategy. Think, if we release this feature in this particular way, what will happen next? What are the chain of events that could occur three steps down the line? How could this go horribly wrong? Or how could this go in a way that's different than I planned it? A great offensive strategy, when it comes to engineering, doesn't undermine your defensive strategy. And a great defensive strategy doesn't just try to recover from a reckless offensive strategy. They work together in tandem. The categorization of defensive and offensive should be thought more of as, a codependent relationship rather than distinct modes of operation. Thank you so much for listening to today's episode of DeveloperTea. Another thank you to Linode for sponsoring today's episode. Head over to linode.com slash developertea. Use the promo code developertea2020 at checkout. That's developertea2020 at checkout for that $20 worth of credit as a new customer of Linode. If you enjoyed this episode of DeveloperTea, I encourage you to subscribe and whatever podcast you're listening to, I encourage you to check out the podcasting app you currently are using to listen to this episode. We have a huge back catalog of episodes. And of course, we're putting out two new episodes now. We just went down from three episodes to two episodes. We put out two episodes every week of this show. So it's easy to forget about the show and then feel like you have to catch up. Two pieces of advice. If you subscribe, then you can choose as shows are coming out, which ones you want to listen to. And secondly, just a piece of advice. If you are joining us this late, there's no reason that you have to go back and listen to the whole back catalog. This show is designed for you to pick the episodes that are most relevant to you. Thanks again for listening to this episode of DeveloperTea, which can be found on spec.fm, along with every other episode of the show. And of course, other incredible podcasts like Design Details, React Podcast, Tools Day, and more. Go and check it out. Head over to spec.fm to find more incredible content. Specifically for you. Of course, a huge thank you to today's producer, Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.