Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I'm going to be talking about picking the best tool versus picking the right tool. When we talk about picking the right tool for the job, a lot of times we evaluate the tool on its own. We'll look at the benchmarks for a given language or perhaps we'll look at the community around the language. Maybe we'll look at whether that language has some libraries available for it that fit the job description, but quite often we don't think about the people who will be actually creating that particular piece of software. And I think this is the fundamental piece that we forget when we are trying to find the right tool. And it's really the most important piece in a lot of ways. But so many times we look at what the newest framework is or perhaps what the fastest framework is and we assume that we should learn that particular framework. And it's not just frameworks, it's also languages. There are always going to be languages that are considered up and coming languages, perhaps the popular language of the month if you want to call it that. Of course, for example, JavaScript recently became the number one language on GitHub. And that's not to say that you shouldn't learn JavaScript. In fact, I would recommend that you do learn JavaScript, but that is to say judging any tool from an objective perspective forgets the fact that it is actually a human that is using that particular tool. Now before you get all up in arms and go and get your pitchforks and chase after me, I am not saying that we shouldn't be looking at some of the objective measures that explain how effective a tool is. For example, if you can make a tool faster without changing the API, there are very few who would disagree with the faster being more valuable. It takes up less energy and it doesn't take any investment from the people who use that tool to actually gain from those benefits. But the objective measures are not the only ones that matter. In fact, I would recommend asking each other, asking the people that you work with on a particular project or perhaps on a permanent team, ask each other what you like working with. I like working with Ruby, but there are a lot of people who need to accomplish the same things that I accomplish with Ruby and they pick Python. Now are there technical differences between Python and Ruby? Absolutely. But for my purposes, for what I use Ruby for, there isn't really much of a gap in terms of performance between Ruby and Python. So the subjective character of the language is a big reason why I choose to use Ruby. Even the creator of Ruby, however, says that no language can be perfect for everyone. He tried to make Ruby perfect for him, he says, but maybe it's not perfect for you. And that's a very strong statement that a language can't necessarily be the right language for everyone for every project. And in fact, even if it is objectively measured as the right language for a given project, it is very possible that because of the human factor in software development, specifically because people are developing the software and maintaining the software in the future, you can't ignore whether or not somebody enjoys using the language, for example, or enjoys the semantics of a given framework. So I'm going to give you a challenge, a very simple challenge here. And the challenge has two parts. The first part is to ask yourself if you are making the subjective parts of a given tool that you use if you're trying to make those subjective parts objective. In other words, I'm giving you license to make one of the reasons why you use a tool that you like it, not just simply that it's the right tool, but instead that it's the right tool for you that you actually enjoy writing that particular language or using that particular framework. So the first part of the challenge is to investigate whether or not you are making objective claims about parts of your preferences that are actually subjective. If you are trying to fight for a language and saying that it has better performance benefits over another language, when in reality you may not even know if it has better performance over another language, you just enjoy using it. I would challenge you to investigate that. And the second part is very simply to have a conversation with your coworkers and with your teammates about the different technologies, the different tool sets that you all use together and if you enjoy using them, if you actually have some sort of affinity for that particular tool. It is possible that you will uncover either a strong appreciation for certain tools that you and your team use and therefore you may decide to invest some more time in using that tool to its fullest capacity or you may uncover a distaste for some of the tools that you use. And that should lead you to a discussion of whether or not there is a replacement for that tool that would encourage you to do better work, that that tool is currently kind of hindering your progress because it's really quite annoying to use, for example. Take some time and evaluate your tool set, evaluate how well it fits you, how well it fits your preferences. Now, I do have a word of caution. Be careful in thinking that simply because of your subjective appreciation for a given language, that that language is absolutely correct for every project. I do not think that tools just because you like them are the right tools, but instead I'm saying that you should consider whether or not you like a given tool. And if you don't like a tool and there is a better alternative that accomplishes the same goals with an acceptable performance rate, then consider those tools. Why not go ahead and consider shifting to those new tools that you actually enjoy using more than the other tools. The reason for this is because if you enjoy using a given tool, if you actually have an affinity towards that tool, then you are more likely to spend the extra time that is necessary to truly get the most out of that tool that you can. As a musician, for example, if I truly enjoy playing a particular guitar, then I can typically sit longer with that guitar and practice longer with that guitar. Even though it doesn't necessarily make me a better musician, I can become a better musician by practicing longer sessions and investing more time, investing more energy because I'm enjoying myself. I hope this has challenged you. I hope this discussion about tool sets has challenged you to consider whether your tool set is actually subjectively the right fit for you and your team, and to challenge you to not make objective arguments about things that are actually subjective. To start allowing yourself to enjoy the tools that you use and make part of that enjoyment your justification for choosing that tool. Thank you so much for listening to today's episode of Developer Tea. If you didn't notice today, I don't have a sponsor, so I'm going to take just a minute to talk about some of my friends that I work with at spec.fm. There's two things I want you to check out, especially if you are a designer. Check out design details. There is going to be a link for this in the show notes. Of course, you can find all of this at spec.fm. There's show notes at spec.fm as well. Check out design details. They are at spec.fm slash podcast slash design dash details. Of course, again, there's going to be a link in the show notes. Brian and Brenn, they are the hosts of design details. We teamed up to create spec together. It's a great show where they interview people who are making all the things that we love to use every single day. The other thing I want to tell you about is called Little Bites of Coco. Jake Marsh has created Little Bites of Coco. Again, it's on spec.fm. You can check it out there. But it's basically these little short pieces of content about iOS and Mac development. So especially if you are interested in iOS and Mac development, that is an incredible resource for you in some ways similar to Developer Teabecause it's intentionally short. It's intentionally given to you in, well, bite-sized chunks. So go and check out Little Bites of Coco and of course design details as well. If you haven't signed up for our Slack channel, you can do so at spec.fm slash slack. Again, this will be in the show notes as well. But if you want to come and chat with us, I personally am in that chat room and the guys from design details are in that chat room. There's always good conversation happening there. Go to spec.fm slash slack. Thank you for listening to today's episode. I hope you will join me on the next episode of Developer Teato make sure that you don't miss out. Make sure to subscribe in iTunes or whatever podcasting app that you use to listen to podcasts. Thank you again for listening to Developer Tea and until next time, enjoy your tea.