You may be tempted to put this phrase on your resume or to answer an interview question with this response that you pick the best tool for the job. This is what a smart developer would do, or at least that's what we've been told. And there's a sense that if you try to use the wrong tool for the job, it's because you like that tool too much. And that somehow we're supposed to be agnostic towards our tooling and the only way that we can show that we're agnostic towards the tooling is by saying that we'll choose the tool based on the job alone. While the underlying idea of not becoming dogmatic about our tools makes sense, we're going to talk about why choosing tools based on the job or choosing the perfect tool for the job is an unrealistic and perhaps even a damaging goal. 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. We're going to talk about four specific reasons why you'll never be able to truly pick the best tool for the job. The first reason is fairly simple. While not all tools are equal and we would never say so on this show, tools do not operate themselves. In other words, we must consider the human factors at play. For example, if you are particularly experienced with one language over another, then given a problem where two languages might solve this problem, one of them is one that you know very well and the other one is one that you're fairly inexperienced with, it's very likely that a reasonable choice is the one that you know very well. Choosing the right tool for the job is necessarily done in context of the person who is doing the job in the first place. The assumption, when we think about the idea of choosing the best tool for the job, the assumption is that we're going to look at some kind of performance metrics or some kind of capability or paradigm that the given tool provides or takes advantage of and match that capability or paradigm to the problem that the tool is trying to solve. But a simple adjustment that we might need to make in our mental model of choosing the best tool is thinking about the operator, choosing the best tool for the operator doing the job. So this is the first reason why you will never be able to choose the perfect tool for a given job. People are different from each other and tools do not sit outside of their operators. They can't work without someone actually telling them what to do, at least in our current scenario as developers. The second reason, if we tried to pick the best tool for each job, for each job, we ignore the many costs of coordinating these tools, maintaining them in the future and hiring a team, for example, to work across those different tool sets. So when we talk about picking the best tool for, quote, the job, usually we mean more than one job, a given product may have a hundred jobs that need to be done, which jobs specifically are we going to pick for? Typically the way that we think about this is, you know, what are the key elements? What are the, kind of the core features in this product, for example, and we pick our tooling based on those core elements. But that necessarily means that we are making trade-offs for some of the jobs that we're going to do with this code. So what trade-offs are we making for the less critical jobs? Since it's unlikely that we're going to have a new tool for each and every job that we have in a given product, it's also likely that you're going to make a lot of compromises and optimize for only some of those jobs. And the reason this is important, it may sound nuanced, but the reason this is important is because we need to be aware that we're making trade-offs, that we are choosing a tool that is not optimal for everything. And that when we make choices about optimization, when we try to align our tools with core features, we should expect that we're making those trade-offs. We're going to take a quick sponsor break, then we're going to come back and talk about two more reasons why you'll never be able to pick the perfect tool for any job. Today's episode is sponsored by XTeam. XTeam is the most energizing community for remote developers. You can work from anywhere for the world's leading brands and get supported to do more of what you love. You'll get the chance to work with big brands like Riot Games, Fox Broadcasting, Kaplan Inc, Coinbase, Beachbody, and much more. And if you've ever wanted to travel, you can live and work in one of XTeam's roaming hacker houses. These are called X Outposts, and they're around the world. The change is locations monthly, and this allows you to explore and work remotely in the most beautiful locations. You can take part in the adventures, share passions, and learn how to be a better remote developer by participating in these hacker houses. You can be a part of the most energizing community for developers in the world by participating in XTeam's seasons, capital S seasons. This is a three-month experience that's filled with challenges, rewards, games, competitions and more, and it's all centered around a theme that will inspire and energize you as a developer. XTeam also does something really cool called Unleash Plus. I want you to take a moment and think about what truly energizes you. What do you love to do? Well, Unleash Plus is going to give you $2,500 to go and do that. Whether that's going to conferences or going to the gym. Maybe participating in adventure sports or maybe you like to be a photographer in your free time. That's the kind of stuff that you can use your $2,500 per year on. Go and check it out. XTeam.com slash Developer Tea. That's x-team.com slash Developer Tea. All one word. Thanks again to XTeam for sponsoring today's episode of Developer Tea. So, we're talking about why it's impossible or nearly impossible to pick the best tool for the job. Of course, you can pick a tool that will suit you as the developer for a given task. This is a much more reasonable way of thinking about it. And here's the other reality. We'll talk about this before we jump into the other two reasons. You as a developer, you should be able to pick tools that you like. This doesn't mean that you should be able to force your whole team to use tools that you like, but you should be able to take into account. Given a scenario where you get to choose, you should be able to take into account the things that you enjoy using. The idea that enjoyment of writing code shouldn't be factored in doesn't really have a sound basis in behavioral psychology. It doesn't have a sound basis in product development for that matter. Choosing tools that we enjoy using can help us stay motivated. Can help us enjoy our work on a day-to-day basis. Our quality of life might be better because we enjoy writing in that language or using that particular tool. So don't discount your own preferences, even if it's just because you like the aesthetic even of the tool that you're using. Okay, so let's get on to the next two reasons why you're never going to be able to pick the best tool for the job. Number three, picking a tool for a job assumes that the job today is all that matters. We don't know what will change in the future, so by choosing a perfectly fit tool today, we might be making a one-way decision that is very difficult to reverse making the next tool choice impossible or at the very least much more suboptimal. So really what we're saying here is that choosing a tool that is perfect for one job is probably going to end up in you overtuning to that job. It makes a little more sense to imagine a handful of things that you might want to do with this project. Now don't try to forecast 10 years into the future every single time you're picking a tool, but try to imagine if this tool is so specific that it's going to prevent you from expanding on the work that you're already doing in the future. This is a very expensive decision that seems to go very well at first because once again, you're overtuning for that first job. But as you move forward, you'll quickly find that the decision you made to lock into one tool that was overtuned to one type of job can be very costly, it can be very frustrating to try to back out of that kind of decision. The fourth and final reason why you'll never pick the best tool for the job is that trying to pick the best tool for the job also assumes that you know everything about the job, that you can know in advance what the best tool will be. This is kind of a paradox because you're very likely not to be able to know everything about the job until it is totally done. In retrospect, you might be able to choose a different tool that could have worked better, but this assumes that we understand the job fully before we choose the tool and that somehow the tool is purely for execution, that you've chosen the tool and you're kind of pressing play and moving through the motions. In reality, for developers, our tools are research tools as much as they are building tools. They help us explore the problem, find its edges just as much as they help us iterate on products. So, tools that can remain flexible as we learn more about our problem, even though that tool may not be super optimized for whatever problem you're solving, that flexibility is incredibly important as you experience change. Thank you so much for listening to today's episode of Developer Tea. Thank you again to XTeam for sponsoring today's episode, head over to xTeam.com that's x-team.com slash Developer Teato get started today. Speaking of tools, we have an awesome podcast on spec.fm called Tools Day. Go and check it out at spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.