Episode #138: The Best of Serverless Chats (Part 2)

May 23, 2022 • 67 minutes

In part 2 of this two part episode, Jeremy and Rebecca discuss some more of their favorite moments from the last 30 episodes cohosting the show together.

Episodes mentioned:

• Episode #108: Mulling over Multi-cloud with Corey Quinn
• Episode #123: APIs and the Evolution of Serverless with Dorian Smiley
• Episode #124: Self-Provisioning Runtimes with Shawn "swyx" Wang
• Episode #127: Supporting Women in Tech with Kristi Perreault
• Episode #125: Configuration over Code with Eric Johnson
• Episode #118: Deploying on Fridays with Charity Majors

Transcript

Jeremy: Hi everyone I'm Jeremy Daly.

Rebecca: And I'm Rebecca Marshburn.

Jeremy: And this is Serverless Chats. Hey, Rebecca! Back again.

Rebecca: Hey, we are back again! Really excited for the second edition of this episode. But before we go anywhere, Jeremy before we started recording you said something like, "Well, we'll banter a little bit because we're pretty good at it."

Jeremy: We're excellent at it.

Rebecca: And I would really, I hope that people will tweet at us to let us know on a rating scale of one to five if we're either very, very good at it or excellent. And that's a scale of one to five.

Jeremy: Right

Rebecca: One is very, very good. Five is excellent. So pick your poison. No matter what we're going to come out on the upside.

Jeremy: Right. Or they could also be like, "Can you just make it so that you limit your banter to some delineation of 30 seconds, so I can just skip forward until we get to the end of it and get to the actual meat of the conversation." So anyways, well ,so last time we talked, we went back through a number of episodes from the last 30 episodes. And it was pretty good, I think. I mean the episodes that we went through are just amazing. Again, we have amazing guests. We talked about that last time. But we have another, what? Six or seven episodes that we do want to kind of highlight here. But before we jump into that maybe we can get an update on your car. Cuz last time told us that your car was stolen. So any updates on that?

Rebecca: Indeed, well no updates other than no. So Genevieve or Jenny for short or we called her 'The cheap 1991 Jeep.'

Jeremy: Nice.

Rebecca: I don't think I can say this word. I'll change the B word to 'beach.' But she's apparently the police told me that she was stolen to do crimes, most likely. And I was like, 'Oh no she's out doing crimes?' And they're like, 'Oh yeah she's doing crimes.' And I was like, 'Well Jenny a bad beach now.' And Jenny has not returned. And I'm thinking that she has chosen a different path in life.

Jeremy: Yeah she's out there. She's got went and got a tattoo, maybe a nose ring. Who knows. I mean just, these kids today.

Rebecca: I know. Whoever is with her I hope they're having a great time because that is a very special car. She's a special car. But thank you for asking. I will let you know if she returns.

Jeremy: Keep us up to date. She might need an Instagram page or something like that so people can follow along. So, well let's jump into this because I do want to get to the rest of these episodes today, and not extend this to a third or fourth "best of." Maybe later, maybe we'll do that in the fall. We'll have another another recap of episodes. But when we left off last time we listened to a clip from Werner Vogels. We listened to a clip from Tom McGlaughlin, from Simon Wardley. And we finished off with a discussion about security from our episode with Merritt Baer and Megan O'Neill. And it was all about 'hope is not a plan.' And that, essentially, security has to sort of be a thing that's part of your culture. And there was a really interesting conversation around culture there. So I look at this, and I I look at security, and I think a lot of people look at security as maybe a burden, right? Something that is just, we keep using that word 'unsexy.' Which we probably shouldn't be saying that word but that was the thing about security, is that it really is this thing where it's just like, 'Oh, it's something else to do.' And that's also very true of operations and things like that. Like, just running patches on servers. Serverless takes away a lot of that. Serverless takes away a lot of the security concerns as well ,right? Because that shared responsibility model really shrinks when you go to serverless. But there are still, I don't know if want to call them 'burdens,' but there's still responsibilities and things that we have to think about when it comes to serverless.

Rebecca: Yeah, I think you're talking about, like, whenever you make a decision, even if it's the right decision, there are trade-offs involved in that decision. And so you could say that the disadvantage or the trade-offs that you make that are on the "negative" side of what you're losing, or the con, to whatever that decision is, we might call them burdens, right? Are there extra things that you now have to think about? And so in our episode number 108: Mulling Over Multicloud with Corey Quinn, we talk about the idea of the serverless pay per use billing model and whether or not it's a nightmare for procurement, for accounting departments, for the trade offs that you are then making when you switch or move to that model, and other teams are pieces of the org that might be affected. Anything you want to add before we dive into this clip with Corey Quinn?

Jeremy: No, I think you set it up well. And I think the point or the question that was asked was this pay per use model, which sounds great in theory, is that a nightmare for procurement departments? But also is it something where, that's just moving to be an acceptable practice.

Corey: Cloud it is a nightmare for a lot of those folks too, because there's a giant misunderstanding in many respects that distills down to the cloudier that something is, and by which I mean the closer it gets to serverless versus a data center, the less expensive it becomes, but also the less predictable. There's a baseline cost to service your first customer, a bunch of things that need to exist in your environment. And the additional cost beyond that distills down to a model of unit economics.

Something we saw during the pandemic in many shops that prided themselves on auto scaling, for example, saw 80% drop off and user traffic, but their bill remained largely intact at a flat line or doing what AWS bills always doing, and so increasing with time, because data doesn't delete itself. Great. Auto scaling is more of an aspirational thing in some cases, and people use the term elasticity in cloud to mean, "Oh, I can scale up." And you need to scale up because if not, you're dropping customer traffic on the ground. Scaling down has never really been a primary area of focus for companies.

Because at that point, it's just extra money, which I know sounds like it's for steal, but it's not really. Losing customers and disappointing them is way more important than, "We spent a little bit too much on our infrastructure." So people don't emphasize the scale-down part of the story. Now, as we wind up seeing the whole serverless approach, there are benefits to procurement done right. Simon Worldly framed at once is tracing the flow of capital through your organization. For a long time, it was hard to find expensive Lambda bills. There was a blog post somewhat recently on the AWS Management and Governance blog on July 22nd, How The Washington Post's Arc XP uses CloudWatch Metrics Explorer to reduce costs.

And it talks about how The Washington Post had access into the early beta of CloudWatch Metrics Explorer, and how there was an internal proprietary algorithm that they use based upon a variety of different metrics that they then gather and then figure out how to handle provision concurrency, and how much of that's being used and dynamically address it in real time. And AWS strongly talked about this as if they were indispensable at creating this. Yeah, The Washington Post is a reference client of ours. Who exactly do you think came up with a lot of those principles and ideas during the course of an engagement there?

And The Washington Post team is great at this. They are phenomenal. They are further ahead down the serverless path in some of their workloads than most companies you've talked to. And what's also interesting about this, and I want to be very clear, this is the sort of thing that people will read and think, "Oh, I need to absolutely implement something like this," and they'll go and do this and spend time on it. And I'll check their AWS bill and talk about these efforts, and they're spending 70 bucks a month on Lambdas function. Maybe that's not the thing you want to be building that advances the state of your business.

Let's admit, The Washington Post is very clearly a scaled out company. They are doing a lot of neat stuff with serverless and they are clearly doing things that are interesting enough to be at the vanguard of what we're seeing as far as cost optimization goes in the world of serverless. They wouldn't have been featured in the AWS blog if they weren't.

Jeremy: So, there's so much there. And actually so much sort of gold and clarity there, I think, if you're thinking about where you go from a cloud cost optimization standpoint. And the idea that when you move to serverless and things, not only the fact that things become metered, but your utilization is so much lower, right? Because that scale up/scale down thing- that's something that a lot of people don't talk about. I remember I had a conversation with Austen Collins, who was very much so saying that at the beginning of the pandemic that there was a rush for these companies to scale down. And that's something that they saw, which I think was pretty interesting. And so you cut your costs, potentially, dramatically by only utilizing a part of, or only utilizing the compute and the resources that you need, and that's a good thing. But then when it comes to, like, cost optimization you've got two things: the unpredictability of the bill, right? Cuz maybe one month it gets really high, maybe another month it's really low. And then you also have the fact that, where you might be able to optimize those, bills are so low that, again, if you're spending $70 a month on Lambda function invocations, spending a month of an engineer's time who's making $150,000 a year to save you, what? $10, $20 a month is probably not a good use of your time.

Rebecca: But ratio wise $10 out of 70. I mean, let's just use that as a stat.

Jeremy: Saved 13/14% or whatever it is off of our bill.

Rebecca: Shaved 13 to 14 exactly, exactly.

Jeremy: It cost us like 200,000% of their salary in order to do it but whatever, sure.

Rebecca: Yeah, I think, I mean one of these trade-offs, right, in this decision, is the trade-off of how important to you is predictability in your costing? And then if you're a small team, let's say you're a very small startup. You're a 3, 5, 10 people. And you basically kind of know who your customers are and what that's going to be, maybe. But once you're a huge company and you're like, 'Hey we have so many different distributed teams. They're all building their own things. They're all like, almost rolling into smaller accounting that goes up to larger accounting.' There's just so much unpredictability there, that it's something truly valuable to at least consider before you're trying to save $10 off of 70.

Jeremy: Right and I mean, again there's more there, too, about things being metered. There's an interesting opportunity to trace that value or the cost all the way through. And again he mentions Simon Wardley, who we we played a clip from him last week. But, there is an interesting thing there where it says like, 'Look you could actually meter' and say this particular customer Is using, we're not maybe we're not multitenant, right? So you're using Lambda ,functions to just invoke for this particular customer API gateway and these other things. And maybe they've got their own dynamo DB table and whatever. So all of those costs become really transparent, assuming you tag everything correctly. But all those costs become really transparent. And you could actually say, 'Oh well this particular customer is costing me X amount of dollars.' You could also do that on a per service basis where you could say this particular microservice that we're running costs us this amount of money. And even maybe break that down by customers and utilization. So there's a lot of really interesting things you can do there. The question is: is it worth it, right? Like, do you spend the time to do that and add all of that extra capability cuz does it really matter? Especially if we're talking about fractions of a fraction of a fraction of a cent sometimes when a request comes in, right? Like, is it worth it to sort of track that stuff?

Rebecca: Yeah, I guess it's sort of like take a step back and not like 'can we overturn every rock' but it's 'what are the big rocks?' And then what are the little rocks and what are the pebbles. And then let's decide, can we go after that big rock? And then if we find that big rock where do we find the value and cost trade-offs there? Not necessarily being like 'we're going to turn over a thousand pebbles.' I mean, I think we all know, if you want to hear very strong opinions ask Corey Quinn anything. But I do think he brought up a very interesting, nuanced point. It's not, and obviously we love serverless, so I'm not saying, like, 'Don't do serverless because it might have unpredictable costs' at all, but it is a very good reminder that because something works very well or might solve something by 15% it's not necessarily always the 15% you want to solve for. And so it's just another thing, like anything else, any other technology you use, you want to be considerate about when you deploy, it why you're deploying it, what it's solving, how you're spending your time, et cetera.

Jeremy: Right, yeah. And I think the other thing when it comes to trade-offs is this idea that even choosing a cloud is a trade off, right? And so Amazon/AWS, you and I, obviously a lot of experience with AWS. It's an ecosystem that, I, as a developer, am very comfortable with because I know a lot of the services that are there and so forth. But It was platform week at CloudFlare. They launched D1, which is a distributed sequel server that runs at the edge, essentially. They have R2 that went into open beta which is free egress, which you don't get at AWS, right? I mean, so they've got pages plugins and workers that run for 15 minutes and all these other things that they're doing now that are not necessarily putting them on par with AWS, but it certainly is getting them close. And it's going to make a lot of people who are already saying, like, 'Well we're already using workers and CloudFlare as a CDN in front of our AWS workloads because it's a little bit better, right, when it comes to that type of use case. But we still want to run all of our stuff in AWS for this and whatever. But then Zeta is a new serverless database that looks pretty interesting. Or maybe Fauna right or we really like this other service that does XYZ, and we want to use that. So, now you run into this complexity of multicloud being a thing, right? So we just talked about multicloud. But I think multicloud in the sense of cloud agnostic is not what people mean by multi-cloud. And it certainly shouldn't be. Like, you're not trying to run the same workload in multiple clouds. Maybe for certain redundancy and if you're providing some service that just can't go down. But if you're checking your Facebook feed, like, you probably don't need to run that in multiple clouds. But you might be using several providers. And those providers might run different clouds and all kinds of things like that. So the question comes is: how do you manage that complexity? And right now you've got a few services like Terraform you've got Pulumi that, I think, can do cross cloud things. And a couple others. But really, when you are choosing what cloud to write to, you are being very specific in terms of the resources that you are choosing. And so when we talked to Dorian Smiley, this was back in episode 123, we talked to him about APIs and the evolution of serverless. And I really liked what he had to say about, essentially, writing CloudFormation.

Dorian: The premise is that serverless in reality is AWS specific. It hasn't yet delivered on the abstraction between all of ... It's not multi-cloud and it's not edge. It's really about AWS. And you still have to glue together a whole bunch of things to make an architecture. So I still need to glue together my lambdas. I still need to write cloud formation for a lot of things because not everything is written into an open source component that abstracts away that complexity. So I'm still writing a whole bunch of AWS control plane specific stuff. And along with a whole bunch of other things that I may compose incorrectly, that I may set security inappropriately around. We can get into arguments about whether resource level permissions are appropriate or you should be using something like STS always and you should never assign resource level permissions to anything in AWS.

We can argue about that all day. But the point is that there is a lot of work that goes into that. I mean, we're spending more time doing that than we are writing the code. I could write a function in 30 seconds. Especially if you have a generator sitting on top of it. But then I spend three days troubleshooting why it doesn't work when I deploy it to AWS. And that's even if you're using the serverless framework and good abstraction tools. And it's still not multi-cloud. But if I were to think of what is the perfect way I could abstract that away? Well, one of them's an API. And especially if you think of something like Fauna, right?

Where you have this distributed database, it's amazing, it does what I want to do. Or something Dgraph where if I want GraphQL and an actual graph database. Who would've thought that would be a thing? Of course it's a thing. But I don't need to worry about how they deploy their infrastructure and they could actually solve the multicloud problem and I would never know it. I could write my code once and I have the abstraction built in. I'm just making an API call. And I don't need to spend any time writing infrastructure as code. And I could actually build an app on Versal and be up and running in a global edge compute network in an hour without one line of AWS control plane code. Which I would love. That's sort of like my guiding light.

If I can write an app without any AWS control plane specific code, I've achieved something important. And I think this is something AWS has got to wake up to. There's this opportunity cost that's racking up in their balance sheet right now. And they don't seem to understand it, but people are ... I don't think they're going to suffer that much because the people building these services are often the abstraction layer is built on top of AWS. To them, that's a win. They're still going to get the business. What I think they need to pay attention to is that these services that no one is going to use because they're too complicated to deal with their garbage control plane are going to be like this albatross around their neck or this weight sinking them down because they can't just spin those things off tomorrow.

There are a lot of people that depend on those things. But they're going to wake up one day and realize that companies that are solely dedicated to solving those problems deliver a better developer experience and a better service than their five person team that spends a lot of time listening to businesses but never spent one day talking to the developer that uses it. That's why I think the API economy is going to leapfrog serverless. It's the developer's stupid. If you ignore developer experience, you will fail. 100%. I don't care what you do. Eventually you're going to fail. Someone will come along and crush you. But that's why I think it will leapfrog is just that you're able to offer this incredible developer experience and accelerate the outcome by an order of magnitude. It's mind blowing, right? And the people working on it are amazing. All the people working in this space of the API economy are just like me. They've had similar experiences. They thought of this years ago. And they want to enable a good developer experience. And so to me that says they're going to win. At least in my mind.

Rebecca: I mean, a lot of good things said there. But, man, the developer experience and the fact that developers are the practitioners every day working with these tools, and as Dorian says, he calls it 'it's the developer stupid' which is a play on words. It's 'the economy stupid,' I believe, is the play on words. But he says if you ignore developer experience you will fail 100%. I don't want to speak too far into the future how this dovetails beautifully into our next episode, so Jeremy I want to stop here to ask if you have anything that you'd like to reflect on before I'm like, 'Oh my gosh, guess what's next!"

Jeremy: Yeah, well I think that the thing that Dorian said, that was something that I couldn't quite articulate well myself, and when he said this I was like 'That's exactly right. That is what I'm trying to say,' is that people, when you write cloud formation, or you use the serverless framework, or even when you use Sam or Terraform or some of these other things, you are writing AWS control plane specific code. And that is the crux of it right there. And so, from a true multi-cloud standpoint, as long as, even though Terraform abstracts some of the stuff away, like even if you're using the CDK. You're saying I need a Lambda function. Spin up a Lambda function. Connect it to an API gateway with these configurations and so forth. And you just spend a lot of time very much so focused on the primitives that you need in order to stitch these things together. So, perhaps you want to introduce the next segment where some people have been thinking about ways in which this could be more generic, maybe.

Rebecca: Yeah, I almost forgot that we had teed up that episode with Dorian around multicloud and what that means. And it's using different providers. It's not necessarily checking your Twitter feed with like four different clouds. Because I got so excited about the end of that clip, right? Where he's like, 'It's the developer experience.' And, so, we've had some incredible guests. Or I would say most of our guests are developers generally or have been in the past. And this specific guest I remember you and I being very giddy to talk to. He is no longer, but was at the time when we talked to him, the head of developer experience at Temporal. And so it's episode number 124: Self Provisioning Runtimes with Sean Swyx Wang. And we were talking to Sean around developer experience in general. How to make systems that developers can understand and move through and work with, without needing to be like extra fluent in every single nuanced, like new language, or like special bauble or knickknack. I know I'm using very technical language when I say 'bauble' and 'knickknack' but it feels like

Jeremy: Two knickknacks and a pay whack to yeah.

Rebecca: But sometimes that's what it looks like, right? When you're like working with a new product or provider and you're like, 'Oh they named their knick-knack Knickknack. And this one's called a Wachamacallit. But they do the same thing. And anyways so I'll stop just saying random words. But we, I think you and I both, really love loved and continue to love how Shawn Wang is all about empowering the developer to get their work done through simplicity.

Jeremy: Right. And the term that he uses is 'self-provisioning runtimes.' And so we asked him to explain exactly what what he meant by that.

Rebecca: I thought he said knickknack.

Jeremy: He did, oh well, maybe he did call it knickknacks.

Rebecca: Perfect.

Shawn: Essentially, what if your system, whatever system you're running in understood your program enough that it was able to provision its own resources to run that program. And so, right now out, we're very used to provisioning resources and then running the program. And then whenever... The whole concept of DevOps is essentially like, "Okay, program ran out of resources. So we needed to spin up more resources or fix the resources," or whatever. But why don't you just read your program that you're freaking running and just figure it out? I don't know, you tell me. And so, obviously that's extracting over a lot of complexity, but that's the end goal. That's where this all ends up.

And so, ultimately, this blog post came from a number of pain points. Again, I was still working in AWS at the time and the new hotness is AWS CDK, and Pulumi as well. Infrastructure is code. Literally as code, not as [crosstalk 00:27:48]. Exactly. But actually as code that you can program and reuse. So, all that good stuff about software engineering practices applies to CDK and Pulumi as well. But I was like, "Okay, this is great, but also we're just building up a whole bunch of stuff just to compile down to cloud formation," or whatever. And then on the other side, we're still reading in a bunch of config values and then carrying on with the actual program logic. Why don't we... Who's like merging the two? This is obviously the end game, right?

So, I have this graphic here of these abstract little blocks because I've been looking at language theory design. I think the formal term for this is PLT, programming language theory. And I have some friends in that field and I always listen to them, but they keep talking about types. They're like, "Oh yeah, if we had a better type system the world would be much better place." And I'm like, "Sure." Stronger type system, monads and all that good stuff. But one of the main advances in programming language that has still not been beaten is just programing languages that took care of memory allocation for you. Like had automatic garbage collection or they just got rid of the concept of having to manually manage memory registers.

And that's a huge step advance. But that only happened because we had just assumed that the run time would take care of it. And yes, it's not perfect. Yes, you have performance trade offs, and yes, sometimes you have to opt out of it and go down to a lower level language, but 90% of developers don't need that. And so, similarly, 90% of people who work with cloud don't need to know the underlying implementation details of what kind of storage and what bucket to put where. Just figure it out for me, and let me just work on the app. So, that's where I'm at. I want programming languages to advance to the point where they can just assume the run time to do it. And I want infrastructure provisioning to advance to the point where they can read programming languages and figure out what they're supposed to provide.

Jeremy: So speaking about words that don't mean anything: monads. He mentioned monads. No actually, that does mean something. But, no this is like the exact theory behind what I've been working on for the last, whatever it's been, 18 months or something like that. This idea that whether you call it 'self provisioning runtimes' or you call it like a cloud compiler or you call it infrastructure from code, which is what we call it. Essentially that is this very simple idea that we are writing things twice. We are essentially saying we want this program to do these things. And then we're writing to say, 'And here are all of the magical pieces of the cloud that we need to assemble in order to make it work.' And the problem is is that you are essentially putting all kinds of hints in your code anyways to know what it needs to do. And it used to be that we could just upload a file that had our whole programming instructions in there onto one server. And then maybe there's the complexity of there being a database. But the server itself had web server built in, Apache built in, maybe even had caching built in. And some of these other things, you get the distributed systems, it gets much more complex and more complicated. And rather than us absorbing that complexity into the model we were used to, we completely changed it and made it very, very difficult now, I think, for people to build distributed or for them to build modern applications.

Rebecca: Yeah, I think there's something special that he says at the end of that clip, right? Where he's talking about implementation details and the underlying implementation details. And he's like listen: Take that away from me, most likely, for the modern app that I want to build. Like, there are, of course, time and space and place for everything when it makes sense where you need to know the details. Or you want to know them. Or maybe done the trade off analysis and for some reason you wanted to you want to know all these details. But for the most part, what he's saying here, right, is like you don't need to know the kind of storage and what bucket to put where. Like, right now you want to just work on the app. So when I can allow you to do that, when we can build something that allows you to do that. To reduce the number of times that you do things twice, that work is redundant, that you didn't even need to know that in the first place. Then that is a step and advancement in the right direction.

Jeremy: Right, and I think that's a hundred percent correct. And I think the figure he mentions, again, it's just anecdotal, but 90% of developers don't need that. I think it's higher than that. I think there are probably 99% of developers, who are building a lot of these apps, don't need to go in and turn knobs. I mean, this is something that Lambda I think did brilliantly. We had this conversation, long ago I had this conversation with Tim Wagner and with Jay Nair. And, actually, I think even Holly Mesrobian, when we were talking about Lambda and sort of the lack of control that it gives you. Where it's like, there was one knob. It was like: how much power do you want? And it was in terms of memory. But that memory then tied to CPU and some of these other things. But that's one of those things where it's like, sometimes people just feel like, I mean, it's almost like a placebo, right? Like, if I can just turn it a little bit. Like, I'm going to hit that elevator closed button cause it makes me feel good. Makes me feel like I'm in control. But that elevator door is going to close when it wants to close, right? And that's the same thing I think that you get with something like Lambda and that memory thing. Now it certainly does do something and it gives you that little bit of control. But it controls a lot of things that it's optimizing for you behind the scenes. And that is one of those things where it's like, as a developer it's really great to use something like the serverless framework and say, 'okay I want a function. And I want it to run this handler code. And I want it to respond to an API at a slash user's end point, right?' And that'll do some of the work for you. It'll deploy an API gateway. It will map the Lamda function. It'll wrap the Lambda function a zip file. It'll upload it to an S3 bucket. Like it does all these things for you behind the scenes. But you're still basically saying, I still have to define the fact that I want this code to run when this happens. And then in the code itself you're saying 'well when this is triggered then do this and whatever.' So there's just a whole bunch of redundancy in there. And I think that most people don't even need that. And the cloud should be smart enough in order to know like, 'Oh you wrote an API script or a script that runs an API or a schedule or an event fires off, whatever. It should be able to wire it for you. It should be able to do those IAM roles for you. It should be able to do all of that. In the vast majority of developers like vast, vast majority of developers, they just don't need to know that stuff.

Rebecca: Yeah, kind of reminds me of this, I think it was a 90% invisible podcast. And they were talking about, this is almost going to sound very tangential but they were talking about the design of a nuclear reactor. It might've been three mile island?

Jeremy: And you might not want to abstract that away. You probably want to get down to the machine code on something like that.

Rebecca: No, but what they're talking about is they're talking about failures in design. And how when all of the different control panels were designed differently and in some control panels red meant it's operating, in an other control panels red meant there's a problem, there's an alarm going off. And so they were talking about the idea of design and all the knobs and the more knobs you put. And when you put someone in, obviously, a pressurized situation, it was not easy to parse what meant what where. And basically, I mean, there's all sorts of takeaways from this episode, but they do talk about there is something about giving people less knobs in order to do their job better. So that they can focus on the actual part of the job. And also then, hopefully, designing those knobs that you do have in a much more cohesive clarifying way. But I don't know, the way that we're talking about like simplifying things, right? It's like, if you are going to have knobs, make them clear. And a lot of times maybe ask yourself do I need to have this knob?

Jeremy: Right. Well, and this is not a psychology podcast but if you've ever heard of 'decision fatigue' it is something that is very, very real. You have a limited amount of decisions in you every day. This might be pseudo science. So don't necessarily listen to me. Go look this up yourself. But from what I've read is that decision fatigue is a very real thing where you have a limited number of decisions that you can essentially make every day. Which is why a lot of people, when they get home from work and they're tired and they had a busy day, they'll overeat. Or they won't eat healthy. Or whatever it is because they're just at a point where their mind is like 'I can't make any more good decisions.' So I'm just going to choose the default or whatever it is. I think that that does translate to some of these things as well. It's like, if you are constantly making, if you have to make 50 decisions in order to get an API endpoint up and running with a couple of simple things well what do you think you're going to leave out or what are the decisions you're going to skip? Security right? Maybe redundancy. Maybe other types of fail over or resiliency or things, like, there's just going to be too many things that you have to think about beyond all the things you already have to think about that those things are going to be lower priority. Which is probably why security gets left out of the conversation so much.

Rebecca: Right. Or you think about the decision and you end up saying like 'Ah that's tomorrow's problem.'

Jeremy: Yes. I saw that to myself all the time.

Rebecca: Yeah. Oh totally. Yeah me too. You're like, 'okay well we don't have to solve that right now. So I'll just decide to decide this tomorrow.' But like we talked with Merritt Baer and Megan, don't decide to do security tomorrow.

Jeremy: Hope that you can do it tomorrow.

Rebecca: Yeah exactly.

So we've been talking, obviously going further and further down into technical ways of building, technical ways of evaluating what to build, what might be the future of serverless or where we could go, and just programming in general. But there's also this other side that we love to talk about with our guests which is development culture, growth and learning, and advocacy of that learning and expertise across mediums, across people starting as new engineers all the way up to senior engineers and staff engineers. So let's talk a little bit about some of our favorite cultural moments where we've learned something from our guests.

Jeremy: Yeah and I think to sort of tie a lot of this together. Just going back to the idea of decisions you have to make, right? One of the things about having a hundred decisions to make and having all these primitives you have to worry about and having all the expertise that you probably need in order to put all this stuff together: that takes a lot of learning. And it also takes, in most cases, a lot of teamwork. And environments that promote growth and understanding and a culture of learning and just acceptance and things like that. So in order for you to be able to go through this process of learning something as complex as cloud computing, I think you need to put yourself in an environment where you have mentors, where you have other people that are willing to help you, and certainly where you're in a position to ask questions. And they say there are no dumb questions, but people, depending on the culture, do get criticized for it. And it's hard for everybody in order to, especially if you're a junior, or you're not sure to swallow your pride and be like 'I don't know what you're talking about. I don't know what those I don't know what those acronyms mean. Or I don't understand how this particular thing works.' That's really hard, I think, for anybody. But I think it's particularly hard for women and for people of color and any underrepresented group that goes into tech because we just know that tech has a stigma, right ?It's justnot kind, it's not welcoming, for the longest time, especially through the.com era and the early two thousands, there was a lot of this whole bro culture thing whatever. And it's changing, I think, I hope, right? We hear a lot of good stories about how it's changing but these are discussions and conversations and just experiences I think that need to be talked about and need to be shared so that if you're sitting there, again, as a white male that got the job, didn't have to worry about negotiating salaries, and everybody just sort of takes for granted the fact that well, maybe I have a CS degree so good to go. But if you're a woman it's like 'well yes I have a CS degree. Oh, I got my master's degree.' And you have to do more I think to prove some of these things. This is very real and this is happening. So we had Christie Perrault on the show. We had a really good conversation with her because she wrote an article about her experience as a woman in tech. And then I think we had a pretty ,good exchange here that showed that these conversations yes are hard. And they're difficult to have sometimes. But you can also have them with a little bit of levity in them, maybe.

Kristi:
So I have to say these things are not easy, they're definitely difficult. And I will even say I have trouble with some of those things myself too. The one that really resonates with me, that stands out a lot that I catch myself with constantly is the you guys statement, using that language because it's just so ingrained in every day and you use it to group things. And I'm trying to be more conscious about catching myself when I say that, which is funny, because here I am writing this whole article about it. And I'm like, "Well, I got to learn from myself a little bit here too." So that's one example for that water cooler talk. Educating yourself so you can educate others, that one's probably one of my favorite sections because I think that it highlights that we're all still learning this. Like I just said, we're all still trying to figure this out together and let's do it as a collective.

Even approach it like you do any new tech that you're learning and stuff like put out what you're learning and put out what you're ignorant about so that you can learn from others and share experiences. And then some of the things for ask women what they need, I'm a pretty loud person. I'm not afraid to step up and say stuff, but that's not everybody. So some people might need more help being highlighted in meetings or for presentations and things, they might appreciate being reached out to more. Others just don't like doing that kind of stuff, so maybe highlighting them in a meeting just makes them more nervous and they don't like it. So that's what it comes up to with just asking what folks need individually, because we're all individuals at the end of the day and everybody needs something different and is looking for help in different areas.

Jeremy: I find that you the you guys thing is everywhere you go, on TV. I'm from the Northeast, so Northeast United States, and you guys is just something that everybody uses. Women use it, men, it's everywhere. And then you are on tech Twitter and there's very much of this push to move away from it, which I think is amazing. And I just find though that it's like fighting an uphill battle and we need to change it, but at the same time, even my daughters. We don't use the term usually in our own household, but my daughters hear it from friends and things like that and it's so pervasive. And I'm just curious a thought on this because you have so many people that push back.

They're like, "Oh, you guys is meant to be gender neutral. It's not really that big of a deal or whatever." But I think to some people it is a really big deal and it doesn't feel like you're including them. But I'm curious your thoughts on the separation between workplace and casual or I guess recreational, that's probably not the right word, but that's the thing where I find the language you choose when you're in a professional environment. And you're communicating with people even on Twitter as part of a professional profile or whatever, and communicating on LinkedIn and within Slack and within company, things like that. I think people get confused in terms of the language we use outside and the language we use professionally. And I think there's a line there, but I'm curious what your thoughts are on that.

Kristi: Yeah. So funny, one of the things that I love about my company is that you're really encouraged to bring your whole self to work and I feel like I can do that. I feel like I have such a relationship with my colleagues that it's very much like that. I put a daily fun fact in our channel every day to get conversations going and stuff. So I do think maybe that line is becoming less and less clear as we go on, especially because that work and personal isn't as separate anymore with how much remote work there has been. You're screen sharing or video sharing in your house now. You're ingrained a little bit more in each other's lives, which is why I think it's maybe even more important to pay attention to some of the language and some of the ways that we're speaking to people and how we're embracing differences and diversity across the board.

I do think in certain professional situations, of course, formal presentations and some of those things, yeah, you do want to be probably a lot more careful with those things. And I'll say I'm one of the people that I'm not super offended by the you guys thing. I'm happy if you want to say that or use that, but I do know that other people aren't. So that's where the communication really comes into play. And like I said, I'm not somebody who's afraid to speak up and ask or if something's bothering me, I'll say it, and then that's how we can learn from each other. But I tend to really treat my work life and my personal or personal dev life pretty similar really, just because of that whole idea of bringing my whole self to work and being my whole self wherever I am. And I'm lucky that I've been able to be supported in that and that I have a safe space to do that.

Rebecca: I want to add here too, when it comes to gender neutrality about that term or using that phrase, I get it. I get it and I understand, well, that's just like a part of speech, it's like benign, if you will. However, actionably to talk about a small action one can take. Whenever you say you guys to a room of mixed gender folks, just replace guys with ladies and watch what happens. It is very strange. I'll do this I'll walk into a room of a mixed group and I'll say what's up ladies. And it's weird and people will be like, I don't get it. And you're like, well then try to explain to me that guys is gender neutral if you could just replace and say, no, I'm just using it in a gender neutral way.

And people are like, that's clearly not gender neutral. You just called us all ladies, and that's it. So I do think that it's... And I don't mean that to be poking the bear, but just for all of us to just question our own, what do we mean when we say neutrality and is it really? Well, what can you swap out in your language to see if it really feels neutral with the opposing word, boy, girl, whatever that binary is. And oftentimes it's funny, it can be very light and can be very lighthearted. But I think it's been a really helpful almost teaching moment for everyone to say, "Hey, that actually does feel strange." And then it's like, "Okay, how do we interrogate that?" And I think it feels strange because that actually shows you that hey guys is not gender neutral if you could say, hey gals, and people feel confused.

Jeremy: So I think he did poke the bear a little bit there but in a good way. Because again that, honestly, we played a little bit more of that clip to sort of hear the whole interaction back and forth. Because I think it was important where you took that. Where again that's just one of those things where it's like if somebody came into a room and said 'Hey gals' or 'Hey ladies' or whatever to a mixed room it would feel really weird. And and as an aside to this again another way just, I have two daughters but my youngest daughter randomly started just calling everybody 'girl.' So she's like 'Hey girl!' And so she'll say it to me. So now we just have this thing where that's what we do. We just call eachother like, 'Hey girl! Hey!' Like just whatever. And it's fun, it's lighthearted, it's within a family, and it's whatever. Clearly that's not going to work in a business environment. But it's the kind of thing where it just, again, it reiterates. It helps me too. It reiterates that thing where it's sort of like, 'yeah that is something that we probably take for granted, that idea of gender neutrality. Even in the term, 'Hey guys.'

Rebecca: Yeah I think, I mean the goal here, or one of the goals, I think there are many goals with this idea of interrogating the culture in ways that we can. And Christie Pearl had written, just so anyone who wants to look for it, on her Medium it's called 'How to Support Women in Tech.' And she outlined these four different ways that you can. And this was us looking at one of the ways and this was sort of the conversation that took place after one of the ways of how to support women in tech. And I do think, just the idea though of interrogating our own assumptions and where we think things seem normal to us, where it has been normalized, if we can interrogate those, right? And we can start to say like 'Hey how do we build women up and support women in tech?' That is just an exercise toward also then asking ourselves, not just how do we build women up and support women in tech, how do we support minorities in tech, LGBTQ plus in tech, how do we support gender non-binary? How do we support whatever it is. Like, if it's your sexual orientation, your religion, your identification as a certain gendered or non-gendered person. But unless we start to interrogate those in any of these forums, we're not going to interrogate any of them. So how do we start taking steps to make sure that we're asking ourselves those questions at the very beginning, when we're creating a culture or a space?

Jeremy: Yeah I totally agree. And I think that's the big thing with this idea of starting to use different language like that or starting to just be conscious of the language that we use, to be more inclusive. Because we, again, diversity is one of those things where I just, I don't think, if you've never experienced it, if you've never had the moment where you're like 'wow this person thinks differently than I do.' And however they think, maybe that represents a small part of the population. Maybe it represents a huge part of the population. And to hear somebody else frame something differently or articulate something differently, that is such a learning opportunity. And to have that diversity around you 10 X, 100 X as a team to do that. So the only way you can build a group of diverse people is by appreciating and accepting and welcoming and doing whatever you can to make that diverse workplace or that diverse culture a safe space for everybody to be in. So yeah I totally agree. This is something where just there's a lot more work to be done here. I feel like we've made a lot of progress in the last few years. Still a long way to go. So you also mentioned this idea of like being a safe space or comfortable and welcoming for everybody. And that includes junior people, that includes senior people that maybe don't know. We talked about this idea of asking questions or being able to ask questions but we had a guest that maybe helped clarify this a little bit.

Rebecca: We certainly, we did. Eric Johnson in episode 125. We talked a lot about a lot of great things including mostly Dr Pepper and how all of us are extremely long-winded. And we were at time about six different times in the episode. But in this particular moment in the episode, Eric is basically saying, 'Hey it took me a while but I finally was like: Hey everyone even though I'm supposed to be a a senior developer advocate, principal developer advocate, I don't know what this acronym means. I don't know what we're supposed to be building here with these words. I don't know what problem we're trying to solve because there are like vocabulary that's used and maybe we're introducing features I haven't worked with. I don't know.' Like ultimately the takeaway here was that he had to say like, "How do I end up being able to be okay with saying I don't know?' And then we talked about how, in certain ways, power dynamics might be such that someone who is senior in their role when they say 'I don't know,' it's seen as a source of like humility and strength. But when someone is junior in their role it can feel really scary because they already feel junior. And then they feel like they are going to be seen as junior because they're saying I don't know. So we're talking about this like, how do you make a space where it's a learning environment, where everyone is growing and learning? And it's always seen as a strength, not only to ask the question, but to answer the question responsibly and respectfully and basically with a level of grace where it's like 'Hey, I also did not know and let's explore this together.'

Eric: And so there's no way you know everything, and so I would sit in meetings and just quietly, the QRSW, niner niner, 42, whatever, and you know, I've been in those meetings and it's like, I don't know what that means. Finally, just one day I literally said, "You know what? I'm asking the question. I don't know what that means." I raised my hand virtually, I don't know what that means, and it was really funny because over 50% of the room goes, "Yeah, I don't know what that means either. I'm so glad you asked. I don't know." So I think the first thing I've learned is you don't have to know everything and you'd be surprised, somebody, if they're talking about it, somebody knows, but you don't get better if you don't ask the questions. I think it's really critical that if you don't know, ask. If you get fired for that ...

Jeremy: There's something wrong with the culture.

Eric: That's not your fault, that's somebody else's fault. Yeah, there's a problem there because the only way we learn is by asking. My dad was a teacher, he was a high school teacher, and here's his thing was always ... And we always say this, there's no question too dumb. But he really meant that. If you don't know, the only way to learn is to ask the question. I've said this before and I'll say it again, if you're the smartest person in the room, you need to change rooms. I want to be in the room where I know the least. Case in point, and here's a story, Jeremy. I'm a drummer, we talked about, it turns out. I was playing in community college. I was the best drummer they had and I really thought that was something. And then I transferred over to a school of music in Phoenix, Arizona. It turns out I'm not that good. I'm really good for one finger, I'm really average in life. You know?

And so the worst drummer there ate my lunch, but I learned more in my time there with those drummers being better than me than I ever did being the best because if you're always teaching, you're never learning, right? And so ... I'm just full of cliches, aren't I? How many cliches can I fit it? But that's one of the things I learned, you have to ask the questions, don't be embarrassed about it. And what I've found is at least in my experience, and you hear people who, "Oh, AWS is this, or Amazon is this, or Oracle is this." Or just whatever. They classify companies based on people. I guess this would be a second lesson, based on experiences with people. But the reality of a company is it's a group of people. And yes, while we have policies in place and things like that, some people are better managers than others. And so they base all story off a bad manager, all story off a good manager.

My experience has been very gracious. I mean, there's an expectation. You work hard. We work hard, play hard. But the there's a gracious allowance of oh, you don't know? Let's teach you. Now if you keep saying I don't know what that means to the same thing every time, probably the problem might be you and not them. But yeah, I mean, those are some of the things that I've learned. I'll stop there unless you have other questions, but those are some key things.

Rebecca: I want to follow up on that because... So in my time at AWS, that was also one of my key learnings. If you don't know, don't be afraid to ask because someone says, what do you say, QR QR 21, 21, 9, and all of a sudden someone goes long. They're like, "Blue 42. I thought you told me a button hook." And you're very confused.

Eric: Was there a niner in there?

Rebecca: Yeah, niner niner. Yeah. So when I first entered AWS, I mean, everyone has different levels and stuff like that, but L5, so lower quote, air quote, lower level in terms of the hierarchy of an organizational structure.

Eric: Sure.

Rebecca: And I would be in meetings with VPs of people who were making very large organizational business decisions and something that at one point, I was reading a doc and then I had all my red pen circles, don't know what this means, not quite sure how this fits together. And finally, I got to the same point you did where you're like I'm just going to ask. And something that was interesting is when I asked, afterwards the VP stayed and said, "I also didn't know what that meant."

Eric: And I was talking about it.

Rebecca: Yeah, and I was like, "I was a little worried to ask that question." And he said the same thing, right? Don't be afraid to ask. And then we talked about it and I was like I think something that happens, right? Is someone who is, let's say, quote, air quote, lower on the level hierarchy is more afraid to ask because they feel like they need to rise up since everyone around ... They don't want to be that person that's like, "Oh, I'm at a low level and clearly, I'm at a low level because clearly, I deserve to be at the low level because I don't understand." And so we talked about what does that mean for that person at the higher level to ... How do you create? And now that you're a principal and having a principal developer advocate, are there any tactics or ways where you're like, "Hey, how do we create this space so that people ..." It's seen as humble when someone at a high level asks what could be a scary you should know this question, right?

Eric: Right.

Rebecca: Because they're like, "Hey, clearly, I'm at a high level, but this doesn't make sense to me. Can you explain it?" Versus it feeling like a different burden of proof on someone who is at a different level. So do you have any ways where you're like hey, when I'm in a room, even if I know the answer, I ask the question to open up that safe space or any other tactics or ways that you think that space can be created so that people can feel like they can ask those questions?

Eric: Yeah, and I think you just hit on it. We do service office hours. We do service office hours on Tuesdays, and one of my jobs, I feel, as the host, but it's the same in rooms and private rooms as well, is I ask the question. I know the answer, sometimes, not always, but I ask the question that I don't think has stuck. You can kind of see the eyes and stuff like that, and that's one of the things I really try hard to do is pay attention to the room because you can often tell when people are off the tracks, right? They're just in there kind of doe eyed, shaking their heads, yes, yes, yes, I get it. I understand. But do you? And so I really try to open that up and ask the questions.

The other thing, and this was interesting, Chris Munns and I had this conversation when I started there, he said, "What are some things you would change?" And one of my frustrations, which was documentation, and AWS is not alone in that, documentation is hard. But a lot of times we make assumptions and this is a safe space internally. We make assumptions, we go, "I'm sure you know this so I'm just going to skip right over it and tell you to do this with this, with this, and the documentation." And I spent half my life going, "I don't know that. I don't understand how we made the leap from here to here."

And so when I write docs or when I do explanations, either I'm speaking publicly and internally, is I try to connect every dot and sometimes it's too much. I'm a talker. Sometimes it's overkill. And I'll say, "Look, if I'm telling you something you a lready know, go ahead and interrupt me, that's fine. But I'm going to say this and then you can ... You might correct me." But those kinds of things to not make the assumption. I think a lot of times we assume we're all in the same room, we're all at the same level, and that's not the case. And so those are some of the steps that I take.

Jeremy: Yeah I mean, I think that so much in there. Also amazingly fun to talk to Eric Johnson. But yeah, he pointed out a lot of really good points. I mean, this idea of just asking questions because you're never going to learn if you don't. The point he mentioned here of being the worst drummer, you can be the best at something. If you're the smartest person in the room you've got to change rooms. I love that one of the 30 cliches that he threw in there. But good ones, right? But yeah I mean, those all make sense to me. And that is something that I think is really, really important. And if your culture doesn't ,support asking questions then that is a really, really bad culture to be in.

Rebecca: Yeah, I fully agree. And I just absolutely love this reminder that asking questions should be seen as a fountain or a wealth of empowering everyone in the room, not just the question asker. In communities we have this idea of the, some people call them observers, at one point they were called lurkers, I actually asked this in the Uncommon Community Common Rooms Community recently 'what would you call someone who "passively" interacts in the community?' So they're not necessarily visibly participating. But that doesn't mean they're not logging in, reading other people's questions and answers. And right now the leading number of votes is for 'quiet learner.' And I do think that that's actively happening in a lot of rooms where if someone is asking that question, everyone is benefiting from hearing the answer .It's not just an A-to-B conversation when that's happening in public. That question and that answer is empowering everyone else in the room as well./ And I think that's something that we need to hold on to and remind ourselves that even when it feels scary to ask that question that you're not out only asking it for yourself, you're likely asking it for a lot of people in the room.

Jeremy: Right. Yeah, and I think that a lot of what we've just talked about, especially with these last two clips, are very much about culture. It all comes back to culture. Even Merritt Baer was talking about culture. So culture, culture, culture. What it is you do. How you embrace people. The processes you put in place to make sure that things are getting resolved or whatever it is. And, one of my favorite episodes, and this is because I love listening to her talk about the things she talks about. I love reading all the blog posts she writes. She's so honest about this stuff: Charity Majors. So good in terms of the stuff that she writes. And we talked to her episode 118 and we called it 'Deploying on Fridays.' Because if you search for 'Deploying on Fridays' I think Charity Majors comes up as the number one thing. And there's so many people that tell you don't deploy on Fridays. You don't want to deploy on Fridays because you don't want your engineers to have to spend their Friday night debugging. But we asked her about this and wanted her to clarify her stance on deploying on Fridays. And it goes beyond just having good CICD systems. It very much so has to do with engineering culture and how you feel and value the engineers you have working for you.

Charity: This is some place where I think people like to paint me as a radical, and just a fire breather or something. I'm not. I am from ops. I am a pragmatist at heart. I am not trying to draw a line in the sand and be like, "If you don't do this, you are terrible." My point is just that, if you are unable to deploy for a solid 20% of your week, that's not great. That's not something to aspire to.

Some people will be like, "Well this is a sign of how much I value my people, and their weekends and everything." I'm like, "No it's not. If you really value their time that much, you wouldn't want them to only be protected from this on Fridays. People get paged overnight all week long. If you really care about your people, you will fix this problem, so that deploys are safe, reliable, easy, easy to flip back and revert, easy for engineers to deploy their own shit. That should be a nothing-burger, right? It should be, it's the heartbeat of your system. Heartbeats should be regular, predictable, trivial, like nothing. Small diffs, one engineer at a time. As you go out constantly, all day long. If you've done these things, it will make absolutely no sense to you to block off Fridays."

There are some places where some people have extreme situations. Some people, blah blah blah. I don't know everyone's specific situations, and there are some situations that I'm like, "Okay, that's valid." But for the most part, I hear a lot of excuses. For the most part, I hear a lot of shit that makes me see that they just haven't done the work. If it takes them an hour or two to get their code out, I'm pretty sure they're batching together a whole bunch of engineers to code at once. Which, there are five things wrong with this, you know? If it takes you that long to get shit out.

The amount of time it takes you to get a single line of code out into production is extremely telling. Can you do that in 15 minutes or less? If so, you can probably ship on Fridays, no problems. If you're doing auto deploys, if you're ... It all goes together. I just don't like seeing it used as an excuse to not improve. If you can't get there, I get that. Sometimes people are dealing with a lot of legacy shit, or they've got external customer requirements. I'm just saying, you can probably get a lot closer than you are now, and it will be nothing but benefit to your people. Every step that you can get towards being able to auto deploy regularly, will help people, will save time, will make your engineers' lives more joyful. It's win win win win win, and so I don't understand why people continue to just radically under-invest in this area.

Rebecca: This human does not mince their words. And I love it. You highlighted a couple of specific parts that even stand out from this already stand out clip. Want to tell us about them?

Jeremy: Yeah, I mean the biggest one for me is: I just don't like seeing it used as an excuse not to improve. And that's one of those things where if you're an engineer, and you're writing code, and it takes three days for that code to get into production, that is way too long. Because I can tell you right now, I don't remember what I just said 20 minutes ago. Nevermind code I wrote three days ago. So even if it's a couple of hours to get into production or to get into a point where it's starting to interact with the system in a way that is meaningful that we can actually start to debug it If something goes wrong. Because that engineer, we talk about this through the whole entire episode. And this episode is great, by the way. One of my favorite episodes that we've had because we talk about all those different things where we're like 'An engineer is the one, the faster the engineer can get that code into production, the faster they can debug it. And when it's fresh in their mind, that's the time when you want that to happen .And you have to test in production. This is another thing that Charity says all the time. You have to test in production with distributed systems. Because you cannot replicate the fragility of a distributed system in the cloud with a dev environment. You can't do that. You have to observe it. You have to see how data is flowing through, where things break, how quickly they break, how often they're failing and so forth. And if the engineer who built that code, or wrote that code, can't see that almost instantaneously, then it's going to take forever to figure out. So I love this idea of just saying 'Look, if you value your people, you're going to give them the process that they need to not only succeed and write good code and be able to validate that code, but you're going to give them that sense of confidence that they know they can put something into a system that is going to be able to easily react or is going to be able to quickly roll back if there's an issue. As opposed to, again, waking them up, even if it's a Thursday night or whatever it is, to fix some bug because they just merged 20 diffs at the same time.

Rebecca: Yeah absolutely. You're going to work toward and end up delivering that win-win win-win. I think she was five wins in this: win win win win win win situation. It's a win for the engineer as a human, it's a win for that team, it's a win for the company. Like if you're able to do this nimbly and you're able to deploy on Fridays and test in production that's not just saving that one person's valuable time, effort, sanity: It's better for the business.

Jeremy: Right. Well, we probably could have split this episode into another one, but I'm not sure how many of these best of episodes we can do before people were like just give me a new guest. Anyways we'll put it in the show notes all of the episodes that we mentioned here. But I, again, amazing guests. So much fun doing this with you, Rebecca. Thank you so much for doing this with me, as well because we, I think, we've gotten so many good quotes out of people. I just don't know if we're good at this or just people are just so willing to talk? I mean, yeah the guests are amazing but this has been so much fun. So hopefully we will be able to do many, many more episodes together, talk to more amazing guests, but we are out of time.

Rebecca: Yeah. Thank you for this walk down memory lane. And thanks to all the guests who allowed us to walk this memory lane. And to our listeners If there was, in part one or part two, an episode that was your favorite or if you had a favorite episode that we didn't cover here, let us know. We totally wanna hear.

Jeremy: Righ.T Or if there's a guestsyou really, really want to hear from, there's someone you want us to have on the show, we love talking to people. And we also, I think we like hearing the sound of our own voice a little bit too much, Rebecca. Maybe that's part of it. That's why we're so long winded.

Rebecca: I like hearing the sound of your voice, Jeremy.

Jeremy: Yeah. Well I think if Eric, if we could have Eric Johnson on, if we added him as a third co-host, then guests wouldn't even get a word in edgewise. But anyways, we'll see, I don't know. Maybe we'll do that. Maybe we'll do the 'Jeremy-Rebecca-Eric Hour' or something like that. That would be fun .Thank you everyone for listening. Thanks again to all our guests. Thank you Rebecca. And to you all, the listeners. So we'll see you again next week.