 Thank you for sticking around. Like I said, my name's Abraham. Recently, I graduated a program called Deaf Bootcamp 2013. And I was talking about, as I was considering what it meant to be an engineer. And it might be, for some of you from the perspective of someone that's relatively new, because that's my perspective. But hopefully, those of you that have been doing this for a while have something in game from this too. My name's Abraham. Like I said, if you have any talk to you after this or on Twitter, it's cool with me. I work for a company called Centro in Chicago. Thanks to them for letting me come out here and be with you. So today my talk is TED for your sole virtue in web development. So what is TED, first of all, right? TED is test-driven development. It's an acronym for the first to a process that people have found helpful to develop software. And so simply, you could sum it up as red, green, refactored. Red is just meaning that most of the libraries that you would use to write unit tests, if the test is failing, it would display as red. Just to let you know. And when a test passes, it displays green. So the first step in TED is to write a test or a spec that fails. So this test is going to specify some behavior that you haven't implemented yet. So you write the test, you run it, and it's red because it's failing. The next step is to get that test to pass. You write the code that actually performs a behavior that you specified earlier. And once you've done that, you run the test, it goes back to your green. You know that you've done what you set out to do. And the third step is to refactor. A lot of people forget the step. I know I have. But refactoring is done easily at this point because you have a test that guarantees that your behavior is set. As long as that test is showing a green, you can rename variables, reorganize your code, get rid of state, abstract things. There's a whole host of options that open up at this point in refactoring. And a reason a lot of us don't refactor is that we don't want to break anything. So your tests help you ensure that you're not breaking anything. So that's TED in terms of test room development for software. I started to think to myself, well, I'm getting ahead of myself. So it helps me when I'm staring at just my blank screen. It helps me to get started by writing a test. Often for me, at this point, there's so many options that it helps me just narrow things down and write a test that specifies what I'm trying to accomplish. I like how David Stelz put this in his blog post. He said it's about figuring out what you're trying to do before you run off half-cock to try to do it. This blog post, it's old. And he ended up writing RSpec after this blog post, I believe. And RSpec, so Jasmine borrows a lot from RSpec, but described in Iplogs. I don't know if you've used Jasmine to test your JavaScript, but... So I like how he put this. It's about having a goal in mind before you start coding. I think this is very helpful. It's been helpful for me. But I started to think, what if we applied this TDD process to ourselves, to who we are as people, to our character, and what if we had a goal in mind for who we wanted to be and we approached it like engineers would? What would happen? Would this be a useful process? What I found is that it can be very useful. But let me just admit that I didn't get into coding with all these lofty goals of development character. And I also think that the reason why we need it is evident in the fact that science and technology isn't self-directing, right? It can be used for good or it can be used for ill. I think the best example from pop culture is Walter White. You know what I'm talking about? Breaking bad? Anybody? It's them that see me show. Okay, yeah, so you're tracking with me. You know, this guy's a genius. He's a chemist. He sets up a lab, but Walter White doesn't use his power for the benefit of society, right? He used it to build a method empire. So probably the total polar opposite of that. But like I said, I didn't get into software development trying to think about virtue and character development or anything like that. I got into software development to get paid. Just the simple things in life. I wanted to eat olives out of a goblet. I wanted to have body guards just standing there watching my dogs play poker. This is what I was aspiring towards. And it turned out as I was learning what it meant to be an engineer, that the process of software development could be not just a chance for me to feed my family, but actually a chance for me to become the best Abraham that I could become. You know, the best person I could become. And so as I talk about TDD for your soul, hopefully that's what's available to you as well. So let's talk about what it means to grow as a person. The framework I want to use are the four classical virtues. You started with Aristotle, but moral philosophers throughout the ages have used them. I picked up at them and developed them. Guston, Aquinas, everyone else coming after them. The four classical virtues, I'm sure, you already know what they are. You look like a virtuous bunch to me. But people in the back, especially up top, they look shady. So let's just reiterate. The four classical virtues are self-control, justice, courage, and wisdom. Self-control, justice, courage, and wisdom. But what do those have to do with software development? Anyway, let's go through them. First virtue is self-control. Self-control. My lack of self-control shown so brightly when I started to learn how to code, especially when I encountered an error message. And error messages to me were just so debilitating. I didn't know how to properly use them. I didn't know how to see them as information that could be useful. They just seemed like they were derailing my flow. And especially when I was on my own at first, I think that's the hardest time, not knowing how to debug, not knowing how to get unstuck, not knowing how to read documentation and use the resources that are available. So my lack of patience and anger quickly came out in these moments. I mean, some of you were like me. This slide really speaks to the developer's condition, this oscillation from euphoria to despair. It just shows a lack of self-control. And I think we've all been there, that is if you're anything like me. But I think it's hard to talk about self-control in general in our industry. The platonic ideal of our work environment looks like this. My dad worked in the sewer department in the city of Chicago, and I don't think he'd understand what this is. It looks more like an adult Chuck E. Cheese or something. It's not like a place to work, right? I mean, there's some cultural things in our way, I think. But maybe somewhere I've been talking, you're like, I don't have an anger problem. I don't need all the kutrim, it's not a simple person. I don't experience the highs and lows like you talked about. I don't know what you're talking about. Maybe for you, self-control rears its head in these situations. Right? There's someone else been here. This is something I have to resist often. But as developers, we have this drive to know what's right and what's true and often to share that with other people. That's all good. But some of us don't know when to turn it on or not, when to engage, when to exhibit some self-control and realize it's not worth arguing over. So these are situations where our lack of self-control can manifest itself. And these were apparent to me as I learned how to code. I started to think, what if I started to look at the rest of my life where my lack of self-control is affecting my relationships. My dad taught me everything I knew through action movies. That was just his way. And I still remember Dirty Harry said this. A man's got to know his limitations. That's what considering your lack of self-control is about, is knowing where your weaknesses are and knowing how to approach them, how to plan for them. And so the process of self-development can reveal your lack of self-control, but also it's a moment for you to think about the rest of your life where impatience, anger, really high highs and really low lows, an argumentative nature. These things, where have they affected the rest of your life? And this could be a moment at a time for you to engage and think about what it could take for you to change and grow in that virtue of self-control. Let's consider the next virtue, which is courage. So courage, what's courage about? Courage, simply with engineering, I think there's two ways to talk about courage. One is this mindset that we have to have. When we see a problem, especially a problem we've never encountered before, instead of running away from it, we run towards it. We get wrapped up in solving problems. I skipped meals because I was coding. There's this drive to finish, to come to a solution but possibly the best solution you could come up with. There's this, the buffers have that in them. It's not, not everyone has that. That's what I hear people say, anyone can learn to code. The thing that I want to push back on is, yes, that's true, but not everyone can code professionally because not everyone has this type of mentality. Although I think it can be taught. I like how Richard Feynman described it. He won the Nobel Prize in physics, but he dismissed the award. Instead he talked about, I think this is what undergirded his courage as a scientist was, he said, the prize is a pleasure of finding the thing, the kicking of discovery, the observation that other people use it, meaning it's work. Those are the real things. That's what drove him in his courage. The other way, I think it's relevant to talk about courage as a web developer is in the context of a pair program. There are two pairs on a computer desk. This is the worst slide I have. I just love it though. I can't get rid of it. So pair programs for those that don't know, it's two developers sitting at one machine, two monitors, hopefully they're mirrored, and usually one keyboard would suffice. The idea is that one person is actually using the keyboard and the other person is engaged, asking questions, proof reading. It could be directing the coding process. It's two developers and hopefully they would switch at some point. The pair program is a real-time collaboration. This can be frightening. This requires courage because you're exposing your thoughts in real-time. Those thoughts might be all over the place, right? Especially if you're pairing with someone that's a lot more experienced to you. I know I felt intimidated pairing with people when I felt like I wasn't up to it, up to the task. Let me show you a little. This is Ruby code, so nobody faints or anything. When I first learned how to code, it was in Ruby. This is a real example from two years ago. I had this exercise where I wanted to find the mode of an array of integers. I think it took me two hours, possibly longer. I'm feeling god mode and I'm in depression mode. It was horrible, but I got this thing working and work. It felt great. I talked to my friend and he showed me the solution. If I had this courage in that moment, I'd be like, wow, that's a great solution. What can I learn from it? Instead, I couldn't even accept it. I was kind of like, yeah, that's okay if you're going for simplicity. In that moment, I felt threatened by the solution. Instead of I wasn't open to learning. That's what type of courage that's required to take advantage of moments where you're exposed to new ideas and better ways of doing things. Instead of feeling threatened, there's a courage that you're ready to learn at any point. I like how Bernadette Brown said this in her book, during Grayley. So this is a sociology. Bernadette Brown is a sociologist. This book's not about coding, but I like how she put this, courage starts with showing up and letting ourselves be seen. That is a pair of programming. You can't help but be seen. There's nowhere to hide unless you just sit there and don't do anything. But that can be the frightening part of it. I think for a lot of us, the reason why we wouldn't pair is because there's lack of courage. It's another opportunity for us to think about where else are we being held back from lack of courage? What are the steps in our lives, in our relationships, in our family, in our community? This is a moment too where we can think about how to grow, encourage, and that is just the development of what, in the rest of our lives. The next virtue, the next virtue is justice. Justice, a lot of people talk about justice. What does justice have to do with engineering at all? What does that do with what at the moment? Well, you know, Lady Justice is typically depicted as blind, but often is blind, not always. But often, usually it scales in her hand, right? She's weighing something out. The idea is that justice, simply put, is giving to each what they're owed. Giving to each what they're owed. And you can extend that to not just people, but to institutions and communities, traditions, that sort of thing. So it's weighing out these obligations, navigating all those. But in order to do that, right, you need to pursue, you need to perceive a cosmic order, some set of obligations that you have. And then you have to navigate all those. Even when they're conflicting. That's the idea of justice. And so we're all going to have different views of justice. We're all going to have different conceptions of what are our obligations and what aren't our obligations and how do we even navigate those. That's where we have conflict between our views of justice. But hopefully, there's enough overlap in this room where we can look at something like this and realize we don't want to be in this situation. We don't want our face in this slide, right? Like, there's something wrong with this intuitively. But maybe you never made a connection. This is actually talking about justice. That writing unmaintainable code and leaving this company, that's an unjust practice. What I would say is there's just code and there's unjust code. So what does that even mean? That sounds really esoteric, right? So I like how Sandy Mets put this. This book is about OO in general. It uses Ruby examples, but I like what she said about just design. That design is more the art of preserving changeability than it is the act of achieving perfection. So changeability is an attribute I would attach to just code. The code that it's just, it navigates these obligations that it had. So what could the obligations be for code? Well, I would say it's changeability. Changeability means two things, right? One, that the requirements are going to change. That's just a given, you know, it's a presupposition. Like, the requirements that you're trying to meet in that moment where you're writing a code are going to change. There's going to be use cases that change. There's going to be different applications. Things are going to change. Nothing is static. And so that's one piece of code that there's code that coheres with that idea that the things are going to change. So it's written in a way that it's extensible, right? It's easy. It's easy it can be to maintain, to extend, and for other people to write. That's the other piece of it, is that who does your code belong to? It's not just for you in your professional setting and an open source project. You know, you're in a hackathon. Wherever it is, this code isn't just for you, right? It's for people that will use it after you, even maybe after you're a long gone. So people that need to read it, they'll need to see documentation, make sense of it. After all the knowledge that you had, the tacit knowledge, you, it's not there anymore. So code that's just is open to being changed. It also considers that all these other users that will come along later. So it takes a lot of energy to code in this way. I mean, it's not natural. I don't, you know, if you remember that example I just put up with that. My only concern in creating the, in finding the mode of an array of integers was that it would spit out the right answer. It wasn't about organization or maintainability or, you know, being well expressed, anything like that, right? And, but it takes extra work to do that stuff, at least until it becomes second nature. It takes more work to write documentation, to organize your code, and to think about producing just code. And so the only reason to really do it is that this is a value for you to produce just code. Maybe you never thought we're on that way, but that's actually what it is. I like how Michael Sannell, he's a professor at Harvard. He taught a really interesting course on injustice. I think it's available online, actually. So he said that thinking about justice seems inescapably to engage us in thinking about the best way to live. So when we think about producing just code, we can start to think, you know, am I producing code that coheres to all of its obligations? But also, like, what about the rest of my life? Am I living in a way that's just, am I satisfying all the obligations that I have, that others have with me? Your loved ones, your family, your friends, your employers, the community you come from, right, your neighborhood? There's all these different obligations that we have. Are we living lives that are just, not just as developers, just as people? So this is an opportunity to think about that and possibly grow in this virtue. Lastly, last virtue is wisdom. What does wisdom have to do with web development, if anything? Well, as I was starting to learn how to code and how to write software, I came across the idea of design patterns. Design patterns, Bob Martin said, defined it this way, that 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 in the period of many years. So design patterns are, you might not even know when it came from, right, the command pattern, the observer pattern. It's cool to look into the history behind some of these and how they evolve it. To use them, you don't need to trace out some etiology or anything, right? You just implement them. Use them as you see fit, as you see them to be useful in your situation. This is how it works for coding using design patterns. This is what Bob Martin said. Other people told you about, you got to write a book, you heard it in a talk, saw it in a blog post, and you start to implement that. So what would it mean to find design patterns for life, for life itself, right? That's what wisdom really is, is the artist's skillful living, making good decisions, knowing which path to take, which steps to take, confuses. I don't read confuses, so I don't know if we actually said this. The internet told me about this, so hopefully it sounds good though. By three methods, we may learn wisdom. First, it's by reflection, which is the noblest. Second, by imitation, which is easiest. And third, by experience, which is a bitterness. So I think this is very accurate. I mean, you know, how many of us carve out a title or can have silence and time to meditate, write notes, to think about choices you've made, the path you're taking, a lot of them are so busy, we have so many toys and so many responsibilities, so many interests, that we don't have that time for the noblest path. There's another path to write experience which Confucius says is bitter. But a lot of us, this is how we learn is that if we don't make that mistake, we're not going to learn from it. But imitation is about finding people that are worth imitating. So in the developed world, that's a lot of what we see. This conference to me showed me a lot of people that are worth imitating in terms of how they approach solving problems with code. But what about for the rest of your life? Who's living that life that you want to live? Who's worthy of imitation? Are you in contact with anybody like that? Whether someone an author or someone better than that is someone in person, right? Someone that you know that you can talk to, you can get these light design patterns from. There's someone like that. A lot of us live in isolation in this regard where we just think, magically I hope I just become more wise. We're not proactive about seeking that type of input. So this could be a moment to grow in wisdom. A moment to look at our lives and think about do we have this art of skill to live in? And so we just recap the four classes of virtues. There was self-control, courage, justice and wisdom. And so in taking these and writing tests, getting back to the idea of TDD for our souls, who consisted of our reflection along these lines. I think these are great from they come from this last word. He said, you know, he gave three broad questions. Who am I? Who ought I to become? And how ought I to get there? You can think of these as like feature specs or something even if you want to keep stretching the metaphor. So what would it look like to TDD for your soul? An example of this would be something that I've implemented for myself is these long lines of courage that often I found myself resisting the opportunity to learn because I was afraid of exposing my ignorance. So the test would be to me to write a test about Abraham, are you being creative at work? And I was failing that test. And so the next step is to implement habits and behaviors that would help me to pass that test. And this is all correct but I started to practice this habit of just saying half hour maximum time limit that I would stay stuck in a problem. So I try to read that commutation, try different angles but that half hour elapsed and I would ask for help and I would get a great place where I could get help easily and it's never been something where I need to be afraid of asking for help but it's always been internal. I just didn't want to admit I needed it. And this was as a beginner this is something I had to wrestle through. So this is how I practice this it's right between the refactoring comes from after a moment, I mean that half hour time limit I don't do that anymore. That's the refactoring piece. I don't need that type of artificial rule. But that's the process of TDD for the soul. That's the way I approach it. And so for you the question will be for you to consider these broad questions and what they mean in your life. So I can end it here. I've been this talk before and I can just end it there TDD for your soul came up with this try it out maybe and we can all go. But I need to just talk a little bit about why don't people what's one big obstacle even doing this. A lot of people just don't walk out here and they're like that was great see everything once again. And I found this cool slide I had to just put this in there too. But the reason why the big reason why a lot of us won't TDD our soul is because of shame I think though. Somehow somewhere we were taught to have shame over our failures. And so why would we write these failing tests about our weaknesses. Our lack of character. Why would we introduce more shame to our shame plate right like that it's ridiculous. You know what is shame even it can be contrast with guilt. So guilt is feeling badly about something you've done where shame is feeling badly about who you are right. So shame is often centered around this idea am I good enough and we're feeling ashamed the answer is no. The answer we hear is no. And so if you're already feeling this way why would you invite more of it in right. Because in meaning that you have failures and weaknesses it just feeds that voice it tells you you're not good enough and that your failure and that you have these flaws and no one wants to hear that almost nobody would want to go through that process right. But what I'm saying is that there is a different way to look at these things that in fact our failures don't have to drag us down but there's a buoyancy that we can have with failures where they become not an anchor pulling us down but a vehicle towards growth and developing virtue and so there's a different way to look at these as failures where we're not wallowing in them we're not afraid to admit them either because we're seeing that they're actually going to help us grow and so let me know who this is shout it out if you do. Shepard Shepard Book from Firefly right so he's a religious character that's from a series that was on TV called Firefly that was cancelled and there's a movie called Sprinty that came up due to the fans and their demands for some resolution in the series which is really cool and so I'm a big fan of Jasmin who's a writer behind this so nerds would recognize that if you're a nerd like me but Shepard Book was a religious character and he often had his clashes with the main character of the Firefly world whose name is Mal Mal is an agnostic I think he just hostile to the ideas of religion that Shepard Book had but at one point in the story Shepard Book knew that he needed to motivate Mal to make a decision we also knew he had to get past his hostility and he said he said to Mal I don't care what you believe just believe it I don't care what you believe just believe it and that's what we told him in order for him for Mal to already take that next step and so me the metaphysical grounds for the way I approach failure and growing in virtue and not coming to shame but using those moments to take me on this journey of growing in virtue these things coming to me from the resources I have because I follow Jesus Christ that might not be the path for everyone here but we need to all find grounds and the resources to go on this journey if we're going to grow in virtue and so I don't care what you believe just believe it whatever it is the only choice that would be horrible to make it be to not make a choice at all because what's open to us is a chance to grow and to become the best people that we can become so I call it the blues mentality I come from Chicago and the history of blues are really interesting blues music is affected every genre of music we're talking about I would say and I like how Ralph Ellison put this that the blues is an impulse to keep the painful details of 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 what this thing is our failures don't have to destroy us right but we can squeeze something beautiful from it and I'm not talking about making music all that's cool too Ralph's saying squeeze from it just a journey of growing in virtue so with this mentality we can admit our flaws we can admit where we don't have self-control, justice courage or wisdom we can be frank about that but not to just stay in that moment but to use those moments to interpret the behavior and the habits that we need to grow in those four areas and thereby this process of treating our soul is not just about becoming better software developers better engineers it's about becoming better people who benefit us all thank you