Have you ever felt like you've had to plan everything before beginning to write your code? In today's episode, I talk about the disposability of our computing resources, code testing tips, and how to intermingle coding with planning.
Thanks to today's sponsor: Digital Ocean
Today's episode is presented by DigitalOcean. Go to https://digitalocean.com to get started, and use the promo code "DEVELOPER TEA" at the checkout after you create your account to get a $10 credit!
I hope you've enjoyed this episode. Until next time,
Enjoy your tea.
Transcript (Generated by OpenAI Whisper)
Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking to you about the disposability of our computing resources. Have you ever felt like you weren't allowed to write some code because you hadn't planned it properly or because you hadn't explored all the options available to you before you started writing that code? This is something that can hold us back. If we think that we have to plan everything before we start writing code, then we forget that writing code is a process. One of my favorite celebrities, his name is Adam Savage. He probably wouldn't consider himself a celebrity or maybe if he does, then he doesn't really like calling himself that. But in any case, Adam says that when you are learning to be a maker or somebody who is crafting with a lot of materials, you first must be ready to fail the first time. In other words, the very first time you're going to create something, go ahead and prepare yourself for failure. In fact, plan on it. The reason you need to plan on it is because in Adams or at least you have to plan to have extra materials because some of the materials you use are going to be ruined by the initial failures. You're going to carve something wrong or you're going to put something together or melt it because you're applying too much heat. You're going to put something together wrong. Any number of things can cause these materials to be expended and so you need to plan for those extra materials. Now, the same is true about failure for computer science, for programming. If you're trying to solve a problem, if you're trying to build something that's never been built before, out of the raw materials of code, out of the raw zeros and ones and memory structures, and out of the raw pieces of a programming language, prepare yourself to fail. Prepare yourself to fail. Now, this also means that you need to come with an abundance of resources. But one of the great things about being a programmer is that these resources are much easier to get. In fact, all of our computers have these resources pretty much available at our fingertips. The thing is, we have an adversity to using them like they can be used. For example, when I'm testing a Rails application, I can spin up a database and create hundreds, if not thousands of records, in order to test my code with something like factory girl, for example. If you don't know what these things are, basically Rails allows you to test your database interactions by actually performing those database interactions on a test database. Some people don't like doing this. It feels weird. It feels like they're going to corrupt the database, or otherwise they're going to make a mistake. They're going to use up the resources of their computer, but that's just not true. With modern computers, there's no reason for us to not create new files before we have a perfect plan laid out. It's not the same as a world where those resources are limited. We don't have to plan in the same way that somebody, carving leather has to plan. We don't have to bring extra resources with us because our computers already have that extra space. They already have those extra resources. So I'm encouraging you in this episode to start coding earlier. Start coding earlier in the process of planning. Your code will be an exploratory experimental process if you do it this way. Now you might be thinking, how can I have exploratory or experimental code living alongside a project that is already well established, already working? I'm going to answer that question as soon as I get back from this quick sponsor break. Today's episode of Developer Tea is sponsored by DigitalOcean. DigitalOcean is simple cloud hosting built for developers. They're dedicated to offering the most intuitive and easy way to spin up a cloud server. And in just 55 seconds, you can deploy a solid state drive cloud server. Plan start at only $5 per month for 512 megabytes of RAM, a 20 gigabyte solid state drive, one CPU, and a full terabyte of transfer. In addition to offering simple and affordable SSD cloud hosting, DigitalOcean is dedicated to building out a strong community and supports open source software. They offer a vast collection of hosting tutorials and invite Developer To submit articles and they pay $50 per published piece. Deploy your SSD cloud server with DigitalOcean today by going to digitalocean.com. Now DigitalOcean has been kind enough to provide Developer Tealisteners a discount of $10 when you use the code Developer Tea. So go to digitalocean.com and use the code Developer Teato get $10 off today and you'll get up and running with your own SSD cloud server in just 55 seconds. That's digitalocean.com. I've been talking a bit about the abundance of computing resources that we have at our fingertips and the importance of starting to work with actual code and even real data as early as possible so that your planning process is intermingled a bit with your coding process. Now this can pose problems because if you already have a stable platform and you start coding before you have a exact plan or an exact structure for that code you might introduce bugs that you're not aware of. So how do you protect yourself against this? Well it's very simple. You write tests. You write tests for everything that needs to be tested and that needs to work in the future and then you run those tests throughout the process of experimentation. This means that if your experiments break something the tests that you wrote last week or last month those tests should fail. So you need to write good tests but make sure you're writing tests and that will catch and prevent errors from creeping into your code after the fact. This is what is called regression testing. It basically tests your old code when you add new code that could break that old code. Having good test coverage means having regression tests and having regression tests means that you can experiment with your code earlier in the process which means you can learn faster and get past the failure state much quicker and much more efficiently. So to avoid having anxiety about creating new classes or creating new files or creating a test database or duplicating things over and over on your computer you need to have regression tests in place that protect you from breaking old code and from introducing new bugs that you aren't aware that you are introducing. Thanks so much for listening to today's episode of Developer Tea. I hope it encourages you to start coding a little bit earlier because we have all of these resources that are available to us. Speaking of resources, check out Digital Ocean today's sponsor. They provide a very fast and easy way to get up and running with a Cloud SSD. Just 55 seconds and if you use the code Developer Tea today you can get $10 off. So go check that out. All the links will be in the show notes. Thank you again for listening to today's episode and until next time, enjoy your tea.