Earlier in my career and at the beginning of most people's careers, we learn about best practices. These are things that we will almost defend religiously, although often we're not entirely sure why we're defending these things. The idea is there's a bunch of heuristics that people who are smarter than us have learned over time, and if we apply them on the average, we'll have better outcomes. And this is actually not a bad model to work from. In fact, a lot of the time, if you apply best practices, even if you don't know necessarily what the outcome is, by way of it being a best practice that is practiced by many other people, you're likely to get a better outcome than if you were to go kind of randomly decide what to do. But you'll notice something as you go through your career. More and more often, you will have to make trade-offs, hard decisions. You'll have to do something that maybe feels wrong. And the reason it feels wrong is not an ethical concern or a moral obligation, but rather it feels like you're breaking the rule. The rule of the best. The best practice that you learned at the beginning of your career. Many of you have probably had this experience. You raise a concern about work that you're getting ready to engage on. And the basis of your concern is, well, this is not a good practice. Your manager or a tech lead may tell you that we understand, but we're going to do it anyway. This can feel hard. In today's episode, I want to give you a way of thinking about this kind of work so that it doesn't hurt so bad. So that you can understand its place in your overall career. This analogy comes from golf, a sport that I personally don't play. But I can understand the analogy and you probably can too. The analogy is very simple. It is the short game and the long game. The short game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. The long game. Even though it may have long-term impacts, Making the decision might be a short-term impact on you. You'll likely learn how to use the other framework. It may become very clearly obvious that the other framework would have worked better, or maybe you were wrong. The key lesson here is that sometimes we make compromises in the work that we do, not because we don't have a value system, but because evolution brings evolution, we also expect others to make compromises in the work that they do. And this is a core tenet of collaboration. We play the short game so that we can collaborate for the long game. Now, none of this really has much to do with the actual timetable here. Really, this is just about calibrating where you are willing to make concessions with other people. Now, the model does extend beyond collaboration as well, and we can talk about that a little bit. But this is the most important lesson for this episode, and that is when you play the short game, what you're likely doing is building social capital. You're buying yourself the opportunity to continue collaborating with a group of people. Now, it may be that you say, you know what, I actually am not going to play the short game. I'm going to, you know, leave the group. I'm going to, you know, leave the group. I'm going to, you know, the company or I'm going to change my relationship with this group of people. And that's an option as well. But typically people do want to find a way to collaborate and they want to find a way to get most of what they want in the relationship. This usually can work. This is a misconception that we're always going to be compromising on major things, each side compromising and neither side being happy. But as it turns out, most compromises happen in the highest effect when one side compromises something that they don't really care very much about. Remember, that's the short game. And the other side compromises something that they also don't care very much about. But the opposing side cares about the thing that's being given to them. In our previous example of the choice, but maybe it's not actually that important to you. If you were to go with the second option, the option that the opposing side is suggesting that you go with, maybe it's hugely valuable to them for some reason. Maybe it's a skill set that they already have, or it's easy to hire for, for whatever reason, it's more valuable to them than it is harmful to you. They care more about it than you do. This is a long game for them and a short game for you. As a way of kind of explaining this same model a little bit further, another kind of analogous model here is the concept of a price of admission. Even though you do have to give something up, it is worth that price in order to gain something else. This is analogous to the long game versus the short game. We're going to take a quick sponsor break and then I'm going to come back and talk about what happens when you accidentally misapplied this model. Developer Tea is brought to you by Split, the feature management and experimentation platform. What if your release was exactly how it sounds? Finally, a moment of relief and escape from those slow and painful deployments that hold back product engineers. They just sit there and stare at the progress bar that seems to never move. You can free your teams and your features with Split. By attaching insightful data to feature flags, Split helps you quickly deploy. Measure and learn the impact of every feature you release, which means you can turn up what works, turn off what doesn't, and give software innovation the room to run wild. Now, you can safely deliver features up to 50 times faster and exhale. Split feature management and experimentation. What a release. Reimagine software delivery and start your free trial and create your first feature flag at split.io slash developer tea. That's split.io slash developer tea. Thanks again to Split for sponsoring today's episode of Developer Tea. The long game and the short game. This model can easily be misapplied. For example, it is possible to accidentally label something the short game when in fact it's the long game. An example of this is the short game. It's the long game. It's the short game. It's the long game. It's the long game. Making concessions in places where it really does matter to you. Good examples of this happen on teams that choose, hastily choose a tool that locks them in. Maybe they have some kind of vendor lock in. It becomes very expensive and it's extremely difficult to get out of that tool. Even though the short game here seems like it was a win, they were able to easily solve a problem by just you know, buying something. The long game ended up being compromised. In fact, this was a long game decision because they have a lot of downstream consequences from that decision. It's something that everybody on that engineering team probably would have said that they cared about quite a lot. And this happens often with things that we think in the moment are short game decisions. So this is very important to be careful about. There's two ways that the decision is made. One, we accidentally misapply the label of short game. We imagine that this decision is small, it's easily reversible, and it turns out not to be. Or two, we make enough of the short game decisions that we never actually get to the long game. A variant of that second version is that we make enough short game decisions that we kind of train people around us that we are willing to make short game decisions. So we lose the opportunity to push for the long game. As loaded as I believe the term is, it's probably useful in this example, the idea of technical debt. A good manager will have some way of recognizing when their team has built in a unsustainable manner. That is, they've taken on things that most people would call a heavy amount of technical debt. But by doing so, they have signaled to the organization, whatever the decision-making process is, in the product organization or whatever project management they're using, they've signaled to those decision-makers that technical debt is okay, or these kinds of decisions, this kind of work, is what this team is willing to take on. And so to beat the metaphor down a little bit into the ground, in order to effectively play the long game, you have to practice it as often as you can. Practice the short game. In other words, it's important that you actually do make decisions that lean towards the long game. In that previous example, that might mean choosing to prioritize some work that people would call a debt pay down. The important thing to recognize here is that as we mature in our careers, we begin to understand that we probably are not going to be able to play the long game on every decision that we make. There's going to be compromise. There's going to be situations where that game just simply doesn't work. But that being said, we should also be incredibly careful of that becoming an excuse for always flipping and playing only the short game. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Split. Head over to split.io slash developer tea, split.io slash developer tea. You can get started with a free account, and create your first free feature flag today. Thanks again for listening to this episode. If you enjoyed this discussion, and you'd like to add more to the discussion, you can talk with other driven software engineers and non engineers for that matter in the developer tea discord community. Head over to developer tea.com slash discord to join for free today. Thanks so much for listening. And until next time, enjoy your tea.