There's an old joke (and a famous website) comparing programming languages to religions, but the analogy is truer than it might seem at first blush. Logic structures are everywhere in scripture. Pair programming strongly resembles the intensive 2-person style learning found in all orthodox Jewish Yeshivot.In part 2 of this conversation, we continue to explore how your religion - the one you grow up with or grow into - is very much like a module you've inherited as a code owner. Listen or read the transcript below.
Leon: 00:00 This is a continuation of the discussion we started last week. Thank you for coming back to join our conversation.
Josh: 00:06 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.
Leon: 00:29 Um, I'm curious about, uh, again, some of the things, you know, the ways that we look at this, for example, uh, with consequences. You know, if you, if you do, if you are that cowboy coder and you break that module, you say, "Ah, I can write a better one of these and I can...", You know, and all of a sudden what happens? Like the entire code is an operable and I think that religion has a similar thing. Somebody who comes in and says, uh, you know, I know that there's these religious tenants, but we don't have to do this thing that's not important anymore. And the whole thing falls apart.
Josh: 01:05 Hey, Mormon Mormonism had that.
Leon: 01:07 Okay. In what way?
Josh: 01:08 Well, so Mormonism was founded on the idea of a, of restorationism. Um, so that the, the idea of, um, truth had to be restored. And one of the truths that was restored by Joseph Smith, the founder of Mormonism, was the idea of, of polygamy. And that was carried on after his, his, uh, death, uh, murder martyrdom, however you wanna frame it, um, in a, in a jail. Um, and Brigham Young carried that on. So, you know, Joseph Smith had like 34 wives. Um, Brigham Young had 57, I think, some number like that, but when Utah wanted to become a state, um, the US government said there's no way. We are not letting a bunch of polygamists, um, uh, obtain statehood. So in, um, the mid 1890s, 1895, I think, um, Mormonism dropped polygamy. And when they did that, there was a huge rift that was established, uh, in the church. Um, there today there are Fundamentalists, uh, Mormons or Fundamentalist LDS, um, who still practice polygamy. Uh, even when Joseph Smith was, was killed, the idea was, you know, who's going to take over, um, the church split then the, um, his, his, uh, son Joseph Smith, the third cause Joseph Smith was actually Joe Smith Jr. So his son Joseph Smith, the third, um, started a, another religion. Um, so like these riffs, um, they, they happen and they tear apart, um, really good teams, you know. So again, you know, Mormonism had it right. It was as, "Hey, this thing works really well for us except for we're going to get rid of it..." And it breaks. So when you, when you do that within technology, when you do that within a programming language, when you fundamentally change the core of who a, of your technology, you can piss a lot of people off.
Patrick: 03:09 Nobody likes a fork.
Corey: 03:10 [Background] No!
Josh: 03:10 Nobody like soft fork.
Leon: 03:12 Oh, he took it. Okay.
Corey: 03:13 Yeah. Patrick got it. Before I could, yeah. This is, this sounds exactly like you're forking or branching off code eventually off of, you know, GitHub or do you think about just Linux in general? I mean, especially apropos with Josh, uh, talking earlier about, you know, being scared of Linux, you know, this is, this is exactly what Linux did. You have your Debian and you have Red Hat and you have Minz and you have Cinnamon. You have all of these things because everybody has said, oh I can do it better or I can do it, I'm going to do it differently. Or you know, and it's just this chain that comes on down. Our open source projects have this all also, I mean the number of times I've had, you know, to especially in my current job to hey this, this one feature works great man, I needed to do this other thing that I will, I'll just fork it and just use it for my own purposes.
New Speaker: 04:03 [inaudible].
Leon: 04:04 yeah.
Patrick: 04:05 Isn't that the point of theology really? Which is you have four different projects that are all forked from the same root. And there's a lot of people who will love to be opinionated and argue with you all day that their one particular implementation implementation is the one true and only implementation at anyone else who gets excited about anything else is obviously wrong. But the reality is that they are all forked from a common set of service requirements. And that th that really the point of theology is to establish some base, uh, almost, anti-patterns. Exactly. But a set of a set of common frameworks that everything else descends from and as long as you can see it from those original design requirements, then you don't have to worry so much about the specifics.
Leon: 04:54 Right. So I, yeah, I like that idea that, that religion in in one respect is establishing both patterns and anti-patterns and saying, you know, this, these are the things that work well and you know, or tend to work well and that's uh, based on observation of Millennia and the wisdom of the sages of the language that's doing it or the religion or whatever. And here's some anti-patterns that we've seen and here's why. So I think that that's, that's good. I was also thinking about, again, back to the idea of consequences that um, in code, you know, we talk about bad code and you know, uh, you know, the program just doesn't run, but that's not the worst thing that can happen when you run bad code. It can actually destroy the host system. You can actually do physical damage to the system with bad code. And you can certainly wreak havoc with data, with the, with the tribal knowledge of a corporation. With bad code, you can delete entire databases and you can, you know, you can really lose the essence of what's going on. And I think that people who try to take a religion or a religious, uh, philosophy living structure and then bend it to their will and change the foundational principles really do end up destroying the host system, in this case, the society. Um, and they have, you know, they have the risk of destroying the data that sit, that societal knowledge of how we do things, the, even the societal identity of who we are, um, that religion poorly implemented can have that, can have that consequence. Um, so I think that there's, that that similarity again of, as, as programmers, we know that there's actually a lot at stake if we, if we don't test, if we don't implement correctly, if we don't follow, you know, I would say proper procedures, best practices, that it's more than just, oh, your module didn't run, "Haha. Sucks to be you." Like we can really like mess up badly. Y2K is a great example of the potential risks of what could have happened.
Doug: 07:03 And one of the advantages that you get them is as coders because I can really mess things up. [Don't ask me how I know]. Um, but as a result, when you take that into, when I take that into my religious life, I'm careful with how I handle the attributes of my religion, the beliefs of my religion. I have been known in some conversations to go ahead and question people who were really, really solid in, uh, you know, in their belief of something that was wrong and really irritated some people. And, and I'm more careful about that now because I now know that I have got the capability to break things, to break people, to actually make their lives worse. Um, if I go ahead and use what I know about how my religion works, how my code works to essentially make it, make things break. So I'm really careful about drawing people out to make sure that they really are making a mistake. It used to be that I would assume that if something went wrong, it was probably somebody else on the team. I now assume it's me. I mean I'm in nine times out of 10, I'm right. But so I'm much, much more careful about how I do what I do in coding. But I'm also very careful about how I do what I do in my religious community cause I don't want to break that community.
Leon: 08:21 All right, so I'm going to ask you folks, cause you guys are, our programmers are real programmers on a Script Kiddie. Um, how often have you had this really elegant, really concise, incredibly compact piece of code that you realized you can't put into the final program? You need to expand it out, make it longer because you knew that the people who are going to come back later to troubleshoot weren't going to understand your super duper concise version. You needed to expand it a little bit and is not the code version of putting a stumbling block, stumbling block before the blind.
Doug: 09:00 Yes. Many times. I mean one of the, one of the tenets is the person who kind of come into code later. You're never going to be as smart as the person who wrote it in the first place. So you really need to write it for a dumber programmer cause that person coming later. Maybe you mean? Well now when I was teaching programming, I mean I actually had a really beautiful piece I used to call it, I was teaching c and it it would take a digital number and turned it into binary and it was like a two line recursive piece of code that was just, I mean I called it programming poetry. Um, none of my students got quite as excited about it as I did but it's nothing that I would ever put into a real piece of working, uh, code because most people have trouble understanding recursion to start with and this stuff was so spare that it just, you had to spend a half an hour just to finally grasp what it was saying. So the, the trick is to go ahead and find something that works but that regular people can understand as opposed to you on your most brilliant day.
Corey: 10:01 I mean we have a similar thing though in in Judaism. I mean you, you always think about there are patterns that we always, that we have to follow. We have these set lists of things, you know, uh, solid principles Uncle Bob Martin has yeah. That, that we follow and these are your journeys and we have ideas at the rabbis, you know, either you're added safeguards and those are pretty much what our design patterns...
Leon: 10:31 OK, right.
Corey: 10:31 ...are, this, these, these rules. And of course, one of the fundamental rules of this all is you're not putting a second one on top of one on top of another decree. Basically, you're not putting a pattern around another pattern that that's just, it's in and of itself, its own anti pattern.
Leon: 10:49 Right, right. You don't put a fence around a fence.
Corey: 10:51 Yes.
Patrick: 10:52 That would be nice and code. Yeah.
Leon: 10:54 Right. Because yeah. Too many layers of, of extra, um, ...
Corey: 10:58 Too many layers of that distraction. Yeah. I mean, as an example, I remember I was on a project where the, the project that the code was, the project was supposed to have been delivered six months earlier and the guy who was their architect had spent months just doing the architecture and he had over architected it to the point where even the simple html tag was its own function and it, it bogged down the system and it just made it so impossible to where it looked beautiful. But it was so impossible to work with and to actually create the code that no wonder this project was running so late.
Patrick: 11:41 OK, there are no, there are no zealots in software.
Speaker 6: 11:43 Okay. There shouldn't be. There are certainly are.
Patrick: 11:48 Right. Well, what if, and this goes back again to the kind of community aspect of great, like what if the best religions are the ones that are religions of attraction in the same way that the best projects are the ones that are project of attraction and there is no right or wrong, um, what there actually is as a sense of fellowship around a um, um, a goal. And that those projects which tend to drive the most engagement are the ones that are most welcoming and where there are this disparate set of voices, each with their own opinion. And there is no, you did this right, you did this wrong, you are an elder, you are new to this. And instead that the projects that are the most successful with technologies are the ones that build fervor, naturally because people are just excited to be a part of it, right? Like that. And that as the ultimate anti pattern that removing judgment from it and letting it be a project of attraction is the one that builds really healthy communities around a particular type of technology that actually survived.
Leon: 12:50 Right. And, and I'll also say that to your point about judgment, that uh, both religion and programming, um, individuals come, come to those groups and they say, I want to improve, I want to be better. But there's a really big responsibility and there's a, there's a dance that has to be done about giving correction. That, in religion, Doug, this goes back to your point about being careful about what you say and Patrick, what you just said about you know, about code, that if, if I invite someone to say, "Hey, can you evaluate my code? Can you, you know...?", I'd like you to look at my, you know, lifestyle, my choices and offer your perspective on it. That's an invitation. If that invitation is not extended, someone who offers uninvited their correction, whether it is code or religion, is really crossing a line and has a very real chance of driving that person away in both cases.
Patrick: 13:51 Right. I think, not to drop the observability word here, but I will...
Leon: 13:56 There we go!
Patrick: 13:57 So much of it ends up being like, how do you instrument a religion, right? Like, is it, are you looking at, you know, are you looking at latency? Are you looking at CPU utilization and memory? Right? Is it about how it affects the end user or is it about you? And like a, a bunch of really discrete metrics about the infrastructure. Because if you measure something, let's say, what is the 'peace' metric here? Right?
Leon: 14:20 Okay.
Patrick: 14:21 What is the faithfulness metric as opposed to, oh, I do the Hokey pokey and I turned myself around and I get up and I get down at the right times and I say all the magic right words. It's like where do you put the metric on it to determine whether it's doing the most good or not or whether it's the best for you or not. So there's an opportunity to uplevel. I think we tend to get way too granular into the practice instead of the outcome. Oh, and I'm talking about code now in technology, but yeah, I mean like putting, putting metrics in place that are not sort of minimum acceptable performance metrics, but instead like, where's the delight here? Where's the thing where we're going to move forward? And those tend to be more crowdsourced, end-user focuses. And not so much about everyone who's already converted or everyone who's already practicing the right way. But like people who were new to it. Like is this actually something that a community would want people that would be attractive and would draw people to it? Or is it insular and it actually excludes people? Or it makes you feel like you're always trying to catch up, uh, because you're afraid of being judged?
Leon: 15:23 Right. But I will say that in both religion and code, there's the aspect of people wanting to work hard at it. The, the joy doesn't mean that it caters to the lowest common denominator and makes everything easy and low risk and low work and low stress. That both religion and code work best when you're asking people or you're offering people an opportunity to grow. And that means sometimes facing some relatively uncomfortable elements of themselves, but not in a way that breaks them, It's in a way that strengthens them.
Patrick: 15:58 but aren't, they aren't the best projects. The ones where you can get to 'hello World!' 10 minutes after you, uh, get clone. Um, but also the ones that you can spend hours every night digging into the code base with more and more detail and opinion and history about why the thing ended up the way it was like aren't the best projects, the ones that are open that there is no idea of this person is an expert and this person isn't and it's accommodating to people who are interested in technology and excited about automation and learning how to, to really think beyond a prescription and get to the part where they're using their passion and it doesn't matter and you don't judge them for you, you welcome them to the project regardless of of their experience level?
Corey: 16:44 Yeah, I mean that's one of the key things that I, I've had to adopt being a team lead now at my company is I've got a number of developers who have far less experience than I do it. It's a matter of not just getting them up to speed and making sure that the team is enjoying the process and make sure everybody is excited. I mean, we work on the accounting module and accounting, you know, you can get kind of boring.
Leon: 17:12 It's not the sexiest module in the program.
Doug: 17:15 Hey, hey, hey, I like accounting.
Corey: 17:19 Yeah. I mean, Hey, I'm Jewish. I love counting money.
Leon: 17:21 Oh God!
Corey: 17:21 Also, don't get me wrong...
Leon: 17:23 Corey!
Patrick: 17:25 We should have video for all the head shaking.
Corey: 17:27 Do we have a legal department?
Leon: 17:32 [Groaning] OK, keep going
Corey: 17:32 But there is that, that, that element of having to bring people in and making sure everybody is taken care of. Then leading back to what Patrick was saying that I want to make, I need to make sure as as the team lead, that everybody's in the right place and everybody's in a good place for it and for this project to move forward and for us to all collectively get this across the line and get to the end where we're supposed to be.
Doug: 18:01 Evangelical Christianity when it's done right, in my opinion, of course, but because of course I know what's right, you know, uh, but evangelical Christianity when it's done right is both welcoming in the beginning, but has that ability to grow and your joy and everything increases over a period of time. Evangelical Christianity as it's portrayed generally in, uh, the media and in most people's minds is that whole judgmental hitting you with the Bible. You know, you're a terrible person judging the world. Uh, and it's unfortunate that, that, that's the impression it's gotten. But that's because there are a number of people who are Evangelical Christians who feel it's their job to fix the rest of the world. The reality is, it's like in the Christian world, we're not supposed to be judging the world. It's not our, that's not our bailiwick. It's not my job to go ahead and fix everybody else. We're, we're actually supposed to fix ourselves. You know, when you come into the Christian community, you're, you're essentially are guided by the community and to grow in that community, but your job is not to go ahead and fix everybody that's outside.
Leon: 19:13 Okay. So I think that puts to bed, uh, some of our ideas about the ways in which our religions are like our programming lives. But I don't think it's a perfect match. I think there are situations in which it does fall apart. Um, for example, we were talking about consequences, you know, of our choices. And while there are a lot of similarities, I don't believe that a core memory dump is the same as spending eternity in hell for those people who have such things. So, um, what are some ways in which our religions are not like programming? Where does this not stand up?
Doug: 19:46 With consequences?
Leon: 19:48 With anything.
Doug: 19:48 I'll tell you. Well No, I'm gonna say with consequences because the, there's a couple number one, 9 times out of 10, if you screw up in code, you know, like really soon. I mean, if you're working in a compiled language, it doesn't compile. If you're, you know, you run your tests, your tests fail. I mean, you find out right away. You can sin really badly in most religions. And it doesn't, the reason why we have televangelists that sleep with their secretaries for months and months is because you don't, God does not immediately hit you with the lightening bolt when you screw up. So the, the, the consequences in religion tend to come at a longer range and people being not quite as focused as they should be, might think that they got away with it. Uh, whereas programming is a lot. Um, it's, it's kinda in your face. Now. It is possible to have an era that doesn't show up for years later. You know, they do exist, but for the most part, if you screw up, it hits you in the face, right now.
Leon: 20:50 The feedback loop is much tighter. Okay.
Doug: 20:52 Really tight.
Corey: 20:53 The other thing is, I mean, we have, you don't have too many people bouncing between religions as much as you have people bouncing between coding languages. I mean, in a given day. Sure. I'm primarily a .Net developer, but I work with Angular. I've worked with, I work with SQL, all these different languages and you know, bouncing between them like, oh, this cool feature on this. Oh, this cool feature on that one. And so, you know, you don't really have that as far as the religious context goes.
Leon: 21:23 Fair enough. Okay.
New Speaker: 21:24 So I'm going to be adversarial here. I'm going to disagree with Corey and I'm going to agree with Patrick. I think that more and more in the world we're seeing people who are bouncing between a religious observance. Um, and, and Doug, I'm going to be a little oppositional with you as well. Um, if I, I think, I think people who are in high demand religions, um, have a very clo...or very tight feedback loop. Um, you know, so for example, within Mormonism, uh, in order to go to a Mormon temple and LDS temple, you are required to have a temple recommend. That is something that is issued to you every two years after you, uh, go through, uh, an interview process where there are, I think 12 questions that, uh, assess your, your spiritual and physical, uh, worthiness. Um, if you screw up, um, like, I guess I did when I said I didn't, I no longer believed they will revoke that, um, temple recommend. And you can no longer attend the temple. So there are definitely religious observances out there. Um, I call them high demand religions. And where there, there is a very tight feedback loop. Uh, Jehovah's Witnesses. If you are deemed unworthy by the Council of the Elders, um, you are shunned. Uh, and those are two between Mormonism and, uh, and Jehovah's Witnesses. Those are two that I'm very familiar with. So I, I think that, I mean, maybe there are some religions that are really like code and that the, that that feedback loop exists. Um, and so, I think fundamentally we have a problem here, uh, on this podcast and that is that we have self-selected some people that are rather altruistic, um, and have a very broad view on both religion and technology, right? What we need here are we need some very coarse fundamentalists. Um, some people who are very dogmatic.
Leon: 23:30 [Laughing]
Josh: 23:32 Um, I mean, maybe we're talking about going up to the Linux forums as Patrick suggested earlier.
Leon: 23:37 Oooo...
Multiple people: 23:37 Oh yeah. Oh,.
Leon: 23:39 I feel called out.
Patrick: 23:40 Okay. Apple forums.
Multiple people: 23:41 Apple, that's worse.
Josh: 23:45 [Laughing] It really, Oh, you know, we're, we're, we're talking about, um, in a very pragmatic and, uh, holistic way the way that we want religion to function. The reality though is if we look out into the world that's not the way that, that religion necessarily functions. Um, you know, there's a reason that there's a really bad church in Florida that, um, travels around the United States, uh, shaming and shun...., Shaming people for things that they do. And I'm not even going to mention their name cause I just don't like them. But those people are religious. And for those who are listening, I am air quoting, you know, my little heart out here. They are, they have a very profound religious observance but they would not fit in well with this group here.
Leon: 24:32 But I would, I wu... I would also argue that that flavor of whatever of lifestyle is exactly, we are talking about with consequences that a religion where you've changed the base tenants and you've started to really veer away can actually do damage in the same way that code can ruin, you know, a societal structure or it religion can ruin a societal structure that your code can ruin your data structures. Um, I wouldn't call that a[n] effective or even a legitimate, uh, religious expression, and I've realized that I've alienated them and I'm okay with that. Um, I would, I would also say.
Doug: 25:12 They're not going to like you!
Leon: 25:12 that's fine. I'm good with that. I, I consider that a plus. Um, I also think that, um, to a few points that were brought up, the bouncing between religions, I think that there's a difference between people who bounce between basically, I won't say fundamentally, but basically Christian religions going from, uh, and, and I'm going to, I'm going to express in betray my lack of nuance when it comes to Christianity as a whole. So feel free to dog pile on me if I'm really wrong on this one.
Corey: 25:45 [Background] You're wrong!
Leon: 25:45 Thank you! That, I want to point out the other Jew just did that, but um, to say that, to say that, you know, bouncing from say Presbyterian to, uh, to um, Catholic to something else is a lot different than bouncing from Buddhism to Judaism to Hinduism that, that you're really, you know, those are some radical shifts, but you can have somebody who bounces from say Perl to C# to say Delphi and you know, very gracefully goes between those,...
Patrick: 26:24 What if it's not about the language at all, right? Maybe it's about what if it's about service requirements, right? And that the demarcation, um, much like with an app server where it's requests come in and then the code itself is abstracted by whatever happens on the back end. And so what the requesting client sees a request and they see latency and they see data completeness or resiliency or availability. These are all things that they see. And then the actual code behind it, the, the design patterns, the way that it was compiled, the unit tests that were part of that acceptance delivery, the way that it was deployed, all of that is concealed to the end user, right? So what if at the end of the day, it really is just about the services that you deliver and that the way that way we choose individually to make the sausage that delivers that service don't matter. What if it really is about the service delivery and that taking yourself and your theology and your dogma out of that interface is what actually delights users, is what actually encourages people around you to hang out with you, to engage in conversation and the rest of it, and so that taking that whole idea of opinionated platform, judgment, patterns, correctness away in the same way with application delivery, is the goal. It's how do we measure whether people actually enjoy engaging with us and they don't need the details. And in fact the details distract from an opportunity to have a great interaction and to do, to leave the world a better place than it was. That the details do matter and they matter, especially in terms of being concealed or at least not being forward with the details and said being forward with the service delivery. Not with the details.
Josh: 28:07 Listen, We can't ever have Patrick back on the show. I am just going to say that right now. He is far too levelheaded.
Leon: 28:13 [Laughing]
New Speaker: 28:13 Uh, yeah. Sorry Patrick.
Patrick: 28:17 Well listen, I think about, I think about technology literally 90% of the time, the fervent and my handle. There's no joke about that, but I'm not kidding. I spend probably the remaining 10% of my time thinking about cosmology and theology and morality and the rest of it. Like "Why am I here?" I mean like the whole point of, of, of religion is that we evolved an organ of our brain that is designed to engage mysticism that allows us to go beyond, you know, being 12 years old and realizing our mortality and you know, as a cave person jumping off of a rock because you realize that this whole thing is eventually gonna come to an end. So you have to put something in there like the human experience is about mysticism. So like you're, I don't want to say you're picking a flavor and putting something in there, but like recognizing that it's about that user interface that's for the, the great faiths, the great religions that have been around for a long time. Theologies that that thought, whether it's theologies or it's um, uh, software approaches that were year in and year out. Like if you look at some really great Cobol coders from back in the day and you compare to the code that, that a lot of people are writing now and feel like no one has ever followed this pattern before. Of course we have that. It's that it's really about that longterm goal. And it's really about delivering services. Not about the patterns, the specific patterns that you use or the words that you say or the the verb tokens that you use or how it's compiled, or is it interpreted that doesn't matter. It's like what happens after the demarc point. Thanks for making time for us this week to hear more of technically religious visit our website, TechnicallyReligious.com where you can find our other episodes. Leave us ideas for future discussions and connect to us on social media.
Corey: 30:01 .Net!
Patrick: 30:02 Go but optimized for Google, so GoLang.
Doug: 30:06 Delphi.
Leon: 30:08 Perl!
New Speaker: 30:08 Guys, guys, please, can we just unite against our common enemy?
All: 30:12 Php!