 You know, like all the way around to the other side, we're like farther from the snacks and at the eventual lunch, so I really appreciate a ton. I'm also reminding myself, I've given a fair number of conference talks now, but I always get super nervous no matter what right before I start, so I'm mentally right now, I'm just reminding like, okay, the next 30 minutes will not literally kill me, like I will not die, I'm just going to be fine, we're going to get through this. And also just a warning, I am recovering from a little bit of a cold, I got some meds this morning, I have a whole bunch of cough drops and water, but I may need to just like all of a sudden lurch to the side so I don't cough into the audio recording, it's just a heads up, but it's fine, again. Not going to literally die, just feels like it at times, so yeah. I always give this, if anyone here is wanting to get into conference talks and public speaking, I always love talking to people about that for sure, and a piece of advice I often give out is like, set your goal at the right level, especially with early talks, if you don't die, that should be a success, so again, kind of on this theme. Anyway, actually introducing myself. My name is Kay Wu, it's short for Catherine Wu, and I've been a Ruby developer at Nurellic for a little over three years now, but the way I got into software in the first place was I went to a Python based boot camp called Hackrite, fun fact, a lot of people who attend Hackrite are huge Harry Potter fans, and so I would like to point out that I am wearing a Harry Potter shirt today, yes, I actually made this, so we can also talk about that later, really proud of myself, yeah, anyway, it's super cute, if I may say so myself. You can come compliment me about it later, it's cool. So even though I went to this Python boot camp, I am super into Ruby, you can tell because I dyed my hair to match, right, how many people have that level of commitment, I even have Ruby shaped earrings that I wear now when I come to conferences, and of course it's just really great that I didn't pack my pearl earrings instead. All right, so stuff that this talk is actually about, I'm going to cover a little bit the two main programs that I've been running at work for these last couple years, talk a little bit about why I think having those sorts of programs or similar ideas are just a good thing to be having in general, and then the core of the talk is around three general principles I've come up with for running these sorts of continuing education programs. We'll see how those principles come up in the details of how I've implemented them, and then I'll just send you off with some final thoughts, and hopefully have some time for questions at the end as well. So there are two programs in particular that I'm here to talk about today. The first one is the Technical Book Club. I've been running for over two years now where we read about one to two chapters of a technical book each week, and then we meet with somewhere between two and 20 people to discuss the contents of what we just read. And I would like to note as well that I was working on a different project, but decided to get some stickers designed for as well. So that's how you know that it's like a legit program, right? It's got some stickers, which I have some as well, so feel free to come and ask me for those later. So that's the first one, Technical Book Club. The next one is, oh, yeah, so this is a brief showing of some of the books that we've been able to cover in these two years. So pretty excited about a bunch of them. They're not all Ruby-specific books either. The topics vary by a fair amount. So like if you want to learn about different kinds of concurrency models, like Matt mentioned in the keynote this morning, the book on the bottom left there seven concurrency models in seven weeks was one that re-read that I thought was really excellent and pretty accessible as well. And don't worry so much about remembering specific titles or anything here later. I do have a bunch of resources linked if you're looking for recommendations later on. Okay, so that's the first program. The second program is one that we call Lunch Conf. So again, it has a sticker and it also has a cute name, so totally legit program as a result now. And this one is one where we meet weekly and I book a conference room at the office and we just pick a approximately 30 to 60 minute long conference talk and just watch it while we eat lunch together and maybe have some discussion afterwards. So this is usually probably around 10 to 15 people there. And in the past year and a half that I've been running it at approximately one talk a week, sometimes a talk will span two weeks. But through doing this, this means I have watched over 70 conference talks on topics ranging from parsing to refactoring to performance, all sorts of really interesting things out there. So let's talk a little bit about why these are good ideas in my opinion. I gathered a couple quotes from attendees of these programs and someone was like, oh yeah, it gives me shiny hair and clear skin. And in just three visits, I grew two inches taller. Oh my God. I've been five foot two since eighth grade. I reached adult height in eighth grade, so that would have been really amazing. So someone wants to sell me that. But some legit quotes I did get from people include all of the learning, none of the stress, isn't that pretty amazing? So it's because it's set up to not feel like school if that's something that you were always a bit turned off by necessarily. Another quote I got from someone is, watching conference talk is a whole different experience when you get to talk about them afterwards with folks. So that's kind of a huge benefit from attending conferences like these in person, right? We have the hallway track afterwards. We get to discuss with each other. But we'll have to go home afterwards. And it's not always easy to get to conferences regularly or for a lot of people in different experiences. And yet we have so many resources available to us on the interwebs and so it's a way to address that kind of experience too. So in a little bit more detail, I'll go over why continuing ed, why group learning, and why at work in particular. So for continue education, I really think that the first reason for this is it's fun. It's really fun to keep learning new things. It keeps your excitement alive and gives you a break from the day-to-day stuff that you might be having to handle. I think it's good for your current job that you're at right now because you can often apply the content directly to your work. For example, someone said, lunch conference is such a great thing because we watched this Rejects Talk and I totally just used it in researching our customer issue. So you can learn things when you're not under pressure for dealing with a fire. Someone said this, which is one of my favorites, which was I get to notice all the gaps before they become fatal flaws. And so ideally, you might be able to prevent some of those fires in the future even with having some more context. And regardless of what background you may come from, it is not possible to know everything that is out there. So for example, New Relic has a very large code base that's several years old. We write a book about refactoring. We're also an enterprise software application, which is why we read a book on patterns of enterprise application architecture. All of those things ended up being pretty helpful in a day-to-day basis. I think it's also good for your long-term career because again, you can learn things the easy way rather than having to necessarily pick it up through experience in the hard way. But it also gives you the potential for discovering new areas of interest. For example, we read a book about error handling in Ruby, which led to someone giving a lightning talk, covering some of the content that we had in there and wanting to dig into it a little bit more. So why group learning in particular then? For me, the number one reason behind this part is I am trying to use peer pressure pretty deliberately on myself. I got to a point where I was tired of saying, oh yeah, I'll do that someday. So it turns out that I will do things under peer pressure that I'm not motivated or get around to doing just for myself. So really, I run these programs because I'm talking other people into helping me do a thing that I already wanted to do. This is, I think this is known as a forcing function, is a terminology I've heard, which is any task activity or event that forces you to take action and produce a result. So for example, Book Club is every Monday afternoon from four to five, and so every Monday afternoon at 3 p.m. I am getting on top of doing that reading because I want to show up having been prepared for that. It's also really helpful group learning, I think because you're doing it in a very active and reinforcing sort of way. You are going over the material at least twice, maybe more. First by reading through something yourself, then through the discussion, and then sometimes even after the discussion, if new points have been brought up, I might go back and like, okay, really, reinforce and get this into my brain. We discuss questions like, how come chapter four says one thing, but chapter seven says this other thing? Or we might ask you questions like, what did the author mean by et cetera and what else is going on there? Sort of trying to synthesize and pull all of these things together. One of the attendees says that it's that human interaction that really helps lock it the knowledge in. And I think that having this discussion really enhances the experience of reading these books. Someone else even noted, I'm not the most social of people, and yet learning socially happens to be how I learn best in the end. So I think overall, you can end up learning a lot more than you might otherwise on your own, because it includes learning about what not to trust as well, that you don't have to just take the author's word for it. In the discussion, we'll often present multiple sides of the argument, and people are willing to disagree as well. Some of the books that we read are considered classics in computer science literature and whatnot, but sometimes it also means they were published 20, 25 years ago and whatnot. For example, that enterprise application architecture book I mentioned, a lot of the patterns we look through there, those of us that were newer to the field were a little bit like, oh, at one point this was a thing that was discussed and given a name, but in our experience so far, it's been taken care of for us by frameworks such as Rails. They've implemented a lot of these patterns. So knowing about them helps us better understand the shoulders of the giants upon which we are standing. We can also know we don't necessarily have to go forth and use the patterns directly as is. We can get a bit more context and updating it for what we're facing currently. And then why at work in particular, which is something that I feel has been a huge part of the success of these programs. Well, for one, it's just really convenient. We have to be there already anyway. So that's really helpful. But I also think that doing it in the office when you can can allow you to take advantage of resources that are there. We don't have a formal continuing education budget as far as I'm aware, but I just went and asked if that was all right. One time we were buying a book, it was a bit more expensive. Like the computer science textbooks always tend to bump up the price by like two or three times. So I was spending, I don't know, like $950, around $1,000 on buying a bunch of these books. And I went to my VP and was just like, hey, just a heads up. Like I want to buy these books. Like that's what we're interested in learning next. We're really excited about this types and programming languages book that we want to read. Is that all right? And my VP went to me and turned to me and was just like, Kewu, I spent $1,000 buying donuts this morning. Please, please spend $1,000 buying some computer science textbooks. It's not just the money resources as well. Having it within the office allows us to take advantage, I think, of extra time in between other projects and tasks that we're working on. And we have the conference room and snacks and whatever else the amenities are all there. And I think I've mentioned this a little bit so far already as well, but again, I learn a lot better from these topics when I can try to find a way to make that material more directly relevant to what I'm doing. If I can apply it to very practically and immediately, that will seal in that knowledge so much more quickly. A fair amount of the time in these discussions, like we're reading a slightly more theoretical one right now and I finished a chapter and just be like, okay, that's cool that they're describing that this is a thing that exists and is the thing that you can do, but what do I use it for? This is often a question I have. And so in the discussion we can brainstorm, like okay, well, maybe there are pros and cons, like in this kind of situation, this is why you'd want to know about this particular technique or strategy. It's also really fun in a way, and this was a little surprising to me, but just in terms of the developing relationships aspect of doing this at work, through this, we get to interact with people we might not normally have projects that we're working with. So other engineering teams across the company, folks from the support teams are welcome to join as well, folks from the training teams, and it's just really nice to know a lot more about what's going on at the company outside of my own immediate bubble there. People end up finding like-minded folks that they can either try to pair program with at times or be mentored by as well, and it's really rewarding to me to see those relationships blossom. And lastly, another benefit was setting the discussion a little bit, kind of trying to drive a little bit what people are getting to see at work. So if the topics that I might be particularly interested in such as inclusivity and how can you improve that at the company, we can through some of these kinds of programs try to help get that some broader exposure with the other folks at the company as well. That if we have seen the same similar material, we can also again talk about how we can apply it for our direct lives. So the three general principles that we have in common here. Well, so some of the common challenges for these sorts of programs, I think that come up in people's minds are, it adds overhead, it's more coordination than if you are just doing something on your own. You may not want to get stuck managing it necessarily. You don't, maybe you want to work on other projects later. You don't want to be on the hook for this forever. It's not your core job as a developer after all. And as a result as well, it can be easy to push aside with other deadlines. So I'm going to introduce these three general principles and then I'll, again, I'll go into more details about how they're applied in the programs that I've been running. So the first one is to make it easy. And this is to try to reduce the overhead as much as possible. A lot of times people will come to me and sort of be like, okay, we're like, you do all these different sorts of things, like that's so great, whatever. And I'm like, okay, the secret is you just set the bar really, really low, so low that it's hard not to do it instead. Ideally, there's an option where all people have to do is block up the time and then just show up. So my goal in running these programs is I only want just enough involvement to keep things alive but not more than that. Because sometimes people will say, oh, wouldn't it be great if we, you know, like if we like prepared exercises or there was homework and I'm often like, that's a great idea, but we don't need it necessarily to just keep it going. So if you want to invest the time now and do it occasionally, that's really great. We don't have to commit to that on an ongoing basis necessarily. The next principle is to make the program distributed, make it as decentralized as possible. So much like software, I don't want to be the single point of failure when it comes to running these programs. I travel, I might get sick, I might want to move on to other things and this is a way to try to handle the concern that you might end up getting stuck managing this. So one example of this kind of thing is document how things are being run so that it would be easy for someone else to cover or take over when we're moving on from here. The last principle then here is to make it useful, which helps resist the urge to de-prioritize these sorts of activities. Because I think above all, if you're not getting much out of something, you should stop doing it. Again, people thank me for running these sorts of programs but it's really selfish. I run them because I want them to exist and because I feel that guilt for not reading as much as I could, it's useful if it's productive and it's not useful if it's paralyzing and makes me want to stop going any further. Trying to set up this positive feedback group really helps keep that momentum going and build on our previous successes here. Sometimes people might drop off a little bit later in book club and they come up and they're like, oh yeah, I wasn't so successful because I didn't finish the book and I always want to cut them off immediately and say, no, don't say that you weren't successful because you didn't stick through, you didn't come through every meeting, you didn't finish every single chapter in the book. If you read more, if you learned more than you would have otherwise, that is a success and you should feel good about that. You already did more than zero. Again, setting that bar so that you can build up those accomplishments and feel, remind yourself of what you've already been getting out of it. So if we pull those together, another easy way to remember this is E-D. That's why the middle one, they're not the simplest words necessarily, but it's so great. So each of the programs that I run, there are multiple areas where these principles have been applied and so I'm gonna tell you a little bit about how I've done them and therefore what I think were the keys to making them work well. So for just getting started, I think you should pick your own starting point, especially if you're the one getting the ball rolling on these sorts of things. You should make it really useful for yourself because you're picking something that you're interested in and it makes the setting up of these sorts of programs a little easier because you don't have to argue necessarily just yet about where to even get started. So all of this started with me wanting to read Sandy Metz's book, Pooter Practical Object-Oriented Design and Ruby. A bunch of people at the office have been talking, oh yeah, we should do it someday. And so I was just like, okay, we're doing it. If you're interested, you should come. For LunchConf, the starting point for these was that I bookmark all of these talks but that I just don't watch them on my own. I'm not very good about watching videos necessarily. And I think at RailsConf last year actually, somebody was saying, oh, I just like watch it at lunch, sometimes like at my computer. But again, I thought I wouldn't do it that by myself. So the thing is that New Relic, pretty much everyone takes their lunch between 12 and one. So I thought, oh, I'll just use that same strategy as a book club and I'll talk other people into doing it with me. And we set up this forum where people can submit all of their bookmark talks and it's into this spreadsheet now. So again, it's all these things that I already wanted to do. I just needed a little bit more of a nudge to actually make it happen. And so from here you can go ahead and recruit participants for that pooter book club. I had an idea in mind of a core group of folks that had already said yes, I am interested in reading this book. So this helps the program be decentralized because other people are also motivated and want to keep it going. We can help each other out on this. I tried to gather a mix of different experience levels here as well because that turned out to be really useful for having interesting discussions, both getting really good questions from the more junior folks as well as hearing always really fun war stories from the more seasoned folks that were in their group. Those included mentors as well. So if you're newer to the field, you probably have run into folks that are just like, oh yeah, you should totally read or watch or whatever else kinds of things. And that was the moment when I would often turn it back and be like, okay, if you really think I should read or watch this item, like, do you want to do it with me? Like join our book club, join Ledgekopf. And it turns out people are actually often really willing to reread or rewatch something that they thought was really helpful before. And from the mentoring side, I feel like it's a way that mentors can very concretely help more junior folks without the burden of having to set up a customized curriculum for teaching or sharing knowledge. One thing when we got started as well was I was very insistent on having just a consistent time and location. So the very first meeting with that core group, we did talk a little bit about, okay, Monday afternoons tends to be a little bit better. You have caught up from being up for the weekend, but you're not kind of, you still feel like you have time for meeting a Friday deadline or whatnot. So the two reasons for this is in general, I just show up where my calendar tells me to. I was joking with someone the other day that I feel like it would be totally really easy to kidnap me someday because you could just put a calendar event there and I would just show up. Whatever, sure, okay, that's fine. Yeah, true story. So that's the first reason. I'm like, if it's on my calendar, then I will make time for it and I will go there. The second item though is I hate rescheduling a meeting for a large group of people where you have those email chains where you're going back and forth of, oh, this might not work. Like what about this other one? Am I having a preference? Oh, I have to be 30 minutes late. Oh my God, no, that was so much time. So I think it's a lot better just to accept that sometimes people won't be able to make it. But the goal is not for everyone to make it every time. That is too high a goal. Again, lower the bar a little bit. We want instead for it to be easy for people to know what's going on and decentralized or not having to wait for specific people to make it necessarily. And an idea I had here is almost I wanted it to become an institutional or organizational habit that we just know Mondays at four o'clock on the 20th floor, that's when book club is happening. Before, as we were getting started, we also make sure to discuss and set some ground rules, which I'm a big fan of just to get everyone on the same page of this is the microculture that we're working with for this particular program. So for example, the first rule of book club is, and I'm probably already breaking it right, is to just come to book club. That's the first sticker that we have there. Just come to book club. It's okay to come, even if you haven't done the reading necessarily, because it turns out people are really good about not asking for summaries necessarily, and they can still ask questions and for folks that have done at least some or hopefully more of the reading in trying to explain what was being covered to other folks as well, learning by teaching it to someone new. So again, this is the really easy option. All you have to do is just block off time and show up. Hopefully you've made an attempt, that's again why Mondays at three o'clock I do all this reading, but you can also just come and make it a habit. When we're starting off with any of these programs, I also try to have people articulate what their motivations are necessarily. So at the first meeting for a new book, we'll go around the table and just have people say out loud, this is what I want to get out of it. And sometimes that's very similar across different folks, and sometimes it's very different. So that's really interesting as well to hear other people's perspective of this is what I'm hoping to learn and how I hope to apply it going forward from here. Because of course there should be some difference after reading through a book or watching some talk with them before, right? It should have some sort of impact. And so talking about this is what I hope and expect it to have can help remind people to stay on top of and finish it through. Another ground rule we have is just that if two people are around and have done enough of the reading, the meeting will go on. So this is just one of those things where it's like you only need two people to have a discussion going, right? We're setting the bar low and it's extremely easy algorithm for whether or not to keep a meeting because even if you have a consistent schedule, again, I don't want to get into the conversations of, oh, should we cancel? Should we put it off? Like again, if we have two people, it's happening. We also have this ground rule of reminding folks as well, like it's okay to disagree with the content that we're reading just because someone managed to publish it into, you know, have a publishing company put this book out for them, doesn't mean that they're necessarily the end all be all authority. And again, there's that time component as well. That may have been good advice in that particular situation that particular time, but what does this mean for us today? A new thing that we've been doing recently is trying to involve more remote folks as well. Because we started with just locals, I thought that would be a little bit easier just to get things up and running and establish just how useful this was given the investment that we've been putting in. So for, now that we have remote folks, some of the ground rules and patterns we're trying to have include making it be everyone's job to notice if someone remote is raising their hands to speak or trying to give them space for that as well and involve everyone. Because we are a little bit more Portland heavy, but there's just no reason that we can't include more folks there as well. I still also have a failsafe like using Slack for the discussion facilitator if it seems like other people aren't getting a chance to jump in or there's some sort of delay or other issue with the video chat set up there. For Lunge Conf, we have a ground rule that's like, look, if you're not getting very much out of this particular talk that we're watching or it's not quite what you thought it was, go ahead and head out from there. Like, you know, if it's not useful, you should cut that off and move on with your lives. So the only addendum to that is along the lines of if this one is on what you were looking for, we'd love to get other nominations of other talks that would really be great to watch if you've had ideas around that. I also like to set things up to have a place where you can record things much like a Wiki page. It's decentralized so that everyone can update those details. We have a record of the ground rules, which books we've read already. And it's useful for remembering relevant links that people might have shared in the slack time afterwards or that came up in the discussion. It makes it also easy for new people to educate themselves about what these programs are like. So again, trying to make it as easy as possible for people to join and continue things going from there. So I'll talk a little bit about running the events on a weekly basis. First is moderating. What we're doing on and off with Book Club is that we try to have two moderators set for each weekly meeting. And the responsibilities include committing to doing all of the reading for that particular week. So ideally we rotate through and over the course of the book, most of the time, again you can just come to Book Club. And then once in a while when you're the moderator, like okay, this week you're really going to focus, finish all the reading and try to bring some relevant work examples when it's appropriate. This is one of those areas, again, where having people from different teams and organizations participate is really fun because then I get to see a little bit as well the different examples that they are coming across in their day-to-day jobs. Moderators are also in charge of making the discussion useful for everyone as much as possible, just creating that space. One phrase I've been using at times lately is I'd like to hear a comment or question who hasn't spoken yet. And I can sometimes just let that awkward silence sit for a while. I'm trying to practice being more okay with awkwardness and not needing to fill the silence necessarily and hopefully this can make it a little bit easier for other folks to join in and participate even if they're not necessarily the loudest folks to start. Again, we have these two moderators assigned. This is ideally for each one to have a backup. Things come up, it happens, but we want to have that decentralized management. There was definitely a lot more moderating. Initially when we were getting started and people are getting to know each other, trying to get everyone to talk, but once, again, these things became an institutional habit, we sort of developed our own culture and it was easier to keep things going. We rotate those assignments, I'll do it every so often and I keep these programs continuing, but I don't consider them belonging to me or I don't want to be the gatekeeper on them. And again, getting that exposure to other work projects is really helpful. And then after all that, having a forum for continued discussion from there. So we have a Slack channel which makes it really useful for easy asynchronous participation in that discussion. People, it's decentralized because people can coordinate amongst themselves if needed. Oh, actually, that meeting room got overbooked so we're moving here instead, whatever else may be going on there. And other people just like using Slack better, but an email mailing group would totally serve the same purpose as well. So it is natural for enthusiasts to fade after a little while. It's always the very first meeting where attendance is highest because even if you've done everything you can to make things easy and useful, it's just kind of a natural consequence that it fades a little bit. But that's totally fine. One thing I try to do is ask questions because I understand that people are busy and I'd like to always get feedback and learn more about how we could make it more inclusive, make it easier for people to participate. And a lot of times this ends up being that people feel like they fell a little bit behind but then they're like, oh, it's just like, it's so much, I have to read like five chapters to be able to catch up. And I can tell them, having read a bit more of those, oh, actually this is a book where the chapters are fairly independent from each other. So really all you have to do is just do the one chapter for this week. And if you get a chance, it would be great if you wanted to. Like if you think you're gonna learn something from those previous four chapters, we've collected the resources, you can reference back and kind of catch up with what the discussion had been. But reset the bar again, just read the one chapter or just come, just come to book club again. I also, in the form I use for collecting names for who's gonna do the book, I have a really light amount of guilt tripping. It's a question that says, I commit to making an effort and there is only one acceptable answer. The answer is yes. So I haven't been able to run like an A-B test necessarily see how effective it is, but it's a good reminder to folks anyway of like, oh yes, I got a book and I do want to do this for myself as well. And that's where it comes in of reminding people that, no one is forcing them to do this. You signed it up for it in the first place because you thought you were gonna get something out of it. And I have no real investment over like whether someone follows through on their own learning goals. I want them to succeed out whatever they're prioritizing and sometimes just having a conversation about, oh yeah, like actually we do think that that's gonna be helpful in some way and we should keep going. So then for choosing the next item that you might cover, we often have some sort of voting or submission process which helps people be involved. They get invested because they have kind of more of a stake in the game and more likely they come. So again, I have a variety of specific recommendations if you want to get started. There's a blog post with a link in the last slide of this talk. For choosing the next book, we often have a mix of nominations that are language focus and also not language focus. Sometimes we even have exercise-based books because it turns out that the language in the examples doesn't matter that much, I feel. We're going between the original refactoring book and then the refactoring in Ruby book. And it turns out that the language translated one had some poorer reviews, I think. So we went ahead with the original and I haven't really written very much Java before but for the purposes of understanding the examples as discussed, it was actually not so bad to follow along with them. Another recommendation I've had is that we have a spreadsheet with a bunch of nominations on there and it's been really helpful to try to buy a copy, just one copy to start of each of them to stock our office library with them so that when we're voting, people can grab the book and flip through it and see a little bit like, oh, just in general, this is kind of what's involved. That's actually not as intimidating or not as thick a book as I thought it might be once I can see that in person and then later we can place the larger order if we decide on that particular book. For choosing the next talking, and we have a spreadsheet from all the nominations that people have submitted and so the moderator picks three options from that spreadsheet and then everyone votes amongst those three options so it's kind of the reward for being the moderator is you get to drive the discussion a little bit of these are the three topics that I'm really into right now and everyone else can submit further preferences after that constrained list. So some variations on the theme for similar programs that I have popped up at the office. One is called Business Time which is this was we were talking about what is even involved really in going to business school and getting an MBA. My boss was talking to me about reading business case studies and it turns out you can just buy those. You don't have to pay like six figures plus in order to get access to them. So that's really interesting for those of us that were wanting to like what is involved for like a CFO's job? Like what decisions are they making? That was really interesting. The security team put together a themed book club for them as well trying to learn new techniques and share knowledge of it with the broader community. Our support folks are on the fifth floor and so they started one called Fifth Floor Book Club which is focused on topics that are more directly applicable when you're in customer facing roles. So still technical but more along the lines of like I think they read a book on different operating systems that they might come across when dealing with support tickets. And one of my favorite ones that got started is called Introvert Book Club. And the description for that is no talking aloud. Just stop by and read near your friends. I think it's so great. Again like you have that group accountability. It's you know people wanting to work their way through office library books but you don't have to do the discussion if that's not what works for you. One other one I learned about this at a lightning talk at RailsConf earlier this year is rubybookclub.com which is a podcast and Twitter discussion going through a series of books. Right now they're reading Sanny Metz's newest book 99 Bottles of Oop I think. And so I think this is really good if you work for yourself or for what a reason you feel you may not have the room to get this going at the office. One more idea is a thing that they called SelfConf which was something someone organized as just a one day event at their office. The point, the case that they made was all we need is like 100, $200 for food to provide people for lunch and we can essentially run our own conference from talks that people have said or gave in response to the question of what were the best talks that made you a better engineer or served some other purpose for you. So and all you need is room and maybe some food for people for a whole day and so much more effective than necessarily sending the whole team to travel somewhere else for a conference, right? So I love that idea, I thought that was really great. So some final thoughts. Again, you don't have to run these programs forever. The whole point of decentralizing is that others can take it and run with it and if at some point interest dies down and we're not getting out of it what we used to be we'll just retire it and put it to a close. Again, the definition of success was we did more than we would have otherwise and that is already a win. I think as well that what makes something useful or easy to accomplish in your own workplace may very well be pretty different from mine. So go ahead and adapt it, experiment and see what works. My friend Erica earlier this year I was practicing a talk with her and trying something new out and she turned to me and was like whenever I talk to you Keiwu I feel like you're running some kind of experiment and I am the lab rat in this situation. So it's true, I'm always trying to try out new things. One thing I'm doing right now for getting myself through books is I am taking notes on post-it notes and then putting that inside the book directly because they belong to the office technically so I don't feel quite comfortable highlighting or writing all over them and taking notes in a notebook then I have to match them up necessarily but putting it directly in the book then I just slip through like oh yeah like I had a thought or a question and now it's directly linked with the section that I had the question about. So the final exhortation I will leave you with is may your bookmarks decrease in number and may you achieve all of your learning goals. Thank you very much. So the question was, I've talked about these two different programs, book club and lunch coven and the question was whether they are run in parallel or alternating pretty much, right? That's the question. Yeah, so they actually do run independently so each one of them happens every week because a lot of the folks involved in one are also involved in the other. Sometimes we do have a bit of synergy or whatever where we had a book club discussion and someone was like oh yeah, there's this, I think like we were reading the concurrency book and then someone mentioned the Rob Pike talk about concurrency and go and so then we watched it in lunch coven not that long after it, it was really nice to have alternate media that presents similar ideas to help with the learning. Cool, so I don't wanna keep you from lunch too much longer. Again, thank you so much for coming and please, please come say hi, I'm not always the best at starting conversations or introducing myself and I have to be in a wedding in Boston this weekend so I'm just at RubyConf just today unfortunately but I want to meet you all and I do have stickers both for Nurellak and for these programs, so thank you very much.