Hello everyone and welcome to Developer Teaepisode 8. My name is Jonathan Cutrell, I'm your host and today we're going to be talking about the hardest things that I've ever do as a programmer. But first I want to say thank you so much. All of you who are listening to the show for making the first week or so of this show just an absolute joy to create. I'm recording these in advance. So this is done probably about a week in advance before it's actually going to be launched. And it's just been a fantastic process from front to back. Everyone who's been commenting and sharing and visiting the site, I'm just elated to be able to share with you in this process. So let's get started. The hardest things that you'll ever do as a programmer. What do you think they are? Immediately as a computer scientist I start thinking well really difficult math problems usually are the most difficult thing that I have to deal with or maybe SQL queries, making SQL queries really fast or writing a clever solution to a problem that needs to be a little bit faster than the previous solution or refactoring someone else's code. All of these things are not easy things to do. Now I'm not talking about what are the hardest things that you'll do in life. This isn't going to be some kind of subjective life lesson. I'm talking about actually encode. What are the most difficult things that you're going to have to do? Phil Carlton famously said and Martin Fowler actually quoted him saying that the hardest things in computer science were cache invalidation and naming things and he's talking about actually naming like variables. This strikes me as odd and actually very accurate and I'll tell you why. Both of these things come down to the simple fact that the hardest things in computer science are actually those things that are subjective. The things that are kind of difficult to trace back to their origin. We have to come up with these names for variables for instance and we're creating them out of nothing and we have to make something that has some sort of meaning but there's not really a concrete objective way to go about creating that variable name. We have to reach into our brains and predict what other people might expect, a particular variable to actually map to, to actually be. This may seem relatively easy to you but ultimately the things that you write in your code, the ways that you name things, this is how other people experience your code. Naming things is so important because if you're working with obscure variable names then that code is very difficult to understand as a human and variables are really actually the connection, the human language that you're using to explain your code to other humans. Obviously hopefully you're writing documentation with your code but variable names are such an important part of our jobs. The other hard part that Phil Carleton said was cache invalidation and the reason for this is because it could very well occur that your code is absolutely 100% correct that all of the algorithms are falling right in line that everything should be working but the cache hasn't been invalidated properly and you either have to go in and manually invalidated or some other process in order to actually get what the code should be producing versus what the cache is actually showing. This isn't intuitive for a scientist, you see the code and you expect the code to output the proper things and invalidating the cache is the only step that's standing between you and actually seeing what should be put out. It's a difficult process, it's kind of frustrating when you realize well all I had to do was kill the cache and everything was working just fine and you might go through hours of debugging just to find out that you were right all along which is a good feeling but you wasted a bunch of time because you just forgot about the cache or because the cache wasn't invalidating properly based on some variable like time or maybe an update hook wasn't running or something silly like that. These are really hard things in programming, they certainly are not the only hard things. So, in the future we're going to be talking a little bit more about difficult parts of being a programmer, what are the things that we do on a day to day basis that make our jobs difficult, the hard parts of our jobs because usually the hard parts are where we can actually grow and where we can become better than the average. Starting on the hard parts of being a developer, if you can get really good at the hard parts, everybody is relatively good at the easy parts but how many people are great at the hard parts. Become great at the hard parts as a developer. The quality of your work and the quality of your life will both go up. Thanks so much for listening to episode 8 of Developer Tea. I'm so thankful for you and for all of the time that you've given me in this podcast. If you have any ideas for me, any suggestions, any thoughts, please let me know. You can get at me on Twitter, at at Developer Teaor you can email me at Developer Tea at gmail.com. Make sure to leave a comment for the community at developertea.com and until next time, enjoy your tea.