We all love our tools. We love the technologies that we build our applications on. We love our management tools, our paradigms, our frameworks. In fact, sometimes we can become myopic about our tooling. This happens usually accidentally. We begin to use our tools to solve every problem that we have. My name is Jonathan Cutrell, 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. And today, I want to ask you a simple question with a difficult answer. What are your tools not made to do? In fact, I'll ask it another way. What are your tools really bad at doing? What are the tools that you have that you are using day in and day out? The different management frameworks that you are using, the project flow, that style. What is it not good at? Certainly if you have adopted these things, then you have made the decision based on something that those tools, those mindsets, whatever it is that you're using for your operations day to day, those things are beneficial because they accomplish something that you want them to accomplish. But it is just as important or perhaps even more important to understand, explicitly understand what our tools are not good at. They're not just tools. What are we not good at? The team that you're on, you likely have some kind of assembly of skills on that team. But if that team was to be given a problem that is not well suited to solve, what is that problem? Here's why it's important to think about the opposite of your strengths. Right here we're not really talking about weaknesses. These are things that not only are you not good at, that you shouldn't ever try to do. There's two very important reasons why it's necessary to look at the other side of the coin and explicitly identify the places that you shouldn't be going. The first reason is so that when those kinds of situations arise, do you know that you can rule out whatever your default is? In other words, if you have a tool that you use by default, if you have a process that you use by default as a team or if there is a certain team within the company that gets the new problems by default. All of these things are possible. If a problem of a certain type comes across your desk, it doesn't match up with the things that you're good at. You know, immediately, to not try to solve it with the wrong thing. Don't try to solve that with the wrong tool, with the wrong people. If you don't do this exercise, it's very possible, perhaps even likely, that you'll use all of those things that are at arm's reach, that you'll use the wrong tool, the wrong process, the wrong team, the wrong skills, and ultimately, you may fail at solving the problem altogether or you may limple along and only solve it at a very suboptimal level. But perhaps more importantly, when we identify the things that we are not, this can go a long way in clarifying the things that we are. And when we identify what our tools are not good at, this can give us a very clear focus as to how the tool works in its best case. And in this particular scenario, we're not really talking about saying no in order to save time. Instead, we're talking about adopting the right kinds of opportunities. We're talking about aligning your tooling, aligning your personnel, aligning your mindset, aligning your goals with the right things. When you draw hard lines in the sand about what you're not good at, what you're not going to do, what your team is not going to do, what your tools are just not suited for. When you draw those hard lines, not only do you box those things out, but you give yourself a clear domain of agency. You see much more clearly than before what you can do. If you recognize early on in your career, the things that you just simply are not suited for, maybe you don't want to do them. And for that reason, you're not suited for them. Instead of being a software engineer on an unknown track, you can say that you don't really feel like you're suited for back end work, that you'd like to work more in the front end. Or that you're not really interested in the manager's path. Maybe you can then make better decisions about your career path and especially look for companies that recognize the value in the deep individual contributor path. Am I yours as both an engineer and as an engineering leader? Some of the biggest architectural rewrites that I've seen have been the result of not just using the wrong tool for the job, but for allowing the job to creep. The scope of whatever we were using the tool for originally may have made sense to some degree, but over time that job is outgrowing the use case that the tool is actually capable of reaching. This exercise is an expression of a larger theme of exercises that I've recommended that you do on the show before. That is looking at the inverse, looking at the inverse of, in this case, capabilities or skills, things that you would consider yourself to be good at or your team or your tools to be good at, looking at the inverse of that can often be illuminating. And sometimes we recognize that we're trying to fit ourselves, we're trying to fit our tools, we're trying to fit our teams into a mold that we were never intended to fit in. So I'd encourage you to do this specific exercise on regular basis. One other area that I've applied the same kind of thinking to is to my own personal values. You can think about your values in terms of the inverse of your values. Thanks so much for listening to today's episode of Developer Tea. I hope you enjoyed this discussion on clearly defining what your tool set or what you as a software engineer, what you're not very good at doing or what you're choosing not to do, what you're going to choose not to do with your giving tool set. Thanks so much for listening to this episode. If you enjoyed this episode, please join us on the Developer Tea Discord community. We can have discussions like this one. We can even talk about this specific episode with the other engineers that are there. So far in that Discord community, I have not yet once seen an uninviting interaction or an interaction that made someone feel uncomfortable enough to report it. You've had none of that. It's very much an inviting community. If you are looking for a group of engineers that you can feel open with and you can ask any question about your career or about your progression as an engineer, this is a great community to do that. Head over to developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.