“Just in Case” vs. “Just in Time” with Aditya Bhargava

• Aditya’s blog: https://www.adit.io/
• Grokking Algorithms, Second Edition: https://www.manning.com/books/grokking-algorithms-second-edition
• DuckTyped: https://www.ducktyped.org/
• Last Skeet in AWS: https://lastskeetinaws.com/

Transcript

Aditya Bhargava: 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, like, having learned something useful.

I think learning is, like, one of the great joys in life. And 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.

Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Adiyta Bhargava, 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. Adiyta, thank you for joining me.

Aditya Bhargava: Thank you. I'm excited to be here.

Sponsor: 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 Duckbill bill.

And my CEO informs me that is absolutely not our slogan.

Corey Quinn: So, you have done a number of different things, and 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, "Ooh, AWS networking." Yeah, stop me. You've heard this one before. "Stop." Instead, the way they're illustrated. There are ducks with personalities popping up in these things. There are, it's a very human approach to it. Even the writing is extraordinarily familiar in style. It's not written like most things in this space.

Where did you come from that this is how you communicate? Because I love it. I want to see more of it.

Aditya Bhargava: 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 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.

Corey Quinn: You've noticed, I don't know what it is about the insanity of AWS networking, but for those who are unaware 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 in 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, you need to, at some point, "Okay, we need to draw this out," and suddenly my disused whiteboard gets a lot more use.

Aditya Bhargava: 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 joy to go into a post and think, "Oh my gosh, I'm going to 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.

Corey Quinn: They say that a picture is 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 bloodbath 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.

Aditya Bhargava: 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.

Corey Quinn: 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. In 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. It's 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.

Aditya Bhargava: Thank you. The way I teach, I kind of break it down into two philosophies of teaching and learning, and I think most people do it the wrong way, which is kind of a hot take for this podcast.

Corey Quinn: Oh, this is the place for hot takes. Please dive in.

Aditya Bhargava: 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, like, having learned something useful.

I think learning is, like, one of the great joys in life, and I think the times I learn 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.

Corey Quinn: 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 mylastskeetinaws.com Bluesky 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, that's not true. There is, it's a big number, but there's 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.

Aditya Bhargava: 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, you know, run a server and have someone be able to connect to your server?

And I think that's such a great motivator. You know, 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, you know, 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."

You know, 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 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." And 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.

Corey Quinn: 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 going to look very hard at what, 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 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.

Aditya Bhargava: Yeah, I mean, I think that's exactly right. And one of my other hot takes, that people really struggle with as 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. Yeah. that's not actually a useful way to learn.

Corey Quinn: I am a reader. I have that same flaw where it's, I feel the need to finish it and I, what sort of got me out of that model for better or worse has been the absolute, horrifyingly, 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. 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.

Aditya Bhargava: 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,

Corey Quinn: Do they think you're paying by the word?

Aditya Bhargava: Yeah. I mean, people generally do buy books based on page count, but I totally agree. I would pay more. I just picked up this great book actually called. I think it's called the 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.

Corey Quinn: I want to be very clear that everything I have just said about brevity being soul of wit and all, this, 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, wow, 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.

Aditya Bhargava: 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.

Corey Quinn: 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 plodding, so I find it infuriating when the only way to pick up something the 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. Where they do the teaser at the front, and then they drag it out to make sure it hits ten minutes, and it's, buddy, I wish there were better ways to do it, but some of 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 okay. 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 end to end tape roll credits. No, it's they get straight to the point and they go with it.

It's wonderful.

Aditya Bhargava: 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.

Sponsor: 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.

Corey Quinn: 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 Grokking 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 could tell when you're at home, people don't tend to refer to you as professor. What's the deal with that?

Aditya Bhargava: Yeah, that's a good question.

My role in the book, I always think of as 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 as 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, you know, 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 like 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 search, 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 1 and 100. 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.

Corey Quinn: Yeah, almost a binary search on some level, mentally speaking. Although there are 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 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.

Aditya Bhargava: Exactly. We all know this.

Just, you know, 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 he can actually apply to your job. Cause he can use binary search everywhere. You just need to know the concept behind it.

Corey Quinn: 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.

Aditya Bhargava: Yeah.

Corey Quinn: It is not something that is just sitting there doing, just flapping in the breeze here. 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 ten 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 style of storytelling I just haven't seen very often.

Aditya Bhargava: Thank you. 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, 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 grokking series, and so they said, "You know, your book is going to be like the first one. That's going to be the flagship. We want to make this a real success, and then we'll build on this grokking series." Which they have, but this editor Bert really taught me how to teach and writing.

I had a lot of the ideas, but he's the one, you know, "just in time" versus "just in 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, "You know, 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 know, 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.

Corey Quinn: And, and now you, lately you've been deviating a bit from that direction.

Now, 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 Substack, DuckTyped, people who are interested, it's 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. I, 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 of 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 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, the fun world of AWS networking yourself?

Aditya Bhargava: That's a good question. Yeah. I mean, again, I am 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. You know, 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 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. You know, 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.

Corey Quinn: 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, when I copy and paste the magic spell from the tome of wisdom that was formerly Stack Overflow and is now ChatGIPPITY, 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 NANOG 91, and my talk, like, "What do you want us, 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 they you don't need to know a lot about networking to get started to, 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?

Aditya Bhargava: Oh, that's 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 "just in case" learning all the time for that reason. Like, it's not enough to just like, no, the short version of how something works. I really need to understand it 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, you know, let's say intermediate at this topic.

So I think a great book on AWS networking for me would be. Okay, here is 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 is 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.

Corey Quinn: 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 of 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 ChatGIPPITY, 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, 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.

Aditya Bhargava: 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. And that's "explore." And now, movies. I think it's fair to say are becoming less popular. Fewer people are going to the theater to see a movie. Studios can't do that sort of experimentation anymore because the, you know, 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." The "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.

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 Como because now I have to build this whole front end and that thing is going to come in really handy for this."

Corey Quinn: 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 trying to just memorize it forevermore.

Aditya Bhargava: Yes, and that's why my posts, 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, roughly remember all the set up networking set up. 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.

Corey Quinn: Absolutely. I read a lot of articles, some well written, some not as much, but very few have drawings of ducks.

Aditya Bhargava: I'm sure.

Corey Quinn: 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?

Aditya Bhargava: People should go to www.ducktyped.org. That's the Substack.

Corey Quinn: Excellent. And we will, of course, put a link to that in the show notes. Aditya, thank you so much for taking the time to speak with me today. I really appreciate it.

Aditya Bhargava: Thank you. It was great to be here.

Corey Quinn: Absolutely. And thank you all for listening. Aditya Bhargava, 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, along with an angry, insulting comment, making sure to include a drawing of a duck.