Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today we're going to be talking about learning again. Of course one of the most popular questions I get through Twitter and through developertea@gmail.com and through the contact form on developertea.com is how to become a better programmer. What are the things that I need to do to become a better programmer? And the easiest answer and perhaps the best answer is always learn. Always learn more. Set yourself up for a continuous learning process that is constantly feeding itself. You know this is this is the spirit of the agile methodology that is to try something, measure it, look at what you've measured, gain some insights about how well that thing went and then try something else and then compare. You go through that process over and over and over. And the truth is everybody has a different process that works the best for them as different as we are as different as our personalities are. There's different things that we respond well to and there's different things that we respond awfully to whether or not you're an introvert or an extrovert for example, you might work well when you're surrounded by people or you might work well in isolation. Now of course there are quite a few studies that talk about the general public where is statistically, you know what helps people work the best, what types of situations are people most productive in, but it comes down to trying these things out for yourself. So I want you to set yourself up for a constant learning process, always feeding back into your process, always feeding back into the way you do things. Now as a part of this process building experimentation technique that I'm asking you to try out, I think it's important that you learn how to experience a problem. Now I'm not talking about you know intentionally failing in order to try to fix something. I'm talking about experiencing a problem that you don't have a solution at your fingertips for. And it's very hard to do this because our first instinct is to copy the error message in our log file and Google it and find the top stack overflow post. And certainly there are good times to do this. There are many, many sessions of coding where you know I was on stack overflow every error that I encountered and typically somebody has encountered that error and they help me figure it out. And that usually makes me productive in ways that I wouldn't be productive without Google or without stack overflow. But the truth is a lot of those stack overflow posts I have actually visited multiple times because none of the information really sticks when I go and Google my error message and immediately put the fix in place. So many times I've had to re-google the same exact error messages that I've Googled in the past. And the thing is that my fingertips and it helps me solve the problem immediately and it makes me more productive. Now does that make me a better programmer? Possibly I would say no. Some people would say yes. Some people would say that stack overflow is a perfectly fine tool to use. And again, this is not a stack overflow bashing. But instead this is a way of saying how do you learn? How do you actually make your mind better? How can you become a better problem solver? Quite a few episodes back. I mentioned a quote by Charles Kettering. The quote is very simply a problem well stated is half solved. Now if you don't know how to state your problem, in other words, if you're just simply Googling the syntax of the problem, then how are you actually learning? How are you actually solving that problem? You are actually just using code from someone else who has gone through the process of solving that problem. So how can you go through the process of practicing problem solving? How can you choose to stay away from Google and intentionally solve problems? I'm going to take a quick sponsor break and then I'm going to come back and give you kind of a challenge for you to try out over the coming weeks, perhaps a month or two. Try it and see if you feel like you are becoming a better learner and see if you are solving problems more effectively. If you have a better way of approaching each and every problem you encounter, I'm going to take a quick sponsor break and we'll be right back. I'm so excited to tell you about today's sponsor because there's opportunity for almost anyone with today's sponsor and that is hired.com. On hired software engineers and designers can get five or more job offers in a given week. Now each of these offers has salary and equity built in up front and there are both full time and contract offers and opportunities available on hired. Users can view the offers from over 2,500 companies of all sizes from startups to large public companies and then they can accept or reject the offers before ever talking to any company. So there's never any obligations and it's totally free to use. It's 100% free to use. Now normally if you get a job through hired, they'll give you a $2,000 thank you bonus. But if you use the special link for Developer Teathat will be in the show notes, hired will double that bonus to $4,000 if you accept a job. That's hired.com slash Developer Tea. Now even if you aren't looking for a job but you know another engineer or a designer who is, you can refer them to hired and if they accept a job on hired, you will get a $1,337 bonus. That is a huge opportunity pretty much for anyone. So go and check it out hired.com slash Developer Tea. If you've listened to Developer Tea for very long, you of course know that learning is one of the major pillars of this show. We talk about learning all the time. In fact, there are multiple other episodes that that learning is kind of a core subject of that episode and that's true for this episode as well. Now the reason learning is so important is very simple. This industry changes all the time. All of our code is changing constantly to adapt to the changing industry to adapt to the technological advancements that are happening all the time around us. Smaller chips, faster bandwidth, et cetera, et cetera. There are so many things that are growing very quickly. New features and new languages, new ways of thinking, new ways of organizing data, all of these things require us to acquire new information, to take new information from what somebody else is spending their time developing and learning that information. Understanding what that information means to what we do on a day to day basis, taking new things to implement into practical projects each and every day. The great thing about learning as a developer is that the opportunity to learn is presented to you all the time because learning happens when you fail and failure is just an inherent part of coding. We are quite bad at coding perfectly the first time, so we're going to fail very often and we're going to learn from those failures if we know how to fail properly, if we know how to deal with failure and learn from it. That's exactly what this episode is about. I'm challenging you to stop reaching for the quickest answer, stop reaching for the easy solutions, and instead experience the problem and try to find those solutions yourself as if you could not Google the error message, as if you couldn't have access to Stack Overflow. Once again, I am not saying that you should try to act out your entire career without using the solutions of people who have come before you. Obviously, that's the whole spirit of programming languages in general, abstracting what other people have learned and implemented in order to kind of stand on their shoulders. That is the spirit of programming and computer science at its best. We do best when we work together. Absolutely. But there are occasions where the solution for a problem is not as simple as googling it. In fact, there are many problems that we face each and every day where the answer is not absolutely available to us either through Google or another means. So I believe that developers should make practicing problem solving a part of their continuous practice of learning. We need to learn how to problem solve as much as we need to learn the syntax of a given language. Problem solving is a core piece of what we do each and every day as developers. So here's the simple challenge that I want to give you. I want you to keep some kind of notebook. It can be digital. I like keeping a written notebook by the side of my desk so that I can't hide it. It's always visible to me. Keep that notebook available to you as you are going through the process of a given day and each and every day when you experience a problem, write it down in that notebook. I want you to take three problems a day and think about them for five minutes before you Google them. Now that's 15 minutes of investment a day in learning how to solve problems more effectively. Now what this is going to do is it's going to force you to look and read what is happening in front of you. You're going to have to read the error message and avoid the immediate reaction of googling or asking someone else. I want you to write it down and then sketch out what you think could be the problem. Now maybe you're going to dig into some source code. Maybe you're going to find yourself on GitHub looking through the issues. That's fine. But I want you to look through the code, look at that problem and try to dissect it without looking for a verified solution to that problem. Now this might work for some of you. For some of you, it may not work at all. This is one of those things that you have to experiment with. But subjecting yourself to hard problems, subjecting yourself to a situation where you have to use your brain to solve those problems is an essential practice for developers. You can't skip problems, solving. You can't expect to become a world-class developer without knowing how to solve problems without knowing how to read source code and understand what's going on in that source code that may be causing your problems. Now am I saying that you should stay on it until you solve the problem? No, not necessarily. I think there comes a time where Googling that problem, Googling that error message is necessary in order to, for example, make the necessary progress in the budgeted amount of time that you have on a given project. What I am asking you to do is deny your gut reaction to immediately jump to Google for an answer, immediately jump to the IRC chat where the team that built that particular tool is waiting to answer questions. Don't jump directly to those places. Instead, struggle for about five minutes with whatever that problem is, trying to solve it on your own. Try to find the root cause for that problem. Now, if you've never done this before, if you have never solved problems without Googling them first, this is going to feel a little bit uncomfortable. And you're going to probably experience a little bit of imposter syndrome. When you go and read source code of the favorite tools that you use each and every day, and you can't understand half of it, that is a very normal scenario to find yourself in. Don't be discouraged. Keep on learning by subjecting yourself to hard problems. Now, once you've done this for two or three weeks, I'd love to hear from you. I'd love to hear the types of experiences that you've had that were enlightening, and perhaps the things that you didn't expect to learn that you ended up learning. I would love to hear those stories. You can email me at developert.gmail.com. Of course, you can reach out on Twitter as well at Developer Tea. Thanks so much for listening to today's episode of Developer Tea. I appreciate each and every moment that you spend with me here on the show. I don't take you for granted. The audience is what makes this show what it is. So thank you so much for listening to this episode. If you or someone you know is looking for a job as a designer or a developer, go and check out today's sponsor, hired.com. Incredible opportunities from over 2,500 companies offering salary and equity, both contract and full time, just so many opportunities there. Make sure you use the special link hired.com slash Developer Tea, which will actually double your signing bonus if you do end up getting a job through hired. And don't forget that hired also gives out a referral bonus if you refer somebody else. So refer them to hire.com slash Developer Tea. Thank you so much for listening to today's episode. And until next time, enjoy your tea.