Object-Oriented Programming (OOP)

Summarized using AI

Closing Keynote: OOPS

Avdi Grimm • November 28, 2018 • Earth

In his closing keynote at the Keep Ruby Weird 2018 event, Avdi Grimm explores the theme of whimsy in Ruby programming, focusing on the philosophical implications of object-oriented programming (OOP) and its inherent transactional fallacy. He argues that code, while essential, is incidental to programming, which should be viewed as an applied philosophy that shapes our understanding of the world. Grimm emphasizes the importance of messaging over method calling in OOP, referencing Alan Kay's original vision of OOP as a messaging-oriented system rather than one focused solely on objects.

Key points discussed include:
- Whimsy in Ruby Culture: The quirky nature of Ruby programming reflects a whimsical culture, although Grimm admits he struggles with this concept.
- Code as Incidental: Programming should be seen as a way to express philosophy and understand the world, rather than just writing code.
- Messaging vs. Methods: OOP should focus on messaging, where objects communicate and decide how to respond, contrasting with the traditional view of calling methods.
- Transactional Fallacy: Grimm identifies a significant issue in programming practices—modeling processes as transactions leads to confusion and disconnection from real-world dynamics.
- Importance of Grace: Building graceful processes involves starting from current states, acknowledging history, and embracing failures as part of the learning experience.
- Embodiment in Programming: Encourages programmers to stay connected with their bodies and recognize their physical self as vital to their work life.

Grimm concludes that by recognizing the intertwined relationship between our programming ideals and our life philosophies, we can approach both programming and life with a mindset focused on process, flexibility, and grace. He urges programmers to move beyond transactional thinking and build systems that respect the complexities and messiness of reality. The keynote serves as a reflective call to rethink our programming practices and life choices, reminding us to embrace the process rather than fixate on predetermined outcomes.

Closing Keynote: OOPS
Avdi Grimm • November 28, 2018 • Earth

Keep Ruby Weird 2018 - Closing Keynote by Avdi Grimm

Avdi Grimm is a father, a Ruby Hero, the head chef at RubyTapas.com, and author of the books Confident Ruby and Exceptional Ruby. He splits his theoretical spare time between hiking the Smoky Mountains and dancing to oontz-oontz music.

Keep Ruby Weird 2018

00:00:09.500 Hello! How y'all doing?
00:00:16.100 Right, so yes, I am Avdi and this is my very first Keep Ruby Weird.
00:00:22.380 Now I'm kind of bummed out that I missed all the other ones, but we soldier on. This has been so cool!
00:00:34.469 Before I go any further, can we just get a round of applause for Terrence and all the organizers?
00:00:49.780 I have to admit that I feel a little bit unqualified to be up here. I've been a fan of Ruby's weirdness over the years, and the quirks associated with it.
00:01:01.430 However, I think the most defining feature of Ruby's weirdness and its culture has been whimsy.
00:01:10.060 It has a real whimsical silliness to it. I had to come to terms with the fact that I'm just not very good at whimsy.
00:01:21.140 In fact, I dislike puns.
00:01:26.540 So hopefully, you can put up with me. I may not be good at whimsy, but I have a lot of weird ideas.
00:01:35.770 For the past few years, I’ve been preoccupied with one particular weird idea: I believe that code is incidental to the practice of programming.
00:01:55.970 I don’t think that code is central. Instead, I believe that programming is the practice of applied philosophy.
00:02:12.800 We use code as a tool for making sense of the world around us, for categorizing concepts, and for telling the stories that shape our experiences.
00:02:24.830 But here's the crucial point: I don't think it goes just one way.
00:02:32.319 I believe that the way we design software is unconsciously influenced by our beliefs about how the world works. Our ways of perceiving the world are also unconsciously influenced by how we model the world in code.
00:03:07.240 There's a principle from the Hermetic philosophical tradition that encapsulates this idea: "As above, so below." This means that what is within us is reflected in our work in the world, and our work in turn changes how we perceive the world.
00:03:29.709 I believe our approach to software gives us a window into how we think about the world, our lives, and our relationships.
00:03:55.180 Today, I want to take you on a philosophical journey. I want to tell you a story about this mutually reflective relationship between our inner world and the world of programming.
00:04:08.470 It starts 20 years ago. This year is an anniversary for me. Twenty years ago, this past summer, I was taking an advanced C++ course at my local community college.
00:04:29.979 I was nailing all my assignments but still needed a final project to wrap up my grade.
00:04:43.270 Coincidentally, at that same time, my dad was working as a programmer at Raytheon. He got this bright idea that since I was learning about C++, I could consult with his team on their software project.
00:05:06.340 Somehow, he convinced his boss that this was a good idea. So there I was, this 18-year-old kid in a tie-dye shirt, sitting with buttoned-down engineers, trying to sound like I knew what I was talking about.
00:05:21.070 Mostly, I remember just repeating the word "polymorphism" over and over again, while they nodded along.
00:05:34.330 A couple of months later, I received a call from the engineering manager asking if I wanted to work for them as a contractor on the same project.
00:05:50.290 That was the beginning of my professional software career, coincidentally attached to a radar project that I worked on.
00:06:01.750 Has anyone here ever flown into Chicago, San Francisco, Detroit, Philadelphia, or Atlanta?
00:06:13.980 I've realized that my career in software has centered around the idea of object-oriented programming from the very beginning.
00:06:30.350 I've been thinking about object-oriented programming for two decades now, and along the way, I discovered that nearly everything I thought I knew about it was wrong.
00:06:45.550 I don’t have time tonight to discuss all the OO fallacies I've had to unlearn—that's a different talk altogether.
00:06:58.150 But here's the thing: you might be wondering what right or wrong even means concerning object-oriented programming.
00:07:07.180 Who gets to define object-oriented programming anyway?
00:07:18.580 Well, OO is not like Agile; it wasn't defined by a committee. While it built on many earlier ideas, the design paradigm of object-oriented programming was invented and named by Alan Kay.
00:07:29.569 Kay and his team at Xerox PARC created a programming language that aimed to embody the spirit of object-oriented programming, and that was Smalltalk.
00:07:42.729 Pretty much every OO language or those trying to embody OO principles have been influenced by Smalltalk, including Ruby.
00:07:54.830 If I'm going to discuss what is and isn't object-oriented, my authority will be Alan Kay and his writings about object-orientation.
00:08:07.880 While he never provided a formal definition, one of the most concise explanations he gave is this: "OOP to me means only messaging, local retention, and protection and hiding of state, plus extreme late binding of all things."
00:08:21.849 Understanding how Kay defined OO clarified many things for me. However, even with those understandings, there was one massive fallacy I had yet to confront, which I want to address today.
00:08:37.070 Early in my career, I thought OO was all about calling methods. Calling a method meant invoking a procedure on an object instead of merely passing an object or a data structure to that procedure.
00:09:04.730 Later, I learned that OO was really about sending messages. Alan Kay himself regretted naming it object-oriented programming, as the focus should be on messages.
00:09:19.579 So, what is the difference between messages and methods? When we send a message, the object we send it to decides which procedure to run.
00:09:32.540 Different objects can implement different methods for the same message. This is a form of late binding, as the decision is made at the last moment.
00:09:50.290 Messages invoke methods where the actual definition is determined at runtime based on the object's type.
00:10:02.570 This definition of messages makes sense, right? It’s the one I've taught to others for years. But let's compare the object-oriented definition of messaging with the original, traditional meaning.
00:10:16.700 When we send a message through the mail, we include everything the recipient might need to know in order to act upon that message. If they need information from an outside document, we summarize the relevant parts.
00:10:50.210 When sending a message to an object, we can send along the whole kitchen sink if we want. When we send a message through the mail, we step away from the mailbox and move on with our lives.
00:11:13.340 We may or may not receive a reply. In contrast, when we send a message to an object, it’s synchronous; we wait until that object finishes processing the message.
00:11:29.000 In some languages, we always receive a reply in the form of a return value.
00:11:43.570 If we send a message in a language the recipient doesn't understand, nothing happens. But if we send a message to an object that doesn't understand it, our entire thread of execution crashes.
00:12:08.220 When sending a message through the mail, we know it might not reach anyone. Yet when sending a message to an object, we expect it to be handled or our entire thread fails.
00:12:19.410 These characteristics start to diverge from the concept of messaging. Yet we’re told that messaging is central to OO.
00:12:47.740 Let me tell you a quick 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."
00:12:54.920 The novice replied, "But master, I have lived with you for ten years and have never seen you use this power even to bring the TV remote to the couch. You always tell me to fetch it for you."
00:13:03.290 At that moment, the novice was enlightened.
00:13:06.870 Here’s the bitter truth of object-oriented programming over the past 40 years: much like the Zen master, we promise the power of sending messages.
00:13:25.110 However, we are not actually succeeding. Alan Kay envisioned objects as similar to biological cells or individual computers on a network, communicating solely through messages.
00:13:36.060 But even Smalltalk, the language designed to embody OO principles, never fully realized the messaging idea.
00:13:42.720 In fact, every OO language has failed to deliver on the central promise of OO, yet we continue to act as though we are programming with real messages.
00:14:07.070 This disconnect between our conversations and the reality is why we repeatedly revisit the question of how to do OO correctly.
00:14:20.960 My goal isn’t to dismantle your faith in object-oriented programming, but cognitive dissonance is dangerous.
00:14:34.290 For decades, we have claimed that we are programming with messages when we obviously are not.
00:14:50.210 Many will argue that the original sin of object-oriented programming is mutable state. I disagree.
00:15:04.700 I believe the original sin is return values. Return values fundamentally deny the messaging model.
00:15:17.170 But I'm not here to deliver yet another critique of object-oriented programming. This problem of synchronous procedure calls with return values goes beyond just OO.
00:15:32.510 There is a monster stalking the programming labyrinth, and in my experience, this monster causes more confusion, more technical debt, and more rework than any other misconception.
00:15:51.820 I call this beast the transactional fallacy. The transactional fallacy occurs every time a developer models a process as a transaction.
00:16:09.540 A transaction has a goal and no existence beyond that goal. It is synchronous, blocking until it finishes.
00:16:29.270 You can’t set a transaction aside for later. It must complete in essentially zero time, at least from a human perspective.
00:16:45.970 It shouldn’t hang indefinitely; it either completes or aborts with no concept of partial completion.
00:16:58.620 If an error occurs, it self-destructs, leaving behind nothing more than an exception.
00:17:14.200 Every time your service workers crash because a web service unexpectedly takes minutes to respond, that's the transactional fallacy at work.
00:17:30.500 Every time your program freezes while parsing a large chunk of input and showing a progress bar seems impossible, that’s the transactional fallacy.
00:17:46.930 When you realize a form needs to be multi-page and your code requires drastic rewrites, that's the transactional fallacy.
00:18:05.200 When users lose their work after a session expires and become frustrated, that’s the transactional fallacy in action.
00:18:27.840 And then, when you find out you need to run queries against incomplete form submissions, once again, that's the transactional fallacy.
00:18:41.470 Modeling processes as transactions creates numerous complications.
00:18:51.940 Every time I bring one of my kids to a new doctor, I spend 15 minutes filling out intake forms.
00:19:03.800 At least I know that if I put the clipboard down, the forms won’t reset. I can take the forms with me into the consulting room and fill them out asynchronously.
00:19:11.860 I can leave some fields blank, and if they need additional information, they can reach out to me.
00:19:19.970 I shudder to think what the intake experience would be like if designed by a programmer.
00:19:36.060 The transactional fallacy has a universal symbol: the spinning beach ball of death.
00:19:49.600 It's the universal symbol for a programmer's expectation that something will finish or fail quickly, yet it does neither.
00:20:03.950 The transactional fallacy extends beyond code; remember what I said earlier: as above, so below.
00:20:20.960 Our coding approach and our philosophy of life are interconnected and mutually reinforcing.
00:20:37.320 Fundamentally, the transactional fallacy is not merely a programming problem; it reflects a misunderstanding of the world and the lives of the people in it.
00:20:56.730 When we commit to a transactional perspective, it can lead to serious ramifications.
00:21:03.269 I want to get a little more personal. I mentioned earlier that I started my software career at 18.
00:21:16.350 In retrospect, this marked the beginning of an almost 20-year-long transaction.
00:21:27.809 They say it's good to have goals. Well, back then, I envisioned my desired life: a wife, lots of kids, a house in the woods in the mountains.
00:21:42.480 I wanted to work from home, surrounded by my kids. I aimed to homeschool and homestead.
00:21:56.480 I dreamt of building tire swings, creating tree forts, being snowed in with a roaring fire, and sipping tea while thinking and writing.
00:22:09.600 So I set out on a path to accomplish these dreams.
00:22:23.970 Shortly after getting that first software job, I figured I could fast-track my goals by acquiring an instant family.
00:22:39.810 I became a husband to a woman I barely knew and a stepfather to two young children I was unprepared to raise.
00:22:55.490 As we had more children, money was tight, and those visions of my goals seemed to fade.
00:23:02.460 So, I focused single-mindedly on advancing my career to achieve them.
00:23:15.500 This influenced every decision I made, from working late, neglecting hobbies and friendships, switching jobs, to starting my own business.
00:23:33.110 I raised my profile through blogging, podcasting, writing books, and giving conference talks, all in service to this one vision.
00:23:46.350 I was relentless, living for the future: 'When I get there, I’ll have game nights with the kids,' or 'When I get there, we’ll go hiking every week.'
00:24:08.170 I thought, 'Just a few more long days and years, and everything will align.' Even when our values suggested we should update our dreams, I didn’t waver.
00:24:32.530 My life had become a synchronous transactional function, fixated on the return value. You bet you didn’t see that coming.
00:24:50.780 I reached my destination literally; I drove up a steep mountain driveway to our new Tennessee home.
00:24:56.640 At age 35, I had accomplished every goal. But I only enjoyed that feeling for two years.
00:25:09.920 A year and a half ago, my wife told me she was leaving, something we both agreed should have happened much earlier.
00:25:35.200 Working through our separation agreements revealed how every part of the dream I worked toward was set for disassembly.
00:25:56.170 From the aftermath, many revelations emerged, including how transactional my approach to life had become.
00:26:09.890 I realized I had spent nearly two decades trying to bring my life to an end, not in death, but to a static state—a return value.
00:26:31.030 If you’ve seen the Lego Movie, I realized I had become Lord Business, striving to control everything.
00:26:38.880 My vision was so vivid that I lost sight of the present. It wasn’t news that my partner and I were miserable together, but I had overlooked it.
00:26:58.490 Transactions ignore intermediate statuses; they resolve to only two possible outcomes: success or failure.
00:27:09.770 As programmers, we often think in terms of problems, solutions, outcomes, and binary states. I had become my own spinning beach ball of death, waiting on function returns.
00:27:27.880 It may seem I'm stretching the metaphor here, but consider this: you can’t spend eight hours a day, five days a week on something and not have it influence your worldview.
00:27:36.180 As above, so below—our programming paradigms seep into our worldview.
00:27:50.780 This brings us back to programming. Is there an alternative to thinking in transactions?
00:28:05.540 Let’s revisit Alan Kay and Smalltalk for a moment. He envisioned objects as biological cells or individual computers, communicating through messages.
00:28:12.200 This description suggests something asynchronous, independent, and potentially resilient.
00:28:29.300 Digging into Smalltalk's history reveals the roots of a more profound design than the sham messaging system we've learned to cope with.
00:28:41.179 For example, in Smalltalk 72, classes are also functions that match incoming messages and decide their actions, potentially ignoring them altogether.
00:29:00.930 If you look at this closely, it resembles Erlang or Elixir code, demonstrating pattern matching on incoming messages. Carl Hewitt observed Smalltalk 72 and later developed the actor model, which shaped Erlang’s design.
00:29:14.430 Here's the colossal secret at the heart of object-oriented programming: it wasn't meant to be about objects in the current sense.
00:29:34.720 Alan Kay's vision went beyond objects; it was about processes.
00:29:51.200 In the past few years, I've shifted how I approach programming: I now seek processes.
00:30:05.060 I’ve started modeling systems as processes composed of more processes. It's not just about choosing the right language or framework; it's about perspective.
00:30:21.750 It's looking for workflows in the human systems we enable and modeling those workflows as processes instead of just individual steps.
00:30:35.290 In the end, everything is a process: web service calls, user accounts, and even our own lives.
00:30:52.040 Your project is a process. Your software team is a process. Your identity is a process, ever-changing but coherent.
00:31:08.450 Your life is not a transaction; it is a process. Life has taught me to look for processes and embrace them.
00:31:23.890 What has changed in these two decades of software development? I no longer seek objects; I’m learning how to build graceful processes.
00:31:48.170 I won’t pretend to have time to teach you process-oriented programming; I’m still figuring that out myself.
00:32:05.330 But remember, as above, so below: the way we live influences how we design software.
00:32:20.330 For the remainder of my time here, I want to talk about what it means to be a graceful process.
00:32:38.440 Then, hopefully, you’ll find some of these lessons inspire changes in how you write code.
00:32:55.690 However, we face a problem: I can’t simply teach you about being process-oriented because transferring static knowledge is itself a transactional act.
00:33:07.870 Fortunately, you have a teacher ready to help you; that teacher has always been waiting for you.
00:33:20.910 The best teacher for embracing life’s processes is your body. Your body is never static; it has no ideal end state.
00:33:35.600 Your body constantly regenerates, interrupting you during your attempts to reach return values, like feeling sleepy, hungry, or cold.
00:33:48.180 We programmers tend to act like brains in jars, trying to separate ideas from our physical selves.
00:34:02.750 Learning to be a graceful person means recognizing your embodiment. It could start with mindfulness practices, like meditation or yoga.
00:34:16.440 You might take up running, biking, weightlifting, or hiking.
00:34:27.630 However, watch out: hackers are so accustomed to detaching from their bodies that we often quantify instead of connecting.
00:34:39.800 So, throw away your Fitbit. Listen to your body. Feel when you need to move more. Understand when you’re dehydrated. Excuse me.
00:34:53.770 Believe it or not, for me, understanding embodiment has even enriched my appreciation for Instagram and selfie culture.
00:35:10.490 I don’t follow many programmers; I mostly follow poets. But I do follow Lydia Halle, known as the Avec Odor, and Alex, the Yogi Coder.
00:35:20.220 They both have huge followings. They post about their coding and what they’re learning, but surprisingly, they include pictures of themselves.
00:35:41.140 This may seem extraneous, but it stands against the common disembodiment among programmers, reminding us that we are people with bodies.
00:35:53.020 I challenge you to become comfortable portraying yourself and your body. You can start immediately by taking a selfie with me tonight.
00:36:05.750 Building graceful processes also entails starting from where you are and learning to appreciate state.
00:36:19.020 I realize that this is not a popular suggestion in some circles. However, state represents recognition of time.
00:36:40.070 Everything we aim to achieve, whether with computers or otherwise, involves time marching on.
00:36:56.100 State acknowledges that any process, whether a workflow or a human, is a collection of events and their effects.
00:37:04.020 Another perspective is that state embodies an understanding of entropy.
00:37:17.460 The world constantly throws chaos at us. I've seen it suggested that human beings serve as compression functions.
00:37:36.600 We accept an endless stream of incoming events and generate a smaller set of actions in response: the things we speak, write, and do.
00:37:53.680 This helps us create sense and meaning, opposing entropy in a chaotic world. Our software processes must do the same.
00:38:09.930 State signifies the requirement for history in our systems; stateless transactions simply aren't sufficient.
00:38:26.520 Alan Kay recently wrote a brilliant post on Quora addressing whether functional programming and object-oriented programming are incompatible.
00:38:43.660 He asserted that we need both progression over time and clear reasoning about how every detail has come to be.
00:39:00.130 Yet, we can avoid the problematic semantics of mutable state. Kay argued we could have real objects as stable world lines.
00:39:14.950 They could reach their next stable states in a functional manner without race conditions or bugs.
00:39:32.090 This compatibility reveals that using objects with state can compose functional calculations into discrete timelines.
00:39:53.470 I think for humans in general, and for programmers particularly, we cherish the idea of a clean reset.
00:40:05.740 One of the hardest realities for me to accept is that growing older involves continuously closing doors.
00:40:18.290 There are many experiences I will never have, people I will never meet.
00:40:30.700 Starting from where you are means recognizing entropy.
00:40:34.440 It means accepting that no clean slates exist; history is always present.
00:40:49.060 Starting where you are means engaging with legacy code when you’d rather rewrite it completely.
00:41:01.790 Building graceful processes also entails falling forward and failing forward.
00:41:22.850 I read Douglas Adams' Hitchhiker's Guide to the Galaxy series as a kid. Adams wrote about the art of flying: the knack lies in learning to throw yourself at the ground and miss.
00:41:35.600 I used to dismiss this as humor, but recently, I've come to realize the profound philosophy behind it.
00:41:48.700 Entropy is inevitable, and thus, failure is inevitable; surprises are unavoidable.
00:42:05.680 Sometimes, unexpected things happen, like a scorpion landing on your monitor. How do modern programming languages typically handle sneak attacks?
00:42:16.180 They raise exceptions, discarding the current stack and local variables, potentially shutting down database connections.
00:42:34.290 More often than not, the focus on preventing failure increases the potential impact of the failure when it finally occurs.
00:42:49.240 Failure, alas, always manages to occur. We should focus less on preventing failure and more on understanding how we arrived at that moment.
00:43:03.310 The trick is falling forward with style.
00:43:15.900 When my transactional life crashed, I discovered something shocking. While I had local friends and many online acquaintances, I had neglected to foster a local tribe.
00:43:33.330 This is a widespread issue among programmers. Being a brain in a jar leads us to settle for online friendships.
00:43:48.620 I conducted a Twitter poll recently with over a thousand responses. Most participants felt they lacked adequate local support.
00:43:59.410 If you're part of those 72%, I urge you to prioritize making local friendships. This is crucial and should be done before facing catastrophes.
00:44:13.450 If you’re unsure how to begin, please come talk to me afterward; I’m here to help.
00:44:25.660 Now that I’m no longer striving toward a fixed life point, I engage in reflective thinking about my life’s purpose.
00:44:48.130 This turns out to be a surprisingly difficult task because I’ll delve deeper and just end up with vague mission statements.
00:45:05.210 Phrases like 'everything to be the goodest for everyone, everywhere, always' are commendable but impractical.
00:45:21.230 Instead, I've found it helpful not to seek a mission, but to cultivate concrete, fanciful images or 'arrows' guiding my direction.
00:45:38.130 One arrow for me has been my beer list—prominent people I hope to share a beer with someday.
00:45:54.590 It probably won't shock you that Alan Kay is on that list. I also aspire to meet Adam Savage, the former host of MythBusters.
00:46:11.580 However, I don't just want to share a drink randomly or because of a backstage pass.
00:46:27.720 By referring to my beer list, I aim to become the kind of person they would invite to have a drink.
00:46:43.680 I want to find myself in a life situation where it’s natural for me to share a beer with them.
00:46:58.040 Most people on my list I likely won't meet, but this list serves as a criterion for decision-making.
00:47:11.680 It helps clarify which choices draw me closer to being someone they'd want to share a beer with.
00:47:27.720 So, find those arrows, those inspiring images to guide your choices when faced with crossroads.
00:47:43.800 These images will be different for everyone.
00:47:56.680 For some time now, I’ve discussed graceful processes, but you might be curious where grace comes into play.
00:48:09.690 I have few remaining hobbies, but I regularly take myself out dancing.
00:48:24.800 When I go to clubs for goth industrial or electronic dance music, they lack couples' dancing.
00:48:36.720 I've been dancing for years but never learned to dance with a partner.
00:48:49.260 Occasionally, someone tries to dance with me, and it feels awkward. One incident ended with someone asking if I was okay.
00:49:03.400 Recently, someone invited me to dance after we had just met. I warned them I wasn't trained in dancing, but they insisted.
00:49:16.330 It became a fiasco. I had no idea what I was doing; each time I failed at a move, they gracefully flowed into it.
00:49:31.950 Even as I botched the twirls, they smiled and kept dancing, eventually making us both look good.
00:49:42.770 This made me consider the meaning of grace—twofold. It signifies beauty in movement, but in many religious backgrounds, it also represents salvation.
00:49:56.220 In that dancing moment, I recognized that the two meanings converge—grace allows for error, transforming it into beauty.
00:50:11.370 Grace turns the chaos we encounter into meaning.
00:50:27.360 It involves being mindful, grounded, and aware of your place in space.
00:50:41.440 Grace requires beginning where you are, working with legacy, and embracing the journey.
00:51:05.170 It embodies the essence of falling forward and spontaneously responding when faced with last-minute decisions.
00:51:18.760 Grace leans toward the people surrounding you, trusting them to catch you or help you up.
00:51:34.570 Grace is present, not fixated on the future.
00:51:51.310 Grace means being able to laugh at oneself and letting go of what you're trying to solve in order to pursue the bigger picture.
00:52:05.620 Ultimately, grace is what saves us. So, live gracefully, build graceful processes, and don’t forget to dance.
00:52:12.790 Thank you very much.
Explore all talks recorded at Keep Ruby Weird 2018