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 Cutrell. You're listening to developer Tee 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 is 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 makes sense to deconstruct. 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. And 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. 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 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 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 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, but 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 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 is more optimal for whatever that job is. Now it makes sense to talk about the job. But first, we are going to talk about today's sponsor, Compiler. I had the opportunity to speak with the hosts of the Compiler podcast. That is 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 a very long pathway ahead of continuing in the same way. 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 it. You're right. It is 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 pie cast. The latest episode is episode number six. Do we still need strong copy left licenses? Thanks again to compiler for sponsoring today's episode of Developer Tea. 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 just 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. As we talked about the fact that we very often limit. We limit what tools we are picking from. Picking the right tool. If we were to take this analogy to 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. 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 software engineering jobs. This becomes less true depending on how 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. But 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 and 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 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 know, 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 phenomena as engineers. But moment we hear the beginning of a problem, not even the full, you know, 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 kind of deconstructing them and saying this area of picker is going to reduce our possible set of tools down. And this particular problem is going to reduce our possible set of tools down. 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. They can 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 copy left licenses? And again, another huge thank you to Brent and Angela for having a conversation about compiler with me, really enjoyed listening to this season. 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 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 of 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.