 Welcome to my talk. It's called TDD for your soul, subtitle, as you can read, virtue in software engineering. So TDD, just for those of you that weren't sure what that meant, it's an acronym for test-driven development. Most of you know that already. But test-driven development is an approach to running software. A lot of people find it profitable. I like it myself. It helps in a lot of ways in your process. And what I'm doing in this talk is considering, what could it mean to apply that process to ourselves as people, ultimately so that we don't just become better at coding or engineering, but that we'd be better people, better human beings. That's where we're going. If you're in this room expecting something else, it's too late because the doors are locked so you can't leave. You're stuck with me as it is. But hopefully you can pick up something along the way, even if that's the case. So like I said, TDD is this process test-driven development. And it's usually, you can shorthand it by saying something like red-green refactors. So red means writing this test. You write a test specifying some behavior. And because you haven't implemented the code to make that behavior happen, that test is going to fail. So that's the red piece. The test is failing. So the next piece of that is getting that test to go green, meaning that getting that test to pass. So you write the code, write the implementation you need to make that test pass. And the third piece is often forgotten, but it's refactoring. So now that you have a test that locks in that behavior that you want, you can feel free to refactor, to rename, to modularize, to do whatever you need to do to drive your code, whatever you want to refactor and improve on it. And the test should still be passing, and so you feel free to do something like that. And then you just repeat again. You start again with red, writing a new test. So that's the process of TDD. And I started thinking about this concept of applying this process to ourselves because it's, I don't think you can really argue that science itself, right? The process of discovery and learning, inquiry, these things don't necessarily lead to virtue themselves. Technologists, you know, people that are in the know, on the cutting edge of engineering, they're not necessarily good people. They're not necessarily virtuous just because they know how to do certain things, right? I mean, probably the best example of the point I'm trying to make is Walter White. No one knows. Anyway, it's a pretty popular show. Glad to see that you should watch this, not now, but watch it later. But the premise is right, Walter White, he's this genius, he's a chemist, and brilliant man, high school teacher at first, but he uses these powers for ill. He starts cooking meth, right? I mean, how can you think anything worse than that? So he becomes this meth kingpin, in a sense. So that's someone using this brilliant mind, this capacity for science and engineering, and not using it virtuously. But so just so we're clear, just so you and I, we know where we're standing. I'm not this person that came into software engineering with all these ideals. I got into software engineering to get paid. Okay, I just wanted to make money. I wanted to eat olives out of a goblet. I wanted to have dogs play poker in my living room and have some bodyguards just there just in case, you know. That's what I, this is what I was aspiring towards and I couldn't help it through the process of becoming an engineer. You know, I started to think that, that there's a real opportunity here. There's an opportunity for me to do more than just make money and make some cool stuff. You know, there's just a process for me to embrace this journey and work on some vulnerabilities that I have, some weaknesses, some flaws, and try to become the best person I can be. Now, if you're anything like me, you will resist a process like this because I did the whole time. I still do, even as I try to undergo it. And so just for the sake of injecting a little energy in here, I'm gonna try something since we're all friends, and you're not used to this, right? Tech conferences, you just sit there, usually you're half on the phone, half paying attention. I know, I've done it myself, but I want you to help me out. You know, I want you to help me out today and verbalize this natural tendency to just resist thinking about our character and our virtue and who we are as people. And the way I did it, I talked to myself like something like this, but Abraham, I just wanna code. I want you guys to say that with me real quick, but Abraham, I just wanna code. Let's try it one more time. But Abraham, I just wanna code. So that's just verbalizing what you're already thinking anyway, right? Like you don't wanna deal with any of this stuff. And so when I cue you, I want you to say it back to me. Let's try it one more time. But Abraham, I just wanna code. All right, so yeah, any animosity you have towards me just put it into that phrase and we'll be good to go. You know, any kind of energy is good for me, negative or positive. So let's consider what the virtues could mean for software engineering and for ourselves. The four classical virtues we're gonna use as a framework are, I mean, everyone here knows what they are already. They look very virtuous. People in the back, they look shady. So for them, the four virtues are self-control, courage, justice, and wisdom. Self-control, courage, justice, and wisdom. That's what we're gonna talk about. But Abraham, I just wanna code. I know, but the Hulk, I got the Hulk slide ready. So let's just talk about his first virtue which is self-control. Self-control, what does self-control have to do with software engineering, number one? Well, when I started, I started learning Ruby. Ruby's known for being friendly and just being accessible for learners. That's one of the things I love about Ruby, right? And it's expressive, good documentation, lots of resources. So I'm sitting at Starbucks learning how to code, working through exercises, little puzzles, trying to become an algorithmic thinker, working on my use of data structures, that kind of thing. And often, I would hit something like this. As often, I have a nil object and I'm trying to call a method on it. And at first, this was super dispiriting. You know, I get really upset, get frustrated. I'm at Starbucks all by myself. That's part of the issue. By the way of being new is if you don't have resources, it can be really lonely. And once you hit a stumbling block, it feels like you might as well take the rest of the day off. And so I would get very frustrated learning how to code. So my lack of self-control came out in that context. But in general, it's hard to, maybe you're not as impatient as I am, but as developers, as engineers, it's sort of difficult to talk about self-control, because we often work in places that look like this. It just looks very indulgent to anyone outside of our world. My dad worked in the Sewers in the city of Chicago. I don't think he would even understand this place. So yeah, self-control as developers. It's kind of an interesting topic. I mean, maybe for most of you, none of what I said applies to you, but maybe this is your situation. It's from XKCD. Maybe, so anyone been here? I was doing this last week. So as long as developers, as engineers, it's good. We want to know the truth. We want to know what's right. And for a lot of us, we need to tell everybody we know and convince them, even if it means missing dinner or sleep. So our lack of self-control can come out in these types of situations, often for us. There's a scene from Dune. Anyone familiar with this book, Dune, sci-fi classic? This is really good stuff. There's a lot of stories coming out these days that bite off of Dune, like hardcore. So if you want to be, you know, the good part about being a super nerd is, like, you criticize everybody else. And so that's one of the reasons I read Dune. Anyway, in Dune, the protagonist, this guy named Paul, he's a boy, but he's got these superhuman abilities of awareness, and they're starting to come to him. This is the way he describes it. He's just hanging with me. I'm going to read it to you, quoting from this passage. I might lose everybody right here. In grasping the present, he felt for the first time the massive steadiness of time's movement everywhere, complicated by shifting currents, waves, surges, and counter surges, like surf against rocky cliffs. And what he saw was a time nexus, a boiling of possibilities focused here, where in the most minute action, moved a gigantic lever across the known universe. He saw violence with the outcome subject to so many variables that his slightest movement created vast shiftings in the pattern. OK, yeah, so this writer probably definitely did acid at some point. But what I'm saying is, when I'm looking at a console, when I've got Vim open, hopefully any Vim users here like to see that too, the possibilities sometimes can stagger me, especially as someone who's only been doing this for a year. So I don't have the tacit knowledge that some of the people here that have been doing this for a while, you begin to develop these intuitions. I don't have them. I don't have a lot of them. So I'm sitting there and just considering, I have some business logic I need to implement. What am I going to do? How am I going to name this? Should I pull this out into a module? What about state? I have a bunch of friends doing functional stuff. Maybe I should do something like that. I just read about the design pattern. I should implement that definitely here. Or maybe, I don't know, maybe Rails isn't the solution here. Or why am I using Ruby again? All these things, they can turn through my mind. That might just be me. I don't know if anybody else is like that. The possibilities seem endless. You often don't know where to start. But test-driven development is actually helpful in this regard because it forces you to take a path. I like how Dave Estelle has put this in his blog post from 2005. This blog post was the beginning of our spec, from what I understand. Someone checked me on that, but you can look it up. It's a new look at test-driven development. It's from 2005. And he says it's about figuring out what you're trying to do before you run off half-cocked to try to do it. So you write a test or a spec, and then you go out and implement it. So it forces this intentionality, this purposefulness about your actions, and it limits you in a good way. It helps you exercise self-control as a software developer. And in my resistance to TDD is my resistance against self-control often. So what you find is when you start thinking about this stuff and then thinking, okay, self-control as a developer, how am I resisting these impulses to just do what I want, to just run off half-cocked as Dave Estelle put it? But also, am I resisting that in other parts of my life? My dad, the way he described, he taught me a lot through action movies. He's an immigrant, so that was his way. I remember watching Magnet Force with him. I remember this line that a man's gotta know his limitations. That's what self-control is often about, is knowing yourself, knowing your limitations, and knowing which desires to follow and which desires to resist. Often, instead of us leading over our desires, our desires lead over us, and that's the problem. And the more you think about this as a developer, as an engineer, start to reflect on your self-control or lack thereof. And you can start to see how you're not, you have limitations with self-control as a developer, but also just as a person. And it's actually an opportunity for both of those things to get better if you take this path of virtue. But Abraham, this is where you start. I just want a code, right? No one wants to talk about self-control. It's even called temperance usually, which sounds even worse. I tried to change the name up, didn't probably help all that much. But we're gonna talk about the next virtue. That's courage. What does courage have to do with engineering, with software development? Well, courage, I think there's two things to talk about. One, is there's a courage in just being an engineer and being curious, and being someone that, when you see a problem, you don't run away from it, you run towards it, right? Some of us are energized by these tough situations where you actually don't know how we're gonna get there to the solution. We're sitting there, maybe you're in a planning meeting, you're considering some feature, and you actually, you don't really know how it's gonna work out, but that's exciting. That's part of the energy you get from being an engineer. And I know I've skipped lunch because I was so into what I was trying to do. That's a rare thing for me to skip lunch over. I don't really do that for people I like, but I'll do that if I'm into some heavy process. There's a lot of people here that'll like that. There's a sense of courage, I think, that a lot of us have about solving problems. I like how Richard Feynman put this. He won a Nobel Prize for his work in physics, and this is what he said about the Nobel. He sort of just missed this prize, saying, the prize is the pleasure of finding the thing out, the kick in the discovery, the observation that other people will use it, meaning my work, those are the real things. So for him, it wasn't about these prizes, but he had this courage to do all this amazing stuff, math and physics, because he had this mindset, right? I think so the second thing to talk about with courage is pair programming. So those are two pairs. I don't know if everybody, you guys see that? Yeah, you like that? This is the worst slide I have, I love that. Someone made that, I mean, that is great. So pair programming, what is pair programming for those that don't know, it's two people sitting at one machine, two monitors, one keyboard. I don't know why that mouse is there, that's a non-Vim setup, right? Like a, but pair programming, this involves lots of courage, right? Why do people not, how many people here pair program all day? Okay, yeah, so you do, everyone else ad hoc, you know when it comes up, that's how I do it as well. But it's a great way to learn, lots of positives to it, cleaner code often, but I still resist it. I don't know if you're ready to admit that with me. You can just agree with me silently, but every time I think about pair programming, I still try to figure out if I can get out of it. You know what I mean? Like, ah, do I really need to, let me try a bunch of other stuff real quick. So why is that? I mean, for me, it's about vulnerability. You're exposing how you think in real time to somebody else. And that can be a very scary thing to do. The reason why that can be scary is, you know, the way you think might not be that great, you know? And that's, you're trusting somebody with that, right? Like the thing is even about a pull request that you submit, you can make it look good, right? You can review it, you can agonize over it and just put your best foot forward. Pair programming, it's just on the spot, you know? It's just two people, ad-living, and so I think that's why people resist pair programming. I know for me, that's what I have to work against is being overly critical of my process and not wanting to invite somebody else into that and just seeing how I really work on stuff, seeing how I think about code. I mean, let me just get real with everyone here. This is from my, this is from a project for Dev Bootcamp and this is part of the pre-work, that's what it was. So it's a simple assignment to find the mode of an array. Find the mode of an array, pretty simple. This is my solution, it works, I was really proud of it. It took me like two hours. And this is last year just starting out. But I'm super proud of it. In a weird way, I was proud of its opacity. I don't know if anybody else knows what I'm talking about, but I was proud that this was unreadable. Like, I like that, because I was like, I know what's going on here. Man, you know, that was me line by line struggling with this thing. I got this thing to work, felt great, went down, ate some lunch, came back, and I saw that someone else posted a response, like not a response, but also another solution. And you can see other solutions through this platform we were using. So I go and look at this other solution from Kevin. What's Kevin got? I mean, you know, it's all right. Like, if that's what you're trying to do, you know, that's cool. But I was upset, you know, let me just be honest. I wasn't happy about this situation. You know, I felt like personally challenged, right? Like, I felt threatened by this solution. But if I had this courage, if I had this courage that I'm talking about, I could look at things like this and be like, wow, let me learn from this. You know, let me see what I can pick up from this and that can help me get better. And also, while it's cool that Kevin is that far along, I can learn from a guy like that. But I wasn't like that in that moment. So that's my lack of courage that exposed itself. I like how Bernadette Brown put it. She was talking about courage. She says in her book, During Great League, courage starts with showing up and letting ourselves be seen. And you can't help but do that when you're pair programming, right? That's all you're doing. And what she was talking about is relationships. That is the key to making meaningful connections with people. So some of us will see like, we resist pair programming, we resist mentor being mentor, even asking questions in meetings. I mean, there's all these different moments we have to display courage or not. And if we're honest with ourselves, we'll see that, you know, I'm missing a lot of those opportunities. And so you can see that the engineering, it's an opportunity for us to grow in courage as engineers but also as people. But Abraham, I just want a code. No one wants to talk about courage. I just did. I don't know anyone here, but that's okay. That's why I'm up here, I guess. But no one wants to talk about courage really, but maybe you'll want to talk about justice. Let's see, let's see what you think about justice. What I think justice has to do with coding, well, what is justice anyway? What is it? I mean, a lot of people throw that term around without defining it. You know, lady justice was depicted as someone that was blind. And the whole point there was justice isn't partial, right? And also with these scales, there's a sense that it's about finding some balance, about weighing different things. And so I think simply justice can be described as giving to each person what he or she is owed. Giving to each person what he or she is owed. You can expand that to giving to each person or institution or community what they are owed, right? So it's navigating a sense of obligations. And to navigate those, it requires something, it requires a perception of order, of a cosmic order that informs the norms that we build up. And so we're getting a little esoteric here. We're getting a little esoteric. Michael Sandel from Harvard, the way he put it is, he said, thinking about justice seems inescapably to engage us in thinking about the best way to live. So that best way to live is gonna differ though, right? Among all the people here, there's gonna be some overlap. That's the only way we can function in society together. But we're gonna have different conceptions of this best way to live. But hopefully your intuitions in mind are enough in line. So we can look at something like this and be like, I don't wanna do that. Whatever that, I don't, wherever you're coming from, you know, there's like a lot of consultants that have to do it, right? They fly in and write a bunch of garbage and leave. So, you know, the good ones don't, but writing maintainable code is about justice. So what does that mean? There is a way to write just code and unjust code, all right? So just code is at least two things. It satisfies at least two things. One, an obligation to time. An obligation to time, what do I mean by that? So when I was sitting at Starbucks working on these little ruby exercises, I had no obligation to time being satisfied there because I was just about finding the solution and being done with it and never working with it again. But the code that we write in a professional setting or even open source or side projects, you know, business ventures, anything that's not just play, and I encourage people just playing around with code. I think that's a great way to learn too, but any code that's not just that, it's not just about that moment, it's gonna exist and it's gonna hopefully function in some capacity. And what happens is over time requirements change. So the user has different expectations or technology changes, there's upgrades, right? So time isn't static, but it's dynamic and code is your projects that are part of that. And so for the code that you're producing to be just, it has to recognize that things are gonna change. And so I like how Sandy Metz put this. She said design is more the art of preserving changeability than it is achieving perfection. So changeability, how do you perceive that? It's naming, organizing, pulling things out and abstractions when it's appropriate. Those types of practices, and Sandy Metz gets into that in her book, which I recommend, those practices, the only reason why it's worth doing those things is if you recognize that your code isn't just a static thing, but it's dynamic, it's part of this time and things are gonna change. Also part of that, the second piece is your code isn't just for you, it's for other people. So you need to actually think about the people coming after you that have to read your code. I mean the most selfish way to do this is think about yourself in six months that you have to read your own code and if it's written poorly, you're gonna have a hard time. Anybody had that experience yet? With themselves, look back at a project, you don't know what happened, what you were thinking, yeah. So that's like, at least you can do that for yourself. But think about other people. People you don't even know yet, other engineers. Maybe you'll move on from this company that you're at or this project that you're on. And there'll be people there trying to work with the stuff that you wrote. You have an obligation to them. And the just code that you write will satisfy those obligations to them. And if it's unjust code, we're in this situation, right? We don't wanna be in this situation, right? Everybody, we're on the same page, hopefully. I don't know you, but I hope we can all agree to that. And what we'll find in this process is that you start to think about, man, my writing code that is changeable and that is accessible to other people. It doesn't satisfy its obligations to the community that I'm in. And this process can also be a time to reflect upon in my life, like in my living in this way. Also, my navigating the obligations I have to the people around me. And it can be a time for you to grow in that virtue as well. But Abraham, I just want a code. Nobody wants to hear about justice. Maybe you want to hear about wisdom. This is the last virtue, wisdom. What does wisdom have to do with coding? Well, wisdom is depicted as reflection often. I found this quotation from Confucius. It says, by three methods we may learn wisdom. First by reflection, which is nobleness. Second by imitation, which is easiest. And third by experience, which is the bitterest. I hope Confucius said this. I don't really read Confucius. I'm gonna just submit that. But the internet told me that he said this, so we're just gonna go with it. I think it works either way. But what does this mean? Number one, reflection as an engineer can come through writing, reading, studying, that sort of thing. So hopefully those of you that are working as engineers, your employer recognizes that you need that time. I mean, how many people here would say they have time for reflection? That you carve out time for reflection? That's really important. It's hard to fight for that time. You have to fight for it sometimes. But just tell him Confucius said, it's a noblest way to learn wisdom. I think that might help. So second is by imitation, he says, which is the easiest. The imitation as an engineer. I think you pick up a lot of this when you're a pair of programming, but any type of situation where you're getting code reviewed, any mentoring situations, that's the easiest way to gain wisdom. And I think that's understandable if you talk about the third. The third is by experience, which he says is the bitterest. So what does that mean? You know, a lot of us take pride of the fact that we need to learn by experience. You know, I'm not gonna trust anybody till I see it myself, right? What Confucius is getting at here, I believe that's the bitterest way to learn because you learn through pain. You learn through suffering. You know, a lot of us will never grasp any clean coding principles until we have to deal with that pain ourselves, until you're struggling on a project, trying to maintain something that's been in production, feeling the pain of that, of why weren't these decisions made back then? Once you feel that, then you start to realize a little bit of wisdom would have helped in the situation. For a lot of us, that's where we're at. And that, we just need to know that's the bitterest way to learn. It's a way to gain wisdom. It's just gonna involve the most suffering. I like how Uncle Bob put this when he's talking about design patterns. He said design pattern is a well-worn and known 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. And so this is really, this is talking about coding design patterns, but this is what wisdom is in life. It's a design pattern for living. You might not even know where a certain pattern comes from, who wrote it, who came up with it, what book referenced it. You don't need to know any of that stuff to use one, usefully, right? That's what wisdom is. It's just a crude knowledge. And so how are you growing in wisdom? What's your plan for growing wisdom? Is it through reflection, the noblest path? How many people here have people to imitate, have mentorship, have good code reviews, practice pair programming, those types of things? That'd be the easiest way to grow in wisdom as an engineer. And while over the years, we'll gain the experience, how many of us are thoughtful about these first two things? You know, and taking that further to ourselves, even if you do have mentoring, even if you pair program, who are you trying to imitate for how do you want to live, for the person that you want to be? Right, not just as an engineer, but just as a person. Whose life is worth imitating that you know? Do you have any relationships like that? These are the types of questions that can come up when you start to think about wisdom in the context of an engineer, but then expanding it to the concept of the whole person. But Abraham, I just wanna code. Yeah, I know. I'm gonna wrap it up. I'm gonna get out of here. But we just went through the four classical virtues. We talked about self-control, courage, justice, and wisdom, and how those things can apply to us as engineers, but also as people. And the reason I started talking about this stuff, oh, these are some good questions from a moral philosopher. He says, this journey of virtue, you can sum them up by asking, who am I? Who ought I to become? How ought I to get there? And so if you're gonna TDD your soul, like that's the topic, right? If you were to do those things, you'd start by writing a test for yourself. And let me just give you an example for my life. I wanted to grow in courage as a developer, but just as a person in general. But I made this test for myself that I was going to ask more questions at work, something simple like that. So I failed at that for a while and I made it applicable to me, right? I failed at this test for a while and I started to get it to pass by asking more questions, by taking the steps that it took, the habits to be around the people I was comfortable with and the people that I wanted to learn from and just asking more questions so I could learn more quickly. So that's the way I started passing my own test for myself. And those are the types of things that I'm talking about with TDDing your souls is considering the virtues, considering where we're weak with them, being really honest, brutally honest with ourselves, about our vulnerabilities, about our flaws, about our lack of justice, self-control, courage, wisdom, and then addressing those things, developing the habits it takes to start to grow in these areas. So I could finish right here and it would be okay, but we have Darth Vader in the house right now. And what he's saying is, I find your lack of test disturbing, what's this about? Well, my sense is that, you know, most people are just not gonna do this. You know, that's fine. You just, Abraham, you just talked about this. That's great for you, but I'm just not, I'm not really gonna do any of that. So, you know, what's next on the schedule, right? Like, I think that's, my sense is that, that's where a lot of people are at. And for some of you, I can't do anything about that. But for, I think for a lot of us, the reason why we would not TDD our souls, right, is something called shame, right? Shame, you know, what is shame? How is shame preventing us from this process of growing in virtue? Well, shame, what is shame? Shame is, you know, it's often contrasted with guilt. And so, shame is feeling bad about who you are, right? And guilt is feeling bad about what you've done. So, you see the difference there? You know, this question of am I good enough? I mean, you're feeling shamed. The answer that you hear back is no. And for a lot of us, it sounds like this voice. I don't know who's talking for you. It could be a father or mother, a friend. I don't know. Someone that you know, or maybe it's yourself, but there's a voice that's saying, yeah, you're not good enough. You're not gonna make it. And so, if there's a case for anyone here, if you have shame over anything, why would you engage in a process where you can get even more shame, which is considering where you lack virtue, right? Why would you do that? Why would you hurt yourself even more, right? Some of you, this is what you're thinking, even implicitly, so you won't, why bother? It's too painful. I have enough to deal with it as it is. I feel bad enough about the stuff that I'm not good at. Why would I want more of that? That sounds stupid, Abraham, right? What I'm saying to you is that there is a process where criticism, this feedback about our weaknesses and our shortcomings doesn't have to be an anchor that's pulling us down, but it can be something that we float on and that can take us somewhere. There's a buoyancy that can come and engage in this process in the correct way, and this buoyancy can take us somewhere. It can be an adventure. That's what the process of growing in virtues as an engineer, but also just as a person is about, is going somewhere, becoming this person, the best person that you can be. And so, what does it take? What does it take for that to happen? Well, anybody know who this is? Yes, so I got a lot, yeah, I like that. People know Shepard Book from the Firefly series. There's a movie Serenity that came out. So what Shepard Book, he's a character and he's talking with this Captain Mal, right? Mal Reynolds. And Mal is sort of hostile to Shepard Book because Shepard Book is a religious man and Mal is not, you know, he's like agnostic or just doesn't care, he doesn't want to hear any of that crap basically, right? That's his tone, but they're friends and they respect each other. And in the movie, at a key point, Shepard Book tells Mal, he starts to instruct him because he knows that there's, you know, it's coming down. I'm not gonna give away anything, but Mal's gonna have to make his moves, he's gonna have to do his thing. He's gonna have to be the hero. And Book is giving Mal this advice and Mal starts to shrug him off thinking that he's getting into his religious stuff again. But a love of Book says to him, he says, Mal, he says, I don't care what you believe, just believe it. I don't care what you believe, just believe it. So the way I lean into these questions of virtue and the process of growing as a person, also, but also having my dignity as a person and resisting shame, these are hard things to do because it's the process of being vulnerable without being shamed. The way I do it is through religion. I follow Jesus Christ, I try to live in that manner. That informs it for me. But that might be the path for you. And for most developers, I don't think that's really the case, but you need to find a path. That's what I'm saying. I don't care what you believe, just believe it. We all need to find a way to lean into these opportunities to grow. We're not running away from our vulnerabilities, but embracing them. Not embracing them in a way where it's, we're complacent, but we're embracing them for the purpose of growth, for the purpose of becoming the best people we can be. To bring it all together, let's talk about the blues. I'm from Chicago. It's known for its blues. And the blues came out of this context of suffering and oppression, right? I love how it's described here by Ralph Ellison. He says the blues is an impulse to keep the painful details and episodes of a brutal experience alive in one's aching consciousness to finger its jagged grain and to transcend it, not by the consolation of philosophy, but by squeezing from it a near tragic, near comic lyricism. So from our vulnerabilities, with the right metaphysical grounds, with the right mindset, wherever that you're getting that, wherever you're gonna find that, you can take these moments of weakness and squeeze something from it. So we're not gonna squeeze music, I'm not a musician. I'm not talking about making a song, but I'm saying from these moments, you can squeeze this character, this virtue, this growth as a person. And by that means you can become the best person you can be, not just a better coder, you'll be a better coder, a better engineer, a better team member. You'll definitely be more advantageous in your professional setting. Not just that, but you'll be a better person. Better husband, better son, better friend, better wife, better daughter, better mother, whatever it is, whatever situation you're in, you will grow. And these virtues, that's why it's important to talk about these virtues. So I hope that you have something to take away from this. I hope you'll take this journey of virtue that I'm on. Hopefully you're under go to in your own way, make it yours. If you have any questions, I'd love to hear them, any critiques too. My name's Abraham. Like I said, you can find me on Twitter here. I'm working at Centro in Chicago, we're hiring too, so if you wanna talk about that, I'd love to talk to you. Thanks to them for sending me here. I will, I have a little time here to take any questions if anyone has any. Any questions at all? You guys just wanna code, I know, right? I told you, that's what I'm talking about. Any questions? No? Okay. Well, thanks for listening. Thanks for attending.