Hello everyone and welcome to my Developer Tea. Episode 10, my name is Jonathan Cutrell and I'm the host. And today we're going to be talking about how to approach programmatic problem. It's a bit of a tongue twister but it's something that I think every programmer, every developer is interested in. This actually is prompted by an email that I got from a listener named Kevin. Kevin is a junior CS major and he's wondering if I could discuss this issue of how do I approach a programmatic problem and how do I go from just having an idea to making it a reality. There's a great quote that has been attributed to Charles Kettering. The quote basically says that a problem well stated is a problem half solved. There's a smattering of other quotes that say basically the same thing that if I was given a problem I'd spend 90% of the time defining what the problem actually was and 10% of the time implementing the solution. So for developers I think we should learn from this empirical knowledge about how to solve problems and the very first thing that we have to do to solve a problem is to understand the problem thoroughly. A lot of the time what this means is to inspect the problem in as many ways as possible. So I'm going to give you a few steps about how I'm going to give you a few steps that I usually use to solve any given problem and that starts with that inspection process. So step one is to get out a piece of paper and a pen and draw out your problem. Draw out whatever it is that you're trying to do. A lot of the time this ends up being little shapes that represent the nouns of whatever the problem is so whether that's a model or some other kind of resource, some kind of thing that is a part of your problem. So like a user for example or an account or a file. These are all these different things that could possibly be a part of a problem. You draw out the problem. So how do these things relate to each other, what do they need to do in order to get to the solution point. So when you're drawing this what you're going to quickly realize which is step two of this is that you need to define where you're starting and where you're wanting to end up which if you're paying attention is it sounds a lot like what you want in a function right. So you define your inputs and your outputs. A well-defined function has clear inputs and clear outputs. So if you define your inputs and your outputs while you're drawing on this piece of paper, then you have your inputs on one far section of that paper and your outputs on one far section of the paper opposite of the inputs. And then the stuff in the middle, that's the code that you're going to be writing to take whatever that input is and make it give you the output. So for example you might have a function that takes two sets of latitude and longitude and returns to the distance between the latitude and the longitude in set one and the latitude and longitude in set two. So you have these two points and it's imperative that you find out how to impart the knowledge into your problem solving mechanism so that it can take these otherwise arbitrary inputs and give you a meaningful output. So the final step here is to break down every single small piece between the input and the desired output. This is very procedural thinking. What you're going to want to do is figure out what are the steps of knowledge necessary for me to write into my code so that this function or this particular problem solving method has the necessary information to take the beginning function arguments or whatever it is that this thing already knows about and return to me the thing that I want to know about. So I want you to focus on something that I said there specifically about imparting knowledge into the code that you write. When you write code that translates to points of latitude and longitude into some sort of distance between those two points, you are imparting knowledge into your code that was found by a human that went and figured out how to do this. They went and figured out how do I determine what the distance is between these two points. And those two points, by the way, were created on a map that was also built by humans. And in fact, distance is an arbitrary measure that only humans understand. So all of this computing that you are doing is basically a complex way of saying, I'm going to take something that humans have done in their minds and humans have done through research and I'm going to put it into a computer. I'm going to take this knowledge, this empirically researched knowledge and put it into a computer so that then I can reuse it and share it and make it do other things so I can take more knowledge and stack it on top or so that other people can take more knowledge and stack it on top. And this ultimately is the best form of problem solving and that is how do I figure out what pieces of knowledge the computer needs to transform some kind of input state into the desired output. Thanks so much to Kevin for sending in the question about how I approach programmatic problems. And thank you for listening to episode 10 of Developer Tea. If you're enjoying this show, be sure to drop a review into iTunes. If you have any feedback for me, you can get at me on Twitter at at Developer Tea or you can email me directly at Developer Tea at gmail.com. We also have a website at developertea.com where you can leave comments on each of the episodes including this one. Thank you.