Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell. I'm your host and today I'm going to be telling you how to decide when to learn a new tool. This could be a new language, it could be a new framework, something that you haven't used before either in production or on the side in a hobby project or some kind of side project. So I want to give you kind of a rubric for evaluating when you decide to adopt a new technology. And this is kind of a difficult thing, right? Because we have a lot of tools that are go to resources that we know we're going to use. For me, I use J query on almost every project and I realize that that's kind of divisive. There's a lot of people who say that, you know, you should be able to write vanilla JavaScript for your project. But ultimately I found something that works and may not be absolutely the most perfect solution, but it works great for me. And so I'm going to continue using J query. And I suggest that you find your go to tools. You know, I wrote a post about this recently. If you look at the tool set of a blacksmith in the earlier part of the second millennium, let's say like in the 1400s, and then you look at the tool set of a blacksmith two or three or 400 years later. Those two tools sets are very, very similar. Now there might be a slightly more ornate version of the tool set. There may be some slightly more polished versions of those tools, but fundamentally a blacksmith has the same tools throughout history. They've used the same tools for forging metal. And really there's a lot for us to learn from the blacksmith. There's a lot for us to learn from someone who has become very acquainted with their tools. Why don't we also become very acquainted with our tools? I would say that in large part we should slow down, reconsider when we feel like we need to constantly be adopting new tools. Why should we adopt new tools? Now today, I'm going to give you a rubric for saying that we need to be able to do a new tool set of a blacksmith. Yes, it is time to adopt a new tool, but I do think that in large part we have this sense that we need to adopt something more quickly than we really actually do. So here's a challenge for you. Take, take a step back and reconsider whether or not you actually need the new tool. Now, if you just are trying to learn for the sake of learning, there is value there. There is absolutely good value in expanding the way your brain works. This is a pragmatic programmer says that you should learn one new language every year, for instance. And it's important for us to do that because as someone mentioned on stack overflow. There are different languages in the world that have completely different constructs. For instance, there is a language that doesn't have the idea of specific numbers in it. So if you were to to present to them the number one or the number two or single the word single or the word many, they can't completely comprehend those constructions, those ideas of discrete numbers because they've never been implemented in their language. So as a developer, there are things in other languages than what we're using on a day to day basis. There are other languages that do things fundamentally differently. And if we were to learn how to program in multiple languages, then our brain has the ability to think differently than we did previously. This gives us a frame of reference to be able to determine what tools are most appropriate for a given context. So, and there's a lot of ways to learn about these things. It's important for us to know people, for instance, who understand what the different tools are and what would be appropriate for a given context. It's very valuable for us to maintain relationships with people who are experts in multiple different fields. So, meet people, reach out. Don't become a recluse because you're not going to be able to become an expert at every single language that you pick up. So, now that we've got that out of the way, let's talk about the rubric for deciding when to learn a new tool. The rubric comes down to two basic things. If you walk away with nothing else, remember these two things. The rubric for evaluating your technology adoption decisions is based on two types of value, value for your business and value for you as a person. Now, you may not care about value for you as a person. I do. I like programming and honestly, there are tools that I like programming in better than others. You all know that I very much enjoy Ruby. And if you don't like Ruby, that's fine. I have absolutely nothing against you. But I think that if you do choose to use a technology, you should also enjoy it. There's so many different languages out there. There is very likely one that you will enjoy using. Your happiness is important. And in the long run, if you're building something that you hate building, you're less likely to build it with care. You're less likely to become a craftsman. And if you don't care about that, then you can disregard the idea of personal value. But if you want to become a craftsman, then consider adopting technology that you actually enjoy creating with. The other side is business value. And this is the one that's arguably the most important for understanding when we should adopt tools. Because most often when we ask that question, when should we, where referring to, when is it the best idea for our business? When is it the best idea for my company? If you're over, if you're over a team of developers, when should you invest in your developer spending time learning rather than using what they already know to build something? And I think it comes down to two different types of business value. There's value now and there's value later. So value now is how important is it that the thing you are building is shipped in a given timeframe. In other words, if you can get this thing out the door tomorrow, how much of a value is that giving to you? Versus if you were to wait a little bit longer, right, if you were to wait a little bit longer and implement something new, something that you don't already know, it's going to take you some time to learn that thing. So is there value in you shipping this thing faster rather than slower? If there is, then consider that value as important. You aren't going to hear from me that you should always be adopting new tools and you're definitely not going to hear from me that every time a better, you're definitely not going to hear that every time you find a particular tool for a job, if it fits perfectly that you should learn it. I don't think that's true. Because time is extremely valuable. In fact, it's the most limited resource and we all have the same amount every day. So value now is extremely important. You shouldn't discount time to market if you want to use business terminology. If you need to ship quickly, then consider that an important part of your decision making rubric. However, if you want value on the later end, right, if you want for your technology decisions to provide value in the long run, if you need for your particular application to be more maintainable. If you, for instance, are wanting to make sure that it's developed with the most appropriate tool, then it's very likely that adopting a new tool might be worth your time. It's the tool you are learning now, a better fit for the job and more flexible for your application in the future. How much work will it take to pay off the technical debt that you would incur if you took shortcuts to get to market earlier using the wrong tool. So this is basically just if you are trying to get something done quickly, let's take a practical example on the on a given website. If you're a front end web developer, you might be throwing together a few jQuery functions without much structure to the way you're writing your JavaScript. And maybe you're doing like an inline style here and there and you're throwing important in your CSS file and you're just putting these things kind of hacky solutions or quick fixes throughout your code. Well, later on down the road for the next developer who comes along or even if you come along and you see your code again and you have to change something, how difficult will it be for you to change it? Is it going to be more difficult for you to track down the things that you need to change than it would have been to go ahead and implement that in the beginning. Certainly, there are times when it is appropriate to put those quick fixes in place, especially for instance, imagine a situation where you had to get something out the door that day because I don't know that there was an investor meeting the following day or maybe there was a massive amount of traffic to your particular site. Well, then it makes sense for you to go ahead and do the quick fix. We are proud of it. It's not some kind of exposition of our code. There's no reason for you to say this is absolutely the best thing that I could do right now. But it's about value. It's about when that value is most important. So another part of value later is if you're trying to adopt a new technology, is that technology being adopted by other people currently. The idea behind this is if you're adopting a technology that is likely to open doors of opportunity in the future, or if the technology is growing and you're trying to grow a company, and there's like a new flourishing community around this particular technology, and there's new people that you could hire to work with that technology, then it might be worth investing early in that technology, even though even though you may not be fluent immediately. Even though you might not be able to ship very quickly with it right up front, there is a long term gain because that technology is is gaining a community. It's gaining a foothold with people in a social setting of sorts. So it allows you to get in touch with developers who might would want to work with this. So this is the rubric really for understanding when to adopt a new tool. There's two basic types of value business value and personal value. And then under business value, there are two types of business value value now and value later value now is do you need to ship this as soon as possible. Or before a specific time and if you absolutely need to ship it before a specific time, then you do everything you can to do that. Value later is what is the value of flexibility? What is the value of maintainability for your project? And then you just simply compare those two values and see which one weighs out. Now that seems simple when we're talking about it now, of course it's much more of a difficult process in practice. But remember that learning should be the way that we are constantly approaching our situations. And so if you have an opportunity to learn and if the way forward isn't clear, then choose when you can choose learning every single time. Learning gives you exponential value that you can't see now. Learning gives you the opportunity to create things that are maintainable more maintainable not only now, but also in the future. So consider flexibility as as the preferred option. You want value later more than value now more often than not. So the rubric essentially is just business value, personal value and then prefer value later. But if the value now supports it, then quick fixes are totally an okay thing. And you should feel totally fine about putting in quick fixes in your code if you need to get something out the door as soon as possible. Thank you so much for listening to Developer Teaou can reach me on Twitter at act Developer Teaor you can email me at Developer Tea and gmail.com. You can also go to developertea.com where their show notes and a contact form. If you'd like to support the show, go to developertea.com, friends slash donate. Thanks for listening and until next time, enjoy your tea.