 So, our last speaker is Abraham Sangha. He spoke last year, or year before, last year at Mountain West JavaScript, which was a sister conference to Mountain West Ruby, and he gave just this fantastic talk. And so, again, the good thinking was is, I would really like to know where Abraham is, his head is at a year later. And I really like to leave the last note for Mountain West. I'd love to leave something I can't do what Abraham said last year. And so, I'm very, very pleased and grateful that Abraham agreed to come back and talk to us again, and I'm really looking forward to it. So thank you for coming. Thank you. Thanks for having me. My name is Abraham. As Mike mentioned, I'm talking about TD for your soul. If you're confused, I think that's appropriate. I'm going to explain exactly what I mean by that. But you can tweet. I would love to hear your comments, critiques, whatever you have to say. Let me know. As I would say to my friends, get at me, you know, just let me hear it. So, TDD for your soul, virtue through software development. TDD, I'm assuming everyone here knows what that means, but just in case, just quickly review, we can summarize it with three steps, red, green, and refactor. Red is writing a test or a spec that fails. Green is writing the code to make that test or spec pass, meaning green, and the third step is refactor. Refactor is changing the code, improving it for readability and elegance while maintaining the behavior of that code. That's the refactor step, and then you start over again at step number one. So that's TDD or test-driven development. Now what's the for your soul piece? Oh, sorry. So how TDD helps me is when I'm at this stage in software development where the world is my pearl, every option in the universe is available to me. I just don't know where to start. Often it helps for me to start with writing a spec. And I like how David Stelz put this on a blog post. He said it's about figuring out what you're trying to do before you run off half-cocked to try to do it. And so there's some intentionality there. There's a purposeful step in writing a spec. Now I didn't explain the for your soul piece yet. So what does TDD for your soul mean? What it means, let me illustrate with an example from one of the greatest characters, modern TV, Walter White. How many people know who this is? Okay, I guess good. We're on the same page. You can never be sure, you know. But so Walter White, he's a genius. He's a chemist. He's also an engineer, it turns out. But he uses his powers not for good, but for evil. He builds a meth empire. It's that I'm not giving away anything by letting you know that. And so science is not a self-directing process, right? It can be used for good and it can be used for evil. And so as people that are involved in science and technology, we had the same opportunity to use our powers for good or for evil. And what I propose is that we need a lot more good in this world. And these people in this room, if we all united under that vision, I think we could do a lot of good in the world. So that's sort of the premise of my talk, TDD for your soul. Now, let me just be clear. I didn't get into software development with these lofty thoughts in mind. And if you work with me, you say I don't even live up to them. So glad I'm coming all the way out here to Salt Lake City to give this talk. I'm from Chicago and I appreciate that. But when I got into coding, I had much more base desires, right? I had much more less lofty goals, right? My goal was really simple. I was down to earth. I mean, I got into coding to get paid. You know what I mean? Someone knows what I'm talking about. This guy knows what I mean. I wanted to eat olives out of a goblet, you know? That's what I wanted. That's where I was headed. And what I found, though, that through the process of learning how to code, learning how to develop software, working on a team, being a professional, is that the process of software development was not just a chance for me to grow and my technical abilities. It wasn't just a chance for me to feed my family. It wasn't just a chance to do something fun. It was a chance for me to become the best Abraham that I could be. And so hopefully at the end of this talk, you can see that same path, that same process is available to you. Now, in order to talk about what that means, I'll be using the four cardinal virtues, which, you know, for thousands of years, moral philosophers have discussed the cardinal virtues. Everyone here looks pretty virtuous to me. But I saw some really shady people up in the top. I don't know if you guys have been up there, but so for them, I'm going to explain what the four cardinal virtues are. They are self-control, courage, justice, and wisdom. Self-control, courage, justice, and wisdom. The first one is courage. What does courage have? Sorry, it's going to be self-control. What does self-control have to do, if anything, with software development? Well, you know, my lack of self-control came out quite a bit when I first started learning how to write code. I would be staring at a screen similar to this one, and I would feel defeated. You know, I feel anger, frustration. It's hard because I was by myself, often at Starbucks, trying to learn how to code. And I don't know if anyone else has been in that situation, but it was difficult. I didn't know how to read a stack trace. I didn't know that it was actually giving me clues as to what was wrong. And this is very frustrating. My lack of self-control came out in these moments. You ever see a comment like this on a pull request? I want to see this start to happen after this talk. I want to see this happen. I want to start something. And with self-control to me now when I'm thinking about coding is simply we can look at something like the law of demeanor. The law of demeanor is summarize it. An object should only talk to its self or its neighbors. An object's method should talk to its parameters. That sort of thing. But when you see code like this, this trail of dots, it's possible there's an overreach there. There's a smell. There's something happening there where there's some data. In this case, the string. And why do we write code like this? Well, in this case, it's like, I know what I want. I know how to access it. I don't care if I'm reaching across three, four objects to get there. But the law of demeanor is a constraint that we put on ourselves to help us write good code, to help us write decoupled code. But it takes self-control to participate with that, to agree to those constraints. Self-control in coding also, it's hard to talk about just because in our context, this is the platonic ideal of a workplace. It's hard to talk about self-control with other people when this is what we think about. My dad worked in the sewers in Chicago. I don't think I could explain to him what's happening right here. So self-control. Someone else brought this one up, Michael. But this happened to me last week. My lack of self-control comes out in these situations. Maybe you're there with me. As developers, we want to know what's right and what's true. Not only that, but we need to tell everybody in the comments section or on Twitter. So your lack of self-control could come out at times like this. We all know what this is like. I'm not the only one, hopefully. Let me know. But we oscillate between utter despair and megalomania There's something wrong with that. It's not a healthy way to go about living. So thinking about self-control, there are codes. We can move quickly into thinking about ourselves. Where do we show that we are self-controlled people? What's it about as people? We have all these desires and impulses, inclinations, passions, preferences, and how do we control them? Are we controlling them? Or are they controlling us? That's sort of the question. Are our desires taking us toward a goal that we want? Or are we just letting them pull us in every direction? My dad taught me everything I knew through action movies. That's thousands way. We didn't have a lot of heart to hearts, but we just watched Dirty Harry. So I remember Dirty Harry saying, man's got to know his limitations. That's what self-control is really about. It's about knowing who you are and your particular limitations. It's about being honest about them and regulating them through good habits. That's what self-control looks like. And when we think about being self-controlled and when we write code, we can quickly start thinking about, what does it mean to live in a self-controlled way? And am I doing that? The next virtue is courage. What does courage have to do with coding? If anything, well, you know, I think about coding. Well, first of all, courage. What is courage? Courage is it's an ability to overcome fear, right? And we all have fears. A lot of fears we have are centered around failures. We have a sphere of failure. And so when I'm thinking about coding, it's easy to start thinking about how do we handle exceptions, right? How do we handle errors? So one good way, one good process to think about is when something like this when you're writing a mix-in, how do you handle exceptions? And if the action that you're intending to perform doesn't happen, do you let anybody know? And if you name space errors, if you have custom exceptions, you get a nice stack trace, right? In case something goes wrong, it's easier to debug. I find this to be very helpful. I had a coworker call me over about a month ago, and I wrote a module for deactivation. It was called deactivatable. And he said, hey, Abraham, I'm having problems deactivating this object. I'm getting an error. And my first instinct was we're going to war, you know? My code didn't, I mean, it must be you. You know, that's just how I work. So, you know, I was geared up for that, but I went over to his desk, I saw a stack trace. I saw my deactivation error come up. And so I'll quickly diffuse. I was like, you know, I actually called my shot here. So I told you it was gonna throw an error in case of this scenario. And so if only for that, you know, be explicit about your errors, be explicit about your failures. That's something about transparency, right? And so how can we start thinking about courage in terms of a broader perspective on it? You know, I think there's a lot of courage in engineering itself, in the terms of this process of running in and facing challenges that we don't have the context for. Often that's the case when we're developing. And now everyone has this impulse, right? Where we're given some story. We're given some set of requirements. We might not have the first clue on how to dig into that, but often for us it's fun. It's something we look forward to, that challenge. And that takes a type of courage. I like how Richard Feynman put it. And this is when he was dismissing the Nobel Prize that he won for physics. This is what he said about it. He said, you know, he dismissed this award. He said, the prize is a pleasure of finding the thing out, the kick into discovery, the observation that other people use it, meaning his work. Those are the real things. You know, so he used that to sort of give him that courage to do amazing things, you know? Pair programming. You guys, somebody, you guys know, you see what happened here with the pairs? Ever get pairs? Pair programming. Pair programming requires courage, right? I don't know, have you thought about this? That it's incredibly, it's very vulnerable. It's a very vulnerable time, right? It's an intimate thing in a sense that you're exposing in real time, how you think. And you know, when I'm confused or lost about a piece of code, that's the last thing I want to do is let other people into that muddled mess, you know? And it takes some courage to be able to do that, depending on who you're pairing with. And I believe me, and I'm sure many of you have had the benefits of, seen the benefits of pairing, pairing with so many more experienced, less experienced, someone more familiar with the code base, all these things. Now, how to sharing through pairing is it's all, you know, it's very, very beneficial in lots of ways, but it still takes this courage, right? To get out there and jump in and not filter yourself and be open to the process. This is one of the earliest pieces of code that I've ever written. It's a process to find the mode of an array, try to find the mode of the array. It's very convoluted, it's horrible, don't look at it too closely. So anyway, it works though. It worked, I was very happy with the solution. I had a friend who was a little bit ahead of me in terms of experience, sent me his solution, looked like this. And, you know, my response was that's pretty good if you're going for concise, elegant, readable, exemplary code, that's fine. And what I'm saying is like, if I had this courage that I'm talking about, I would have been able to see this and think, wow, what can I learn from this? There's some methods here, I didn't even know you had, you know. What can I learn from this? Isn't it great, my friend is doing so well. You know, there's a way to lean into these moments where you're not afraid, but you're courageous about learning, you're ready. You have this growth mindset, right? That's the courage that software development requires. I like how Brene Brown put this in her book during greatly, which is a fantastic book. But she said courage starts with showing up and letting ourselves be seen. So a pair of programming, you can't help that, right? But let's take it, let's go a little broader. Like, this brings up these questions about our lives. Like, are we living courageous lives? I think we know people and maybe it's you yourself that is sort of swallowing errors, right? Not letting those failures out. A lot of us need help in different ways and some of us are reluctant to ask for help. Are we letting our fears prevent us from our goals? I think a lot of us are or at least have been at times. And so thinking about coding, we can start to reflect on that as far as courage in our own lives. Next, let's look at justice, justice. What does justice have to do with writing code? Well, justice, you know, Lady Justice is depicted as blind to suggest that justice is a process that ought to be impartial, right? And the scales suggest that there's a process, too, of balancing, of weighing out what's worthy. And so justice, we can define justice. A lot of people toss that term around, sort of, without defining it. Defining justice to me would be, let's just agree, I'm something simple, like it's fulfilling one's obligations, right? It's to give to each person what is owed and we can expand that to institutions, traditions and various groups or employers, that sort of thing. So justice is to give to each what is owed. And so when we think about justice in terms of software development, does that make any sense? I mean, have you seen this situation, right? Like, we all have varying concepts of justice, of what our obligations are, but hopefully in this room our, you know, diverse and rival conceptions of justice can all meet in this situation where someone writes unmaintainable code and then leaves the company, right? And so what this is getting at is that there's an obligation that has been unfulfilled in this situation, right? You ever see this as an issue? I want to see this start to happen too. I want to start a trend of people opening up issues that look like this. There's a problem with this code, it's unjust. Boom. So what does that mean? I listed some bullet points here, but let's talk about code in two ways. And obligations, one of the obligations is to other people, right? When you write code it's not just for yourself, when you're especially when you're writing it professionally, it's this collective ownership of code is a powerful concept, but I write something and someone else can refactor it. I should be good with that, I should be happy about that. Although it sometimes feels, you know, it takes me getting used to at first. There's a, but the concept is that the code that you write belongs to other people. It's the same thing that's in play when you think about writing code that's readable. Not just for other people, but even for you. You ever come to code that you've written six months ago? I mean, have you ever done a git blame and been like, who wrote this? You find out it's you. You know, that happens to me every once in a while. But, you know, so writing code that belongs to other people, you have obligations that you ought to fulfill, right? Writing organized code, that's what it's about, right? So there's no obligation to, and that's, I'll call that an obligation to fill towards time, which means, you know, when you write code and it fulfills a set of expectations, the thing is expectations change, right? Business requirements change, your team changes, the business needs change, technologies change, your dependencies change, everything changes. And so writing code that's just, in this case would be, writing code that is flexible, that is extensible, that's able to adapt to these changes. And that's, so that's what I would call just code. I like how Sandy Metz put this, when she said, design is more the art of preserving changeability than it is the act of achieving perfection. And so when we think about justice, it's a way to navigate competing desires. And that's what she's talking about here is, a lot of us are perfectionists, right? Software developers that's common trait. And what she's saying, it's more important to preserve changeability than it is to achieve perfection. So that goes towards what does it mean to write just code? When Michael Sandel, he's a professor at Harvard, he has a famous course for undergraduates. It's available online, I think it's called Justice. But he wrote a book, and in that book he said, thinking about justice seems inescapably to engage us in thinking about the best way to live. So not only can we think about does our code fulfill its obligations, we can start to think about ourselves and do we fulfill all of our obligations, right? As people, we have multiple roles and are fulfilling all of them. We have multiple sets of obligations. Are we living up to those? And those are the questions that start to come to mind and we start to think if we're living just lives ourselves. So the last virtue, the last virtue is wisdom. What's wisdom have to do with coding if anything? And so wisdom is the art of skillful living, right? It's making good choices, it's about navigating as well, similar to like justice, but often with wisdom, a lot of it comes from experience. But I like how the way Uncle Bob talks about design patterns, because to me that's encoding, that's the analogy, right? Like when Bob Martin, Uncle Bob says a design pattern is a well-worn and known good solution to a common problem. Design patterns are definitively not new. Rather, they're old techniques that have shown their usefulness over a period of many years. So we might not even know where our design pattern that we're using came from. We might not know the original context at all. With the proven, it might have been handed down to us from other engineers, right? We might have seen an example in a book or in some documentation. And it's good to dig into these patterns and find out where we got them, sort of what the reasoning was behind them. And sometimes these patterns need to be challenged and changed, but we often use them and we find them to be useful because not every problem we encounter is a new problem, it's been encountered before and smart people have found certain patterns to deal with them, right? And so that's really, when we're coding, we're using wisdom, we're using patterns, we're using design patterns. And so when we think about wisdom, not just with coding, but with our lives, we can think about what Confucius said here. I don't read Confucius, so the internet told me that he said this and we're all gonna just believe that for now. So what he said was there's three methods to learn wisdom, right? First, by reflection, which is nobleness. Second, by imitation, which is easiest. And third, by experience, which is the bitterest. So when we're coding, right, some of us in this room, we can sit and reflect on a problem and some domain that we're familiar with and just by reflecting, come up with some pattern that our team ends up using for years. I've never done that, I've never been in that situation. Some people are more experienced than me. I'm sure that's your reality, which is great. And that's the noblest path, right? But others of us, we use imitation. We just read books and we ask people and we imitate these design patterns. We use the wisdom of others to get the job done for ourselves. The third way, the bitterest way is by experience. And we've all been there too, right? We run off, we find a solution, it works. And later, we experience the pain, right? We experience the inflexibility of some code that we've written. It's not fulfilling its obligation. It's difficult to work with. Every time we have to open up this class, it's just horrible, right? These are the bitter experiences that also teach us wisdom and also can lead to good design patterns. But that's the bitterest process, right? We're gonna confuse this thing as like, why go that route if you don't have to? But so let's take wisdom and expand it, right? From writing code to our lives. How many times, how many people here have time set aside to just reflect, to reflect on life and maybe achieve wisdom in this way, the noblest way, according to Confucius? Do you have time in your schedule or just running back and forth, back and forth? The second way, right, imitation. How many of us have people whose lives we want to imitate? How many people know mentors, people that are our wives that we can imitate? Not just in terms of coding, right? But in terms of their life, how they live their lives out. And then, or are we all in this third category of just suffering in order to acquire wisdom, making our own mistakes? You know, there's some people that take a lot of pride in this, right? Like I can't learn from other people. I have to experience it myself. And then, that's certainly a way to go. But as Confucius warns us, like that is the bitterest path and that's a path to suffering. So how are you acquiring wisdom for your life? That's the question that thinking about wisdom brings up. So we've talked about the classical virtues, right? Self-control, courage, justice, and wisdom. And I like how in this book, after Virtue, Asider, McIntyre put it, we can think of these when we think about TDD for your soul. Maybe these would be, you know, your feature specs or your integration test, right? Like these are broad questions, good questions to ask. Who am I, who ought I to become? How ought I to get there, right? And so what TDD for your soul could look like, just as an example, is something like this, right? Where I wanna grow in self-control. So I write a spec for it that's failing. Just to make this very concrete, let's say I wrote a test about, I wanted to be more self-controlled. I wanted to, I have goals. And I asked some new goals coming out of this conference, especially after Ajah's talk. So to say I wanted to get up early, that means I need to go to bed early, right? And this is something that I'm not good at. It's something I struggle with. And so let's say I set a goal to be self-controlled. And the way I was gonna do that was to close my laptop at 9 p.m. every night, just close it. Simple as that, that was gonna be my new habit. And I either pass it or I fail that test, right? And so after a while, and this is how habitation, sorry, habituation works, right? You build up habits over time by continually trying them. And so once I was able to achieve this goal of closing my laptop at 9 p.m., I could consider that a green spec. And at that point I could refactor, right? Because it's, in me pursuing this goal of being more self-controlled, closing my laptop at 9 p.m., maybe that's too rigid of a constraint, you know? Maybe I could loosen up on that while still maintaining that virtue. That's the refactoring piece, is thinking about how can I do this better? Is there a better way to implement this? But still maintaining that behavior, right? And so TAD for your soul is about writing tests against your life. It's about considering where you wanna be and the four virtues I think are very helpful in helping us figure out who we wanna be. And then writing specs, writing goals that fail at first because we're not that virtuous yet, but working at them, working at them until we become that person. So I could just end it here. I could walk off the stage. Everyone would applaud. It would be fantastic. But no one's laughing, that was a joke. I don't expect that to happen. Maybe everyone's just hungry, but you know, let me just say a little bit more. Let me just say a little bit more. What I find is that I think a lot of us won't actually undergo this process of test driven development for your soul. And there's a lot of reasons why one might choose not to go through this process. Maybe I've done a poor job in actually explaining it. I maybe have certain problems with it. But I think for a lot of people, anything like this is, we resist it, right? We resist things like this. And what is that resistance about? I think for a lot of us, that resistance comes from shame. It comes from a sense of lacking worthiness, right? It's like, why would I write failing tests about my life? Why would I admit that I don't have courage at work? Or why would I think about all the ways that I don't have self-control? I know that. Why would I put that out there? Why would I be explicit about it? Why would I think about it? I'm doing okay, right, without wisdom. Yeah, I make bad choices, you know, but I'm here, you know, if you're here, you're probably employed. I'm guessing, you know, you're doing okay, right? Like there's, we have all this resistance to the concept. I think a lot of it is around shame because we don't do well with admitting our failures and our vulnerabilities and the places where we don't have these virtues. Like for a lot of us, this is a question that we already struggle with about, am I good enough? And what I just suggested doesn't sound like a way to help us with this question, right? In fact, it might make it worse. For a lot of us, shame feels like someone whispering in your ear that you're not good enough, right? But what I've found is that there's a way to not let failures shame us and drag us down, but in fact, it can lead us to a better place. We can be buoyant in these situations and enjoy this journey and this process. And so I'm gonna share that with you and that who knows who this guy is? We've got some hands, shout out his name. Shepherd Book, Shepherd Book from Firefly. And so what Shepherd Book, to Joss Whedon, anybody know, Joss Whedon has gone on to do other things, but he wrote Firefly, it's a fantastic series, I recommend it. But in this series, Shepherd Book is a religious man and the hero of the story's name is this captain named Mal. And Mal is pretty antagonistic towards books, beliefs, but they have a healthy sort of respect for each other. So at any rate, in the movie Serenity at a crucial time, Book tells Mal, because Mal is raising some objection towards books, religious beliefs. And what Book tells Mal in this crucial time, he tells him, I don't care what you believe, just believe it. I don't care what you believe, just believe it. And he told Mal that because he knew that he had to do something important, right? And so similarly, when I think about this process of self-improvement, this process of gaining virtues, for me, my basis comes from my religious beliefs. This is the holy week for Christians, right? And so on Friday is Good Friday, on Sunday is Easter, the way that works for Christians is that it's a historical account about Jesus' execution, which is when he faced shame, and it's met by the resurrection on Sunday, where you achieve victory, right? And that forms the basis of how I combat shame and condemnation to go on a process of gaining virtue. And then that might not be everyone's path, right? But what is your path? What is your basis for fighting shame? How do you do it, do you have one? Or do you let shame prevent you from going on this process, a process where you can become the best person that you can be? Let me put it in a different way. I'm from Chicago, right? I mentioned that in Chicago has a rich history. The blues, the blues is a foundational music genre. You can find elements of it and a lot of other things. You can trace it, it's influenced, right? Ralph Ellison, who wrote a book called, I know him from writing The Invisible Man, which is not like H.G. Wells' Invisible Man, very different. But Ralph Ellison, what he said about the blues, the blues is an impulse to keep the painful details and episodes of a brutal experience alive in one's aching consciousness, to finger it's jagged grain and to transcend it, not by the consolation of philosophy, but by squeezing from it a near tragic, near comic lyricism. There's a lot to take in there. That's a dope quote. That's something you need to think about later. But the way we can apply it right now is our failures, our weaknesses, our vulnerabilities where we don't add up, doesn't have to amount to shame that prevents us from this process of TDD for your soul, of developing our character. Instead, those failures, those embarrassments, those moments can, we can finger their grain in a sense and transcend them and squeeze from them. I'm not talking about squeezing from the moments of creating music, but we can squeeze from the moments where we can create character, where we can develop who we are, the type of people that we are, the type of people that are just, that are self-controlled, that have wisdom, that have courage, which I think is sorely needed in this world. And so, we're at the end of my talk and I hope you can see that there's a path here. I hope it makes sense to you and I hope you'll take it with me, so that not only can we just become better coders, better software engineers, but we can become better sons, better daughters, better husbands, better wives, better citizens, better neighbors. We can all become the best people that we can be. Thank you. Yeah, that's a great question. Let me repeat it. Basically, how do I incorporate the content of this talk at work? Right, that's fair. Right, so appreciate that. I think, to be honest, that I've struggled with that a bit because, like I said, I was joking about it earlier, but this is how I want to view my life internally, but if I put it out there at work, it means I have to live up to it, which I want to do. But I think, I haven't even given this talk at any place that I've worked, like internally, although there's an opportunity to do that. But I think I ought to do that. So thanks for the question. And I think the reason why I have it is because it's so idealistic, right? And it's, I'm not, like I said, I don't have great self-control. I don't consider myself wise. I mean, I can go down the list. And so, but yeah, I think that you've given me something to think about and you've given me the next step. So yeah, and if you find it helpful, I can give you the slides and be happy to help any way I can. Thanks. So currently, my moments of reflection, a lot of them occur on the train on the way to work. And so I wear a pair of headphones and I listen to lectures or music. I've been journaling a bit, too, I think which helps for my personality. But you know, you have to fight for those moments. And what I found, I wanna start waking up early for to carve out more time, but for me it's during my commute. Oh, sorry, I should repeat the question. The question was, where do I find time for reflection? Thanks. So the question was, meaning the virtues or let's say all of them, I think are subjective. And so we all define them in different ways. How do I, basically how do I write these tests, right? So how can I get external validation, I think that's what you said? Right. Yeah, I think it's a great question. How do I write these, how do I come to an agreement on what these virtues even look like and what if my definition of them don't line up with the world around me? And so that's a question about what are the virtues actually, in terms of the concrete behaviors. And that's something, I'm not gonna be able to answer for everyone in this room. For me, it's a bit easier because I am part of a religious tradition and so I have a lot of guidance along those lines. And that's the way religion has functioned, right? For thousands of years. But those of us that aren't part of communities like that, you have a different path to achieving those shared meanings. That's essentially what these virtues would look like is in your context, in your community, what's a shared meaning for courage, for wisdom. Oftentimes, they will look pretty similar, but I think that really depends on who you are and what your commitments are. And you can do quite a bit of reading on virtues, people that you look up to, reading biographies I think has been helpful for me, but, and I also need people that love me to give me feedback. My wife is good at that. And, but yeah, I think those are, that's sort of how I would answer that question. Thanks. Go ahead. What would I say led me to moving in this direction or adapting this ideology? I don't know, man. I mean, on the one hand, I think, you know, we live in a broken world in a lot of ways and I think about that quite a bit and how we can be better people. And so, when I was learning about coding, I think for me it's natural to learn through analogy, to make connections that make sense to me. And I sort of stumbled onto this concept. I started as a five minute lightning talk and sort of just grown from there and I found that people respond well to it. So I just keep giving it until it kicked me out, you know? Sort of, it's been my motto. Yeah, I mean, oh, the question was, what's my new relic for the soul? How do I measure success? And like I said, I don't, I just don't think I can give a simple answer to that question. I think for a lot of us, it depends on your context and who you are, what your commitments are. I think growing in virtue is, that process will never be over until you die, right? So, there's an end goal inside. I think the way it functions is that you just keep, hopefully you just keep growing and you become a person that has a lot to pass on to others. Some good questions, thank you.