Today, we discuss the place of formalization and theory, and how we should be starting from the position of discovery rather than trying to fit every problem to a pre-existing theoretical formula. Today's sponsor is Codeship, a hosted continuous integration platform. Get started today at Codeship.com, and use the code developertea for 20% off any plan when you choose the premium plan!
Today, we discuss the place of formalization and theory, and how we should be starting from the position of discovery rather than trying to fit every problem to a pre-existing theoretical formula.
Today's sponsor is Codeship, a hosted continuous integration platform. Get started today at Codeship.com, and use the code developertea for 20% off any plan when you choose the premium plan!
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell 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. And 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... 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. This is how addition works. If you want 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, Codeship. Codeship 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. Codeship supports your GitHub and Bitbucket projects, and you can also use it to automate your code solutions. and you can get started with their free plan today at Codeship.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 DEVELOPERT. Now that code will be in the show notes, so go to Codeship.com and use the code DEVELOPERT for 20% off today. For fast, secure, and customizable continuous integration, go to Codeship.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 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 way 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 solve a problem. in order to solve a problem. You might not be able to see in your solution 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 at Developer Tea on Twitter or developertea at gmail.com. Don't forget that Developer Tea is in the running for the 16th of May. Thank you so much for listening to the show. And until next time, enjoy your tea.