Screaming in the Cloud - “Just in Case” vs. “Just in Time” with Aditya Bhargava

Episode Date: March 25, 2025

How you learn is important. Corey Quinn is joined by Aditya Bhargava, a Staff Software Engineer at Etsy and the author of Grokking Algorithms. They talk about the nuances of technical learning and the contrasting philosophies of "just in time" versus "just in case" learning. In this episode, Aditya emphasizes the importance of effective teaching methods and the value of incorporating fun things like drawings into technical explanations. This approach also bleeds into his illustrated Substack, DuckTypes. As Corey and Aditya discuss, a good, informative book doesn’t need to drag on, and this quick, insightful, 30-minute conversation is no different.Show Highlights(0:00) Intro(1:24) The Duckbill Group sponsor read(1:58) Corey's admiration for Aditya's writing(5:40) How Aditya clearly explains AWS networking(8:06) “Just in case” vs. “just in time”(10:15) Why business books don't need to be hundreds of pages long(14:19) Reading for pleasure vs. reading for work(16:57) The Duckbill Group sponsor read(17:24) Explaining Aditya's book on algorithms(20:07) The great editor behind Aditya's book(22:20) DuckTyped and how Aditya got into AWS networking(25:16) Where networking folks fall in the era of the cloud(28:12) The importance of staying up-to-date in your field(31:46) Where you can find more from AdityaAbout Aditya BhargavaAditya Bhargava is a Software Engineer with a dual background in Computer Science and Fine Arts. He blogs on programming at adit.io.LinksAditya’s blog: https://www.adit.io/Grokking Algorithms, Second Edition: https://www.manning.com/books/grokking-algorithms-second-editionDuckTyped: https://www.ducktyped.org/Last Skeet in AWS: https://lastskeetinaws.com/SponsorThe Duckbill Group: duckbillgroup.com 

The two ways I would talk about are one I'll call just in case, and the other one I'll call just in time. And most of the learning and teaching is just in case learning. I'll tell this information to you just in case you ever need it in the future. And I think that is a pretty unsatisfying way to learn because you don't get like the immediate rush or satisfaction of of having learned something useful. I think learning is one of the great joys in life. And I think the times I learn best are when I've really struggled against something. I really bang my head against something. I'm like,

oh, I wish I understood how this works. And at that point, if someone teaches me how it works, that's what I call just-in-time teaching. You give me the information right when I need it. That's when I'm primed to learn the material. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Audit Pargov, staff software engineer at Etsy,

and creator of a, I guess the best way to frame this is a series of articles featuring wonderful illustrations that explain one of the saddest things in the world, AWS networking. Audit, thank you for joining me. Thank you, I'm excited to be here. This episode is sponsored in part by my day job, the Duckbill Group. Do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it

should be, negotiating your next long term contract with AWS, or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is. To learn more, visit DuckBillGroup.com. Remember, you can't duck the duck bill bill. And my CEO informs me that is absolutely not our slogan. So you have done a number of different things. And I think the first thing that attracted me to what you have written, and I've included my newsletter a couple of times now, has been not just the subject matter of, oh, AWS networking. Yeah, stop me. You've heard this one before. Stop. Instead, the way that

they're illustrated, there are ducks with personalities popping up in these things. It's a very human approach to it. Even the writing is extraordinarily familiar in style, and it's it's not written like most things in this space. Where did you come from that this that this is how you communicate? Because I love it. I want to see more of it. Sure. I mean, I have been writing this way for years. I used to do blog posts about functional

programming years ago. And I did one about monads, which everyone finds like a really scary topic to talk about. But I did it in the same style. And it really took off. And it's how I like to learn. And it made me think, oh, this is something other people resonate, but also, so I've done the blog. I wrote a book about algorithms that also became quite popular and I have a whole bunch of other ideas. But one of the things is I wish there was a better resource for AWS networking and there isn't. So that's what I'm trying to make here. You've noticed, I don't know what it is about the insanity of AWS networking, but for those who aren't aware with my nonsense,

I know we're recording this on YouTube nowadays because that's where the kids like to consume content and all, but everything I have done has been involved with the written or occasionally spoken word. I am not a visual arts person. It is not what I'm good at. And yet, one of the exception pieces of this is a ridiculous diagram of data transfer costs in AWS land.

I think that there is something about the way that this networking stuff interplays, that it becomes impossible to talk about descriptively instead of speaking wildly with one's hands. Like you need to at some point, okay we need to draw this out and suddenly my disused whiteboard gets a lot more use. Yes I totally agree. I think you know I hear from people sometimes saying they're not a visual learner but I think everyone is because it's such a it's such a joy to go into a post and think, oh my gosh I'm gonna have to read all this text, I know what this is like, wall of text coming at me,

and instead it's like three lines of text, image, three lines of text, image. It just makes it so much more fun I think. They say that picture's worth a thousand words but I guess that's for people who can draw. The problem that I find is that, okay, I need to wind up throwing a bunch of really crappy pictures. I chicken scratch stuff out, and then I send things off to designers or people with, I guess, a sense of competence in what it is that they do.

I kind of write code the same way, where like the first stab at these things is, I don't know what the corporate polite term for a blood bath is, but that's what it is. And they look at this like, oh, honey, step right over here and never, ever, ever touch this again. And you do something badly enough, competent people take it away from you.

It's kind of amazing. You are one of those competent people. It seems like there's no one to take it away from you. So you're stuck doing it. Yeah. I mean, and I love doing it. I have a background in art. So, you know, I really enjoy the drawing portion of it. Yeah, I mean, it also helps my mind shift a bit, right. And like,

think about the problem in a different way. And think about how I could explain that better to people. Yeah, it's networking is one of those strange areas where I when I fix AWS bills, I focus primarily on data transfer as my first go to. And people like to go with what they're comfortable with. And that's not what's happening here, because no one's comfortable with understanding networking in an AWS context. But because I find that that sort of unlocks the data flows of what what is talking to what, what volumes, help me understand what's going on in this environment.

And I always found a network-first approach to be incredibly illuminative when it comes to that sort of thing. You have taken it in a different direction. You're not, as best I can tell, trying to explain this in a context of, here's how to save money, or even here's how to understand architecture. But you're approaching it from a first principles explanatory basis of here's how this stuff works. You have a gift for this. You make it engaging, you make it fun to read, and I don't mean to cast shade but I think there's no way to say this without casting shade. You upstage the AWS documentation folks around

networking by several orders of magnitude. It's, this stuff is incredibly complicated and that's not made any better by the crap state of the existing explainers. Thank you. I like the way I teach. I kind of break it down into two philosophies of teaching and learning.

And I think, I think most people do it the wrong way, which is kind of a hot take for this podcast. Oh, this is the place for hot takes, please dive in. The two ways I would talk about are one alcohol, just in case, and the other one alcohol just in time. And most of the learning and teaching is just in case learning i'll tell this information to you just in case you ever needed in the future. I think that is a pretty unsatisfying way to learn because you don't get like the media. Rush satisfaction of having learned something useful i think learning is like one of the great joys in life. I think the times I learned best are when I've really struggled against something. You know, I've really banged my head against something.

I'm like, oh, I wish I understood how this works. And at that point, if someone teaches me how it works, that's what I call just in time teaching. You give me the information right when I need it. That's when I'm primed to learn the material. You've just put your finger on something that I've been dancing around the periphery of for most of my life. For me, the best way to learn something is I need a project that focuses on this.

By the time that this episode airs, it will have been out. That's how I built my last Skeets in AWS.com blue sky threading client. I had some AI stuff and some brute force and enthusiasm as far as programming goes and I didn't know TypeScript but I kind of know how computers work. I know a lot more about it now. I now know how their horrifying OAuth implementation works and how to do it statelessly in a lambda function. These are things that no one wants to have done and yet somehow I did because I had a problem I needed to solve. If you had instead given me all the documentation for these things, which I have at my fingertips,

it's called the Internet, I wouldn't have picked up a damn bit of it because I didn't have a need for it. The idea of learning something when you need it is incredibly valuable. It's similar almost to the idea of what I've been saying for years about S3, whereas S3 has infinite storage and from a purist perspective, like that's not true. There is it's a big number, but there is a limit to capacity of what they can have. But no, they can increase that storage faster than you can fill it.

I know this because with a runaway script, I tried once. Got it. Yeah, I mean, I think that's a great example. And in this series, what I'm trying to go for is what is the minimum amount of networking you need to know to put up and start an EC2 instance and have it run a server and have someone be able to connect to your server. And I think that's such a great motivator. That's a very clear problem statement.

And so people have messaged me and said, you know, oh, it's so great you talked about VPCs. Could you also cover this information or your subnets article, could you cover this? And my answer has always been like, well, that's not necessary to get this EC2 instance running. I think that becomes just in case information then. And what I'm looking for is just in time information. I have also heard the same thing about my book, because if you look at my book, which is an algorithms book, and you look at all the other algorithms books, my book, and you look at all the other algorithms books, my book is about 300 pages and all the other ones are like a thousand pages. And people are always like, well, you haven't covered all the sorting algorithms.

I'm always like, well, if you ever need to write a sorting algorithm from scratch, you can read one of the other algorithms books. What I'm telling you is all the stuff you need to know to actually be good at your engineering job. And guess what? You can learn that information in 300 pages and that saves you time. And like it's just a much more interesting, fun and useful experience. Is this more to do with understanding

the groundwork of the area? Is it a learning how to learn type of situation? I mean, in my consulting engagements, by far the most common answer I give to clients has been, I don't know, but because I'm a professional, we finish the sentence with, but I will find out momentarily. And that's the way it has to work,

because I'm paid to never be wrong. The first time I bluff and I'm wrong and I'm spreading misinformation in that context, everyone's gonna look very hard and what exactly are we bringing this guy in to do? We thought he was good at this and instead it seems he's a lying clown. You have to be able to learn and absorb things quickly

and understanding where to look for these things is often some of the most important, I guess, technical skills I've ever picked up. Because spoiler, whatever technology we're working on today is not going to resemble bit for bit what we're doing five years from now. Things will be inherently different. That has always been the case.

You have to keep going back to the well. You have to keep relearning things in most areas. I do not know if that holds true in algorithms. I do not have a formal academic background in computers. Like, well, I don't know, we're not getting computers like, well, I don't know. We're not getting another Newton anytime soon. We don't think, okay, great. There are exceptions to this.

There are fundamental natural science laws of these things. But in practice, the day to day, at least for me, is a lot more vocational and the things change incredibly rapidly. Yeah. I mean, I think that's exactly right. And one of my other hot takes that people really struggle with is you don't need to finish books. Like people will start books and they'll say, you know, I'm a finisher. I will finish this book. I do this myself. Sometimes like I want to learn more about machine learning. I have this book, once I finish it,

I will know more about it. But yeah, that's not actually a useful way to learn. I am a reader. I have that same flaw where I feel the need to finish it. And what sort of got me out of that model, for better or worse, has been the absolute horrifyingly, the just pedantic nature of so many business books where this is a 300 page business book

that says something that fits comfortably within 15 pages. The problem is if you're trying to sell a business book and you show up with a pamphlet, people don't think they can charge as much for that, which is a problem. I wish that they would. If you I would pay more for the thin book that covers the same information than the thick one, because I don't need you to act like an old time persistence hunter where

you circle the topic to death until it dies of exhaustion. Tell me what I need to know and get on with my life because there's more important things that I have to pick up next. Yeah, sometimes. Yeah, I've seen a couple of reviews of my book where people say like, oh my gosh, $40 for a 300 page book. That doesn't make sense when the I think you're paying by the word. Yeah, I mean, people people generally do buy books based on page count.

But I totally agree. I I would pay more. I just picked up this great book actually called, I think it's called 100 Page Book on Machine Learning. And it was one of those, like set your own price. And I was happy to pay a good price for it because to me it was like, well, if you can cover this in 100 pages, that's worth a lot to me.

I want to be very clear that everything I have just said about brevity being soul of wit and all, I'm thinking of this in the context of nonfiction. What up my library science friends? When it comes to fiction, I like the long slow rise and fall and multi book series to keep me engaged. I get a little sad when I buy something from my latest author and it turns out well that was distressingly inexpensive on the Kindle. Oh, no, it's only 80 pages. It's a novella, not an actual novel. I was hoping for something meatier. That is not the same thing. Doing things for pleasure versus doing them because you need to learn them to pick up information is a radically different approach. And I'm

not sure that that's well understood by folks who do not spend their lives growing up with books instead of friends. I agree with that. I'll even add to that. I think books are different from like podcasts or videos on YouTube or something where like, often I will watch these like watercolor videos on YouTube and I'm happy to just put on like a long video and just have it in the background while I'm doing something else because it's so soothing to have that around. And I don't, you know, I would rather have an hour long video of that than like a five minute video. That makes perfect sense. I'm not a video person at all.

I read very quickly. I find that the pace of videos, even when you speed them up, is relatively slow and plotting. So I find it infuriating when the only way to pick up something, the other way to do something particular, Photoshop, I'm looking at you, is a bunch of YouTube videos where then people are trying to bow to the YouTube algorithm.

They do the teaser at the front and then they drag it out to make sure it hits 10 minutes and it's, buddy, I wish there were better ways to do it. So my favorite YouTube videos are when I'm looking for a specific model of a sink. How do I replace the drain plug in it? And there's a video that's 10 years old and some guy does it. And the video is 53 seconds long.

And it's OK. He is not going to say around making all this in and out and the rest, unless the video is that's the trick. You don't. And to end tape roll credits. It's they get straight to the point and they go with it. It's wonderful. Yes, I one of my favorite YouTube videos because I do watch a lot of videos. Also, I have this water heater at home because I live in Minnesota and you need hot water all the time in the winter.

But it's really hard to figure out how all the buttons work. And I found this video where this guy in 30 seconds tells you how all the buttons work. And I just was like, you could have made this a 10 minute video, but this is so much better. Like I can just move on with my life. This episode is sponsored by my own company, the Duckbill Group. Having trouble with your AWS bill? Perhaps it's time to renegotiate a contract with them. Maybe you're just wondering how to predict what's going on in the wide world of AWS. Well, that's where the Duckbill Group comes in to help. Remember, you can't

duck the Duckbill bill, which I am reliably informed by my business partner is absolutely not our motto. I want to change gears a bit because you've written a book that I find confusing. You have two editions of it out which doesn't help the direction I'm taking this in. The book is called Grocking Algorithms and the problem I have with this is that you've written a book that has the word algorithms in the subject line but as best I can tell when you're at home, people don't tend to refer to you as professor. What's the deal with that? Yeah, that's a good question. My role in the book, I always think of is like, I'm not the

subject matter expert, but I am great at teaching stuff. So I have taught a lot of things in the past. One of them is algorithms. It's grounded really well because we got this awesome technical editor for the book. Great guy. Both of his parents are computer science professors at Yale. He has a PhD in computer science. I think his thesis was on trees. And he really went through the book and nailed everything down. But my job is just, how do I get away from all the stuff you don't need, such as proving that a sorting algorithm works, which no one needs to do in their job, and talk high level about the ideas? And what I have found is some of them are so intuitive. Just to give you an example, the first algorithm I cover is binary research.

And you don't even need to know anything about computers. I mean, I gave this example to my mom and I said, you know, I'm thinking of a number between one and a hundred. Guess what it is. And she said 50. And I said, well, it's higher than 50. So she said 75. And as humans, we naturally break the problem space down into two. We cut it in half every time, just intuitively. Almost a binary search on some level, mentally speaking.

Although they're asked their elements to the actual binary search algorithm that I found unintuitive until someone explained it to me. And then suddenly it made perfect sense and I've started going in that direction a lot. To be fair, I think that was middle school that someone pointed that out. I haven't somehow gotten to like my 40s

and then never realized, oh wait, you mean if you cut things in half, it goes better? Yeah. Exactly, we all know this. Just intuitively we know it or we learned it at some point when we were younger and we don't even think about it. But like if you read the binary search chapter in the MIT book, it's pretty complex because they go through all of the, you know, all of the proof and like, where is this going? Whereas I'm more interested in what is the big idea

you can take away from this that you can actually apply to your job? Because you can use binary search everywhere. You just need to know the concept behind it. I want to get in a slightly different direction as well, because I don't feel that I have made enough of a big deal about this. The book that you have written, Grokking Algorithms from a technical publisher, Manning, is illustrated. Yeah. It is not something that is just sitting there doing just flapping in the breeze here.

It is, this is, it's engaging. The pictures you have drawn as part of your substack series on AWS networking, it makes it more approachable. It's not, I want to be clear when I say that there's an animated duck that you draw, it's in service of the larger message. It's not there just as a distraction of, well, been 10 minutes need to throw another joke in style. I say this as someone who periodically has that urge himself. The whole thing weaves into a story, a style of storytelling I just haven't seen very often. Thank you. I I feel like that is the part I brought to the book when I started it.

I started working on it in 2013 and it came out in 2016. So it was a long time in the making. I kind of knew how to use the pictures right away. But since you mentioned Manning, which is my publisher for this book, they paired me with this incredible editor. He's like, you know, the head editor at Manning. And I got lucky, they wanted to start this new crocking series. And so they said, you know, your book is going to be like the first one.

It's going to be the flagship. We want to make this a real success and then we'll build on this crocking series, which they have. But this editor, Bert, really taught me how to teach in writing. I had a lot of the ideas, but he's the one, you know, um, just in time versus Justin Case, which we were talking about earlier, initially came from him in the context of writing this book, because initially it had a lot more content. And he's the one who told me, this feels like just in case information.

What does the reader need to know right now? They just did a great job. I mean, you don't, I feel like people don't really get that side of the writing very often is like understanding where the publisher fits in. But Manning really helped make this book great. And now you,

lately you've been deviating a bit from that direction. Let me be clear, 2016 you wrote this, and last year in February you released the second edition, which again, usually a trick we see from professors who want to sell new versions and kill the used market for the textbook they use in their own class. But you went back to that particular well. But where I've encountered you this year

has been in relatively rapid succession. Your sub stack, DuckTyped, people are interested, But where I've encountered you this year has been in relatively rapid succession. Your sub stack duck typed people are interested in ducktyped.org. You can you've gone through this series now explaining concepts of AWS networking. And the first time I saw it like this is great. It's awesome. And then I added to the queue, put it in the newsletter. And honestly, I move quickly.

I didn't think much about it again. Then a couple weeks ago, the second one in the series came across my desk through the same methods. And okay, now this is, this is once is once anyone can write something great almost by accident once it seems, but doing it consistently. Now there's something going on here. And that's why I wanted to talk to you about this. It's it's an area that is significantly

divergent from the algorithms world that you came from, but you're no less effective at explaining this. How did you get into the fun world of AWS networking yourself? That's a good question. Yeah, I mean, again, I just I'm just lucky I happen to know a bunch of people who are experts on different parts of AWS. And I really wanted to understand AWS better. That's where a lot of this writing comes from is like me feeling like, okay, I've learned this thing, but I'm not going to be confident that I know it until I can explain it very clearly to someone else.

And so that's where I started writing these AWS posts, and I've had people review them. And it's been such great feedback. And there's so much more to cover. For example, IAM is such a mess, like such a hard, there's so much to understand there. And someone at my last job, Rula, is, you know, an expert at IAM and I talked to her about like, you know, would you be willing to review this post or like, do you have a resource for learning IAM? And she's a staff security engineer at Rula. And she just said, I don't know a single resource that will cover everything that's needed. I have just learned it over, you know, a decade of being in this job. That's the

kind of thing I think people would be really interested in. I think that would be really valuable information. And it's just a matter of like, I need to figure out how to teach it. I need to figure out what the story is. What is the just in time story I can tell here? And then I want her to review that series of posts and see if that works. It's funny you mentioned IAM, because along with networking,

that feels a lot like the thing most commonly hand-waved over of, okay, when I copy and paste the magic spell from the Tome of Wisdom that was formerly Stack Overflow and is now Chatgipity, great, it does what I expect it to do, but no one really understands what's going on under the hood. Last year, I was invited, to my great honor, to give the keynote at Nanog91, and my talk,

what do you want me to talk about? Just be funny. Great, awesome, terrific. So when left to my own devices and I had no idea what else to talk about, I talked about myself. Most people do. And specifically my journey through how I learned networking, which is digging deeper where I needed to.

And I noticed that increasingly in our cloud world, people don't work with networking because the cloud providers have gotten so good that you don't need to know a lot about networking to get started. To use your example, to spin up an EC2 instance. You don't need to know how the network works until suddenly one day you hit a wall where you absolutely need to understand how the network works. And that is usually a gnarly enough scenario where just in time might not be enough. So where is the ebbing tide of networking folks in the cloud era? Oh, that's such a great question. So I would say just-in-case

definitely has its place, right? And like, as a staff engineer, I do do just in case learning all the time for that reason. Like, I, I, it's not enough to just like, know the short version of how something works. I really need to understand it as at a deep level, because when something breaks, I'll be the one who's called in to fix the issue. And I can't at that point be like, well, I know that, you know, our site is down, but I need to go and like do this deep dive into the docs to figure out what's going on. That's where I think great books come in so useful. And this is where I would really encourage people like, you know, you don't have to finish a book. If you do want to finish a book, read a few books and figure out which book it is that you want to finish.

Because I think a great book, one of the things it does for you is it lays out all of the content that the author thinks you need to know in order to become, let's say, intermediate at this topic. So I think a great book on AWS networking for me would be, okay, here's all the information you need to know so that if something breaks in your system, you know how to fix it. I think it's less useful to have books that are like, here's everything that you could possibly know. And at the same time, it's also not as useful to say, to your point, you know, this is a just in time book,

so we're just going to give you the short version. And then if you need more, you're sort of out of luck. There's a time and a place for it. For example, like, well, you don't necessarily want your surgeon to wind up doing the just in time learning thing right before you go under, but you also kind of do. You don't want your surgeon to have to figure out what,

like how do I perform surgery, pumping that into chat jippity? But you absolutely want your accomplished, certified professional surgeon to refresh themselves on the specificities of this procedure. Is there anything new, state of art in the literature that's come out since the last time I did one? And figuring those things out and adapting and assimilating new information. You need the

baseline. It turns out amateur surgery is not a thing. It's just sparkling butchery. So there is a limit here of how much you can pick up on the fly. Bringing that to technology, I'm not going to go and sell people on hiring me as a database consultant and then learn the night before how databases work. But I might very well look up that night before on what their particular database engine has been doing in the last three months. Yes. So there's a similar there's an algorithm that's sort of in this region called explore versus exploit. And this algorithm is why we see so many movies these days that are like sequels or remakes. Because the idea of it, explore versus exploit is to start with, you explore, you know, what are all your various options, like golden age of movies,

people are like, oh, let's just see what, you know, what we can make. We have all sorts of interesting movies, we have art house movies, let's just see what works. make. We have all sorts of interesting movies, we have art house movies, let's just see what works. And that's explore. And now movies, I think it's fair to say, are becoming less popular. Fewer people are going to a theater to see a movie. Studios can't do that sort of experimentation anymore because the budget's tighter. So what's going to work for them is making sequels because they know that's going to make them a ton of money. So they did the explore.

Now it's time to do the exploit. They exploit the fact that they have all these great franchises. You can do a similar thing in learning. Something I do is like, just learn different things that you find interesting. It don't, you don't need to have a purpose, you know, you don't need to have a reason for doing it. But at some point in the future, you might say, oh, thank goodness I took that CSS course by Josh Camau

because now I have to build this whole front end and that thing is gonna come in really handy for this. There's a lot that can be said for, honestly, improving recall. Because that's part of the issue too, is I can sit here and read five algorithms books. Great, three years pass. How much of that am I really going to retain in the moment on these things? It's important to be able to know where to go look for these things instead of just trying to memorize it forever more. Yes, and that's why I post, I always try to do like a summary, including an image. Because again, I'm sort of writing for me also.

So I want to be able to go back and say, okay, I roughly remember all the setup networking setup I need to do to get things working, but instead of reading through all these posts, I just want to look at one image that gives me the summary of those. That's honestly why I do a lot of pictures in general, because I think you're more likely to remember the content if you have a nice clear visual to go with it. Absolutely. I read a lot of articles, some well-written, some not as much, but very few have drawings of ducks.

I'm sure. I really want to thank you for taking the time to speak with me about this. If people Some well written, some not as much, but very few have drawings of ducks. I am sure. I really want to thank you for taking the time to speak with me about this. If people want to learn more, where's the best place for them to find you? People should go to www.ducktype.org. That's the sub stack. Excellent. And we will of course put a link to that in the show notes. Audit, thank you so much for taking the time to speak with me today. I really appreciate it. Thank you. It was great to be here. Absolutely. And thank you all for listening.

Audit Pargov, staff software engineer at Etsy. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this conversation, please leave a five star review on your podcast platform of choice. Whereas you've hated this conversation, please leave a five star review on your podcast platform of choice. Whereas you've hated this conversation, please leave a five star review on your podcast platform of choice, along with an angry,

insulting comment, making sure to include a drawing of a duck. Bye!