Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, 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'll 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 skim of the earth. I don't know. I don't know. I don't know. I don't know. 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 succinct set of questions is, number one, how do you approach this trade-off? When you need to use something you're an expert in for your current work, do you just learn from the experience? Or, do you just learn from the experience? Do you 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 developers that you're referring to. So, I'm going to go ahead and talk about some of the things that we'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 into the rest of this. 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 Hired.com. Hired is bridging the gap between developers and designers and the companies that want to hire them. Companies on Hired.com provide equity and salary offers up front, and you actually get to see that offer before you ever even talk to the company. 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 Hired.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 Crispin's question and 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 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 ins 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're trying to solve today. So here's my recommendation for becoming a master while also getting things done, Crispin. 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 Mastery tool. If you're a master, you should be able to master the tool. If you're not, you should be able to master the tool. If you're not, you should be able to master the tool. Thirdly, I would 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're writing. If you don't know what something does in the code that you are writing, if you're 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 you are actually writing. If you want to learn a system, start by learning subparts 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 axles of the wheels. If you want to learn a system, start by learning subparts 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 bringing 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 subsystem 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. If you're trying to learn a new 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 the subsystem, you can learn how to run JavaScript. If you're trying to learn 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. Now, you may have to do some inspection. You may have to console.log, let's say, if we're using a console.log, and you may have to use 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 of the code that is running? Do you want to mutate the state in some way? Do you want to use the state that you use to run the code? Do you want to use the 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? And then finally, where, if anywhere, does the code return to? So obviously number one and two are kind of tied together, and number three and four are kind of 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, and paste. And then finally, what is the code that you are trying to do with that code? 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 in 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. Crispin, to sum it up, you learn by practicing. You learn by solving real problems with real code that you have learned. At the same time, you may find yourself bringing your evolution behind you and bringing your you and bringing your evolution behind you and bringing your evolution behind you and bringing problem is, Crispin. 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, Crispin. 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 free trial, please visit Hired.com. And if you have any questions, please 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'll see you in the next one. Bye. I would love if you would give me a review on iTunes. It would be a personal favorite to me. It makes a huge difference for the show. Thank you again for listening to Developer Tea. And until next time, enjoy your tea.