 So, yes, I am Avdi, and this is my very first Keep Ruby Weird, and now I'm kind of bummed out that I missed all the other ones, but we sold her on. But this has been so cool, and just before I go any further, can we just get a round of applause for Terrence and all the organizers? So I gotta admit, I feel a little bit unqualified to be up here. I think that I have always been a fan of Ruby's weirdness over the years, and the weirdness sort of associated with it, but you know, I think to me like the most defining feature of Ruby's weirdness and the culture around it has been whimsy, just this real whimsical silliness, and I had to come to terms, a while back I had to come to terms with the fact that I am just not very good at whimsy. I'm not, and I hate puns, but so hopefully you can put up with me anyway. I am not good at whimsy, but one thing that I do have is I have a lot of weird ideas, and for the past few years I've been preoccupied with one particular weird idea, and the idea is this. I believe that code is incidental to the practice of programming. I don't think that it's central. I believe that programming, in fact, is the practice of applied philosophy. I think that what we use code to do is we use it as a tool for making sense of the world that we live in, a tool for dividing the world into well-defined categories, you know, schemas, a tool for deciding how concepts are broken down into their component parts, a tool for telling the stories that help define our experience of life. But here's the most important thing that I believe. I don't think that it goes just one way. I think that the way that we design software is unconsciously influenced by our beliefs about how the world works, and I also believe that our ways of perceiving the world are unconsciously influenced by how we model the world in code. There's a principle from the Hermetic philosophical tradition that kind of sums up this idea. It goes, as above, so below. Something in this case that what is within us is reflected into our work in the world, and our work in turn changes how we perceive the world. I believe our approach to software gives us a window into how we think about our world, our lives, and even how we think about our relationships. So today I want to take you on a philosophical journey. I want to tell you a story about this mutually recursive relationship between the inner world and the world of programming, and it starts 20 years ago. See, this year is actually kind of an anniversary year for me. 20 years ago, this past summer, I was taking an Advanced C++ course at my local community college, and I was nailing all of my assignments, but I still needed a final project to wrap up my grade. Now, coincidentally, at the same time, my dad was working as a programmer at Raytheon, which you learned earlier, was co-founded by Vannevar Bush. His team was writing software for an air traffic control system, and they were transitioning to C++, and they were having some adjustment pains, and he got this bright idea that here I was learning all about C++. Maybe I could come consult with his team, and then I could use that experience for my final presentation, and somehow he actually managed to convince his boss that this was a good idea. So here I am, this 18-year-old kid in a tie-dye shirt, sitting with a bunch of button-down engineers, trying to sound like I knew what the hell I was talking about. Mostly what I remember is just saying the word polymorphism over and over again, and they're all nodding along like, oh, yeah, polymorphism, good point. A couple of months later, I get a call from the engineering manager there asking if I wanted to come work for them as a contractor on the very same project, and that, 20 years ago, that was the beginning of my professional software career. Incidentally, that is a picture of the radar that I worked on. Has anybody here ever flown into Chicago or into San Francisco, Detroit, Philadelphia, Atlanta? You're welcome. So I realized that my career in software has centered around the idea of object-oriented programming from the very beginning, and I have been doing this stuff and thinking about object-oriented programming for two decades now. And along the way, I found out that almost everything I thought I knew about OO was wrong. I don't have time tonight to talk about all of the OO fallacies I had to unlearn. That's another talk altogether, but here's the thing, like, you might be wondering what does it even mean to be right or wrong about object-oriented programming? I mean, who gets to define object-oriented programming anyway? Well, here's the thing. OO is not like Agile. It was not a consensus that was defined by a committee. While it built on many ideas that came before it, object-oriented programming as a design paradigm was invented and named by one person, and that was Alan Kay. Kay and his team at Xerox PARC, they also created a programming language and an environment that was intended to embody as much as possible at the time, the spirit of object-oriented programming. And that programming language was small talk. And basically every OO language or language even trying to be somewhat OO has been influenced by small talk, including to a very great degree, Ruby. Okay, so if I talk about what is and is not object-oriented, my source of authority for this is Alan Kay and the things that he has written or said over the years about object-oriented. So what does Kay say about OO? What does he say that it means? Well, unfortunately, he never laid down a formal definition, but here's one of the most concise explanations he's given. He says, OOP to me means only messaging, local retention and protection and hiding of state process and extreme late binding of all things. Now coming to understand how Kay defined OO clarified a lot of things for me, but even with those understandings, there was one massive fallacy that I had yet to confront and that is the one that I want to talk to you about today. This is not it, but it's a good place to start. Early in my career, I thought OO was all about calling methods. What did it mean to call a method? Well, it meant to invoke a procedure on an object instead of passing an object or data structure to a procedure. Simple. Later on, I learned that OO was really supposed to be about sending messages and in fact Alan Kay even said he regretted calling it object-oriented programming because the focus really should have been on messages. Okay, so what is the difference between messages and methods anyway? So here's how I learned. When we send a message, the object we send it to gets to decide what procedure to run. Different objects can implement different methods for the same message. It's a form of late binding, deciding what to do at the last possible moment. Okay, so OO is about messages and a message is a way of invoking a method where the actual definition of the method is decided at run time based on the type of the object. This makes sense as a definition of message, right? I mean, sure it does, right? This is the definition of message that I learned. It's the one that I've taught to other programmers for years. But just for funsies, let's compare the object-oriented definition of message with the original definition. Let's compare it with sending a message through the mail. When we send a message in the mail, we include everything the recipient might need to know in order to act on the message. So if they need information from a separate document, we summarize the relevant parts for them. When we send a message to an object, we can include references directly to any other object we know about. We can send along the whole kitchen sink if we want to. When we send a message in the mail, we walk away from the mailbox and we get on with our lives. We may or may not receive a reply. When we send a message to an object, it's synchronous. We freeze until that object is finished processing the message. And in some languages, we always get a reply in the form of a return value. When we send a message in the mail, if we send it in a language the recipient doesn't understand. Nothing happens to us. But when we send a message to an object that doesn't understand it, our whole thread of execution blows up. When we send a message in the mail, we know it might not reach anyone at all. When we send a message to an object, we expect that it will either be handled or our whole thread of execution blows up. Boy, these things are starting to sound not like messages at all, but they must be messages. Something we've learned about objects says that the concept of messaging is central. Let me tell you a quick Zen parable. One day, the master said to the novice, when you achieve mastery, you will be able to move objects using only the power of your words. The novice said, but master, I have lived with you for 10 years and I have never seen you use this power, even to bring the TV remote to the couch. You always just tell me to fetch it for you. At that moment, the novice was enlightened. See, here's the big lie of object-oriented programming for the past 40 years. Just like the Zen master, we keep promising the power of sending messages. We keep saying that we're sending messages, but we're really not. Alan Kay envisioned objects as, quote, being like biological cells and or individual computers on a network, only able to communicate with messages. But even small talk, the language that was intended to embody the OO principles, it never fully implemented the messaging idea. In fact, every OO language has failed at delivering the central promise of OO. We keep talking and acting as if we are programming with real messages. And this is why we seem to keep revisiting the idea of how to do OO right. This is why it's such a slippery concept, because our words and the reality don't match. Now, my goal here is not to destroy your faith in object-oriented programming. But cognitive dissonance is dangerous. And for decades, we've been telling ourselves that we're programming with messages when we very obviously are not. Now a lot of people will tell you that the original sin of object-oriented programming is mutable state. I disagree. I believe that the original sin of object-oriented programming is return values. Return values are a fundamental denial of the messaging model. But I am not here to deliver yet another critique of object-oriented programming. Synchronous procedure calls with return values are part of a pervasive philosophy, philosophical problem that goes way beyond just object-oriented programming. See, there is a monster stalking the programming labyrinth. And in my experience, this monster is the cause of more confusion, more technical debt and more rework than any other misconception. I call this beast the transactional fallacy. The transactional fallacy occurs every time a developer models a process as a transaction. Here are some properties of a transaction. It has a goal and no existence beyond that goal. It is synchronous. It blocks until it finishes. You can't put a transaction aside for later. It is assumed to complete in essentially zero time, at least from a human perspective. It is not supposed to be able to hang indefinitely. A transaction either completes or it aborts. There is no concept of partial completion. And if it runs into any kind of error, it self-destructs, leaving nothing more than an exception in its wake. There is no possibility, no concept of resuming. Every time your workers are crashing, because a web service is unexpectedly taking minutes to respond, that's the transactional fallacy in action. Every time your program freezes up while it's parsing a big hunk of input and you realize that to even show an updating progress bar or a percentage would take some serious re-architecting of your code, that's the transactional fallacy. Every time you have a bunch of stateless service objects and you have a workflow that used to encompass just one request, but now it involves more than one request. And you find yourself looking for a way to sneak bundles of intermediate state from one service to the next. That's the result of the transactional fallacy. Then you have a form and you realize that it actually needs to be a multi-page form. And this causes you to have to rewrite a bunch of your code. That's the transactional fallacy in action again. Oh, but then it turns out that your users are painstakingly filling out this multi-page form and then they're coming back after their session expired and now they're mad at you because they lost all their work. And so you have to rework your code again to stash away the data from these incomplete forms. That's the transactional fallacy. Oh, and then when it turns out that we actually need to run queries against the incomplete form submissions and so you have to rework your code again to make that incomplete data available as a first class member of your database schema, that's the transactional fallacy. And then you have to start modeling a process as transactions. Whenever I take one of my kids to a new doctor, I have to spend 15 minutes filling out intake forms. Anybody feel my pain on this? It sucks. I hate it. But at least I know that if I put the clipboard down, the forms won't reset themselves. At least I know I can take the forms with me into the consulting room and keep filling them out asynchronously while my kid is getting checked out. At least I know that I can leave some fields blank and if they really need to know, they can get in touch with me and pull that extra information. I shudder to think what the intake experience would be like if it were designed by a programmer. The transactional fallacy has a universal symbol. You're probably familiar with it, even if you might not realize it. It's the spinning beach ball of death, the universal symbol that a programmer expected something to either finish or fail more or less instantaneously, and it did neither of those things. But the transactional fallacy goes beyond just code. Remember what I said at the beginning, as above, so below. Our approach to code and our philosophy of life are interrelated and mutually reinforcing. And fundamentally, the transactional fallacy isn't a programming problem at all. It's a problem in how we understand the world and the lives of people in it. When we commit to the transactional perspective, it can have serious ramifications. I know because I made this mistake, and now I want to get a little more personal. I mentioned before how I started my software career when I was 18. In retrospect, I realized that this was the beginning of an almost 20-year-long transaction. They say it's good to have goals. Even back then, I had a vision of the life that I wanted. I wanted a wife and lots of kids. I wanted to live in a house in the woods, in the mountains. I wanted to work from home surrounded by my kids. I wanted to home school and homestead. I wanted to hang tire swings, build tree forts. I wanted to be snowed in with a roaring fire and nowhere to go. I wanted to look out for my deck a little above and away from the world and sip my tea and just think and write. I wanted all these things. And so I started on a path to accomplish them. And shortly after getting that first software job, I figured I could get a jump start on my goals if I acquired an instant family. So I became a husband to a woman I barely knew and a stepfather to two young children I was woefully unprepared to raise. And we had more children. And as we had more children, money was always tight. And those goals sometimes seemed to recede into the distance. And so I set myself single-mindedly to the task of advancing my career in order to achieve my goals. And this informed every decision that I made, the choice to work late, to neglect hobbies, to dismiss friendships, to switch jobs, to start my own business, to raise my profile with blogging and podcasting and books and conference talks. Everything that I did was in service to this one singular vision. I was focused and I was relentless. And along the way, like any good transaction, I lived in the future. I thought to myself how when I got there, I'd have game nights with the kids. When I got there, we'd go hiking every week. When I got there, my partner and I would go on more dates. Just a little further, just a few more 12-hour days, just a few more years. Even when our values started to change in ways that suggested that maybe our dreams should be updated a little bit, I didn't waver. Even as we were miserable and unfulfilled in the present, I stayed the course. My life was a synchronous transactional function. I was fixated on the return value and I made it. Bet you didn't see that coming. I reached the end of my road, literally, as I drove my old Buick with two yowling cats in the back up a steep mountain driveway and I saw the rest of my family come pouring out of our new Tennessee home with huge smiles on their faces. It is hard to describe that feeling. At the age of 35, I had literally accomplished everything I had set out to do. I got to enjoy that feeling for two years. A year and a half ago, my wife told me she was leaving me. To be honest, it was something that we both knew should have happened much, much earlier. But as we worked our way painfully through our separation agreements, I realized that as side effects, nearly every part of the dream that I had worked for all that time was going to be disassembled. In the aftermath of this, there were many revelations. One was just how transactional my approach to life had been. I realized that I had been trying for almost two decades to bring my life to an end. Not an end in death, but to a static state, a return value. Have you seen the Lego movie? Well, if you haven't, sorry, spoilers ahead. So I realized that I had become Lord Business trying to get everything in my life just so so I could freeze it in place forever with crazy glue. My vision of the future was so concrete, so compelling that I lost sight of the present. It wasn't a revelation that my partner and I had been miserable together since nearly the beginning. That much had been obvious. But transactions don't take note of intermediate statuses like that. Transactions don't alter course. Transactions know that everything will be resolved once they finish. They only have two possible outcomes, success or failure. As programmers, I think we are prone to think in terms of problems and solutions and outcomes and true and false and success or failure and in terms of transactions and seeking towards a finished state. I had become my own spinning beach ball of death, frozen on waiting for the next phase to complete, telling myself that once the function returned, then, then I would start really living. It may seem like I'm stretching the transaction metaphor a little bit, but here's the thing. You can't expect to do something eight hours a day, five days a week, and expect it to not influence the way you approach life and vice versa. Remember what I said at the very beginning. If there's one thing I believe about our profession, it's as above so below. Our world view influences our software and our programming paradigms bleed into our world view. Okay, that got pretty intense. Let's get back to safer ground for a minute. Let's talk about programming again. So is there an alternative to thinking in transactions? Let's go back to Alan Kaye in small talk for a minute. Remember he said this, I thought of objects being like biological cells and or individual computers on a network, only able to communicate with messages. Does this describe a transactional system? Hardly. It sounds like something much more asynchronous, independent, and possibly resilient. And when you dig into the history of small talk, you discover the seeds of something more interesting than the sham messaging systems we've learned to cope with. So here's an example of code from the early small talk 72 system. This small talk class is also a function. It is a function that pattern matches on the messages it receives and decides what to do based on the match. And if it wants to, it can decide to ignore a message completely. Now if you look at this, this might be ringing a bell for some of you, because if you look at it and squint, it looks a little like Erlang or Elixir code, pattern matching on incoming messages. And this is not a coincidence. Carl Hewitt saw a small talk 72 and it helped inspire the actor model that he later developed, which would go on to influence the design of Erlang. See here's the colossal secret at the heart of object-oriented programming. It wasn't supposed to be about objects at all. The vision Alan Kay has described was more than objects as we understand them. He was talking about processes. And if there's one fundamental change that I've made in how I approach programming in the last few years, it's this. I've started looking for the processes. I've started trying to model systems as processes, made up of more processes. And it's not about choosing the right language or the right framework. Being process-oriented is about perspective. It's about looking for the workflows in the human systems that we facilitate and then explicitly modeling those workflows as processes instead of just modeling the individual steps. Because in the end, just about everything is a process. Web service calls, they aren't transactions, they're processes. Antities that we often think of as static are really processes. Take the user account, for example. This is something that goes through states, it goes through a lifetime. The user accounts are provisionally registered, then they're confirmed and they might be elevated in their privileges. They might go dormant, be suspended, then be reactivated. It's a process. The project you are working on right now is a process. Your software team is a process. Your own cells are constantly dying and being replaced, but you still have a coherent identity. It's not so much that you're a person as that you are constantly personing. And hopefully, I hope you will continue to do so for a very long time. Your life is a process, not a transaction. What life has taught me over the past few years can be summed up like this. Look for the processes, embrace the processes. So what has changed in these 20 years I've been doing software? I'm not looking for objects so much anymore. Now I'm trying to learn how to build graceful processes in my code and in my life. Now I don't have anything like enough time to teach you how to practice process-oriented programming. And to be honest, I'm still figuring that out for myself. But remember what I keep coming back to, as above, so below. The way we live our lives changes how we design software. I really believe this. And so for the rest of my time here, I just want to talk about what it means to be a graceful process. And hopefully you'll find that some of these lessons maybe also inspire changes to how you write code. Oh, but immediately we run into a problem because here's the thing. I can't simply teach you about being process-oriented. Because the very act of transferring static knowledge is inherently transactional. Fortunately, fortunately, you already have a teacher who is ready to help you. And they've always been there, waiting. The best teacher you can possibly have for embracing the process of life is your body. Your body is never static. It has no ideal end state. Your body is constantly dying and replacing itself. Your body interrupts you in the middle of trying to reach a return value, that last green passing test, and says, I'm sleepy. I'm hungry. I'm cold. You know, as programmers, we tend to try to be brains in jars. We like to pretend that our ideas can be completely separated from our bodies. Learning to be a graceful process as a person means acknowledging that you are an embodied mammal. It means learning to live in your body. And this can be as basic as maybe learning some mindfulness meditation. It can mean taking up yoga. It can mean running, or biking, or lifting, or hiking. But as you do this, as you do any of these things, be careful. See, what I've noticed is that we hackers are so addicted to being brains in jars that we find ways of taking ourselves out of our bodies and staying in our analytical brains even when we're running or lifting weights. We measure and quantify instead of learning to listen to our bodies. And in case it's not clear, what I'm saying here is, throw away your Fitbit. Learn to feel when you need to take more steps. Learn to feel your target heart rate zone. Learn to feel when you're dehydrated. Excuse me. Now, believe it or not, for me, understanding embodiment, embracing embodiment has also meant learning to value of all things, Instagram, and selfie culture, really. So I don't follow many programmers on Instagram. I mostly follow poets. But I do follow these two. Does anybody else follow these two, anybody? So this is Lydia Halley, otherwise known as the avocator. And Alex, otherwise known as the yogi-coder. They have tens of thousands of followers each. And they post about, like any programming blogger, they post about what they're coding, what they're learning. But unlike most programming bloggers, they attach pictures of themselves to every post. And to logical programmer brain, this might seem pointless. It's just extraneous data. But I think it is a powerful stand against the disembodiment that is so prevalent in agriculture. It's a reminder that programmers are not, in fact, brains in jars. We are people. We have bodies. We exist in space. I want to challenge you to do this, too, to get comfortable with portraying yourself in your own body. And you can get started right away by taking a selfie with me tonight at the hangout later. So building graceful processes also means starting where you are and learning to love state. And I realize that this is not a popular suggestion in some circles, in some programming circles. But state is simply the acknowledgement of time. Everything we want to accomplish with computers or otherwise involves the passage of time. State is the acknowledgement that any process in the world, whether it's a workflow or a human being, is an accumulation of events and their lasting effects. Another way of looking at the same thing is that state is an acknowledgement of entropy. See, the world is constantly throwing chaos at us. And I have seen it suggested that human beings are basically compression functions. We consume a virtually infinite stream of incoming events from the world, and we generate a smaller set of events, the things that we choose to say and write and do in response. And this is how we create sense and meaning. This is how we oppose entropy in a world that trends towards chaos. And this is what our software processes need to do. State is the acknowledgement that we need history in our systems. Stateless transactions aren't enough. Alan Kay wrote this great post on Quora recently. He was responding to someone who was wondering if functional programming and object-oriented programming are incompatible. And he wrote, we need both progression in time for most of our ideas and rememberings, and we also want to reason clearly about how every detail was arrived at and to advance the system. But this doesn't mean that we have to be stuck with the bug-prone semantics of mutable state, because Kay goes on to say in the same post, we could allow real objects to be world lines of their stable states, and they could get to their next stable state in a completely functional manner, with no race conditions to get to their next version. And systems should be able to be rolled back to previous versions. He wraps it up with this. Both OOP and functional computation can be completely compatible and should be. There is no reason to munge state in objects, and there is no reason to invent monads in FP. In other words, objects with state are a way of composing functional calculations into discrete timelines. They are processes. I think for humans in general, but for programmers in particular, we love the idea of a clean reset, a reboot. One of the hardest things for me to accept in life has been the realization that getting older is a process of constantly closing doors. There are so many things that I will never do. So many people I will never be. Starting where you are means accepting entropy. It means coping with the idea that there are no clean slates. There's always history. Starting where you are means working with legacy code when all you want to do is a complete rewrite. Building graceful processes also means falling forwards and failing forwards. When I was a kid, I read the Hitchhiker's Guide to the Galaxy series by Douglas Adams. How many people have read these? Quite a few. That's awesome. So if you've read these books, you might remember that Adams wrote something about learning to fly. He wrote, there is an art to flying or rather a knack. The knack lies in learning how to throw yourself at the ground and miss. And for years, you know, I thought of this as just a funny line. And it was only very recently that I realized the profound philosophy for life that this represents. You see, like I said earlier, entropy is unavoidable. That means failure is unavoidable. Surprises are unavoidable. Sometimes a scorpion just lands on your monitor out of the blue. Totally hypothetical example. Now, what is the standard way for a method in a modern object-oriented programming language to deal with something unexpected like this happening? It raises an exception, right? In the process, it throws away the current stack. All the local variables probably closes down some network and database connections as well. Have you ever spent a significant amount of time adding code just to capture more contextual information when a particular exception is raised? Not actually fixing the exception, mind you. Just trying to gather enough data to understand how it is even happening. You know, something that I've observed is that the more focused we become on preventing failure, the more catastrophic the failure tends to be when it finally manages to get through. And it always manages to get through. We need to be less focused on preventing failure and more on understanding how we got there. Because everything is failing all the time, and the trick is to keep failing forwards. Or in the words of Buzz Lightyear, the trick is falling with style. When my transactional life raised an exception and came crashing down, I discovered something. While I had a lot of friends online, locally in my town, I had no one. I had completely failed to build a local tribe for myself. I think this is an endemic problem among programmers. You know, part of being a brain in a jar is that we find it very easy to content ourselves with online relationships. It's not a big leap between believing we can divorce our ideas from the rest of ourselves to believing that typing to a friend is just as good as getting a beer together. You know, I took a Twitter poll about this recently, and over a thousand people responded, and most of them felt that they did not have an adequate local support network. If you are part of that 72%, and if you take nothing else away from this talk, I want to encourage you to prioritize making local friendships. I cannot under, ha, I cannot overstate how important this is. Do it before something catastrophic happens in your life, and if you are not sure how to get started on this, please come talk to me. Talk to me afterwards, send me an email. I will help if I can. Now that I'm no longer trying to build towards a fixed point in my life, I do a lot of thinking about the purpose and the direction of my life. And this turns out to be surprisingly tricky. Because what happens is I'll dig and dig and dig to try to get at my root motivations. And what I, what I wind up left with is some mission statement that's so vague as to be useless. Something like, my mission is for everything to be the goodest for everyone, everywhere, always. It's laudable, but it's not helpful. So what I've found is that it's more useful not to have a goal, not to have a mission, but to have images that you pull towards, which are concrete, but also fanciful. My friend Janelle calls this having an arrow, something that gives you direction. So one kind of arrow that I've found, that I've found useful is my beer list. And this is a list of prominent people I want to have a beer with someday. You will probably not be surprised to learn that Alan Kay is on that list. I also want to have a beer with Adam Savage someday, the formerly of Mythbusters. But here's the thing, see, I don't, I don't just want to have a beer with these people by chance, or because I win a backstage pass. What I mean by my beer list is I want to become the kind of person who they would want to have a beer with. I want to find myself in a place in life where it actually makes sense for me to be having a beer with them. Now, I will probably never have an actual beer with most of the people on my list. But the list gives me a criterion. It gives me a litmus test when making decisions in life. Which choice takes me closer to being the sort of person who would end up having a beer with Adam Savage someday? It's clarifying. So look for those arrows, look for those images that you can pull towards that give you an idea of which choice to make when you come to a crossroads. And the image is gonna be different for everyone. Your arrow is gonna be different. Okay, so you might have noticed that for a while now, I've been talking about graceful processes. And I think I've established the process part, but you might be wondering where grace entered the picture. Let me explain this the best way that I know how. I don't have a lot of hobbies left, but one thing I still do regularly is I take myself out dancing. Now, when I go dancing, I go to goth industrial clubs and electronic dance music shows. I heard that, VNV, yeah, this is a show in Nashville. So yeah, EDM shows, industrial nights, that kind of thing. And if you're not familiar with these kinds of events, they are not known for their couples dancing. Everyone kind of does their own thing on the dance floor. So while I've been dancing for many years, I have never learned to dance with a partner. And every now and then, someone will try to dance with me. And it is never pretty when this happens. One time, someone tried to dance with me, and it lasted about 30 seconds before they stopped and said, dude, are you okay? But this one time recently, someone I had just met earlier invited me to dance with them. And I yelled over the music. I warn you, I have no idea what I'm doing, but they were insistent. And it was a fiasco. I really had no idea what I was doing. But every time I did something clueless and awkward, every time I botched a twirl, they made space for it. And they flowed into it. And they came around again with a big, kind smile. And by the end, well, I was still awful. But I was smiling too. And I was starting to pick up on their cues. And they were making us both look good. You know, the word grace is interesting because it has two different meanings. On the one hand, it means beauty in lines or in motion. But if you were raised with a religious background, anything like mine, you might have heard that grace is also something that saves you. And in that moment on the dance floor, I realized that these two meanings of grace are really one and the same thing. Because grace is something that makes space for you to screw up. And turns it into something beautiful. Grace is taking the random stream of events that are thrown at you and creating meaning from them. Grace is being embodied, mindful, and reflective. It's knowing where you stand in space. Grace is starting where you are. Grace is working with legacy. Grace is falling forwards and missing the ground. Grace is extreme late binding of all things. It's deciding what to do at the last possible moment. Grace is leaning into the people near you and trusting them to catch you, or at least to give you a hand up. Grace is living in the present moment and not in the future. Grace is laughing at yourself. Grace is forgetting what you're solving for and just knowing what you're pulling towards. And when everything has fallen apart, grace is what saves us. So live gracefully, build graceful processes, and don't forget to dance. Thank you very much.