Weeks ago, the world watched helplessly as he Notre Dame Cathedral, burned. While this event was notable for many reasons, one of the things that struck us here at Technically Religious was the protocol used by emergency responders: Save the people, save the art, save the altar, save what furniture you can, then focus on the structure, in that order. We know what can be rebuilt and what can't.” In this episode, Josh and Leon compare and contrast that disaster recovery process to the ones typically used in IT. Listen or read the transcript below.
Leon: 00:00 Hey everyone. It's Leon. Before we start this episode, I wanted to let you know about a book I wrote. It's called "The Four Questions Every Monitoring Engineer is Asked", and if you like this podcast, you're going to love this book. It combines 30 years of insight into the world of IT with wisdom gleaned from Torah, Talmud, and Passover. You can read more about it, including where you can get a digital or print copy over on adatosystems.com. Thanks!
Leon: 00:25 Welcome to our podcast where we talk about the interesting, frustrating, and inspiring experiences we have as people with strongly held religious views working in corporate IT. We're not here to preach or teach you our religion. We're here to explore ways we make our career as IT professionals mesh - or at least not conflict - with our religious life. This is Technically Religious.
Josh: 00:45 A few weeks ago, the world watched helplessly as one of the iconic buildings in Paris, the Notre Dame cathedral burned. While this event was notable for many reasons. One of the things that struck us here at Technically Religious was a response by one of the bystanders, who understood what was happening on the ground. He said,
Leon: 01:04 "The fire department in Paris followed a protocol. Save the people, save the art, save the altar, save what furniture you can, then focus on the structure. In that order. They know what can be rebuilt and what can't."
Josh: 01:17 Now that smacks of a disaster recovery policy to us. But I think we in IT might look at it differently. Which is what we're going to do in this episode. Joining in the discussion with me today is Leon Adato.
Leon: 01:31 Hi everyone. And of course, the other voice that you're hearing is Josh Biggley.
Josh: 01:35 Hello. Hello.
Leon: 01:36 Okay, so I think the first thing, because we're talking about disaster recovery, is let's get our terms. Let's define our data library and differentiate between redundancy, high availability, disaster recovery, risk mitigation, all those things. So do you wanna take a crack at it? Do you want to just collaboratively? Do this?
Josh: 01:58 I love redundancy. And in this world of cloud, I think redundancy is the thing that we do really well now because you know, you can set up a system that is in two regions and so if one of your regions fails here, the region will pickup, you can do a multisite region. Redundancy to me feels like a descriptor that actually bridges across HA and DR and risk mitigation. Um, yeah, redundancy feels like a catchall term, right? It's not something you can achieve. I don't know. What do you think, Leon?
Leon: 02:36 All right. All right. So I think redundancy at its simplest is "there's another one of them." There's another
Josh: 02:42 Oh, like RAID
Leon: 02:43 Yeah. Okay. Right. There's like RAID, you know, having multiple disks - RAID 0 - which is just having two discs, one backing up the other constantly. Or RAID 5... any of the other flavors of raid. So I think redundancy means "having more than one" and yes, redundancy can fit into a high availability plan. But high availability is more nuanced. High availability means that no matter what happens, the "thing" - the service, or the the network, or whatever, is going to be available. That can also be done by doing load balancing. It can also be done by, you know, in networking terms, channel bonding, so you can have those. So redundancy by itself is just "more than one of those at a time." So if one fails, the other one is still going or can take over. But high availability I think has more flavors to it. And then you have disaster recovery. That means that all your beautiful efforts at high availability have failed and it still went down. And so now you're left trying to recover from the failure. But at that point the failure is done. It has occurred, the system has crashed, you know, the meteor has hit the data center. Whatever it is and now you're trying to rebuild or pick up the pieces or whatever it is. Then you have risk mitigation, which sounds a little bit like, "We believe that this disaster could potentially occur, and we want to see what we can put in place to completely avoid the disaster, but we're going to do that ahead of time." So in the case of the Notre Dame fire, it might've been, you know, a sprinkler system. Just something like that. Like that would have been a nice little risk mitigation idea.
Josh: 04:37 You know, I wonder how many of those risk mitigation things that we do on our lives are really, uh, to make us feel better.
Leon: 04:46 Okay. So like the, you know, security theater kind of stuff,
Josh: 04:50 Right, right. Yeah. Like, um, you know, locking your front door. I mean, if someone really wants in your house, they're just going to kick your front door down. I mean, if the police want in, they're going to get in, you know? No deadbolt you pick up at home depot is going to keep them out. Right?
Leon: 05:08 No. Um, and, and I know this is a topic that Destiny Bertucci would love to be part of because this is one of her big things. But, so the thing about the dead bolts in the house, it's first of all, they don't need to kick down the door because you have windows. And I don't mean the computer system...
Josh: 05:24 Ha ha, ba dum bum!
Leon: 05:26 Yeah, we'll be here all week folks. So the thing about deadbolts is that it is way of avoiding, I guess, avoiding risk. It's a deterrent. It's not a protection. I saw some statistics recently that said, unless there was something specifically in your house that that individual wants - you have a Renoir, or a priceless Monet painting, or something like that - then they're just looking for what can get quickly and easily and a deadbolt is absolutely an effective deterrent because breaking a window is too risky and too loud and too noticeable. And if the door can't be easily opened, they'll move on to the next house or structure, where the pickings are easier. Or they'll walk around the house. And I've seen the statistics in neighborhoods where I've lived, that's occurred. Where they tried the front door, they tried the side door, they went around to the back door and "oops!". That one didn't have [a deadbolt. because], "who would go to the back door?!?" Everybody who wants to get in your house would go around to the back door. YOU go around to the back door right when the front... So everyone goes around. So having a dead-bolted system on all of your doors is the most effective deterrent to that. But I think we've gotten a little off topic, you know, in terms of Notre Dame. So I think we've defined redundancy, high availability, disaster recovery, risk mitigation... but what they're talking about, what they talked about in this whole, "first save lives and then save the art, and then save the...", you know, that's different.
Josh: 07:05 Yeah, it is, isn't it? Because they almost - well not almost, they gave a priority to specific items. Right? And I appreciate the fact that they said "save lives," lives are irreplaceable. So..., and there are things, there are some beautiful things in that cathedral that were also irreplaceable. Right. But you know, to their credit, human lives come first.
Leon: 07:31 Right. And, and I think that that's a pretty obvious one. After that though, taking the priority of lives, then art, and then, um, sorry I'm going back and looking at it... right. "Save the people, save the art, save the altar, save the furniture, then focus on the structure." So, you know, why did the roof, you know, get so hot it melted? Because it was just not part of the protocol... They hadn't gotten to that part of the protocol yet. And also what was said later was that not only is that protocol in place for overall, but it's in place room by room.
Josh: 08:06 Oh, interesting.
Leon: 08:09 I think there's an order of which rooms they tried to get to first. Again, looking for people. Once they knew all the people were safe throughout the structure, then they were going to specific rooms and looking for specific things to make sure that they could get those out before they moved on to the next category or even the next room. So I find it all fascinating. But the other thing is, do we do that in IT? Do we set up a protocol for which things we save first?
Josh: 08:42 You know, I'm thinking back and I don't recall ever having a, "Howell moment" and by Howell I'm referencing Gilligan's island and the Howells and the, "Oh deah save the furniture first!" you know,
Leon: 08:58 Save money, save the money!
Josh: 09:01 Yeah. I don't know that we've ever had one of those situations. Now, I will say though, we've taken risk mitigation efforts. Back in the days of doing tape backups, you would keep.. now if someone here isn't, you should, but you keep your backups offsite, you would move them to iron mountain and other similar facilities.
Leon: 09:26 Well, and, and bringing it forward a little bit, the 3-2-1 policy for backups, which is you have to have three separate backups, physically discrete backups, on at least two different kinds of media, with one of them being offsite. And offsite can be cloud, that's okay. But you know, 3-2-1" three backups to different media, at least two different media. One that is not where you are. So I would say that there is an order, but I think it's almost so self evident that we don't bother elaborating on it, which is: Save the data first.
Josh: 09:59 Oh absolutely.
Leon: 10:00 Yeah. So data in... Okay, and we're not talking about a fire in the data center, which changes the nature of everything. But you know, the first thing is save the data. The data equals lives in the Notre Dame protocol. If we, if we want to say it that way. And maybe the application is, you know, art, if we want to think of it that way, like the next thing. Once we know the data is secure, then save the applications, make sure, and by save I mean make sure the application can keep running, post disaster, post outage, whatever that is. So, we're both network folks and, we'll say "the network has gone down," All right? The main circuit out to the Internet, to our customers, whatever that circuits gone down. So what's the first thing? Let's make sure the data wasn't corrupted. Now, we might make sure that that happened before the outage by making sure that the system of rights is, you know, won't get caught in the middle of something that we're doing. Whether it's the particular kind of logging on the database or what have you, that those things are taken care of. But make sure the data's fine. Then make sure the application can get out to... "the signal must flow." The signal has to keep going. So can make sure the application is okay. Maybe the next thing in an IT version of that protocol... Uh, I don't know what would it be?
Josh: 11:32 So, you know, we've talked about keeping the data, we've talked about getting the application out there. Then it's, "can I get the people who need to be connected to it, connected to it." So one of the things when you have a major disaster, is you're often worried about addressing your largest customers and getting them back. But maybe you've got a remote workers and you don't have the VPN, so they're not going to be terminating in your, your new data center. Or swinging those circuits, those VPN tunnels from your original data center to your new data center. Maybe that wasn't part of your disaster recovery plan. So all of those things I think that's the, "Okay, now, now go get all the bits that make the, make your application experience comfortable. And again, I'm a remote worker, you're remote worker. So being able to connect and provide the support to the business is very important.
Leon: 12:32 And I can get behind that in terms of, like, we're the furniture.
Josh: 12:34 Yeah. I mean we've been sat on before. It's all right.
Leon: 12:39 Right. Sat on, stepped on, brushed aside,
Josh: 12:43 and knocked over.
Leon: 12:43 Yeah. Right. Yeah, sure. And I think the structure is, it literally that, it's the organizational structure. Make sure... but that's last because it's the thing that can be rebuilt easiest. The other thing about the Paris, the Notre Dame issue was the other comment: They knew it could happen and by that they knew it would happen again because Notre Dame was trashed back in the French Revolution or "The Terror" as someone referred to it. But the thing that was interesting was they weren't making any meaningful changes to Notre Dame even though it had happened before, and they knew it could happen again. And again, I find this fascinating. I've talked and written before about black swans in IT. You know, that really big event where "the application crashed and we couldn't sell widgets to our customers and we lost blah, blah, thousands of dollars." And you know, all that stuff. "And now we need to make sure that never happens again!" Okay. Yeah. But it was a meteor falling on the earth. I can't... why are we spending time even talking about it? And yet businesses spend lots and lots of time trying to protect themselves from the next Black Swan, which is going to look just like the last Black Swan, even though that one is a black swan because it was unpredictable. So why would they not make meaningful changes?
Josh: 14:09 So, I wonder about that, right? Like why would we not make meaningful changes when we know that something has happened? And I think you've nailed it there. These are black swan events. The chances that, the realistic chances of "The Terror" happening again, were reasonably small in the grand scheme of things. They also knew that the cathedral itself, although it is iconic, it can be rebuilt. So get the things that will go into the new building and in the new building will have new designs. So here, a tale from Mormonism. The Salt Lake Temple was one of the first buildings that was built in the Salt Lake Valley - major building that was built in the Salt Lake Valley after the Mormons moved there from Nauvoo. And when they got there, they built this temple out of stone that was quarried from the nearby quarries. That temple has stood the test of time. It's, it's been there for, uh, geez, I don't even know how many years. Well over a hundred years at this point. They are shutting the temple down in the center of Salt Lake because they are going to make some changes. They're going to redo the foundation, which at one point had cracked, and then they had to tear it out well before the temple was finished and then put it back in and then finish the temple. But they're going to protect the temple from seismic events. And not that, not that there's ever been a major earthquake in Utah, but you know, there could be, and it's hard to take such a landmark off the grid. People literally from around the world to see that that temple and downtown Salt Lake. So I imagine those changes to the Notre Dame cathedral would have been equally... uh, no, let me rephrase that. They would have been more impactful to a tourism around that facility and the worship services that go on in there.
Leon: 16:21 So, yeah, not that Notre Dame doesn't undergo renovations. In fact, this all occurred during a renovation. They certainly were renovating. I just, I wonder about, why not a sprinkler system or whatever. Although, as I sit there and I say it to myself, again, working in IT, well, why don't we put sprinkler systems in our data center? Oh, that's right. That's why we don't do that. And you know, the art, the paintings, the whatever, you know, maybe
Josh: 16:51 The servers
Leon: 16:52 The servers. Yeah. The wiring, the electricity. A water suppression system would probably be be more damaging than not, than the fire, which I guess people feel that they can outrun. And they did, in large part. You know, they really did. And also that the next step up, a halon system is simply not possible in a structure the size of Notre Dame.
Josh: 17:27 I think the key here, though, is don't make any changes because once you make changes, you introduce variables that you can't control. Like really, "no deploy Fridays"? They're a thing. I mean, they should be a thing.
Leon: 17:39 So I hear that, although I think that Charity Majors, from Honeycomb.io, is on a campaign for getting rid of that. But...
Josh: 17:48 I'm just going say she was the one I was thinking about when I said that, I was thinking "Charity is totally going to kill me."
Leon: 17:53 But I will say also that she is presupposing that there is a vastly different architecture in place than A) the kind of structure that Notre Dame is; and B) the kind of day to day small, medium, even large size businesses, but sort of the, the monolithic businesses that we, you and I, are used to working in, I think that she's presupposing that's not the case.
Josh: 18:21 Most definitely not. Right. I think if the equivalent of a of honeycomb in architecture would be something akin to.... Boy, I can't even, I I have no idea. I'm like what, what would change as often as an environment monitored by honeycomb?
Leon: 18:43 Yeah. So neither one of us is architect enough to come up with a good analogy, but...
Josh: 18:50 I have one!!
Leon: 18:51 Oh, go ahead.
Josh: 18:51 What about a 3-d printed house, one of those ones you can build in a day that like puts the concrete down? I think if you had something like that,
Leon: 19:01 ...if that was the case then you wouldn't worry about you. Yeah. You'd deploy changes all the time because you just reprint your plans, right?
Josh: 19:09 "Oh honey, I think we're going to put an addition on this afternoon." "Okay. Hit print." All right. There we go. So Honeycomb is like a 3-D printed house.
Leon: 19:20 There we go. I'm going to tweet that and see how quickly Charity jumps on there to tell us "erm, no!" Okay. Um,
Josh: 19:30 I have a question. You mentioned to me, when we were talking about this episode, about this comment about the "long now in action" and how that resonated with you. Tell me only, what was it about that phrase "the long now?"
Leon: 19:45 I loved the idea - and just to put it in context from the tweet (and we'll have it in the notes from the show.) But the original comment, "They know what can be rebuilt and what can't." (I'd said that before) "...the protocol has been in place since the last time the cathedral was destroyed. Sacked during the French Revolution. The steeple and beams supporting it are 160 years old. And oaks for new beans await at Versailles, the grown replacement for oaks to rebuild after the revolution. This is the long now in action. It's what happens when you maintain civilization." So a few more pieces here about why the protocol is in place and how they do it. They actually do have a sense of disaster recovery. They're growing it! There are trees. And in the thread of the tweet that we quoted, the gentleman who tweeted it posted pictures of Versailles with the oaks that have been grown to replace pieces. Now, of course that's also meant to replace pieces that just wear out after a while, or become decayed or something like that. But the entire idea is that they have their disaster recovery. They have their replacement process in place. But the idea of calling it "the long now" - I think in American we call it the long game, right? But the long game has a whole different flavor than "the long now." The long now means that life is happening - now. We are in it - now. But I'm not just looking at this moment. I'm not living for just this moment. I'm living for this moment, and also to ensure that every other moment is able to be sustained or maintained like it. That my children will experience THIS now. They will walk into iconic structures like Notre Dame and have the same experience I'm having in in large part, if not completely. So I just like that. And from an IT perspective, I think that we would do well if we could build in awareness of the long now - and by the way, which things don't need it. Which aspects of our architecture really are momentary and shouldn't be given the "long now" treatment, like Y2K is a great example of not doing that. You're not thinking about the long now, and you're not building in obsolescence into your code to say, "No! At the end of five years, this has to go away. It has to, we have to do something else with it." So that's the opposite of it. I just, I was just enchanted with both the terminology and everything poetically that seemed to be wrapped in with it.
Josh: 22:31 Yeah. And, and as I, as I've listened to you wax eloquent about that idea, I do think that that is it. That is really an enchanting idea. Maybe to make it a little more base and brutish. It's that whole argument of pets versus cattle. And I think Netflix was one of the first companies to really push that idea. Don't get so attached to your tech that you can't kill it off. Right? We've got this dog, her name is Mabel. She's a Boston terrier. She's the purebred. And she is literally the most expensive gift I have ever purchased for my wife. Not because she was expensive to buy. But in the first year of her life, she is undergone close to $4,500 in surgery because apparently Boston's have bad knees. Who would have known?? And so for my pets, for this pet in particular, we're willing to literally move heaven and earth to make sure that she's comfortable. Right. But I also enjoy eating cows and I would not move heaven and earth to save a cow.
Leon: 23:47 You might spend extra for a really tasty cow, but that's a very different thing. So I have long said both in IT context and also in my home that it's not the cost of the puppy that's gonna get ya. It's the cost of feeding the puppy.
Josh: 24:02 Children too, actually.
Leon: 24:04 Yeah. Well that's, it's all of them. Right. Iit's like "but you know the puppy's free!" No, it's not. It's not buying the puppy, it's feeding the puppy. And I think that again in IT, we would be well served to remember which of our projects, which of our architectural choices, which of our things that we do during the day, which of our activities, are cattle and can be really sort of thoughtlessly left to the side. And which of them are pets. Cause I'm not gonna say that all of it is cattle. Not, not everything in it can be treated like cattle. We want to do a certain level of commoditization, but it's always gotta be the things that are intrinsically not valuable that, that we can change it. Another corollary in the Dev ops mindset that, since you've brought up Netflix. Netflix is named, but also, uh, other companies are referenced in a book called "The Phoenix Project." And the Phoenix project also mentions this thing called Disaster Kata. Now a kata in karate terms is simply a set of actions that you take, and you do them over and over and over again until they just become muscle memory. And so they do disaster recovery or emergency or chaos kata. So they practice being in trouble and getting themselves out of it when it's not really an actual problem. So that when there's a real problem, you have that muscle memory, you jump into the situation. And that's true of military training. That's true of true disaster responders. They do the same thing. They practice certain behaviors, so that they don't have to think really hard about them when they come. And I think that we see this in the Notre Dame cathedral experience also. Is that they had done their kata. They had figured out the protocol and practiced it or talked through it so they knew what they were doing. And this was an example of it. And again, we in IT would be well served to think about which types of failures, which types of disasters and recovery actions we would be well served to practice beforehand. You talked about backups a little bit ago, you know, practice your restores. Otherwise you have what has become affectionately known as "Schrodinger's backup." The backup is both there and possibly not there, and you won't know whether it's there until you try to restore it. And if it's at the worst possible time and the answer is "the cat in the box is dead," then you're going to have a problem.
Josh: 26:42 What you have is you have a branding problem. If you don't know if your backups are there or not there, what you really have are "quantum backups!" You won't know what state they're in until you observe them. So just as long as you don't observe it, then you can assume that they're there. Right?
Leon: 26:58 Um, that's, I, I'm,
Josh: 27:00 I'm trademarking that too late.
Leon: 27:02 That's fine. Quantum backup. It just makes it sound far more exciting and sophisticated, and also then management may want to buy more of it. "Don't check it. Don't check it! You'll let the quantum state out! That's we're paying for.
Josh: 27:18 I love it. See, were gonna be millionaires. Millionaires!
Leon: 27:21 We are, but we're also not going to be able to show her face in IT conferences ever. "THERE THEY ARE!! GO GET THEM!" All right. So I want to turn this around to the religious perspective and talk about you know, this idea of disaster recovery, this idea of, what we protect and what we don't protect. Now you talked about how the Mormon temple is being restructured because clearly they don't want to lose it. They can't 3-D print the temple in Salt Lake City. So yeah. So they're not gonna even try to do that. And also they know the hit to the community that it would represent if something bad happened to it.
Josh: 28:03 And historically, the LDS church has been ransacked right? When they were in Kirtland, the Kirtland temple was destroyed. It was literally burned with, well, I won't say burned to the ground, but it was, it was burned and desecrated. So there's, there is a history in Mormonism, even though it's a relatively new religion from a religion perspective, you know, founded in 1830 of having, it's it's sacred objects desecrated by people who were against them.
Leon: 28:35 Right? Okay. So, so in terms of disaster recovery - and again, we'll presume that every church and every synagogue and every temple of whichever stripe or flavor we're talking about, has their own structural, organizational protocol for what to do if the building is on fire - if that happens. But there's other things that had been disaster and disaster recovery. So there's two I'm thinking of, one big and one small. And the big one was the destruction of The Temple (capital letters), The Temple in Jerusalem. And not only was it the building that got destroyed, not only was it the entire organization of the priesthood that was effectively demolished with the loss of the temple and the single focal point of sacrifice, but the religion - Judaism itself - took a hit because at the time Judaism was a sacrifice based religion that, you know, when you wanted to say, "I'm sorry" or "I messed up" or "thank you", the method that you did that through was to go to The Temple, and bring a sacrifice, and the priest would sacrifice on the altar either all or in part, and you would either eat some of it in celebration or not. And there's all sorts of wonderful flavors of that. But you couldn't go do that in your backyard. That was absolutely not an okay thing to do for a variety of reasons that would take too long to go over. There's some wonderful videos that I might link to in the show notes for this episode. But what's Judaism going to do now? The Temple's gone. There's no longer away to say I'm sorry or I messed up or thank you or I'm happy. There's no longer a way to do that. So does the, does the religion just disappear? No. There was a pivot. First of all, the location moved from a Jerusalem to a town of Yavne. And also what happened was a philosophical change that instead of sacrifices on an altar, it became sacrifices of the heart. That prayer took the place of the sacrifice. First and very, very literally by reading the laws of sacrifice. It was analogous to doing the sacrifice. And so every morning in morning prayers, still to this day, Orthodox Jews will read through those laws of sacrifice and the process and the protocol to do it as a way of metaphorically or philosophically saying this is still alive. But also prayer itself. Also, everybody's home has become an altar that on Shabbat, that Sabbath offering that we bring the two loaves of bread and the wine and everything has taken the place of it. So the religion was able to pivot from a very visceral, physical experience of divinity and connecting to the divine to a very, I'm going to say, intellectual and mental connection. And that was a big change. And for the religion to be able to do that was really remarkable. Not to have people just say, "Oh, well yeah, the building's gone. Yeah, that's it. I guess I'm going to be a, you know, I dunno, a pastafarian or, you know, whatever. I'm not trying to offend any pastafarians. The giant invisible spaghetti monster is a fantastic being if or if it does not exist. So that's the big one. The little one though, the little story is actually in the middle of disaster and having this protocol and how it saves more than you expect. So a friend of mine here in Cleveland was telling me a story about his grandfather. His grandfather was a young man in Morocco and, very hilly, you know, a lot of mountains and stuff like that. And they were sort of look in the low lands I guess. And in the spring, you know, the spring melt and the water was coming in. And I guess one of the rivers overran its bed, and the grandfather could hear the water coming at the town, like a flood was coming and he could hear it. And so what do you do? He ran to the synagogue and he grabbed the Torah because you know, that's the thing like, just make sure you have the Torah. Like again, we're not going to worry about the structure. Nobody was in the building, so he grabbed the Torah. Now the thing that you need to understand is: many people have seen a Torah and they see this parchment that is rolled between two scrolls and then covered with a cloth. That is not what a Sephardic - or people from the Middle East, the Spanish country. There, it's in a box. If the scrolls are strung between two poles, but then that's all wrapped in a box itself. A wooden case. So he picks up this case and he realizes he wasn't fast enough. The water is now there. It's coming into the synagogue and it's rising really fast. And he's waiting through this water with this Torah, this huge boxy Torah in his arms trying to get out, and the water just completely sweeps him off his feet and now he's going down the street, you know, still holding onto the Torah. Which is a big wooden box. That holds air inside. And so he's holding it and now the Torah is holding him up. He's floating down the water, this, this deluge holding on for dear life, both metaphorically and physically to this Torah that is keeping him afloat. And it saved him. And on top of it there's a saying that many people say in Hebrew "etz chayim hi lamancha zikim ba" - "It's a tree of life to those who hold fast to it." And that story was passed down generation by generation that in making sure he followed this protocol, making sure he saved that thing, that one artifact, made sure that he was able to survive also.
Josh: 35:11 Thanks for making time for us this week. To hear more of Technically Religious, visit our website, https://technicallyreligious.com, where you can find our other episodes, leave us ideas for future discussions, and connect with us on social media.
Leon: 35:24 We didn't start the fire,
Josh: 35:26 ...but you can be damn sure we're going to be asked to pull an all nighter to fight it.