How can a experienced developer mess up the fundamentals? And should we really be embarrassed by this? We're going to be talking about this on today's episode of Developer Tea. My name is Jonathan Cutrell. My goal on this show is to help you become a better developer through coaching, through discussing ideas like today's episode. We're discussing an idea from a scientist and teacher named Jon Dinker. I'm hoping I'm saying his name right. Jon Dinker, I happen to stumble across some of his physics publications. He has a website called aviation.com that's av8n.com. You can go and check out some of the stuff about. He's published some stuff about flying and specifically about physics. There's about a hundred articles on here. And the one we're talking about today is called the spiral approach to thinking and learning. So we asked this question in the beginning of the episode. Is it okay or is it shameful for a season developer, someone who's been doing this 5, 10, 15, even 20 years to screw up what we would consider a fundamental practice. For example, launching an app with bugs in it or without testing or perhaps creating bad names for their classes or variables. And another question for a beginner developer, does it make sense to keep them away from the complicated subjects and really kind of wall them in in the easier things, only give them easier tasks? The answer to both of these questions in a practical sense is no. We shouldn't be embarrassed by humans making mistakes of any kind necessarily. It is seemingly more embarrassing for a developer to go against something that they presumably have known for a very long time. But the truth is we are practicing all of our skills as developers all the time. And this is where spiral thinking and spiral learning come into play. We're going to talk about spiral thinking and learning in just a moment right after we talk about today's fantastic sponsor, Coachhip, if you are a developer and you are in this stage of going past the fundamentals, then hopefully you have heard from one person or another that having tests in your applications is a good idea. Not only is it a good idea, it's almost required for any production application that is continuing development. In other words, it's not something that you just built over the weekend and you're never going to touch again. It's something that a client wants you to continue building on and in order to keep that application from becoming a stringy mess of bag code, then you're probably writing tests. But most developers who are writing tests likely are not getting everything they could get out of those tests. Coachhip is going to help you get the most out of your testing efforts. And they're going to do this by only allowing code that passes tests to be shipped to production. There's such a simple concept and yet it's incredibly powerful. It's called continuous integration and it's going to protect you from shipping bugs into production. It's going to protect you from losing money, losing users. That's what Coachhip does. Now it comes in two formats, the basic format, which is going to work for most applications. You can get it installed, configured and launched in just a few minutes. And then the pro version of Coachhip, which is 100% compatible with Docker and Kubernetes. If you're using something like that, then you may want to check out Coachhip Pro. Coachhip is always free for open source projects. So if you have an open source project, you can go and find out all of the things that Coachhip is going to provide for you. And then you can bring it over into your private projects as well. Coachhip was recently redesigned based on feedback from thousands of users. And you can get started for free in the free tier on both Coachhip Pro and Coachhip Basic. These free tiers allow you to do 100 builds per month. You have unlimited projects and unlimited people. Go and check out what Coachhip has to offer to developer to listeners by going to spec.fm slash Coachhip. That's spec.fm slash Coachhip. Thank you again to Coachhip for sponsoring today's episode of Developer Tea. So we're talking about the fact that even as season developers and even as advanced, you know, very capable developers, we very often see very simple mistakes. Of course, this is part of the human nature. We make mistakes. We have oversights of things that we've experienced multiple times. We quote should be able to handle those problems and not make those mistakes. And yet we do see this all the time. This is one of the reasons we do have things like tests and our applications to keep us from making what we consider to be dumb mistakes. But the way your mind works is very different from what we've been taught. We're taught to think that we master a single concept, like for example, variable naming, and then we master the next concept, or perhaps we're mastering two or three concepts at once. But certainly a season developer should have mastered variable naming a long time ago. They should have mastered how to write a test a long time ago. They should have mastered even very simple things like syntax a long time ago. But the truth about learning is very different from this. The truth about learning is that you are going to re-experience and rebuild new connections with the things you've learned every time you practice. Think about this for a second. Every time you sit down to write code, you're going to build new connections in your brain of how that code is applied, how that particular skill in developing code is applied. What Jon Dinker is proposing is this concept of spiral learning. You start on a spiral and you get exposure to multiple ideas. As you're going around the spiral, you'll revisit ideas that you've already been exposed to in the past. You continuously come back around that spiral. You're going to re-expose yourself to those ideas. Why is this important? Why would this be an effective way to think about learning? If you think about, let's say, for example, model view controller, the application development paradigm of model view controller. If you were to only master the concept of the model, then you're not really mastering the concept of the model because it's only useful when paired with the entire concept. The model is not really useful on its own without some conceptual knowledge of the view. The view is not really useful on its own without some conceptual knowledge of the controller and all three of them work together to create a paradigm. In this sense, it is nearly impossible to actually master one at a time. You can start really wherever you want to and by the end of it, you won't really care where you begin. This is one of the core tenets of the spiral approach that you can jump in very far down the line, a very experienced point that the idea of a prerequisite will make itself known. One of the examples that Jon Dinker uses in his article here is Long Division. If you were to be given the task of doing Long Division before you've mastered the concept of a multiplications table, for example. The numbers 1 through 10, multiplying through the numbers 1 through 10, you will very likely and very quickly notice that you are using the same tasks over and over. You're having to do a look up for the multiplication as you are solving a Long Division problem. It's very likely that you will then realize that there is benefit in learning the multiplication table so that you can solve the Long Division problem a little bit faster. The idea that a beginner can't jump in and the deep end of the pool is really not necessarily true. In the same way that an experienced developer will continue to revisit fundamentals every time they use them, a non-experienced developer can be exposed to information that they will revisit later without much loss. In other words, being exposed to a paradigm of thinking or a tool that you're not able to really use yet is not going to hurt you. It's not going to change the way that you think about it later necessarily. It's going to create one exposure on that spiral trip. You will eventually come back around and be re-exposed to that same tool. But now, all of the things that you've been exposed to on that current trip around the spiral, you get to bring with you. Your creating new connections in this trip around the spiral allows you to revisit and revisit over and over and over. Every time you revisit an idea, you refine your perspective of that idea. You create new connections that you previously couldn't create. Especially you couldn't create if you were to try to master one idea at a time. Thank you so much for listening to today's episode of Developer Tea. Thank you to Jon Dinker. I don't know if he's ever going to hear this, but I certainly appreciate all of the work that he's done on his site about physics and about flying. And tons of really cool information. As a developer, I've found these resources to be incredibly inspiring and very interesting. Good reads. Thank you again. I will include a link in the show notes to Jon's site. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Code Ship. Get the most out of your tests and only ship working code. Only ship your tested code to production. That's what code ship will help you do. Go and check it out, spec.fm slash code ship. Thank you again for listening to today's episode of Developer Tea. And until next time, enjoy your tea.