Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I'm going to be talking about discovering formalities. When you learn to code you learn best when you have something to create. This isn't always true necessarily but typically this is true. The reason for this is because we conceptualize things that we already understand and then we map those things into code. Our code is then a representation of a reality that we already have a concept for a way of understanding that concept outside of our code. For example we understand what addition is without looking at code we can say that 2 plus 2 equals 4 and so if we write code that accomplishes that 2 plus 2 input if it outputs 4 then we can be confident in that code because we already understand addition outside of the code. But if we were to start by trying to understand a formal mathematical proof of addition or let's take something a bit more complex. If we were to try to understand a formal mathematical proof of division or of non real numbers and try to implement that without using our common sense knowledge or our experienced knowledge we would potentially get much more confused than if we were to approach it from the opposite end. If we were to approach it from the perspective that say a child approaches the process of addition. If you show a child a single apple and then you bring a second apple and say this is how addition works they have a more concrete example to understand addition. When we take these ideas and apply them to learning how to code or not even just learning but also how to model our code then we come away with much more intuitive understandings and structures for our code. The same problem occurs when we try to impose a particular design pattern on code that we think is going to work for a particular scenario before we try to solve the real world scenario outside of our code. I'm going to take a quick sponsor break and when I come back I'm going to give you a single rule to follow to make sure that you aren't trying to over formalize your code solutions. Thanks so much to today's sponsor code ship. Coach ship is a hosted continuous delivery service focusing on speed security and customizability. You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed. Coach ship supports your GitHub and Bitbucket projects and you can get started with their free plan today at code ship.com. Should you decide to go with a premium plan you can save 20% off of any plan for the next three months by using the code Developer Tea. Now that code will be in the show notes so go to code ship.com and use the code Developer Tea for 20% off today for fast secure and customizable continuous integration go to code ship.com. We've been talking about formality and over formalizing our solutions and trying to solve things with theory before we have a model external to our code. And this is this is common because this is how we are taught to learn. This is how we are brought up in school learning. We are provided with some kind of theory and then we apply that theory to a given situation and we see the results. We see the applied theory of division and we can actually understand that the outcome of a division problem supports that theory and so it just reinforces the theory in our minds. However, only enforcing theory and trying to impose theory on real life situations is not always the most effective things to arrive at a solution. Don't try to impose a functional programming paradigm or an object oriented programming paradigm just to solve a problem because you think that those paradigms are particularly useful. Instead, solve the problem first and then look at the theory that you used kind of accidentally to solve that problem in other words, use the theory to describe the solutions. Theory is also useful to mitigate future problems that you might not be able to see currently. You might not be able to see in your solution that you've created first. For example, you might use one of many refactoring patterns in order to make your code more future-proof by making it more maintainable. These refactoring patterns have been proven over and over and you can utilize those but those are not your solution. They are a descriptor to a solution. Those are not the only way to get maintainable code. They are a descriptor of ways that other people have made maintainable code. So use theory as a formal descriptor not as a step-by-step process that you should be following at every turn. Don't use theory in order to arrive at your solution. Start at the solution and then use theory to describe your solution and maybe use theory to firm up your solution in places where it could be weak that you aren't necessarily recognizing. Theory is typically well researched so you can use theory to define certain holes in your solution that might cause problems later. Remember that formalized learning and formalized theory are only descriptions of ways that other people have found to write code or to do anything really in an effective way. So if you find another way that doesn't follow a particular theory then your way is still valid. It is still completely valid. If you are solving problems that's all that matters. At the end of the day solving problems is our ultimate job. As web engineers, as software engineers, as designers solving problems is our ultimate job. Thank you so much for listening to Developer Tea. I hope you've enjoyed this episode about formalization and focusing on problem solving. If you have questions or if you have thoughts about this episode you can reach me at www.atDeveloper TeaonTwitter or www.Developer Teaon.com. Don't forget that Developer Tea is in the running for the 16th annual Net Awards in the podcast of the year category. If you want to vote for Developer Teaou can go to bitly. That's bitly.ly slash vote T. V-O-T-E-A all over case. Bitly slash vote T. Thank you so much for listening to the show and until next time, enjoy your tea.