Hey, everyone, welcome to Developer Tea. My name is Jonathan Cutrell, and in today's episode, I'm answering a question from Blisener Jack. Today's episode is sponsored by Leno. Leno does a long time sponsor of Developer Tea. We're happy to have them once again sponsoring the show. With Leno, you can instantly deploy and manage an SSD server in the Leno Cloud. You can get a server running in seconds with your choice of Linux distribution, resources, and the node location. We will talk more about what Leno has to offer, including a brand new offer that Leno has for you later on in today's episode. But first, I want to jump into Jack's question. Jack contacted me on Slack, which you can do as well by going to spec.fm slash Slack. Of course, that is free to you, as it was, Jack. And Jack reached out. He sent me a direct message in Slack. He said, long time listener, first time asker. Well, I'm glad you reached out, Jack. Thanks so much. He says, my question might seem pretty general, but I was curious to hear your take on it. How does one learn to write idiomatic, efficient, and effective code in a language? Is there a specific way to study that? And then apply it to your own code? I've read books, I've read code, but I can't seem to actually apply these general ideas to my specific code. Jack, your question sounds pretty general on the surface, but the reality that you have here is that you're trying to make things practical for you. And that's really the question you're asking is, yeah, I know how to learn, right? I know the topics that are discussed in books. I know the topics that are discussed on blogs. I know what people are talking about, but I don't know how to take that information and boil it down when I'm actually writing my code from day to day. The reality for developers is that we do have to apply this concept at a very practical micro level. We have to apply multiple concepts. Every single day we're learning new things, and we're supposed to take those things and distill them down to each and every keystroke that we choose to write our code with. So I wanna address this because it affects every single developer who wants to become great at what they do, even those who are already pretty good developers, you're constantly wanting to get better at this particular thing, learning and applying new information to your coding processes. So I have three steps that I want you to take, Jack. I have three things that I want you to think about when you are trying to learn how to apply your newfound knowledge to your code on a day to day basis. Three pieces of advice. Hopefully anyone else who is listening right now, you will gain some value out of this as well. Number one, find a consistent code reviewer. Find a consistent code reviewer. Another person who is relatively experienced with whatever language you're using can help you learn the idioms of that language. That was one of your things that you wanted to learn, Jack, is how to write idiomatic code. For a given language that may be different from another language. For example, a lot of you rubiest, you may not even know that you can add semicolons at the end of most of the lines of your Ruby code, but that's totally possible. It's just something that most people don't do because it really doesn't help the compiler at all and it's extra code and it kind of looks weird, right? And the reason it looks weird is because the people who write Ruby on a regular basis, they don't include semicolons in their code because once again, there's not really an advantage to it. And so the average Rubyist, if they're reading your code and they see a semicolon in there, they're gonna tell you, that's not really necessary. And if you don't have a code viewer, if you're only studying the spec of the language, then you might see semicolons and be like, okay, yeah, I'm gonna put that at the end of a line because I see it in the spec. So the human eyes that you have on your code, someone else looking at your code, not only is it gonna help you learn the idioms of the language, but it can also help you see things from a different perspective, particularly someone who is more experienced than you, someone who has learned the stuff that you are learning today, Jack, they learned it years ago, perhaps. They have a different perspective from you. They can enlighten you to new ways of thinking and executing your code. This is so important, especially to have someone looking at your specific coding problems, particularly if you can find someone at your job that will perform these code reviews with you. A great place to do this kind of discussion is in a pull request because it's attached directly to the code itself and you can go back and study it again. If you forget what somebody says, for example, it's recorded on GitHub for you, you can go back and study what they told you about a particular piece of code. So get a consistent code reviewer, find someone to review your code on a regular basis. This is incredibly helpful for growing as a programmer. I have two more pieces of advice for you, Jack. Two more steps for you to take. But first, I want to talk about today's incredible sponsor, Linode. With Linode, you have eight data centers with plans that start at $10 a month. You can get up and running in under a minute. And you get hourly billing with a monthly cap and all of the plans and the add-on services that you choose, including backups, note balancers, or long view. You get virtual machines for full control. You SSHN is root and do whatever you want to with that machine. You can run a private Git server. You can have encrypted disks, VPNs, et cetera. They have native SSD storage. They have a 40 gigabit network running on Intel E5 processors. And they have a seven-day money back guarantee. Now, on top of all of this, as of today, as of July 1, Linode now offers two gigabytes of RAM for only $10 a month, $10 a month. That's less than 40 cents a day. It's incredibly cheap, two gigabytes of RAM for only $10 a month. That starts today. Go and check it out, Linode.com slash Developer Tea. And here's another deal for you. If you use that link, Linode.com slash Developer Tea, you get $20 of credit. So let's say, I'm going to lay this out for you. If you were to use Linode for an entire year with that two gigabyte of RAM a plan, that $10 a month plan, and you get $20 of credit, that's $100 for an entire year. That's a little over a quarter a day for your server. There's no better deal than that. Go and check it out, Linode.com slash Developer Tea. Or you can use the code Developer Tea 20 at checkout. Of course, that link and that special code can be found in the show notes at spec.fm. Thanks again to Linode for coming on to Developer Teaas a sponsor. So we're talking about Jack's question, about applying the information that he is learning when he's reading or when he's watching tutorial videos, all the ways that we learn as developers, whether it's at a conference, maybe we're watching someone else's code. There's so many ways that we learn, but how do you apply that information? And the first piece of advice that I gave Jack was, get someone to consistently review your code and help you see things that you didn't see originally. Number two, when you read books, other people's code or articles discussing effective coding practices, translate what you are thinking into code, translate what you are learning into code examples. For example, if you're learning about refactoring, you might learn about the method extraction process where you take a query that's inside of a method and you move that query out to its own method, right? That is a refactoring pattern. Right code that matches that pattern, right code from the before state, the unrefactor version of the code and then right the refactored version of that code that will help you drive home those concepts, right? You're actually manually practicing the concepts that you're learning. The point here isn't to get high quality code out of this process. You're not trying to produce code for your job, right? You're not trying to produce code for your projects, but rather it is to apply your learning in a very specific way. You're actually practicing what you're learning. It's a type of quiz because you're taking what you are seeing, what you're reading, other people's code and you're translating it into something that you have now adopted. You've now imported that information into your brain. So translate that code into an exam, or translate that concept into your own coding example. The problem you get into if you don't do it this way is that you'll start to learn really great lessons from incredibly smart programmers who have come before you and then when you sit down to code, you haven't practiced new habits. You will generate the same kinds of code with the same bad habits that you've had before and then wonder what happened. The issue isn't the lack of information either. You've read the books, you've read other people's code. There's no secret formula here the way you get better at applying these lessons is if you practice it frequently and soon after you've learned the lesson, don't wait until you randomly come upon a situation where you need to recall the information you read a year prior. When you are reading, when you're learning, when you're at a conference, plan to spend a bit of extra time with an article or a book to let the lessons sink in, whether that's with your own self-guided code or maybe you've with code that you've written in the past, you can go back and refactor that code to match this kind of idea. Make sure you're translating what you are learning into practical code examples. Translate what you're learning into coding examples. And number three, Jack, the third thing that I want you to think about as you are learning to apply what you're learning is rethink your code from the ground up. Don't try to import these new things into your existing code unless it's a very simple concept. Don't try to import it into your existing code. A lot of the time when you try to apply best practices to your existing code, you start from a disadvantage. You've learned a brand new way, for example, to structure your application. A lot of these best practices, they deal with the macro design of your code, rather than with the line by line. Maybe you've learned a different paradigm for class design. Whatever the specific skill is that you're wanting to apply, it may be difficult to do that because your code already has set up constraints and to import this concept into your existing code really would require a pretty large rewrite. This issue is often best resolved by starting from scratch. Start from a blank piece of paper and think if I could do this whole thing over, if I could solve this problem again, how would I do it? What you'll find is often your new solution is going to look wildly different, even though it has similar outcomes as your previous code. Your new solution may look wildly different, it may have a totally different, you may even use a different programming language to solve the same problems. A lot of the time the big lessons we learn with code are difficult to apply at a line by line level. Sure, we can apply wisdom like naming your variables descriptively or not using magic numbers, but when it comes to larger scale design refinements, it's likely that the trouble you are having, Jack, the trouble you're having applying your newfound knowledge is partially due to the fact that the system you are trying to work with is already designed with a different, perhaps, opposing system in mind. The system that you're trying to fix, the stuff that you've learned that you're trying to apply to a system, that system that already exists may be in direct opposition or may have some particular elements to it that prohibit you from accurately practicing that new way of thinking, that new paradigm that you have, that new design pattern. So start by thinking, rethinking your code from the ground up. Blank slate, start from the ground up, it's called green field. Go ahead and start from that when you are learning. Now that's not practical to do in the day to day on your job necessarily, but when you are learning, and again, this is an investment in learning that we're talking about here. And Jack, you are smart to ask this question because what you're realizing is it's important to invest in learning. It's important to invest in making your code better. A lot of people think that by simply learning these practices, these best practices, these patterns, that that is what it takes to apply them. And Jack, you've recognized something, it's really important to be able to do that. You've recognized that you are having a disconnect between learning and applying. So I want you to stick with it. I want you to follow these three things. Number one, find someone who can review your code as often as possible. Number two, when you are learning, when you're in the process of reading a book, or maybe you're at a conference or watching a tutorial, translate what you are learning into coding examples. That means slow down, actually take some time to look at what you're learning and translate it into real working code. And number three, rethink your code from the ground up. Don't try to apply these principles to code that already exists when you're in the learning process. Thank you so much for asking the question, Jack, and for reaching out on Slack. If you, anyone else who's listening, if you have a question for me and you'd like to hear me answer it here on Developer Tea, reach out to me, you can email me at Developer Tea at gmail.com. You can also find me on the spec Slack community. Spec.fm slash slack, you can join us there. Or you can find me on Twitter at at developert. Thanks so much for listening. And thank you again to today's sponsor, Linode, if you want $20 of credit on Linode's platform that's two months, by the way, of a two gigabyte RAM server that just started today, $20 of credit by using the code developert20 at checkout or just simply go to linode.com slash developert. Thanks so much for listening. And until next time, enjoy your tea.