 My name is Abraham Sanga, I'm speaking about TDD for your soul, virtual web development. So TDD, hopefully most of us are familiar with that. It's a software engineering that's proven to be helpful for people. Who knows what TDD is? Most people write. So you can sum it up with red, green, refactor, red, meaning writing a test that fails green, write the code that would make that test pass and then you're free to refactor having that test in place and maybe you want to delete the test afterwards. I just learned that today, I don't usually do that. So I started to think, you know, what if we applied this process of TDD not just to our code but to ourselves, to our character, not just to write better code to become better people, what would happen? But I didn't learn the code with these lofty aspirations in mind. I learned the code mostly with this in mind, I want to make money, eventually eat olives out of a goblet, that's really what I was hoping for, but I was surprised. I was disturbed to find out that I was being challenged as a person by learning how to be a better engineer. And so that's what I'm going to present to you today, and maybe you had the same opportunity that I found that I had. Again, we're off the page, I don't know, this one was fine. So at any rate, I'm just going to read this to you. This is a philosopher that wrote about virtue and the three questions he asked were who am I, who ought I to become, and how ought I to get there? So these are the questions that we can ask ourselves to try to figure out what it means to become the best person that we can be, the best version of ourselves that we can be, and throughout the ages, moral philosophers have used the classical virtues as sort of a framework, so that's what we're going to use to figure out what does TDD for your soul even mean, what does it look like, what are these tests that we would write to become better people? So the four classical virtues are self-control, courage, justice, and wisdom. Self-control, what does that have to do with coding, if anything, right? So when I first started learning how to program, I was writing Ruby at Starbucks, it was very enraging, honestly, error messages I didn't know. I actually didn't even read them. I tried to guess at solutions. That was a big problem, and it was a frustrating experience for me. It brought out that I didn't have a lot of self-control, and maybe some of you can relate to this sort of dynamic, right? Like there's something wrong with us, if this is a normal thing, or if everyone's laughing at this, to oscillate between megalomania and suicide, it's just not really, you know, there's something wrong with us, right? Like self-control, we need to, maybe we need to think about that. This also is a problem for me. And so we want to be about the truth, we want to know the right solution, we want to let other people know about it, and those are all good things, but those desires need to be moderated, right? And that's what self-control is about. So these situations have to do with technology and engineering, but those of us that think about this a little more, maybe if you're honestly think outside of coding, outside of work, I have problems with self-control. I could grow in my relationship with other people if I had a little more self-control. Let's talk about courage, also, courage. What's courage have to do with software engineering, if anything? Well, courage, right, is a response to fear, it's a strength in the face of fear. And I think the simplest way to talk about this in the context of software engineering is pair programming. So, yes, yes, slowly the bulbs turn on. All right, so, yeah, this is a horrible slide, by the way, but yeah, pair programming. So pair programming has been shown, how many people here pair program, I don't know, all the time? Yeah, so not everyone, but I do it ad hoc. I'm sure that's how it works for most people, but so it's been proven, right? You get a lot of instant feedback, you write better code, cleaner code. People have shown that this is just a great process. It's good for knowledge transfer as well. Someone more experienced with the code base, pairs up with someone that's not, that knowledge gets transferred, real-time communications happening, so great, so ideal, right? But what's the problem with that? It requires vulnerability, right? You're exposing your thoughts to someone essentially without much of a filter, and the process might reveal that your thoughts really aren't that great, right? Like, that's part of the problem, and that could be hard to hear, right? Like, that's not easy to hear all the time. And so, I was going to show you some really horrible code I wrote. Anyway, you can get kind of an idea of it. This is like one of the first things I wrote in Ruby, and I was trying to write a method to find the motive and array, all right? Find the motive and array. This works, actually, and I was really happy with myself. I was really proud. It took me, I think, a couple of hours banging my head against the wall, and I found a way to do this. And my friend was doing the same exercise, right? He says to me, his solution, look like this. And we had the same level of experience, right? I wasn't someone that was doing this for a while, all right? So, my response was, I mean, that's cool if you wanted, like, elegance and simplicity, you know, that's what you're going for. Yeah, I get it. But if I'm being honest, I was threatened by this solution, right? I wasn't excited to learn from this method and this solution didn't pique my interest. Instead, it made me feel like less than, right, like a worse developer. The guy that wrote this, I'm not going to mention any names, Kevin Buchanan, but he is still my friend. He's a good guy. But, you know, eventually I learned how to learn from him and others that knew how to do things better than me. But I had to have that courage that I'm talking about. Some of us here you can reflect on your opportunities and the ones that you're missing by not being open to feedback, not asking for it as a software engineer, but also just in the rest of your life, you know, where are you getting that feedback that could really help you develop as a person? Next thing I want to talk, oh, there's a quote from Brene Brown, it was really good, got cut off, so let's just keep going. The next virtue is justice. Justice, what does justice have to do with coding? Well, justice is simply the obligations, it's giving to each person what we owe them. It's giving to each person what we owe them. That's a simple way of talking about justice. And so we all have rival conceptions of justice, right? It's part of the problem in talking about the concept like this is we all have our own way to define that. But hopefully in this room, we all just have the right, you know, inherent, just visceral reaction of this situation, right? Like we all know that this is wrong, we don't want to be a part of this, we will not want our face on the slide. So that means that there, to me, that suggests that there's a way to write just code. There's a way to write code that is just, and what I would say is fulfill two obligations, and that's one, it's things like readability is considering other people, the people that are gonna come after you, whether it's people on your team or if it's yourself in a year, writing code, taking the time and the energy to write code that's maintainable is unreadable, understandable, is writing code that's just. And also, Sandy Metz had a quote from her that would have been amazing, but it's not showing up. But what she's saying is that a design, a good design is about preserving changeability. So that's the second way a code can be just, right? Is preparing or thinking about the fact that the requirements, business requirements may change. What your application has to do may change. There's a whole host of things that may change, and writing code in one way, assuming that things that aren't gonna change is much easier, but it takes more work to write just code that is changeable as well. And so how many of us write just code? That's one question. The second question is how many of our lives will be characterized as just by people that know us well? If you ask your friends or your loved ones, will they say that you live a life that respects your obligations to other people? And also, does it also respect the obligations to time? Like things changing? Like what do you think, what are you doing for the future? Those types of things that are lurking in the bushes when we think about lives that are just. The last virtue is wisdom. Wisdom, what's wisdom? Wisdom is the art of skillful living, of making good decisions, right? And we all use wisdom while recording, and this was a quotation about design patterns. Design patterns are essentially bits of wisdom that have been passed on that we use, right? They're well-worn solutions to problems. We might not even know the origins of them or who wrote, who came up with these ideas, but there's well-worn solutions or we're not trying to reinvent the wheel, right? We're just gonna implement these solutions using these patterns that have proven to be useful. And so that's what design pattern coding looks like, what wisdom is, is it's a design pattern for your life, right? It's solutions to problems that people have had for thousands of years and how they went about solving them. And there's this quotation from Confucius that he says that there's three methods where we can learn wisdom. I don't read Confucius, so the internet told me that this was true, hopefully it is. But it's really, I hope it's true. So he said you could learn wisdom from reflection, which is noblest, by imitation, which is easiest, and by experience, which is bitterest, right? So a lot of us, I think, fall on the side, like we need to experience something before we learn from it. So that's like the bitterest way to actually learn something. The easiest, which is attractive because it's for lazy people like me, is to imitate. So when you use a design pattern, you're imitating some people that came before you. And the same thing when you use wisdom in life, you're imitating, but who are we imitating? Who are the people that we have, that we know that are worth imitating, that are living the lives that we want to live? Do you have them? Are you talking to them? Are you learning from them or are you imitating them? There are the questions that come up when we think about wisdom in our lives. So like I said, there's three overarching questions I think that are helpful, like who am I, who ought I to become and how I to get there. And by implementing TDD for your soul by testing yourself, by thinking about your life in terms of self-control, courage, justice and wisdom, we can begin this process of evaluating, writing failing tests in a sense of where we're at and how we measure up and where we want to get to. But so by implementing a TDD for your soul process, we can become, not only become better programmers, but better people in general. That's my talk. Thank you.