We often hear the advice as engineers to pick the right tool for the job. And this isn't bad advice per se. In fact, it's advice that we should listen to. Picking the wrong tool for the job, after all, can be costly. It can be frustrating. And sometimes it may result in rework, starting back over from the beginning, or at least doing a major refactor. Very rarely does it actually result in going back and picking the right tool for the job. And so a lot of the products that we use the wrong tools for end up being difficult to maintain for the long run. But in today's episode, I want to focus on this advice and deconstruct it a little bit. My name is Jonathan. You're listening to Developer Tea, and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. You will get a lot of advice over the course of your career, and it's your job to understand the good that the advice is actually bringing forth. And one of the best ways to do this, in my opinion, is to actually deconstruct the parts of the advice that make sense. In other words, figure out exactly what the advice is saying. In this case, we have three basic parts, and some basic grammar can actually help you in this exercise. But you are the tool picker, and we can talk a little bit more about what a tool picker might be. Then you have the tool itself. What is it? That you're actually picking. And then you have the job. And I want to talk about each of these on their own. So you as the tool picker. When we say you here, this could be a team that is doing the picking. It could be a manager that is doing the picking on behalf of a team. It could be you on your own trying to build a startup. It could be you on your own doing the picking. It could be you on your own doing the picking. And so what I want you to bring into the you as the tool picker is what is the context under which you are picking the tool. You could be picking the tool as an intellectual exercise. What tool would fit this, assuming you had someone who knows how to use the tool, for example. If you just choose a tool that in a vacuum where that tool is operated perfectly, is the most optimal tool for you. If you just choose a more optimal tool to do a particular task, that may be quite different from the tools that you actually know how to use. So picking the right tool for the job may actually mean for you as the picker that you choose from a much more limited set of tools that you already know how to use. Now again, this depends on your context. It's possible that your context is actually incorrect. It's possible that you're in a learning context where you want to pick a tool. You're intentionally choosing the set of tools that you don't know. It's also possible that you are choosing to use a tool based on a legacy system. And what degree of fit does that tool have for the problem at hand? Well now, you have to look at what the problem at hand actually is. Now, let's talk about the problem at hand. Let's talk about tool. What exactly is a tool in this scenario? Very often, we limit at this juncture to tools that we, as the practitioner, the tool picker, that we are incentivized to use. In other words, when somebody says, what is the right tool for the job, our immediate list filters down to tools that we uniquely prefer. And that's the tool that we provide as a service. Another way to think about this is, you might immediately think of frameworks and languages and other programming tools. But there is a very real possibility and perhaps even a probability that something other than code, something other than a framework that you know how to operate, is actually a tool for this job. Now, once again, we have to remember that you are the operator in this environment, in this scenario. So, choosing something that you are not, you know, you don't have expertise in, might be appropriate for your context or it may not be appropriate for your context. Choosing the right tool for the job for you could actually mean that you are no longer primarily responsible for carrying out that job. Because you found a tool that you are not. You found a tool that is more optimal for whatever that job is. Now, it makes sense to talk about the job. But first, we're going to talk about today's sponsor, Compiler. I had the opportunity to speak with the hosts of the Compiler podcast. That's today's sponsor, Angela and Brent. And in today's episode, I want to share a bit of that conversation with you where I ask about the future of their show. I wonder, as you move forward with the show, do you see the kind of format or the way that you explore questions changing? Or do you feel like there's enough of these that you kind of have this endless, maybe not endless, but very long pathway ahead of continuing in the same manner? That is a good question. I mean, because sometimes a question being posed to you, you know, begets more questions, right? So I think when the producers come and, you know, they have this story idea, what we end up with can be very different than what they first anticipated. So just having the conversation, you know, asking the question. Sometimes other questions tend to be uncovered. That's why I think we kind of were really broad with we want to be able to answer or at least address like really big questions or small questions or strange questions, because that kind of it doesn't limit us. There's always there's always a question out there. You know, like you said, someone can say a sentence and it not really resonate. But when you're asked a question, you're forced to consider. You're right. So as long as we're always, you know, posting these types of, you know, questions out there, we're giving people the opportunity to consider. I think it'll be interesting to see, you know, how many we can tackle and tackle. Well, I think we'll do good, though. You can find Compiler wherever you get podcasts. The latest episode is episode number six. Do we still need strong copyleft license? Thanks again to Compiler for sponsoring today's episode of Developer Team. So we've talked about the picker, the tool picker, which may be a whole team of people. Maybe it's you. Maybe you're creating a startup. Maybe you are leading a team. Maybe you're doing a small job. Whatever it is, the tool picker and the context that you're in will affect what the quote right tool for the job is. So when you pick the right tool, you have to determine what is the picking context. And this goes for the job as well. We're going to talk about that in a second. The second thing we talked about, of course, was the tool. And we talked about the fact that we very often limit. We limit what tools we are picking from. You know, picking the right tool. If we were to take this analogy to, you know, working on, let's say, a car. And we have a workshop with a bunch of tools. And those tools are generic tools. Maybe they are very generalized. And you may have tools that work for the job. But they're not specifically designed for that particular model of car, for example. Right? This is a very common scenario for software engineers. Because most of the tools that we pick, most of the tools we use, serve multiple purposes. Almost all of us who are listening to this episode right now, we all use generic languages for this very reason. We use languages that can generalize to many different problem sets. And this is especially true. For people who are in typical programming, you know, software engineering jobs. This becomes less true depending on how, you know, specialized your area of study is. How specialized your area of engineering is. But it is certainly true for the vast majority of the industry. Now, the last thing I want to talk about is the job. What exactly is the job? And more specifically, I want to talk about. An error that we often make when we're trying to pick the right tool for the job. Very often, we focus on the right tool part of this advice. But actually, the thing that we have wrong, the thing that we didn't define very well, is the job part. So we might be picking the right tool for the wrong job. If we don't understand what needs to be done. Then it's easy to. Quickly jump to conclusions about the problem. Now, this doesn't mean that you have to specify everything about the problem in order to make some kind of reasonable decisions. Really, all we're trying to do is predict some kind of fit. Predict some kind of effectiveness of a tool in a given problem set. But it does make sense to develop a consistent language when describing your problems. And this isn't a new concept. In fact, one of the early pioneers in computer science, Michael Jackson. He wrote a book about something called problem frames. Problem frames is a way of identifying a class of problems. Of course, he goes on to identify specific types of problem frames. But the specifics of that, of course, have become more complex. And it's necessary for us to gain this kind of language. In our mind. In our modern software engineering context. And the reason for this is that if you don't understand the general idea. The kind of pattern of problem that you're dealing with. It's very possible, if not likely, that you're going to choose a tool based on what you wish the problem was. And when I say wish here, I don't mean that you are thinking about it and hoping. You're very excited that this problem is this particular thing. But rather that you're using some kind of. Intuitive fitting of what you think the problem is. To the tool that you think will solve the problem. Many of us have experienced this phenomenon as engineers. The moment we hear the beginning of a problem. Not even the full initial pitch for a problem. We start imagining solutions to the problem. And there's nothing necessarily wrong with this. Except if we're too quick to jump to tool picking. We may be picking the tools. For the wrong job. So develop this sense. And the language that you need. To describe your problems. One way to do this is to look into. These kind of pattern languages. Like Michael Jackson actually. Wrote about. Another way to do this is to talk about these problems. In terms of what are they similar to. What kinds of problems is this problem similar to. So you can start to get a handle on. What is the actual problem. That you're trying to solve. This can greatly impact. The kinds of tools that you're going to pick. And very often. When you take this approach. Of identifying each of these three areas. And specifically deconstructing them. And saying this area of picker. Is going to reduce our possible set of tools down. This particular problem is going to reduce. Our possible set of tools down. And this particular problem. And of course. The tool set that we're choosing from. Is going to reduce our possible options down. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor Compiler. You can find Compiler wherever you listen to podcasts. You can listen to the latest episode. Do we still need strong copyleft licenses? And again another huge thank you. To Brent and Angela. For having a conversation about Compiler with me. I've really enjoyed listening to this season. Thank you. Thanks so much for listening to today's episode of Developer Tea. If you enjoyed this episode. Then do us a big favor. We don't ask for this very often. But I'm going to ask for it today. Leave us a review in iTunes. Or whatever app you use that has reviews. Those reviews are critical. They're absolutely necessary. For us to continue doing what we do. Because it's the best way to help other engineers. Find the show. Of course. Plays into all the different recommendation algorithms. Etc. But. Perhaps the most important thing that it does. Is it gives other people another voice. Another engineering voice. Yours. That they can actually. Measure whether or not they should spend their time. Listening to this podcast by. So leave us a review in iTunes. Or again any other. Platform that you use that has reviews. Thanks so much for listening. And until next time. Enjoy your tea. See you soon.