I was working on a little bit of a toy problem recently and it reminded me of what I learned about algorithms a long time ago. And it's a concept that I want to try to generalize so that you can apply it in your job and your life beyond your coding problems. It will certainly apply to your algorithmic problem solving, especially for those of you who are kind of looking to apply to a job. This hopefully will help you with some of those algorithm problems. But that's not the primary intent, the primary goal of this discussion. Instead, it's to give you kind of a core principle of problem solving. And this basic idea is to focus on the characteristics, focus on the properties of whatever you're working with. So I'll give you a very basic overview of a problem that shows this very clearly. Imagine that you have a string of letters and the problem asks you to determine, rearranged in such a way that they become a palindrome. And if you're not familiar with the palindrome, an example is taco cat or race car, letters that can be reversed and they spell the same thing. Now, it's not a requirement that this is actually a word, just that the letters can be reversed and they spell the same thing. A common kind of brute force way to do this is to iterate all possible combinations of these letters and then check to see if it's a palindrome. You can check to see if something is a palindrome fairly easily by splitting it in half and then reversing one half and seeing if it's equal to the other. If it's an odd number of characters, you can do away with whatever the last character is in the first string, basically the middle character you can toss it away. And of course, rearranging these letters is not very fast. If you were to do this for every combination, we don't have to talk about how complex it is, but it's much more complex than you need. As it turns out, if you focus on the features, and if you focus on the characteristics of what you're working with, this can be solved much more easily. Specifically, if you were to look at every letter, count the occurrences of every letter in a palindrome. All palindromes have either zero or one letter that can occur in odd number of times. In other words, all of the letter occurrences can be counted up and the counts of each letter will all be even except for either zero or one. And that switch happens whether you have an odd number of characters, you would have one character who shows up an odd number of times, or an even number of characters, in which case all characters show up an even number of times. Hopefully this makes sense to you. And if it doesn't make sense, you can imagine trying to count up all the letters in a short palindrome and recognize how many are you counting up, specifically if you have a palindrome that's an even number of letters long or an odd number of letters long. And this is reminding me why we don't talk about code very often on this podcast. It's a little bit hard to convey. But the basic idea here is that you can do a much simpler operation by relying, right? This is the critical component, relying on the feature of palindromes that makes this true, right? You're relying on the fact that palindromes, there's this kind of rule that bounds them and you can use the rule to take a shortcut. So as you encounter this in a coding problem, you might see the word palindrome, you should ask yourself the question, what do I know about palindromes? What are the rules of a palindrome? And these rules may be imposed by a formal definition, or they may be given directly explicitly to you, right? But as you start to encounter these things, don't just think about the way that you perceive a palindrome. For example, you could perceive it as the same forward as it is backwards. There may be more kind of meta rules that can build off of that characteristic. We're going to take a quick sponsor break. And we're going to come back and talk about how this feature-based kind of exploitation, feature exploitation can be used in your life and in your work beyond just coding. The Velpete is grateful for the support of Compiler. We are, while there's a brand new podcast answering, the hardest, most complicated questions about the tech industry. And one of the most important things about a good podcast is that you have fun. Well, you do it. Had a chance to talk about exactly that with Brent and Angel. I asked them, one of their most enjoyable moments was when recording this season. I think one of my favorite episodes, and one of my favorite moments is we have this episode all about superstitions, tech superstitions, and trying to figure out what they are and if they actually work and then how they operate in our lives. Of course, we went to the people who encounter superstitions, probably the most, which is people who work in tech support. So they actually end up becoming experts in the people we interview. They tell all of these stories about the kind of like strange things that they themselves do. They have some busy other people do in order to try to get their machines to work. Just like I was particular angles in the sun. And you got to hit the side of it three times. Right. This, you know, not four or two. That will work. I just like, I was just dying that entire episode like it is just so deeply, deeply, deeply funny to me. Thanks so much to compiler for their support of Developer Tea. You can find compiler wherever you find podcasts. We're talking today about a concept called feature exploitation. The idea here is to think about the boundaries, the constraints, the features, particularly the ones that are reliable. I'll talk about the importance of that in just a second, but the reliable features, reliable descriptors, the rules that bound a particular object. In this case, we're using the word object pretty loosely. And we're also using the term exploitation. So I want to give some boundaries here as to what we're talking about. Object in this case is not necessarily related to a physical object, nor is it related to, you know, object in your code. Instead, we can think about object as more in the kind of grammatical sense. Right. Something that we are doing about in this previous case, the object was actually anagrams. Right. Anagrams is more of a concept, but anagrams all share some common traits. Right. So you could also consider this kind of a classification of sorts. And so what of that classification is where you can find some reliable, reliable traits between different objects. Those are the things that can be exploited. Now, just to put some boundaries on the term exploited here, we're not using it in the, in a negative sense, in the sense of just getting the thing that you want without thinking about the consequences, right. Instead, we're talking about using those particular features or traits to solve problems. And we're exploiting those, meaning we're using them as a way to solve the problem that we would have solved already. Right. It's not, it's not abusing in this particular language that we're using. And hopefully you can see how this applies. The important distinction that I want to make as we move forward is that we should be very careful in trying to apply this to human beings. Specifically, humans have traits that change over time. And when we try to use human traits or features as a reliable kind of point for exploitation, things can go very poorly. And especially if we are assuming those features. Now, if we are using the features of a given person that they have told us that they have kind of bought into those features as kind of a stable part of their identity, that's a little bit of different story. This is a critical skill that managers develop, for example, to be able to use features of personalities that have been kind of discussed in an open scenario. But it's very critical to understand that people change. And much about a person is not stable. It's not a stable characteristic in the same way that it would be about, let's say, palindromes. Remember, we are kind of using these features as heuristics, especially when they are less than 100% reliable, meaning anything less than totally certain, right? With palindromes, we are totally certain about that kind of formal description that all palindromes have those characteristics. But when we talk about people, or maybe we talk about companies in just a moment, those characteristics are models at best. In other words, they are not always going to hold perfectly true in all scenarios. But it still provides a useful shortcut, a useful heuristics. So let's say, for example, that you are applying to different jobs. One job is at a large company, one job is at a start-up. Using the features, the classifications that you know about these two kinds of companies, you may change the way you present your value to that company. Right? Let the sync in for a second. We're not talking about changing your skill set altogether, but instead focusing on different areas that might be more valuable to a large company versus a small company. And a large company, one of the features is that you very likely are going to perform a more specific job than you might in a smaller company, especially in a start-up. You're more likely to wear a lot of hats. It's possible that your responsibilities will change. And so you may want to highlight parts of your resume that show how you took on a variety of responsibilities rather than highlighting hyper-specific or deep knowledge that you have about a given area. In many ways, this is a good kind of complement model of thinking to a great question that I learned from Lara Hogan, and I think she probably learned it from Paloma Medina. And the question is, what are you optimizing for? Right? That's the question, what are you optimizing for? You might choose two or three things or one thing ideally that you're optimizing for, but the other part of that question is why? Why are you choosing in this particular scenario to optimize for that thing? There could be many answers. One of those answers could be this feature exploitation. I'm choosing to optimize my interviews to show my flexibility, right? Tracking with me here. I'm choosing to optimize my presentation to this potential company that I want to work at to highlight my flexibility because I believe that the features of this company will require me to be flexible. In other words, the people who are hiring me are looking for flexibility. So this is a kind of a long-winded way of justifying something that might come intuitively to you. But there are a lot of other things that you could focus on that are features that might help drive your decisions. Instead of always being in reactive mode, let's say you are a manager and you have individuals on your team and you've gotten to know them. They have some relatively stable characteristics, personality traits, etc. Instead of just relying on asking them, hey, how is your week going and just taking that input and output and trying to respond to it, you should be taking into account the features of that team, the characteristics of those people. This is going to help you make longer-term decisions, create more context in your mind about what you're hearing in the moment and ultimately as a manager, serve the people that report to you better. Thanks so much for listening to today's episode of Developer Tea about feature exploitation. Hopefully this all is clicking with you and hopefully my whole goal here, the way I measure success, is whether somebody's mind has changed even just a little bit. Whether it's opened up a new way of thinking for you or maybe you've decided to think differently about something that you already had a preconceived notion about, I'd love to hear those stories. Please join the developer to Discord and let me know. You can join at developertea.com slash discord today for free and always for free. We're never going to monetize that community at all. It's just there for you to connect with other people who like listening to this kind of content and with me. Thanks so much for listening. Thank you again to today's sponsor compiler. You can find the first season of compiler wherever you get podcasts. Thanks so much for listening again and until next time, enjoy your tea.