 Next up is Brandon Hayes. Brandon is a dear, dear friend of mine and oh man, I had the perfect joke and I just blanked on what it was. I was going to embarrass you so bad and I completely forgot what it was. All right, so the one thing I'll say about Brandon is that I think about him every single day because my wallet got stolen the other day and my current wallet now is my little pony wallet that he gave me. I pull that out everywhere and people give me that look. Brandon is fantastic. We're so happy to have him back. He spoke at Mountain West JavaScript but never at Mountain West Ruby and he's now in Austin running his own consultancy. He's a big mucky muck. But welcome back to Utah and welcome to Mountain West. Good afternoon. So I have changed cities and programming communities in the last few years here and there. But URUG is in my blood. I'll talk a little bit about that maybe later if we have time, otherwise forget it. Who cares? So after four years of getting on the freeway to drive to my work, the drive here this morning was really unsettling. It was genuinely upsetting to me, like where is the bumper to bumper traffic? Why do you have public transit? What is this place? I don't recognize Utah and B. I guess acclimated to how horrible things are there in some ways. So every person from Austin will talk about the traffic to keep you from moving there. So this is the title of the talk. We're here to learn how to dockerize your React container. So everybody forget everything you know currently about the web development and just strap in. Hang on. I'm being alerted. My tech death watch app just informed me that Docker and React are over. So forgetting anything you may have learned already, we are now going to learn how to web pack your Elm Kubernetes. According to Hacker News, the first thing you need to get to hello world with web packing your Elm Kubernetes is I don't know what those things are. They are words I assume that are made up by people who hate us. Thought leaders in tech have taught me to use your insecurities to sell something to you. So that's exactly what I'm here to do today. So first, let's talk about midlife crisis. A midlife crisis is complicated but basically it's when you start to face your mortality and you start making some rash decisions. This is my dad when he was just a shade younger than I am now and he shares my enthusiasm for fanny packs. This is his little brother. My dad went full blown midlife crisis and picked up the car, traveled the world, got remarried a couple times and moved his family across the country. This is his midlife crisis. I think as web developers, our knowledge expires so fast that we've started fixating on its mortality almost all the time and that leads us to start making some rash decisions. So if you're new to Ruby or you just really, really love it, I bring you a word of comfort regarding your career. If you're lucky enough to feel comfortable with it, then I also bring you a word of caution. So since the web seems to reinvent itself every 45 seconds, it's tough to think past the next framework we're supposed to learn or you'll become instantly and permanently unemployable. I'm Brandon. I help run the front side. I think we're doing some pretty special stuff over there. We're working on a catchy slogan so people know who we are. So just spitballing here, looking to fish some feedback from people. This is us a little over a year ago. We've always been a pretty tight-knit group of folks trying to help and teach each other. We've grown since then, but our mission is the same. We build great software and grow great software developers. We really like making adventurous and ambitious front-end apps. We like to use Ember for that, which is a JavaScript framework that's notable for being authored by an anthropomorphic hamster. It was when I was first learning Ember that I started noticing a pattern that I want to share with you. So let's talk about the state of web development today and explore that a bit. But I'll let Clever Lang make a prediction for you if you're trying to keep up with the pace of new tools, languages, and frameworks. My prediction? It's pain. Pain point number one, how are you supposed to keep up and stay on top of new tools, much less evaluate them? Ember is about four and a half years old and other frameworks have come along since then. A significant number of them. I want to know. I'm sorry. I'm going to try to use this laser. In what universe are there 24 best JavaScript frameworks? Let's be honest about how many of those there really are. So you just sit and stare at all the choices, like an open fridge with a bunch of mystery foods in there and most of them you're pretty sure are moldy. We'll talk about this like you're supposed to have evaluated all these. But you haven't heard of half of them. Maybe I'm too old. This starts feeling like a treadmill, like a mean spirited treadmill that's always set just a little bit faster than you can run. So who set up this ecosystem? This is like designed by these people to punish us. So the second pain point is that once you do actually decide on a stack there's just no way it can live up to your expectations. Like you're sitting there waiting for 20 years for a new Indiana Jones movie. And it's about aliens whose treasure is knowledge. This is not okay. And then this new tool is super amazing. But when it comes time to actually ship, this happens. What used to take minutes can now take days. Documentation is scarce. You dive in into source to see whether it's a bug in the tool or your fault. You don't know who set that up. My guess is this kid's using this wrong. He didn't read the source. The third pain point is that it never feels safe to fall in love with your tools. My grandpa built houses with the same miter saw for 30 years. But your tools are obsolete in less than 30 months. I checked Google Trends and I'm afraid I have some bad news. Rails, it didn't make it. We did everything we could. We even tried giving it WebSocket support. I'm just so sorry. The injuries to sustain from Node were just too great. Damn it, this was always the hardest part of the job. I'll see you at the crossroads, Rails. My sequel died so long ago that I'm sure only a handful of people even remember what that was back when we still used relational databases. You can ask your grandma about relational databases sometimes. She'll explain it to you. That poor, poor, my sequel Dolphin. My favorite front-end framework got killed last year because a new library showed up. So what do I do now? Thomster, no, please, you were so young. And I think everyone here will remember where they were when we heard that Ruby had died. It almost makes you feel bad for all the times that we, all the time that we spent dancing on Java's grave. The thing is, this process, you're starting to get a pattern here, this is totally predictable. So predictable, in fact, that there is a chart for it. There's a company called Gartner. It gets paid a lot of money by a lot of companies to chart where tech trends fall along this cycle every year. And none of those things that we talked about earlier actually died, didn't they? It turns out once it gained popularity, a technology is harder to get rid of than Steven Seagal's toupee. So we're just trying to get from a higher state of pain to a lower one. Then something comes along that addresses, and in some cases creates the sense of dissatisfaction with current tools. What's amazing is how quickly this can happen. I was at Macworld 2007, and Steve Jobs got up and said, hey, here's an iPhone. And I took my six month old Motorola Q out of my pocket, and I looked at it, and I was so mad at it that I literally wanted to hurl my existing phone at the screen for not being the phone I just had learned existed. That doesn't seem rational, but it's how the brain works. So I want to look at this cycle from three angles. First in the abstract, then through the lens of the history of Ruby on Rails, and then how to apply this when you're confronted with a new technology. Lastly, I want to offer that bit of comfort and caution to people who feel a little uneasy watching the pace of change in technology. So let's start with the concepts and walk through how this cycle works. Naturally, we'll use medium think paces, which is now the de facto way to demark the start of all these phases. So the first is the technology trigger. There's this launch with big promise, and the initial spark of interest hits a few early adopters, and the hacker news gets all excited and starts voting it up, and the tech is off to the races. Then we hit the peak of inflated expectations. Suddenly, it's all anyone's talking about. Performance, security, new capabilities you never even dreamed of are all yours if you will just adopt this new tool. Now at some point, that rocket ride ends, and you find yourself in the trough of disillusionment. The tech doesn't meet those outrageous expectations. It's not a panacea, and you get people loudly quitting and the whaling and the ashing of teeth. And if the tech survives, you reach the slope of enlightenment where you start seeing a light at the end of the tunnel. You hear things like 2.0 and 3.0. The tooling gets better. Learning materials get better, and a community starts to form around it. And finally, we get to the plateau of productivity, where a bunch of people just become quietly productive, and they don't really see the need to talk about it too much. And here's something I promise you will never see on hacker news. Yeah, we've been quietly productive with Ember for about 18 months. It's pretty nice. Like, who cares? Go home. This doesn't belong on hacker news. So these are the peaks and valleys of successful technologies if they make it through that trough alive. So let's look at this cycle through the lens, the lengthy, lengthy lens of Rails history. So how many people remember this? It just uses Ruby everywhere. Look at all the things I'm not doing. That's how much work you have to do to get to Hello World. That's not a lot. Whoops, it worked. Whoops. So I assume a lot of people, based on the amount of gray hair I've seen in this room today, compared to my first Mountain West, I'm gonna guess that a lot of people in here remember this. This was the technology trigger. How many people were totally blown away when you saw that for the first time? Okay, a fair number decided to out themselves as extremely old. I wasn't even a programmer yet at the time, but my friends showed me this and it made me want to become one. So luckily for us, BuzzFeed was there to capture every step of Rails' rise to power. I was so glad I was able to dig these out of the archives. So from this point, the tech analysts and hacker news crowd couldn't trip over themselves enough to fight over whether Rails was truly the chosen framework, the one that would make your wildest dreams come true, cure rabies, the hype builds until it becomes a little ludicrous. Then Rails hits its peak of inflated expectations. I wanted to Photoshop something amazing, but I couldn't because this exists. Just ponder this a moment. Migrated database, fix a leaky gutter, it's all there, Ruby everywhere. And who can forget Death Leopard's monster hit from that era? If only the community had someone wise enough to predict this around, I don't know, like RailsConf 2006-ish. Except we did. His name was Why the Lucky Stiff and I wish I could thank him for all he's done for me, including inspiring me that code could be art when I was struggling to learn how to program. He had an astoundingly prescient warning for us 10 years ago and I encourage you to go back and watch his RailsConf talk, performance, whatever it was. This was from a video series he did called The Least Surprise. Right now, anything is possible with Ruby. First of all, it's unstoppable. The hype machine is totally rolling down the street. People have been trying to hit the brakes. The brakes on the hype machine are all burned out and they don't work anymore. And second, so many great projects have used Ruby that it's proof that you can do anything you desire. Any of your wildest dreams can come true. I used Ruby to lure Catherine Zeta-Jones into my unicorn petting zoo. You have a unicorn petting zoo? Made entirely of Ruby. So here at the frothiest peak, just mentioning the name of the technology in the title of your introductory conference talk means it's gonna be standing room only. You can Google for one of a hundred Hello World tutorials and none of them actually help you understand the new technology, but they're there. So once you do figure it out, the promise of productivity means that you're finally going to ship web apps 10x better. You're going to be a 10x developer. So when a recruiter asks if you're a rock star developer or a Jedi, you'll be able to say, yeah, both. You're gonna wow your boss, you're gonna buy the house, get the rays, fulfill your wildest dreams. Now that's not the actual promise, but it's the one that we buy into. And the hot air from all these inflated expectations, well, they start to inflate our ego just a little bit. And you start thinking that maybe anybody who came before you was totally wrong and you are totally right. And you get to get up on stage and tell the establishment exactly what you think of them. And what is more fun than that kind of rocket ride? Come on, the cheered, we're taking this baby to the moon. Only one problem, like a drinking expired soy sauce, the reality starts catching up with you. A technology inevitably slides into the trough of disillusionment. Again, if only someone could have predicted this. Mr. Malski, obviously some people here don't have your vast vision for Ruby. And I'm not sure even I understand the point of indulging these decadent wishes any further. You're just setting this all up for a huge crash when things don't pan out and the idealism fades and the world moves on to the next language, something even more beautiful and expressive. I like to call this imaginary future language absinthe, a language smooth and creamy and scented with purest of licorice. She's lying, absinthe is the apocalypse. She's got rabies, keep the cure to ourselves. She's going to steal our eigenclasses. I really miss that guy. I was wondering if elixir was intended as an oblique reference to absinthe, but I don't know. So this phase is marked by prominent defectors. The thing that caused people to leave for your greener pastures, some people are getting this slide, is causing them to leave for other greener pastures. Go, flip and figure. This is my favorite slide. I don't know if people remember this, but there were some prominent defectors in this phase for Rails, but this one takes the cake for me personally. I met this guy at a Mountain West conference when I was a pretty new developer and he seemed fine, but I mean this dude literally offered to fight every developer, which seems, I don't know, perhaps a little aggro considering we're talking about which interpreter we use to take in strings of characters we type into a computer. Like hey man, you want to fight about it? Like no, I was going to issue a pull request, I don't know. But that's the amazing thing, right? Once the super early adopters declared the tool dead to them, it actually starts doing some real work. And this is where we start seeing service-oriented architecture talks at conferences. You know people are put in a technology to work when it has to speak XML across non-restful endpoints. And this is where those blog tutorials start turning into book deals and a loose affiliation of enthusiasts starts turning into a real community. And all those enterprise dollars start buying race cars. You're welcome. And finally, there's a plateau where a bunch of people become quietly productive with the technology and they don't really see the need to talk about it anymore. There's nothing exciting or cool about quiet productivity. You don't get any more magazine covers. It's been a decade since MySQL did anything anyone considered cool. But billions of dollars with an S, I think, is pretty cool. Is Rails a good technology or a bad technology? Well, that's irrelevant now because it's an entrenched and productive technology. Now we'll have to take a little bit of a detour before we dive back into the history. At a RubyConf talk last year, I got into the concept that there are these three predominant types or sets of preferences in technologists, pioneers, settlers, and town planners. We'll run through a quick cliff notes version of that. Pioneers itch for the latest technology. They like forwarding the rivers of new things, contributing, exploring new territory. It's the thrill of discovery. Settlers try to create order from that chaos that the pioneers discover. They build infrastructure and communities. They connect that pioneering work with real business and user needs. Town planners are just trying to get things done at a scale and performance that's impossible with unproven technology. They're trying to turn your exciting tech boring and they will always win. So let's dive back in to the history to see how this all fits together. Now my theory is that DHH is actually a settler who was kind of pushed into pioneering a solution out of frustration. I doubt he'd disagree that many of his ideas came from pioneers like Martin Fowler. Now outside of Utah, I have to explain this slide. Here, I can kind of infer some things. That we have a whole day for pioneers on July 24th, that it's bigger than July 4th. And they're like, what? Tech loves its pioneers too. And we throw our little parades for them. And when Rails fired that starting gun with the blog in 15 minutes, we threw a parade for DHH. And Rails at that time was actually really surprisingly similar in look and feel to the Rails that you'll see today. But you'd die at death of a thousand cuts if you actually tried to use it. Much less deploy it. If anybody remembers how that was done, I'm so, so sorry. You remember? I remember, I wish he was here, a guy named Rusty was in our early Rails shop and I was on the marketing team so I didn't know what was going on with this stuff. I just knew that our customers would call in yell at me when he would kick the billing server and it would bill people 10 or 30 times. So, we had some deployment issues over there. So, some poor schmucks even bet their companies on this unproven new technology. I wonder whatever happened to these folks? Whatever. This is a fun bit of retconning. This didn't used to be a demo store. It was Toby Lukey's actual original business idea that Shopify was extracted from. I think he should have stuck with this one but I can be wrong. Then the settlers start arriving. People need guides and books and supporting libraries. Deploy tools, hosting services. The settlers are all too happy to look at those as opportunities to help and to build businesses. So, you might at this time have had like nine gems, 10 gems, starting with access, maybe more. Rails 1.2 introduced RESTful Routing which basically turned it from an academic concept into the predominant architecture for web apps these days, which is kind of cool. A huge point, a huge part of settling an area is setting up the schools and we owe a huge debt of gratitude to Ryan Bates for starting Railscast. I know I, I definitely, probably all of you did, had two or three tabs open to this at all times and my boss thought I was a genius. So, some more no-name startups are dumping their futures into this black hole. Oh, there we go, more hipsters dumping their futures in the black hole, right? Get a grip, hipsters. GitHub got their start using Rails around this time. Now you gotta love a service that launches with the promise, no longer a pain in the ass, hardcore forking action, never forget. Now Rails was created to fight the architecture astronauts that had set up shop and fragmented Java culture but as needs grow more complex, architectures adapted. The previously maligned computer science folks took over much of the development of Rails. They brought modularity, relational algebra to active record, the big money starts moving in and the Rails tent has to get bigger, including code schools and enterprise needs. At this point, both your bank and the startup disrupting them are using Rails. So that's how these three archetypes play out in a successful community. Everyone has all these three sets of preferences and these personality types in this big soupy mess but one is typically dominant. So I wanna take a little quiz which irritates you the most? Being required to use outdated tooling or team members that try to rewrite your code base in the latest hipster stack, they're webpacking your Kubernetes, anything that gets in the way of shipping. What do you like the most? Accepting a pull request for an open source library or applying a technology in a way that makes the company money or solving a tricky performance issue. What makes you feel most helpful? Showing someone that there's a new and better way of doing things, improving somebody else's documentation or automating a tedious deploy process. Now this was the Cosmo quiz edition of this talk. Those things will generally kind of give you a sense of, like, oh, I have a certain set of preferences that lead me to the front edge of a technology or I prefer stuff that's stable. All of those roles are important. The pioneers experiment and they help define a sense of what the future could look like. Settlers connect that with real problems and opportunities and town planners help it scale to affect large numbers of people. Settlers and town planners may call pioneers hipsters that are swept around by the latest fad technology. Pioneers often get mad at settlers for using their innovations to gain notoriety or make money. And town planners get called out for lacking a sense of adventure, for being architecture astronauts when they're just trying to make things stable, predictable, scalable. As humans, we're wired to be dismissive of those that don't share our default outlook. That's funny. I think we take each one of these roles on at different points, but it's to our advantage to lean on the ones we're best at and strongest. So me, I perform best in the settler camp as a default because I enjoy connecting things to practical uses. Okay, great, you know the hype cycle, you have an idea of your preferences, what now? Well, once you know this stuff, you can set yourself up for success and avoid being at the mercy of this cycle. So there are also ways to lose. You can watch as your skills turn into commodities and become devalued. You can burn yourself out keeping up. Or you can side with tech that doesn't wind up making it. Or you can opt out entirely and become a Fortran developer. I think that pays actually pretty well. But you can hack the tech treadmill, like zero cool hack the Gibson. So this may all seem like total information overload right now, but once you understand your preferences you can focus your attention on where it's most valuable. So now let's use this to map out the cycle for your personality type. You simply can't get wrapped up in trying every new tool that comes out. But when you do feel obligated to check something out, you just need to answer these two questions. What stage is it in and should I concern myself? Pioneers are best served by grabbing interesting new tools and jumping right in as soon as they hear about them. Settlers can just watch and planners can safely ignore it. At the peak it's time for pioneers to shine. Settlers can exercise skepticism but they need to keep an open mind. Town planners can safely ignore and keep shipping with what they know. This phase is where everyone starts taking notice of a technology but it rewards pioneers the most. Pioneers can train, consult, write blog posts, contribute, even become a core team member. Once that cools off a little bit though the pioneers can bail out if they want. They can change roles and stick it out but they have to acknowledge the fact that they're changing roles to become a settler. If it looks like the technology's gonna make it through and be valuable, town planners can glance up if they want. The pioneers at this point at the slope in Bellatiman are just done. The technology's climbing that slope because enterprising settlers are writing books, establishing consultancies, building products, creating a support infrastructure. Town planners at this point probably should start running through the new tutorials that are coming out. At the plateau, settlers can apply now the low risk technology to these novel business problems. Town planners can help automate, improve performance and create enterprise scale solutions. The toy solution is now running Fortune 500 companies and handling your bank transactions. So I told you earlier I'd offer a comfort and a caution so let's start with comfort. You might be worrying about whether your favorite technology is eroding underneath you. The elixir is gonna kill Ruby and Phoenix is the new rails. I've seen medium think pieces about it so it must be true. Or that the tools you use are just garbage and outdated compared to the shiny stuff that you're reading about in blog posts. Like am I gonna have to go buy a suit? Maybe you think you're broken or lazy because you'd rather keep working with the tools that you know than learn seven new programming languages in the next month. For the last year, I've been working in a production Rails 2 app and you know what, it solves a lot of problems for a lot of people and it's full of problems that aren't in the least related to it being on Rails 2. I'm also working in elixir and Phoenix for a project and you know what about that? I can't shake the feeling that if I'd just been using Rails I'd be done by now a hundred times over. I mean it's great, seriously great to learn new stuff but we've got to stop the cycle of making people feel inferior for using the things that make them productive. Let me put a finer point on it. No one gets to make you feel ashamed of liking the stuff you like. And when the shoe's on the other foot, please consider this and don't yuck someone else's yum. I'm not proud to say I've done this to a bunch of people. Now for the caution. You can eventually be left behind and see your skills become commoditized and devalued. If your job like this lady here apparently is to hold this other lady's like cell phone briefcase thing. You might have stayed with the technology a little too long. Or just literally just be Radio Shack. In the bouncy sports ball thing with the net there's a thing where you plant a strong leg and pivot around that, I'm told. I suggest that you have one tech that you use to shift your productions and something you do on the side for fun. If it catches for you, you do more with it and if it doesn't you swap out your side project, no harm done. There's the stuff you do to learn and the stuff you do to shift. If you follow this pattern you rarely feel swung around by this cycle. You just use the tool that you learned more recently more frequently for new problems. I love Ruby, but I'm now a full-time JavaScript developer. The thing is I didn't really notice the change happen. There's no dramatic exit. I didn't get to write a medium think-piss which I feel a little cheated about. One last warning, there are technologies that bet the farm on hitting the peak big and hoping that carries them through. This almost never works unless you're trying to raise sweet VC cash and disappear. I'm not talking about famous and meteor because they'd probably sue me. Um, so we'll call them feedier and mamas. You want to look for tech that has a vision that sees itself all the way through to that plateau of productivity because personal exploration of tech follows that same pattern. So you get into the hello world phase and you start with a tutorial, you get to hello world, you're excited. You have a simple, not ready for production app, but it works and you know kung fu. You're like, I did it. I have accomplished this technology. I know React. It happened, I did React Native. But that's not really real life, is it? Not when you have a problem to solve. So new stuff is awesome, but the trouble with buying in at the peak is those pesky expectations. We wind up stuck in a ditch inevitably and we thought we'd be rocking and rolling. Suddenly our two-week spike is turning into a much harder road. Have you ever built a proof of concept in like three weeks that took you six months or more to get to production? And you're like, yo, this is the same piece of software. What is happening? Maybe that's what they mean by 10x programmer. So those expectations get inflated because once you demonstrate the velocity of these tools, people start expecting that kind of output forever. Like hurry up, we need the feature. You said this was going really fast and all you can think is it was going so fast and then you know it's dive into your own disillusionment. You slog through this trough with Rails. I promise you this happened to you in Rails. If you have forgotten it, try to remember. And you made it to the other side. So why would you do that again elsewhere? Why bother seeing some of these other technologies to your own personal plateau of productivity? Well, clearly you picked some additional technology for a reason, call it curiosity, intuition, philosophical alignment, whatever. But then the pain starts, things get really rough. So why would you stick that out? Well, ponder this for a second. The way our entire industry works has flipped upside down. The problems we're asked to solve now and even the reasons behind them have changed dramatically over the last 10 years. We've been swimming in this technology avalanche and trying to stay on top and didn't realize the fundamental shift that's occurred. UX drives technology now, not the other way around. The tools we built 20 years ago and even 10 years ago were designed to solve a different set of problems than we encounter today. So we need additional tools to manage this world of UX-driven architecture and people are creating these tools rapidly. A lot of our pain comes with trying to deal with the chaos that's ensued from this collective upsetting of our Apple cart. Have you been doing this long enough to remember selling the idea of using jQuery? That sounds bonkers now, but that's where client-side UX is headed. And that explains the meteoric rises of tools like Rails and the more recent ascendance of JavaScript. I did some stuff in Ember on the side and it felt good and I liked it, so I felt comfortable betting on it. Now, I'm encouraged that I'm starting to hear people call it boring. Your bet may be something completely different, but it's important to understand why these bets are likely to pay off. Sometimes it does make sense to switch to something new and some pioneer types manage to ride this eternal wave every 18 months, but if you are trying to ship things, it can trigger that eternal midlife crisis. If you notice this pattern in your work life, maybe check, just check to see if you're not stuck betting on tools and technologies that target that peak. The tools that have staying power like Rails or Ember tend to push through their 15 minutes of fame on hacker news toward long-term productivity. I want so badly to ship stuff, that's why I love. I thought if I just picked up Rails and then Ember that I'd be free from all of the hard parts, but that's not true, it's not even possible. But I bought into it because that's the cycle and it even sounds like the promise, but that's not the actual promise. Look at all the things I'm not doing. That's not the promise, this is the promise. The real promise is about helping you reach that plateau. On the plateau, you have time to focus. You have time to focus on things that have value. Business value. Got about 10 more minutes of this, so. On the plateau, you have time to think and you start thinking, huh, maybe my boss is an idiot. I'm not saying it's true, I'm saying you can think about it. Maybe it's just that you know that you can do better. And since you focus on adding business value, you can afford to fire your boss and then you do. And then you turn out okay. And you get to go have your own mid-life crisis the way that you want to have it. But that's another talk. And that's it till the next episode. Do I have a minute to embarrass somebody? Let's see, can we get the, yeah. This guy. Am I right? So 10, I don't know, a million years ago. So it's gotta be about, it was 2010, so about six years ago. I can't list all the things that he's done for me personally. So it's gonna be a real, I'm gonna compress it as much as I can. A friend introduced me and said, hey, I just started working at a company called Mosey. I have a friend named Mike Moore. He runs this programmer meetup in Utah Valley at the Mosey office. And I was like, that sounds horrible. And I just was learning to program that I'm like, okay, so I'm gonna listen to a bunch of smart nerds be smarter than me. That sounds super fun, thanks. I went anyway and there was a guy with a fez there. I kid you not. And I was like, I don't wanna be here with fez guy and this whole thing. Turns out fez guy was not a regular, but he probably was a really cool guy. I just didn't give him a chance. And Mike was super intimidating. I was like, oh my gosh, I think Eric Berger was there. And all these people were so smart and so intimidating. It was obviously my first ever meetup. And I went back. I was like, okay, I'm gonna go back until I understand what people are talking about. And Mike specifically took interest in this annoying question filled newbie. He organized Mountain West Ruby, which was my first ever conference, which was incredibly scary to go to. And then after a while of attending the meetups, he said, hey, I think it's time for me to step down and I want you to take over organizing the Utah Valley meetup. And I was like, okay, what do I do? And it was really scary for me, but it gave me the confidence to do a lot of other stuff. He recommended and interviewed me for my first job as a full-time coder and I completely blew it. I mean, big time. And he walked out and he said, hey, you really did not sell yourself super well in there. So that was frustrating. But six months later he got me another interview for the same job that actually took me away from him to Austin. He eventually invited me to help organize Mountain West one year. He gave me one of my first ever speaking opportunities at Mountain West JS. He's literally been a shoulder for me to cry on. And you don't know a man until you've sobbed into his shoulders and his shoulders are perfect. He's given a lot to this community, but I just wanted to take one little slice of that and show you the kind of impact this conference and this person have had. Thank you, Mike, I love you. You're the sparkle to my twilight.