472: What is the skill in software development?

Auto scaling is a simple concept. Automatically add resources when needed and automatically shut them down to avoid paying for excess capacity. How hard could that be? If you've set up auto scaling yourself, you know it's not that easy, especially using the native auto scalers on platforms like AWS and Heroku. That's why you need Judo Scale. Judo Scale is auto scaling as a service, and they make auto scaling simple and easy, as it should be. You can use Judo Scale on AWS, Heroku, Render, fly.io, and more. It's free for low traffic apps and unlimited plans start at $25 per month. Autoscale on easy mode at judoscale.com. Hello, and welcome to another episode of the bike Shed, a weekly podcast from your friends at Thoughtbot about developing great software. I'm Sally Hall. And I'm Joel Kenville. And together, we're here to share a bit of what we've learned along the way. So, Joel, what's new in your world? I've been doing a lot of work in TypeScript recently, and something that's really interesting about a type system is that it often takes a lot of things that are implicit in your program and makes them explicit. Something that I've been digging into a little bit is how much uncertainty you add to your program when you index into a collection. So this might be taking an array and using an index to pull an item out of it or taking a map. This is the equivalent to a hash in Ruby and indexing a key out of that because you're never guaranteed that you're gonna get an item back. You might get undefined. Yeah. Type checker tries to keep you honest and will say, hey. Did you remember to check for the case where that value is not present? I have just started experiencing that. It's my first project with TypeScript. And I've been sort of, like, categorizing some of this uncertainty, taking a little bit of inspiration from Fred Brooks' paper, No Silver Bullet Uh-huh. Where he sort of breaks down complexity in software into essential complexity, which is sort of inherent to the problem you're working with, versus accidental complexity, which is complexity you've introduced by your particular choice of implementation. And I feel like a little bit of that applies to nullability or uncertainty that you've introduced to your program. Some of it is just inherent to the software you build. Like, if you're dealing with user input, you can't trust that. You can't guarantee that they submitted all the fields on a form, things like that. And so that's inherent. But there's other things that are sort of implicit to the choices you've made for your implementation. And I think that oftentimes, choosing an algorithm where you're indexing into a data structure can introduce some of that accidental uncertainty to your program. And so now you either have to tell TypeScript to shut up, or you've gotta, like, add all this extra handling, …