Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be answering a listener question from Crispin Bennett. Thank you so much for writing in Crispin and thank you everyone for listening to Developer Tea. Today's episode is sponsored by Hired.com. We will talk more about hired later on but if you want to go and look for a job if you are a designer or if you are a developer you can go and find jobs at Hired.com. Make sure you check for the link in the show notes. Again we will talk about that later on. But first I'm going to jump directly into this email that I got from Crispin Bennett. I think you guys are going to enjoy this. Crispin says firstly thanks for the podcast. You cover an impressively broad array of interesting topics and I find your thoughtful and analytical approach illuminating. Well thank you Crispin. I appreciate that and I very much enjoy doing this especially for emails just like this one. Crispin says the most frequent frustration I have when learning new technologies involves a tricky trade off. On the one hand learning the topic thoroughly enough to be truly fluent would take more time than I have immediately available as I need to make progress on this project right now. So I make a new addition to my ever-lengthening to learn list. I think we all have one of those Crispin so don't feel bad about how long that list gets. I have a very long one. On the other hand a shallow scam of the new stuff like an API or a library or a new SDK feature just sufficient to get a current project working results in unsatisfying work. A kind of rinse and repeat fiddling. This leaves me with a feeling that aspects of the current project are fragile and more importantly that I haven't learned the new stuff deeply enough to be able to readily apply it should something similar arise in future work. I suspect that this dilemma is only avoidable if you can carve out a really specialized niche for yourself where you can conceive of approaching mastery. But for most of us who will continue to encounter an ever-expanding field of tools and technologies this trade off is just an inevitable part of the game. The best I can do for a 16th set of questions is number one how do you approach this trade off? When you need to use something your in-expert end for your current work do you just learn enough to fiddle the unfamiliar stuff into place or do you manage to set the main project aside to do a deep learning dive and what's your threshold for switching from fiddling to deep diving? Cheers, Crispin Bennett. Thank you so much, Crispin, for your question. I know this is certainly applicable to a lot of people who are listening and this situation is certainly true for developers who use a multitude of technologies and aren't necessarily hyper focused as you mentioned in the question. And this is really the broad majority of Developer That you're referring to here because most people work with at least evolving versions of technology, say over the course of five years, and if you were to look at the technology tool landscape over the course of 10 years it can sometimes be comprised of a completely new set of tools from 10 years ago. So I'll return to a core tenet of the show to frame this discussion. Learning is a fundamental part of any career and much more fundamental perhaps if you are a developer. The tools we use change all the time, the market changes massively. So to be in this business you must be adaptable to that changing landscape. You must be able to learn. But you've pointed out another very important point here, Crispin, and that is in our day-to-day life, our job is not wholly satisfied by us focusing simply on learning. At some point we have to put away the books and start coding. I'm going to take a quick sponsor break and then we'll come back and dig a bit deeper into this conundrum and we'll talk about how to strike a balance between that learning process and actually getting something done, actually getting code written. Today's sponsor is Hire.com. Hire is bridging the gap between developers and designers and the companies that want to hire them. Companies on Hire.com provide equity and salary offers up front and you actually get to see that offer before you ever even talk to the company. And these companies are all over the world in major tech hubs and they are vetted directly by the folks at Hired. If you get a job on Hired they normally give you a $2,000 signing bonus. But if you use the special link in the show notes to sign up, Hired will double that bonus to $4,000. Now if you're looking for a job or maybe you just want to see if you are ready for the job market, you can sign up for free at Hire.com. It's totally free for you. Don't forget to use the link in the show notes so you can double that signing bonus if you do end up getting hired. Thanks so much to Hired.com for sponsoring today's episode of Developer Tea. So let's get back to Chris Pins question and this this seeming conundrum, this dichotomy between having to learn and having to get stuff done. When we find ourselves in the situation where we need to learn in order to actually execute on something, it's really a critical moment because there's this sense of a need for balance. On one end of the spectrum seems to be pure mastery and memorizing every single piece of the code that we're using. And on the other end of the spectrum seems to be the copy and paste tactic. Go to stack overflow, copy and paste code until you find something that seems to do the job. But the reality is this is actually a false dichotomy and first I'll explain why it's a false dichotomy and then I'll give you a recommendation on how you should handle this situation when it does occur. So mastery is not something that happens simply by focusing on learning. It doesn't happen as a result of memorizing everything and it doesn't happen by approaching every learning opportunity in a clean and structured way. It happens as a result of putting a lot of time and effort into the practicing part. Mastery isn't simply memorizing the ends and outs of a tool. Mastery is practicing the use of that tool until you have developed a unique intuition for using that tool every single day. And ultimately the most important step of mastery is practice. Putting the things you are studying to the test rather than doing a so-called deep dive into reading about the subject and then only testing a subset of your newly gained knowledge on whatever that problem is that you are trying to solve today. So here's my recommendation for becoming a master while also getting things done, Chris. When you run into this problem I recommend that you first assess whether this is a tool that you feel you need to master. You could be wrong in this assessment but answer the most important questions. Do I want to use this tool again in the future? Is this going to be integral to future work? Will I be continuing to work on this particular project in the future? What value does mastering this tool provide me both now and later? All of these questions can help you determine how much energy you should put into understanding the tool. Secondly, I absolutely recommend the minimum viable code approach. Do the minimal amount of learning to solve individual small problems. However, I definitely do not recommend the approach of cobbling together copy and pasted code without understanding the context of that code. In other words, you need to understand the code you are writing. If you don't know what something does in the code that you are writing if you are just copying it out of the documentation or like I said earlier, off of stack overflow, then that's not an adequate approach. You need to understand the code that you are actually writing. If you want to learn a system, start by learning sub parts of that system. If you want to learn how a car works for example, you may start by learning where the power comes from, and how that power is converted from raw kinetic energy into the rotation at the axle of the wheels. If you want to learn a system, start by learning sub parts of that system. And if you want to learn a car works for example, you may start by learning where the power comes from, how that power is converted from raw kinetic energy into rotation of the axle and ultimately how that car moves down the road. If you try to learn every system, if you try to learn hydraulics and electronics and the cooling system all at the same time, if you try to learn it all up front, you may have a hard time mastering how that car works. The same is true when you're trying to learn a new software development tool, a new language, an API or an SDK. However, you should definitely learn the sub-system that the particular piece of code is working within. At the minimum level, you should understand the following four things. Now, I want you to write this down and keep this on your desk somewhere because this is really one of the most effective ways of looking at a given piece of code. When you are experiencing a bug, for example, I would recommend you follow these four things, make sure you have answers to all four of them. Number one, where is the code being executed from? For example, if you are running JavaScript, then not only do you need to know that it's being executed in the browser or maybe it's on the server, let's say it's in the browser, but you also need to know where in the document is this particular piece of JavaScript because that changes things. If you understand where the code is being executed from, then a lot of problems may be solved immediately. You may be executing the code at the wrong location. Secondly, what if anything is being passed to the code in the form of state or arguments? In other words, if your code relies on some sort of state that is external to the code, you need to understand what that state is. You may have to do some inspection. You may have to console.log, let's say if we're using JavaScript again, or you may have to log something out to standard out in order to understand what that state is, or you may need to inspect some of the arguments that are being passed to that particular piece of code. Whatever it is that you need to understand, you need to understand the state that is happening, whatever is currently true, whenever your code is running. Number three, what is the desired outcome over the code that is running? Do you want to mutate the state in some way? Do you want to generate some kind of output based on some kind of input? Are you trying to do a call out to an external API and retrieve something and then return it back to the program that is running? What is it that you are trying to do with that code? Then finally, where, if anywhere, does the code return to? Obviously, number one and two are tied together. Number three and four are tied together. Where is the code being executed from and what is going on when it is executed and then what should occur once it is done being executed? What should be true once that code has finished executing? If you can answer these questions, you have learned enough for a practical implementation with pretty much any tool. This is not necessarily true across the board, but this will help you determine if you understand the code that you have written or if you are just doing that copy paste, going through the motions, finding the answer, and trying to plug it in and leave as quickly as possible. It's not necessary to learn every function, let's say, in the jQuery library. You don't have to know every view, helper, and rails. You don't need to know every single nuance of the way JavaScript works. You don't need to know the entire Java standard library to use these tools. In well-designed tools, solving one sufficiently complex problem provides you with enough experience to solve a second problem. As long as you have access to decent documentation, mastery comes not from studying these tools for hours on end, but rather mastery comes from solving a thousand or ten thousand or a hundred thousand small problems with the tools and with the documentation at hand. Just spin to sum it up, you learn by practicing. You learn by solving real problems with real code that you understand. It doesn't matter how small that problem is, Chris. So it is very possible that this leaves you in a similar position where you knew that you need to learn and you knew that you need to learn by doing. But ultimately what it comes down to is that when you have to execute on something, simply execute on it well. Don't cut the corners of trying to copy and paste code. Don't cut corners in trying to finish something quickly without fully understanding exactly what you've done. Instead, fully understand each and every solution that you implement. And when you do this over and over and over, when you've done it thousands of times, that is when you will start to cultivate that sense of mastery, the intuition that comes along with being a master. Thank you so much for the question, Chris Ben. And thank you, everyone else, for listening to today's episode of Developer Tea. I appreciate every minute you spend with me. Thank you again to hired.com. If you are looking for a job in the industry and you are a designer or a developer, go and check out hired.com. Make sure you use the link in the show notes. If you get hired, you will double your bonus from $2,000 to $4,000. It's a great deal. And at the very least, if you are intrigued by the concept, it's free. So you can check it out for free. You don't even have to pay a single cent. Go and check it out hired.com. Thank you, everyone, for listening to today's episode. Make sure you subscribe and I will love if you would give me a review on iTunes. It would be a personal favorite to me and makes a huge difference for the show. Thank you again for listening to Developer Tea. And until next time, enjoy your tea.