I hear and I forget. I see and I remember I do and I understand. Although the origin of this quote is somewhat unknown, it's a Chinese proverb but most of the sources citing that come from the 1960s. The underlying concept of this quote is still very strong. That's what we're going to be talking about in today's episode. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on this show is to help you become a better developer. You may be listening to this and you're not a software developer. You don't write code. You don't do maybe anything with computers. Although fewer and fewer people fit that category as the years wear on and as technology continues to imbue our lives and even if you're a software developer, you may not see yourself as a software developer. The title of developer is very much so incomplete for most people who work in this job. Tons of people own businesses and also develop software. Tons of people who listen to the show are also designers who work with software. Perhaps you are indeed writing code in your day-to-day work. And code continues to become more and more important. So as people start listening to this podcast in those varying categories, I want to make sure that we're avoiding mislabeling developers. I want to make sure that we're avoiding perpetuating a sense of fear, perpetuating a sense of imposter syndrome. We've talked about imposter syndrome in the past. But part of the way that we do this is by not trying to get into extremely technical details in a short podcast. And that's one of the reasons why we focus on larger, more applicable topics that span basically your entire life. You can listen to this episode in five years from now and hopefully it will still be applicable to what you do. So we are afraid to talk about specific technology. We aren't avoiding those conversations, but a lot of the time the better value that you can get out of this podcast is going to be when we talk about things like what we're talking about today. Today's episode is focused on learning. In a recent episode, we talked about a concept called spiral learning. I'd recommend you go back and listen to that episode again because today's episode is very similar. But I want to talk to you about the same concept of reiterating a topic and how you can practically approach learning from the perspective of iteration. You know, as developers, most of us understand this concept relatively well, that as we work on a project, we create new iterations of code. This is why version control is so important. We can go back and see specific decision points when we iterated on a concept. Perhaps when we iterated on an algorithm or quite simply when we iterated on a design or even created a new iteration simply for the sake of clarity. Maybe you named a variable a new name that made more sense and that was the newest iteration of that software. So this concept of iteration is something that developers are constantly working in. And I want to take this perception of iteration and apply it to how we learn. So often we think about learning in terms of applying ourselves enough to learn a subject and then moving on. We learn how to write a particular language. And then we feel like, well, we've learned it. We know that language now. Right. So we can put it on our resume. This is such a broken perspective of the learning process. Now, don't hear me wrong here. There is a minimum to where you can say that you are able to practice something. Right. There are points at which you surpass a certain amount of practical knowledge such that you can say you can use this particular thing, whether it's a technology or something totally unrelated to computer science, you can use this thing in your day-to-day work or perhaps to accomplish a particular solution to a problem. So I don't want to downplay the idea that you do need a minimum amount of knowledge for a particular in this scenario, a particular language to be useful to you in your work. But what I do want to suggest to you is that learning through iteration means that you're going to revisit a subject and refine your knowledge on that subject many times into the future. So if you start the learning process, if you are learning something, you're actually applying yourself to learn something new on purpose, then it makes sense during that learning process to begin with a intentional effort of iteration. And in today's episode, we're going to discuss a practical way that you can do that. But first, I want to talk about today's sponsor code ship. Code ship allows you to ship your code with more confidence. If you are a responsible developer, then hopefully you are testing your code. Now this means that you're testing it both by verifying with your own two eyes that the things that you're building are working, but also you're writing tests, you're writing programmatic tests. And these tests can run and tell you how your software is performing. You're running the code against that software. And the value of these tests is to increase your confidence that the code that you wrote is going to work and that the new code that you added to an existing system is not going to break old code. Right. That's that's the value of these tests. But you can extend the value of your tests by using code ship. Code ship is a continuous integration service. It allows you to run those tests not only on your local machine, but in a hosted testing environment. What does this mean? If you're using something like GitHub, you can push your code to GitHub. Code ship will automatically see that you pushed it to GitHub. It'll pull that code and it'll run your tests for you. And it can act as a gateway to prevent bag code from ending up on your production or on your staging servers. Right. So this allows you to push code with confidence because you know your tests are going to run and you know that your code is not going to make it into production or into staging without actually passing all of those tests. A coachhip comes in two flavors, basic and pro. Basic is going to work for most people. Every project I use coachhip on, I'm using basic. And this is easy to set up. Get a set up in just a few minutes and integrate and get started today. You get a hundred free builds on both basic and pro. Pro is for people who have much more customized environments. For example, if you develop using something like Docker, you can ensure parity between your testing server and your actual production server using code chip pro. Once again, a hundred free builds on both versions, unlimited users, unlimited number of projects. And of course, code ship is always free to open source project. So if you want to maintain an open source project, you can use code ship unlimited, totally free. Go and check it out, spec.fm slash code ship. Thank you so much to coachhip for sponsoring today's episode of Developer Tea. So we're talking about this concept of iterative learning. We've discussed very similar things in past episodes, specifically I discussed some of these concepts with colla desaude in our first interview. I've actually interviewed collaude twice. He's actually the only person who I've interviewed twice on this podcast. Some of the discussions that we had with collaude about progressive learning, basically providing an overview of the subject rather than trying to go through and learn everything master everything the first time you encountered it. This is also very similar to spiral learning, right? The idea is that you don't need to master something before you move on to a new subject. Now this feels very strange and it may feel foreign to you because by the time that you've moved on, you may not feel like you've actually grasped the things that you've been told, the things you've been taught, the things you've been reading or the lectures you may be watching. You may not feel like you have a total grasp on those subjects, but because you're going to revisit those subjects again, you don't need a grasp on those subjects to an expert level yet. So we're going to discuss how you can architect your iterations in the learning process to allow you to effectively intentionally iterate on your learning, right? We want to do away with this idea that you need to master every single subject you encounter along the way, and instead we want to become better at the whole level, right? We want to we want to create an understanding that is fundamental of how everything fits together and that's where things start. Some of this is going to be something that you have to figure out about yourself. Learning is a personal thing, but there is some study, some research that has been done to say that most of us learn in very similar ways and most of us can benefit from learning in multiple ways. In other words, the idea that each person has a different learning style is somewhat flawed, even though you may like learning in a particular way, your brain actually learns very similarly to most other people. And this concept allows us to approach learning from a multi-dimensional perspective, and that's how we get these iterations in place. So I'm going to present to you my iterative learning process. This is how I try to approach learning a given subject. First, I want to look at a roadmap. I want to see the overarching lay of the land, the schedule of commitment that I'm embarking on. How big of a subject is it that I'm looking at trying to learn? What are the different areas? What are the pieces of the puzzle? Now, I'm not looking at specifics into those pieces. In other words, I'm not really looking at a diagram necessarily. I'm looking more for terminology. I'm looking for larger scale concepts that define how large the subject is. This gives me a basic vocabulary. It gives me kind of a roadmap, if you will, and maybe not even a roadmap, but more like landmarks. We get a general idea of the landscape of a given subject. And that gives us some more basic concepts, some more basic language, to put into our brains and kind of anchors that we can come back to at a later date. And this is the first iteration. It's a very large overview to get an idea of the types of vocabulary, the subsections, if you will. One layer deep is all we're going here. The second thing I like to do is figure out how other people typically approach learning these subjects. For example, finding particular literature that has been really important in that particular field, looking for people who have influenced the subject of learning, looking for products that are involved in that particular subject, especially when we're talking about code, looking at the culture surrounding it. These are always of getting a better idea of how people treat the subject. Where can I find this subject in practice? Where is it actually being used? Who knows about this subject already? Then the next thing I'm going to do is I'm going to start looking for imagery. And quite literally, I do mean Google search, image search on Google. And I learned this trick from Caledizad. But I had been doing something similar before I talked to Calediz. Well, and this idea is to figure out how are things fitting together? You know, if you have a very complex software project, sometimes the best way to understand how everything fits together is to draw out a visual mapping of how things fit together. This gives you a spatial dimension to the mental models that you have in your mind. Part of the reason this is important is quite simply because of the way your memory works. You're going to be much more efficient at memorizing or really putting this information in your brain for later recall is all we're talking about when we say memorizing. You're going to have active information available if you can create some kind of spatial mapping, some way of visualizing and quite literally putting a visual reference in front of you or building your own visual reference to understand how different parts of this subject map together. During this process, what you'll probably notice is that you're going to be trying to come up with metaphors. You're going to try to figure out what does this kind of look like? What does this diagram remind me of? What are other things that I can compare to this diagram? And that really is another step in this process. Trying to figure out a way of connecting what you're seeing, this new information that you're seeing, this is something that you already understand. This gives you a metaphorical point of reference and it also allows you to define differences between the thing that you already understand and the new thing that you're trying to understand. This is why learning your second or your third or your fourth programming language greatly increases the value of what you already know about the other programming languages that you've learned beforehand. So now you've created some terminology even though you haven't filled in all of the gaps of what that set of vocabulary actually represents. You have the terminology in your brain. You can go back and fill in those gaps later. You've created these metaphors. You've started to understand how people are interacting around this subject space. You've given yourself an overview of how more specific parts are fitting together in the space. This is more like a roadmap. We discussed the landmark map before. Then you get a roadmap, which is kind of like a zoomed in perspective on a particular subject that you're trying to learn. And then you've created this metaphorical model trying to understand what is this thing kind of like that I already understand. The next step in this process would be to look at an example of iteration from someone else. Somebody who has actually done something with this knowledge before. If this is a math problem, then look at an example of someone who had gone through and solved that math problem. And once again, this is going to leave gaps because you may not have gained intuition for how or why they solve that problem that particular way. But this is creating some anchors in your mind. This is what it looks like for this problem to be solved. And then you can work through understanding intuition by doing your own problem sets. That would be the next iteration. But before we get there, I want you to think small. We talked about this so many times on this podcast. But the very next step that you want to take is to take the smallest version that covers the largest amount of space. Let me say that again, you want to take the smallest problem set, the smallest iterable problem that you can solve with whatever this new knowledge set is that you're trying to gain. Take the smallest version of that problem that covers as much of the knowledge areas on that landmark map that we discussed earlier. Try to solve that problem. Now, if you have a teacher, have them guide you and coach you through solving that very small, that very small problem. As you're going through the problem solving process, you'll notice a few things. One, your coach or your teacher hopefully will be guiding you through common misconceptions or common issues that you are running into. And it's possible that if you're not being coached or taught, you're going to have to self-coach or self-teach. And if you see yourself running into the same problems or the same pitfalls every time, then you may end up having to look for those common problems. Do some research about what common problems are. This is not a bad idea at this stage to look that kind of stuff up anyway. What are the common pitfalls beginners make when learning JavaScript, for example? And understanding some of these common problems is like dark spots on that landmark map. Are the areas that you want to avoid or areas that you want to be aware of that many people end up getting trapped in? Something that a lot of people don't do that I highly recommend and I can't recommend it enough is figuring out where you personally are deficient. This is very different from looking up what common problems are. And it's also very different from just taking notes. If you're in a classroom environment, for example, taking notes off of a slide, this may not identify areas where you personally are deficient. And this is something that I find incredibly valuable to me. I try to take notes in places where I feel specifically deficient. Oftentimes these notes occur in some kind of diagram format. I'll draw the way that things fit together. And if I can't visualize the way something fits together, that shows me those dark spots on the map. That shows me areas where I need to go and do some extra studying, some extra work to figure out what that area looks like to uncover my lack of knowledge or remedy the deficiency in my knowledge so that when that area is referenced again, I have a clearer picture of how it fits in. So at this stage, you're solving small problems, you're taking notes, you're reviewing, you're hopefully getting some coaching, you're reviewing yourself, you're looking for your own personal deficiencies, solving small problems over and over and over, new problems that cover areas of the problem set that you haven't maybe haven't covered yet, solving problems that may put you in that position of a common pitfall so that you can learn how to avoid those pitfalls. And the next iteration may surprise you a little bit. What we've been doing now is we've been creating more and more resolution. We iterate over the same information over and over and creating more and more resolution around that information, understanding the shape, the color, metaphorically just getting a better picture of what's going on in this knowledge. So the next iteration step is to actually turn around and teach other people this. What you're going to recognize is that by teaching, you will fill in even more areas where your knowledge is lacking. You're going to uncover the way that other people learn by trying to teach. And what this ultimately means is that people are going to ask questions that maybe you haven't asked but should have. You're going to anticipate new questions that you didn't ask for yourself, but that you should have. Relaying information that you have learned is one of the best ways to iterate over that information. Once you've done this, you can start back at the very beginning of this chain and reiterate all of those steps. When you take a look at that landmark map again, you have a better picture of what's going on on iteration two and on iteration three and on iteration four. And you're going to refine your knowledge and create higher resolution information in your brain each and every time you go through these iteration steps. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Co-Chip for sponsoring today's episode. And for helping developers all over the world ship their code with more confidence. You can get started with Co-Chip for free by going to spec.fm slash Co-Chip. Thank you again for listening. Make sure you subscribe if you don't want to miss out on future episodes of Developer Tea. You can do that in any podcasting app you use. You can also send me questions at developertea@gmail.com. You can find me on Twitter at add Developer Tea and at jcutrell. And until next time, enjoy your tea.