DAVID: Hello and welcome to the Acima Development Podcast. I'm your host today, David Brady. And today on the panel, we have Mike Challis, Eddy Lopez, Ramses Bateman, Kyle Archer, and Afton Call. Welcome, welcome, everybody. How's everybody doing? It's been a while since I've been on.


MIKE: It's good having you.


RAMSES: Yeah, it's been a while. 


DAVID: It has. It's been. It's good to be back. All right, today we're going to dive in and talk about what do you study to continue learning? And I'm kind of excited to talk about this because this has been actually coming around on my feed and the things that I listen to. I've actually got some unusual answers to this, and I'm kind of curious. But I'm going to throw it out to the room because you guys know that when I show up, I talk too much, so somebody else talk. What do you guys study to continue learning?


MIKE: It's an interesting question because when I graduated from high school, my career didn't exist; that is, you couldn't be a web developer. That role didn't exist in the early '90s. There was no such thing, right?


DAVID: Yap.


MIKE: It didn't really exist in a meaningful way for some time after that. We've touched on this idea before on the podcast that there are some accidents of birth and your background that sometimes affect your career trajectory. This is kind of a big deal. The industry is changing, and it's a new industry for web development in particular but kind of anything that touches the internet that didn't exist in any meaningful form. So if you're not learning, [laughs] you might not even have the chance to have a career because, like I said, the career didn't exist. Mobile development didn't exist...what? Ten years ago, 15 years ago. That didn't exist as a profession because there was no such thing as a smartphone.


DAVID: I saw an actual study on that. I cannot remember the number now, but it was an alarmingly large number of people in the technical sector who had jobs that did not exist when they started college. They graduated and went straight into a job. And their job is ecclesiastical brand manager, or technology evangelist, or data personality manager. What is any of this stuff? And yeah, if you're not studying now to grow yourself, there are entire jobs coming that you're not prepared for because it's not coming down the mainstream curriculum.


MIKE: And that you couldn't be prepared for. Yeah, there's not going to be a university degree for it because they'd have to invent the field, right? [laughs]


DAVID: Mm-hmm. Yeah. 


MIKE: And you're not going to learn mobile development in college if the iPhone hasn't come out yet. There's a chicken and egg sort of problem; one of them has to come first.


DAVID: And academia is 20 years behind, right? 


MIKE: Yes.


DAVID: I remember in 2005 or 2006, the people that I was working with that were coming out of BYU were all Java programmers, and I was really surprised by that. I'm like, when I went there; it was C++ and assembly language. And, oh, you guys are now doing Java. Java had been out for ten years, '96, I think, '94 when it came out, and now it's in academia. But everybody that was good at Java had been programming in Java for 5,6,7,8 years. And it was just now showing up in the colleges.


MIKE: And I think there's always going to be that lag. I mean, just in the best of all possible worlds, you had some really forward-thinking professor who notices a new thing, takes the time to gather the information, stays up to date on the latest state in the field, and writes a textbook. That doesn't happen overnight. In the best of cases, you're probably going to be at least a couple of years behind the industry. 


DAVID: Oh yeah. There's a weird sentiment that I've actually heard a professor express, which is that universities have an obligation to present grounded, well-spread fundamentals, which means they actually have a duty to avoid fads. So the only way to avoid a fad is to wait for something to stand the test of time, and unfortunately, that takes time.


MIKE: So back to your question, [laughs] you got to stay relevant. And I enjoy learning. I enjoyed school. Let me clarify that because there are a lot of people who are like, "Oh man, school was awful." There are some aspects of school that can be wonderful and others maybe not so much. You look at little children, and they love to play. They love to explore. I look at my young kids, and they like to try out new things all the time. It's innate. They find great joy in creativity and exploration. 


And if that's how you define school, hey, school is great. I get to go learn new things and try new stuff. That's play. But if school is learning things by rote and getting in big trouble if you made a mistake somewhere, well, that's not fun at all. So I clarify a little bit [chuckles] that when done right, I think for people in general, we have that innate curiosity and deep longing to try new things and to explore ideas. So yeah, that part of education I really enjoy.


Myself, I love to read. One thing I do is I subscribe to newsletters; some people do it in a different way. But that way, I can look through generally aggregator newsletters in academic fields which I'm interested in so that I can look through; so; here are some articles that may interest you. And I go look through, and I'm like, yeah, that one does interest me so that I can keep up to date on the state of the industry or on nascent industries, you know, things that are starting to form. I'm personally interested in machine learning, so I follow that pretty closely. I follow that. 


I've also taken courses online in topics that interest me, both alone and with others. And I will say that taking a class with somebody else, you are far more likely to finish it because there's the social aspect to it, so I love that.


DAVID: Absolutely.


MIKE: And it is true also that just in the course of your job, you will encounter things, and you shouldn't be ashamed to go out and learn that as you're going. So that's a quick sampling of some things that I do.


DAVID: I love...there's a thing that happens to me occasionally in this field. When I'm talking to people, I talk about being an autodidact and learning and growing on your own, like, motivating yourself. And I actually hear people come back and tell me, "My boss tells me I don't pay you to learn." And I just laugh and laugh and laugh and laugh and laugh because I ask them, "What are you working on?" Because in software, what your boss hands you pretty much every single morning is, here's the thing that's never been done before, go do it. Uh, you sure your boss doesn't pay you to learn? Your job is literally to learn. 


MIKE: Absolutely. 


DAVID: I said at the top of the call that I had kind of a weird insight into this because of something that I had been looking into. And I was going to try and hold it in my back pocket, but you stepped right onto it, Mike, with talking about children. There was a fantastic video...I'll have to dig it up. If we've got show notes for the show, I'll put these out, but if not, you can search for it on YouTube. 


It's a discussion that Neil deGrasse Tyson had in an interview. And he got asked, "What do you study? What are you learning right now?" And he kind of goes off on this tangent about the things that he's studying, about how he's interested in studying how people learn and how people change the way they think. But he veers into this beautiful, beautiful anecdote about how as an educator, he feels that it's his job to spend energy teaching people to love experimentation. And he needed to illustrate what does that mean. 


He's like when you have a six-year-old pushing a tray table with a glass of water on it, and that glass is shaking, that's an experiment. This child is doing an experiment. If I shake this, it tips, it falls, the glass breaks. That's an experiment. I have a situation. I have a stimulus. I have a response. And so many of us, the natural instinct is don't do that, don't do that to the degree that it's just simply a day-to-day occurrence. Yeah, sure, I mean, you got to live with your kids. [chuckles]


But if you can view it from the point of view of this is an exploring creature conducting an experiment on the universe outside of them, and I want to encourage them to gather prima facie evidence, first-hand evidence on the universe around them, you let them break the glass. And you say, "Okay, what did we learn?" without shaming them, not the "What did we leaaarn?" No. But literally, "No, seriously, what did you learn? Tell me what you learned from this." 


Or if you must be preventative in this, step in and say, "What do you think you're going to learn? What do you think is going to happen here?" And again, not to do it in a shaming way but to do it in an encouraging way, and that takes energy. I mean, you got to go buy a new glass [laughs] and then replace it. You got to clean up a mess if the child's too small to clean up broken glass.


But that child goes on to become a scientist or an explorer because they end up with a first-hand thirst for exploration and knowledge. And they also gain this core belief that exploration is safe and wonderful rather than damaging and hurtful because I got yelled at when I broke a glass. I was blown away that that's what Neil deGrasse Tyson is studying right now is that level of learning. And I thought, wow, he's literally learning how to learn and how to teach people how to learn. That's cool.


MIKE: We could probably spend a lot of time talking about the joy of exploration that children have. And maybe that could be a guiding principle as we're talking about this topic. What do you do to stay up to date? Well, be curious. [laughs] If you've got curiosity, feed it because if you don't feed it, it will kind of atrophy, and you'll find yourself burned out and bored. But if you feed it, then you're going to find your career pivoting, and you're going to be in that job that didn't exist ten years ago because you'll have gradually migrated and followed your curiosity into something new.


DAVID: Absolutely. What are things that we can do if not to, I mean, I think it's like a foregone conclusion for us to say we got to keep learning; we got to keep growing. Are there conscious, explicit things that you can do? I know that the Atlas team at Acima there's dedicated time on the schedule. This is learning class. This is time for us to sharpen our skills. Skills Clinic is literally what it's called. And it's an invested amount of time. I've not worked at a place that had that dedicated, so most shops, in my experience, don't do that. 


What can you do to encourage those around you to learn or to create? I just realized I'm trying to trick you into giving me the answer that I want. And the answer that I want you to give me is that if I go create the environment where everybody's learning, then I get to learn too. So I'll throw that out. But what can we do to create an environment of learning where other people can learn, grow, and continue, and we can learn, grow, and continue? And who cares? Not just for you getting your next job but how is that going to benefit your employer here today?


MIKE: You dropped a couple of hints there. [chuckles] The first is you said, well, you do the skills clinic where you dedicate your time every day. Well, not everybody out there is going to be able to walk up to your boss and say, "We're going to start taking an hour every day learning stuff." Now, a lot of you probably could because your boss might be like, "Okay, that sounds great. I want better-educated employees." 


Sometimes that might be a little overwhelming, like, wait, what? What about productivity? But you don't have to start that big. Start a book club. Start a book club. Now you are working with other people, which will help keep you motivated, and you can do that together. Or go find some people who are interested in a class. Go take it at the community college, or a local university, or online. Most of those are get together here. There's a recurring theme. [laughs] It helps keep you motivated if you wanted to make space for other people. 


There are things that you can do, I think, wherever you are to make that kind of space. You can say, "Let's read a book together. Let's do a book club, and then every week, we'll talk about it." You're not taking very much time. You can even do it on your lunch break. You can make that space. "Let's go take a class," and then you swap ideas. [laughs] You give each other support like, "Hey, have you done homework yet?" [laughs] 


You can find somebody who is starting their career or who wants to start their career and say, "Hey, want to get together at lunch, and I'll help you out to learn some of this coding thing?" or this data thing, whatever it is that they're wanting to pursue. Well, now you have a recurring opportunity to get together and mentor somebody. And as you mentor, you learn a lot. 


I threw a few ideas out there. I'm curious, other people I think have been involved in these ideas and more. I'm throwing these out because I've been involved in all of these things before. I mean, I've done these things. Other people, have you done other things, or if you participated in the kinds of things I mentioned, how did it work out? 


RAMSES: One idea that we incorporate quite a bit, probably in our organization but specifically on our team, is encouraging the idea of pair programming and pair reviewing, which I think helps to promote a healthier understanding of how things work or should work, or can work and just alternative solutions. And overall, just better discussions and better collaboration, which I think is important. Each of us is limited by our experiences. And we're limited to our current understanding of things. So gaining someone else's perspective or insight and experience is tremendous. 


AFTON: I agree. I think our pairing, which has been highly encouraged on the Atlas team for quite some time, is a great way to have this ongoing mentoring environment, which then helps everyone to continue learning because everyone is teaching. Those who know more are teaching those who know less, and those who know less get to have a chance to try and explain things to someone else, and that develops their skill. I think that's a wonderful thing that we have on our team. 


I want to go back just a little bit to what Dave mentioned earlier, which was our skills clinic, and how that's been in place for a while as an opportunity for us to spend time sharpening our skills. And the funny thing is, and Mike can attest to this, is we started that skills clinic kind of as part of an internship. But after the internship ended, it was really hard to get the skills clinic to keep going. It was hard to get developers on the team to attend and take advantage of it. 


And even before the skills clinic, the take an hour a day to sharpen your skills was talked about, encouraged. But I found for me; it was really hard to take that time. Even though it was being handed to me on a platter and said, "Do it," it was really hard to take the time. And it has been always really hard because when you're in the middle of a problem, it's hard to set it aside and go do something else. Context shifting is hard. You always just feel like I need to get this done. I need to get this solved. I need to get this out. Sometimes there's pressure to get something out quick. Sometimes it's other people are relying on me. 


There's just always a lot of weight going and pressure to get work done. There's always so much work to do that we can never catch up, which I think contributes to that. So recently, I realized something that has made a world of difference in me, taking that time to sharpen my skills as often as I can. I don't know that I'm getting an hour a day, but certainly, more than I was in the past. And what that was was thinking about my career and what I'm working toward personally. 


So I actually took this little online course on LinkedIn learning about...I think it was how to choose or organize your priorities when everything on your plate is a priority. [laughs] And so it was breaking things down into, well, you have to think about what's urgent, and what's important, and do the things that are urgent and important first, and then the urgent but not important or important but not urgent. They had this stack of how to decide what to do first. 


And then it also talked about another way to decide and get things done that you keep wanting to do but haven't figured out how to make happen is to think, okay, where do I want to be a year from now? Where do I want to be in my career? What do I want to have accomplished? Where do I want to be five years from now? And I was thinking a year from now; I want to have better technical skills than I have today. And I want to have written a lot more code and have a lot more experience in our codebase. 


And in my newish position as a team lead, it's been a lot harder to find time to be writing code and to be learning. But when I said okay, a year from now, if I haven't progressed in those two areas that are super important to me, I'm going to be really frustrated with myself. So the only way to make that happen is for me to make sure that every day starting yesterday [laughs], I prioritize that. 


And sometimes, I have to take something that is a priority and say I'm not going to do that for one hour. And instead, I'm going to spend some time sharpening my skills or working on a ticket because that is also a really high priority. And that's made the difference for me is knowing what my goal is for myself a year from now, five years from now. 


DAVID: That's amazing. That's awesome. Thank you. There are so many things you just dropped on there. I'm writing frantically. I love that idea that there's always so much to do. I would amend that and say there's always too much to do. And just like you said, when everything is priority one, nothing is priority one. Well, guess what? You can weaponize that to your advantage. 


If you can't stop to improve your skills and invest in yourself because you always have too much to do, then stop and invest in yourself because you're still going to have too much to do, whether you stop and invest in yourself or not. And a month from now or a year from now, if you have increased your capacity a month ago or a year ago, you're reaping the benefits of that. 


AFTON: Yeah, absolutely. 


DAVID: You said having a goal, and it reminds me of a thing I did in...oh God, [laughs] somebody told me once that "I hate when programmers stand around telling war stories." This is totally a war story. I'll make it quick. Back in like 2006 or 2007, I had gotten into Ruby on Rails, and I was really excited about it. But all the work in my hometown was PHP. And I had a customer approach me. I was freelancing back then. I had a customer come to me and said, "I want you to build me a website from the ground up." 


And this was an old customer. We had a really good trust relationship. And he also paid me miserably. [laughs] He wanted old rates from 10 years ago when you didn't know how to program. And I negotiated with him that I will do this for you, and I will do it at the old rates, but I'm doing it in Ruby on Rails. And he didn't program, you know, I basically told him, I'm going to do this with a left-handed metric spanner, and he was like, yeah, okay, knock yourself out. 


And because I had that as an explicit objective that I want to get professional experience working in this, I was able to just gin it up out of whole cloth and basically say, I'm starting this project professionally because I'm a consultant and I can do that. And then, a year later, when I got the opportunity to work in Ruby on Rails at a company, and they were like, "Well, what experience do you have?" I'm like, "I've been doing it for the past year." And that was super, super useful.


MIKE: Interesting. My intro to Ruby on Rails was somewhat similar. I was at a company doing Java. They said, "You know what? We need to use an interpreted language. We want the flexibility and speed that we've seen other people have in interpreted languages. So you're going to do PHP." And I'd done quite a bit of PHP kind of on the side. And I thought, given the state of that language community at the time, I thought, if we do this, we're going to have a horrible ball of mud in no time flat. I need to use something that has a framework and organization that we can work with. 


And I heard a presentation about Ruby on Rails at a Java Users Group. It was like, "Yeah, there's this new framework in beta called Ruby on Rails." So I went and wrote the seed of our rewrite in Ruby on Rails over the weekend, kind of learned the language and the framework. I spent a long weekend. I came back, and I said, "Okay, well, I've got this prototype. What if we try this?" Like, okay, I mean, you've already got it, we might as well. [laughs] And we ran with it. And I've been doing it ever since.


DAVID: That's awesome. Rails had that sneaky underdog thing. There was that seminal post by DHH, "Build a Blog In 15 Minutes." I've seen that happen as well where somebody says, "Oh, let's switch to Rails." And they're like, "Well, what's the start-up cost?" It's so great to be able to say, "I wrote it on the car over here today," or, "I wrote it last night." The start-up is done. Now all that's left is all the really hard work. But you don't tell them that. You just tell them, "Oh, look, the start-up piece is done. That's half the work," right?


MIKE: [laughs] It's true. I can say that that application we rewrote ended up having one-tenth the number of lines of code, and it did more. But that doesn't necessarily mean better. So, I mean, I'm not trying to be a framework snob or anything here, [laughs] but there were some definite pluses that came from it. But yeah, exactly; if you come with the prototype, it's a lot easier to sell your cons.


DAVID: There's a line count that, in my experience, Ruby has about somewhere between a 3:1 and a 10:1 ratio of line count. Prior to Rails, I was used to working on C++ projects with half a million lines of code and then PHP projects that had 100,000, 150,000 lines of code. And now, if I see a Rails project with more than 30,000 lines of code, I get scared because that's a big project because you can do so much. 


And there are trade-offs to that. It's a lot harder to tell your manager, "Oh, yeah, I wrote 1,000 lines of code today." It's a lot harder to do that in Ruby than it is to do it in C++ because there's just so much boilerplate. You get 900 lines for free.


MIKE: And you need to recognize there's trade-offs as well. We are talking about interpreted languages. In Ruby specifically, you don't get some of the type checks that you get from other languages, and there are some real trade-offs there. I'm thinking TypeScript is overtaking JavaScript. It compiles to JavaScript; I mean, it's the same language, basically. But people want to have that type safety because it avoids certain kinds of problems. So, I mean, absolutely, there are trade-offs but interesting ones. We can really get into this. [laughs]


DAVID: Oh yeah, I can drill into this really easily. There's a concept that I've seen, well, actually, this is a good example of learning, and then all of a sudden...what I will say about studying to learn something is don't be afraid to chase a tangent because that's where all the marrow is. That's where the juiciest tidbits are is when you're in the middle of something, and then, whoo, we go off down this sidebar. But when my ADHD fires way too hard, I look around, and I realize everyone's eyes are glazed over because we're seven tangents deep. 


And there's an idea where those of us coming from old statically-typed languages we had all this upfront checking that the language had to do. And that cost ceremony, and that caused us to slow down. And it was very frustrating, and we wanted to go fast. And these interpreted languages came along, and these dynamic languages, and it's like, oh hey, look, we don't have to do our upfront checking. Well, then our programs blew, so it's like, okay, we need to do unit testing. We need to test at the other end. 


If you're not going to test that all the types are correct, then you have to test that the program behaves correctly at the end of it. And there's a really phenomenal thing in the industry where you can see some people going; I don't have to check upfront, but I'm too lazy to actually come back around and test at the end. And those people, bless their hearts, their co-workers are the ones who are saying, "Let's maybe go back to statically typed. I think it would be okay if Jim could not write software without enforcing something on either end of this. Let's hook into somewhere.


MIKE: We should do an episode on typing.


DAVID: Oh yeah. I can do about 110 words per minute.


MIKE: [laughs]


DAVID: Oh, wait, wait. 


MIKE: Ramses mentioned pairing. That's really interesting. You didn't say formal study but getting involved with another developer so that you're sharing ideas with each other. Kind of continuing on this idea of tangents, those of you who have learned something pairing, do you usually learn something that you were expecting to learn when you're pairing with somebody?


DAVID: Never. I'll let somebody else take the question, too, though. [laughs]


RAMSES: Yeah, not always. You never really know what you're about to learn. Like, it's not really super formal. So you just get together, do some discussions, and throw out different ideas, different solutions and see what you come up with. It's always an interesting and unexpected experience.


MIKE: Yes. So you set up to solve a problem. You're pairing to solve a problem, and you end up learning something. I was talking with some people about recursion earlier this week about a function calling itself. And we ended up talking a good deal about memory management, about how your computer manages memory, and the operating system, and addressing, and pages in memory, virtual memory, kind of far afield from recursion. 


But we talked about that so that we'd understand how that stack of function calls eventually is going to run out of space. So we went in with one goal in mind and ended up somewhere very different. But they're both useful. It always happens that way if you let it happen. You leave room for that spark.


DAVID: Yes, it's very important to not fall into the trap of trying to predict the spark. Or rather, you can absolutely predict that the spark will happen. I've done podcast episodes where everyone is sitting around going, "What are we going to talk about? I have no idea what we're going to get out of this." And I just told everyone on the call, "It's fine. Just sit down, relax. It will happen. Trust me; it will happen." Banking on the spark happening is absolutely doable. 


But if somebody sits down and says, "What are you going to learn today?" It's really hard. Mike, you might have sat down and said, "Well, we're going to learn about recursion. We're going to learn about creating base cases. We're going to get into mutual recursion where this function calls that, and that function calls back into this other one," and blah, blah, blah, and down the road, you go. 


Nowhere on your prospectus would you put we're going to learn about how memory management, dah, dah, dah, that the heap is well managed and the stack is not, and dah, dah, dah, and down you go. If you lock yourself into that predictive deductive thinking rather than walking in open-armed and ready for inductive learning, you'll cut yourself off from your own creativity. What's the rule from writing? You can't create and edit at the same time. You can't be an editor for your writing while you're writing everything you're writing. I've missed the conversations where I throw three metaphors at a problem at the same time; there you go. 


MIKE: But we went there, this idea that pairing is a really great way to enhance learning. You don't go in there necessarily with a goal in mind. Instead, you create an environment where that curiosity and exchange of ideas can happen.


AFTON: I want to say that this learning from pairing is not limited to learning additional technical skills like some new coding trick or even a new design pattern or something, which are definitely valuable. But one thing I also get from pairing is getting to see how someone else's process works. What kinds of questions do they ask to navigate the problem we're trying to solve? Where do they go in the code? How do they figure out what questions to ask and where to look? And what are the steps that they take from start to finish to solve a problem?  I think processes are super interesting, and having a good process can make you more effective. 


This kind of goes into what I was thinking about what I do to continue learning. I realized also recently that I have two different areas of learning that I focus on; one is on super technical skills, learning a new language, or refreshing my Ruby on Rails knowledge, or even studying algorithms, which we've been doing in our book club. But on the other hand, I'm also studying how to manage projects, how to communicate well with people I work with, like on my team. Right now, as a leadership, we're starting crucial conversations and learning about how important it is to be able to talk to people and communicate well your intentions and your ideas, and organize your thoughts and respectfully, and all those things. 


And we mentioned in an earlier podcast episode; development is so much more than just writing code; we do so much more. We are teammates. We're working with other people. We're organizing projects. We need to know how to manage our time to be efficient and effective. And so I also study time management and figuring out your priorities, how to figure out your priorities, leadership skills, communication because I believe that all those things are also going to make me a better developer, a better teammate, more effective in my career.


DAVID: There's a thing...I believe it's called the synthesization step or integration. I can't remember. There are steps to learning ideas. And for me, the exciting thing is near the end when all of a sudden, you find out that these wildly disparate fields of study are 100% overlapping where you're getting into time management, and you're like, okay, this is important, and it's essential. And I have no control over where it's going, so I have to focus on the process and just let it go where it needs to go. Or this other thing is not important, but it needs to be done. So I need to focus on what is the fastest way to get to this outcome? 


And then weeks later, you're having a conversation with a co-worker, and you realize I need you to write this to this API. I don't want to talk to you about your feelings about it. We'll do that at lunch. I just need you to do this, and I need it done quick. We've got this other deadline. It's like, I need to be efficient with you. I need to focus on the outcome, boom, boom, boom. 


And then an hour later, you're talking to somebody else, and you realize they are wide open vulnerable. And you suddenly realize I can't be efficient right now. Efficient is the most deadly thing I can do to this conversation. I have to be effective in how I communicate with this person. And so you're like, you know what? I'm clearing my schedule because this is important, and I don't know how long it's going to take. 


When you see those parallels, you study how to communicate with people. And then a week later, you're writing some code, and you're like, oh, how do I document this function? And all of a sudden, you realize, oh yeah, I know exactly how the person reading this...I know what they're going to be hungry for, what they're going to be looking for. I'm going to document that, or I'm going to write a unit test that expresses this. 


And it's kind of nice to have somebody come back and find you and say, "I love that test that you wrote because I could not figure out what your system was doing until I saw that test. And all of a sudden, I could see the through line in all of your software." That's amazing. I've had that happen once in my career, and I'm still bragging about it on podcasts today. 


I have a weird question for the group. You know me, I love weird questions. What is the weirdest, most out-there thing that you have learned that you've been able to bring into a professional situation with benefit? I mean, obviously, some of us bring weird stuff into the office just for the sake of bringing weird stuff into the office, and it doesn't always go well. But is there something that you guys can think of that you're like, I did not expect to use that at work today? 


RAMSES: Yeah, that is a weird question, and I don't know if I have a good response for it. I spend a lot of my time trying to learn new things to improve my workflow and to improve my knowledge. I don't know if I have a better response for any weird things.


MIKE: I'm trying to think of a specific example. It feels like everything that I end up studying ends up crossing over. So here's a recent example. I'm going to take my kids out trick or treating. We'll probably release this next year in March or something. You're like, wait, what? [laughter] But we're recording this in October, and here in the U.S., we're doing Halloween in about a week. And we were talking about how to do a quicksort earlier this week, or I think it was last week. Recently, we were talking about how to do quicksort. 


And I was trying to think about how can I represent the intuition behind this idea in a way that you can get your head wrapped around an event or two? And I thought, oh wait, okay, so it's Halloween. And you've just come home with your big bag of loot. You got your big bag of candy, and you want to know which is the worst candy, which is the best candy. You want to trade with your sister. And so you want to make sure you know that you're trading the bad stuff, keeping the good stuff. You want your tootsie rolls to be given away. You want the big candy bars. You get the idea. So you've got this big bag of candy. You want to sort it.


Well, how do you go about doing that when you got a whole big bag of candy? How could you possibly go through and sort that in a reasonable way? Well, here's what you do. You dump out your candy on the floor, and you pick out a random piece. And you say this piece is going to be the decision piece. It's going to be the pivotal piece. And I'm going to take everything that's worse than that piece, and I'm going to put it in a pile to the left. And then take everything better than this piece, and I'm going to put on a pile to the right. That's all you do. 


So I'm just going to put the ones worse than this to the left, better on the right. That's an easy decision to make. And I'm going to put this piece in the middle. Well, then I'm going to take the pile on the left, and I'm going to do the same thing. I'm going to pick out a random piece, and I'm going to take everything that's worse than that one and put it on the left and everything better than it on the right. 


Well, now I've got three piles. And I'm going to do that to each of those piles and then any piles that come after that until I have gone through all of my piles, and all I have is a line of candy. And it's perfectly organized from worst to best, left to right. That is the Quicksort algorithm. For me, that illustrated, in my mind, in a way that I'm never going to forget. And that was a huge leap. It wasn't even a technical field at all. [chuckles] It was just something that came from life. But these intersecting ideas happen all the time, and being able to connect them gave me a huge aha moment. 


DAVID: That is awesome. Do any of us have any thoughts that we want to throw out on this? Is there something that you wish you could have said at this point that you want to get in? 


MIKE: Keep the joy of curiosity in your life. Find a channel where you can keep that curiosity alive. And I think it will serve you really well.


DAVID: For me, I would say don't be afraid to go way, far afield with things. If you want to be a better programmer, study a parenting book, pick up the guitar and learn music, go hiking, learn how to hike better, actually study hiking instead of just throwing at it. Pick stuff way, way, way out, and you're going to find parallels to the thing that you do every day. And it'll surprise you.


RAMSES: Yeah, that's a pretty good way to end it. Try to learn things that you're curious in and also things that scare you. [chuckles]


DAVID: Yeah. Well, all righty. Thank you, everyone. This has been fantastic. I've missed coming back and hanging out with you guys. I'm enjoying my time over in the database land, but I missed the front-end, back-end work. Thanks, everyone, for coming.