15: Let’s Program A Game! Part 3.

So far our game doesn’t do much and we’re going to fix that. The most important thing for you to realize is that when you’re programming, you’re not going to write your final code at the very beginning. I know, I’ve said this before, but I don’t think I can say this enough. Programming is a journey. The main message in this episode is how you can skip over many details when programming and focus first on the bigger picture. Then you can elaborate a bit more on some other part. You don’t have to do any of this in order. So even though programming is a journey, it’s unlike any journey in the physical world. It’s extremely powerful and allows you to try things without fully committing to complete them. Listen to the full episode or read the full transcript below. Transcript So far our game doesn’t do much and we’re going to fix that. The most important thing for you to realize is that when you’re programming, you’re not going to write your final code at the very beginning. I know, I’ve said this before, but I don’t think I can say this enough. Programming is a journey. The next step of this journey is to change the winning message only when a word is guessed correctly. But isn’t that the whole point of the game? It is, yes, but we don’t have to fill in all the steps at once. A physical journey has a definite starting and hopefully a definite destination. You may or may not know how to get to your destination. You have to just start taking steps. Once you’ve taken a step though, it’s done. You can’t change history. Sure you can undo that step by going back but really that’s just another step. If you keep a log of all your steps, it will show that you went one direction and then back again. A programming journey is different. And the steps you take don’t have to all be in order. Imagine being able to take a physical journey where your first step takes you all the way to your destination. You just have no idea how you got there. It gives you the chance to try out the destination and see if you really like it or not. Try that with a road trip. You get to avoid all the bumps, all the crazy drivers, and all the questionable motels and go right to your vacation spot. You can’t do everything on your vacation yet. But you do get to see for yourself if the destination is worth it. Then on a programming journey, you don’t go back to the beginning and say, “Okay, it’s worth it. Let’s go now.” Your second programming journey takes you somewhere to the middle of your journey. Because you might find that right there in the middle is a huge stretch of road that’s still under construction. If you don’t like it, you get to change it. Your log will still show that you went there. But you were able to jump right to the middle, look around, and jump to a completely different middle spot instead if you want. You’re able to effectively rewrite history now. That’s powerful. You can rewrite that history because it never actually happened. It was a potential history based on your initial middle jump. The middle jump happened. But all the individual steps that you would’ve had to take on a physical journey never happened and get to be erased from existence. Let’s say you like your second middle spot better than the first. You could if you want try a third middle spot. Hey you could always come back. These are all single jumps but they set the direction for all the steps you’re going to eventually need to take to get you there. Picking good intermediate destinations is a good way to try things out before actually committing to a specific course. Once you finally find your best middle spot, you’re not done. Why not repeat this process? I mean if it worked good to get you to the best middle, then how about using the same technique to find the bes