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 Cutrell 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 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 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 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 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 counterattack. 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 needed 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 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 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 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 Linode and the cloud. Linode goes beyond that in additional services that they provide now, like GPU compute plans that are suitable for AI or machine learning or video processing, or dedicated CPU plans with physical cores that reserved 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 Nanoed plan that 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 for 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 Tea, and use the promo code. Developer Tea2020 all in word Developer Tea 2020 add checkout that's linode.com slash Developer Tea. Thanks to Linode for sponsoring today's episode of Developer Tea. So when we are in response mode, what this means is that we are 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 Developer Teaanother thank you to Linode for sponsoring today's episode head over to linode.com slash Developer Teause the promo code Developer Tea2020. Check out that's Developer Tea 2020 check out for that $20 worth of credit as a new customer of linode. If you enjoyed this episode of Developer TeaI encourage you to subscribe and whatever 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 Developer Teawhich can be found on spec.fm along with every other episode of this show and of course other incredible podcast like design details react podcast tools day and more. Go and check it out head over to spec.fm to find more incredible content made specifically for you. Of course a huge thank you to today's producer Sarah Jackson my name is Jonathan Cutrell and until next time enjoy your tea.