« All Episodes

Feedback Loops - The Smallest Unit of Learning

Published 5/3/2017

In today's episode, we talk about the importance of feedback loops.

Today's episode is brought to you by Linode. Linode Provides superfast SSD based Linux servers in the cloud starting at $10 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners .

Transcript (Generated by OpenAI Whisper)
What is the most basic unit of learning? I want you to think about this for a second. How do we go about learning? At its most basic fundamental form. Our brain gathering new information and applying that, memorizing it in some applicable way. We've said on a recent episode that learning is really about memorizing information to be able to use it in a meaningful way later. We're going to talk a little bit about how we can apply this concept of what learning is and understand the most basic form of learning, the most basic unit of learning. And then what we can do about it in our work each and every day. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to coach you through some of the hardest parts of your career, give you encouragement and point you towards the way to level up as a developer. As always, we're talking about another topic that we have discussed over and over and over on Developer Tea. And that's because this isn't going to go away. This stuff is the same stuff that we've talked about in the past because these topics are so deep. And they're going to continue to grow as the industry grows, but also as culture grows, as people grow. These topics are only going to become more and more relevant, which is why I chose to talk about these things in the very beginning of Developer Tea. And we're talking about learning. This is a basic topic that is never going to be covered enough. And we'll talk about how this actually is true in another episode, perhaps, but understand that learning is not only the formal pursuit of learning. We aren't just talking about saying, oh, I'm going to dedicate some time this morning to learning something. Each and every day, every action you perform, every client you work for, every line of code you write, every email you write, every person you interact with, there is something to learn. Now, you shouldn't feel self-conscious. If you aren't always aware of this, it would be incredibly hard to walk into every single experience that you ever have with the intention of learning. That's not what we're hoping for here, because that would be absolutely mentally draining, wouldn't it? And it would also seem a little bit insincere. If every single time you have a discussion with a friend or your spouse, if you are looking to see what you can learn from that, that may compromise your ability to, for example, practice empathy. And the strange thing is, we can still learn, even though we're not intentionally endeavoring to learn. And that's kind of what we're talking about today. We're talking about one system that we can really set up as a value. It's really a value that I want you to hold. It's kind of a heuristic that you can set up for every single situation that you're in. It doesn't matter if it's something where you are intentionally practicing, intentionally trying to learn. Or if you're actually just going about your normal everyday actions in a scenario where you could learn something. So let's talk about that basic unit of learning that we discussed in the intro. What is the most basic unit of learning? And you all know that I have a child on the way. Liam will be born hopefully in June and perhaps in July, depending on when he decides to come. But he's going to be born in June. And I know that the first couple of years he's going to be learning a whole lot. And the more I look into childhood education and the learning patterns that children follow, the more I realize that we as adults should really probably model some of our learning after children. Children learn a massive amount in a very short amount of time. Now as we've discussed in previous episodes, some of this is due to the fact that a child's mind doesn't have the bias of a bunch of experience like adults do. You would think that our massive amount of experience would make us better at learning. But as it turns out, the more times you encounter a given scenario, the more likely you are to make assumptions that may or may not be true about that scenario. We develop biases over time and it makes it a little bit more difficult for us to learn at the same rate that a child learns that. And this also makes sense from an evolutionary or instinctive perspective. Once a child has learned enough to survive, any learning beyond that is beyond our primitive brain. We don't have to learn more than is necessary to survive as far as our primitive caveman is concerned. So what can we learn though from the learning patterns of children? So first of all, the most basic form of learning, the most basic unit of learning is quite simply try observe and repeat. This is the scientific method boiled down into a very simple three word phrase, try learn repeat or try observe repeat rather. This is something that we can do over and over and over. And when we take our observations and feed them back into this loop, that's what we call practice. We practice by learning with the intention of getting better so we modify our trials. And this is a very simple concept but it's one that is fundamental to our success. I'm going to take a quick sponsor break then we're going to come back and talk about how this loop, how we can make it more effective, very simple value that I want to give you today. We're going to talk about how we can make that loop more effective today's episode is sponsored by Linode. If you are a new web developer, especially, then Linode is going to support your learning efforts. But this is true. If you are a seasoned web developer as well, that's because Linode is going to be able to scale with you. Linode is incredibly capable as a platform. You can get started on Linode for $5 a month. And for that $5 a month plan, you get a gigabyte of RAM on your server. These servers are running Linux, so pretty much anything you can imagine building, they're going to support you. You get root access on a Linux server for $5 a month. I can't imagine a better playground or a better laboratory for you to experiment and learn from than this kind of thing. Linode offering you a gigabyte of RAM for $5. There's very little that you're going to do, especially when you're first learning that's going to take more than a gigabyte. But if you do need more than a gigabyte, as it turns out, Linode is offering you a two gigabyte plan for $10. This basically beats every competitor in the space at this price point, two gigs of RAM for $10. And you can get 16 gigs of RAM for $60. So you're going to be able to scale pretty much anything that you can imagine needing on Linode. They have native SSD storage as well. So it's not just the RAM, but also the storage. They have a 40 gigabyte internal network and it runs on top of Intel E5 processors. They have a seven day money back guarantee. And on top of all this, they are offering you $20 worth of credit when you use the code Developer Tea2017 that's Developer Teaall one word, 2017. Go and check out what they have to offer at linode.com slash Developer Tea. Now to put that in perspective, you're going to get a gigabyte server that you have a root access to that's in the cloud that you can point a domain to you can point multiple domains to. You're going to get that for $40 for a whole year. So go and check it out linode.com slash Developer Tea. Thank you again to linode for sponsoring today's episode of Developer Tea. We're talking about learning. We left off discussing this fundamental basic unit of learning the try observe and repeat try observe repeat. And the way that we learn is understanding what the modifications to our input do. Once again, this is a scientific method. When we observe, we take some notes, we figure out what what the results were of our trials. And then we modify the things that we're doing in the trial phase, we observe again, and then we repeat as we've already identified this really looks like practice, the repetitive motion of trying and modifying the things that we're trying and seeing how that changes the outcome. That is practice at its fundamental level, but something that a lot of people get wrong and this is this is the value that I want you to walk away with today, something that a lot of people get wrong is that they make the loop too big. They make the loop too big. The feedback loop is what we're talking about here, the loop between trial observing and retrying. They do too many things. They make the loop so large that they're not even sure what they're observing anymore. Perhaps some other variables enter into the scene, something makes that that feedback loop noisy. We've talked about feedback before on the show, but we're going to talk about it again because feedback is fundamental to so many things that we do as developers. It's fundamental to communication, but it's also fundamental to this learning process because you have to have a feedback loop in your learning. A good feedback loop has a high signal to noise ratio. You understand this concept if you've ever worked with analog signals. A high signal to noise ratio means that what you're hearing is not static. What you're hearing is coming from the source that you intend to listen to. If you turn up a radio and the static is very high on it, that static isn't just coming from nowhere. It's coming from other sources, even though you have the radio tuned to a specific source, other sources are interfering. The same can happen in your learning, in your feedback loops, in your learning process. Very simple example. This is an example that you can take and practically apply in your coding each and every day when you make multiple changes in your code and you don't test between those changes, whether that's a manual test or maybe you are running your tests in some sort of programmatic environment, but you aren't testing and you're making multiple changes before you test. What you've done is set yourself up for a high noise ratio. In other words, if one of those changes caused a problem or if one of those changes caused a large variation or if one of those changes was never necessary in the first place, it will be difficult for you to track down which change it is. And here's the interesting thing. It's going to be as difficult as the loop is large. Let me say that again. The number of things that you do between reiterating the number of changes that you make before testing, the number of things that you input before checking the output. The higher that number is, the more complex, the more difficult it will be to determine where a problem originated. On the flip side, if you are doing one thing at a time, if you're keeping that loop incredibly short, if you're making your feedback loop very quick, then you're going to see the change that you just made and the immediate effects of the change that you just made. And you're greatly increasing your ability to connect the cause and the effect. You're greatly increasing the resolution of your learning. You're greatly increasing the resolution of that feedback loop. Your signal to noise ratio is very high if your feedback loop is short. It would be like living right next to the radio tower. The closer you are to the source of the information, the closer the shorter that loop is, the less likelihood there is for interference. It's a very simple principle. And I want you to take this forward and use it in every scenario that you could possibly learn in, gain feedback as early as possible, reiterate as many times as possible. This means that the tools that you can invest in that will make this loop shorter. Those tools are going to pay you back more in the long run. When you are developing locally and you have the opportunity to do continuous integration at the single code line level, in other words, every single time you change a line of code, you get immediate feedback of the effects of that line of code change for front end developers for front end web developers. This means things like live reload. These are so valuable because you get immediate feedback. Because you get immediate feedback on every single change that you make. This feedback loop being extremely small gives you immediate and causal connection to the change that you made and what it did. These are the kinds of tools that I want you to invest in. This is investing not only in quality, right? It's not only investing in tools that are going to increase the quality of your code simply because you're testing more often, but it's also going to be investing in your learning. You're going to get faster feedback. You're going to get connection to the things that you're doing and the outcomes that those things have. Thank you so much for listening to today's episode of Developer Tea. I hope you'll take this information and apply it as soon as you can. There's absolutely no reason for you to make your feedback loops any longer than they need to be. If you can automate the shortening of your feedback loops, you're going to see so much value generated out of that. Thank you so much for listening to today's episode. Thank you again to today's sponsor, Linode. You can get started with a Linode server for $5 a month. For those months for free, basically, for being a Developer Tealistener, head over to linode.com slash Developer Tea, use the code Developer Tea 2017 that's developed T2017 at checkout for $20 worth of credit. Thank you again to Linode for sponsoring Developer Tea. Thank you for listening. Make sure you subscribe if you don't want to miss out on future episodes. Until next time, enjoy your tea.