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 in 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 this hopefully will help you with some of those algorithm problems but that's not the 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 problem 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 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 an 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's the kind of thing that you can do that switch happens whether you have an odd number of characters you would have one 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 you know trying to count up all you try to count up all the letters in a short palindrome and recognize you know the number of characters that you have you know 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 it's the you know you could perceive it as the same the same forward as it is backwards there may be more kind of meta rules that can build off of that character and you can use them to make a better code for your code so if you're looking at a palindrome that's a little bit more futuristic we're going to take a quick sponsor break then 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 developer t is grateful for the support of compiler compiler is a great way to get started so if you're looking at a palindrome that's a good way to get started so if you're looking at a palindrome that's a good way to get started so if you're looking at a palindrome that's a good 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 while you do it i had a chance to talk about exactly that with brent and angela i asked them what one of their most enjoyable moments was when recording this season i think my one of my favorite episodes and one of my favorite moments is we have this episode all about like superstitions like tech superstitions and like trying to figure out what they are and if they actually work and then how they kind of like operate in our lives of course we went to the people who encounter superstitions probably the most which is like people who work in tech support so they actually end up becoming you know our experts and the people we interview and they tell all of these stories about this the kind of like strange things that they themselves do they have some doozies or they see other people do in order to try to get their machines to work just like holding at particular angles in the sun and you gotta hit the side of it three times right this you know not four or two that won't work i just like i was just dying that entire episode like it is just so deeply deeply deeply funny to me you thanks so much to compiler for their support of developer t 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 we'll talk about the importance of that in just a second but the reliable features reliable descriptors uh... the rules that bound a particular object in this case we're using the word object pretty loosely 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 an object in your code instead we can think about object asension evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution 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 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 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 humans. 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, 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, you know, those features as kind of a stable part of their identity, that's a little bit of a 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. And it's not a stable characteristic of a person. It's not a stable characteristic of a person. It's not a stable characteristic of a person. It's not a stable characteristic of a person. And so, we are trying to use these features 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, we talk about people, 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 heuristic. 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 startup. 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 this sink 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. In a large company, one of the features is that you very likely are going to be able to do a lot of things that you are not going to be able to do. You're going to perform a more specific job than you might in a smaller company. Especially in a startup, 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 way to show that you're not going to be able to change your skill set. So, let's start with the first one. 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 optimizing for? Why are you optimizing for? Why are you choosing in this particular scenario to optimize for that thing? And 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, you might want to be in a more proactive mode. So, if you're in a more proactive 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 a longer-term decision. You should be taking into account the features of that team, the characteristics of those people. This is going to help you make a longer-term decision. You should be taking into account the features of that team, the characteristics of those people. This is going to help you 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 my whole goal here, the way I measure success, is whether somebody's mind has changed even just a little bit. Whether it's open, whether it's not, whether it's not, whether it's not, 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 T discord and let me know. You can join a developer T.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.