Episode 37 - Kinsey Durham Grace

Get a behind-the-scenes look at the meticulous planning for RubyConf, where  Kinsey Durham Grace reveals exciting new initiatives aimed at making the conference more inclusive and accessible for developers of all skill levels. Learn about the importance of the early Call for Proposals (CFP) and the exciting RubyConf tracks planned for this year. As she details the structure of RubyConf, featuring three simultaneous tracks and a community-focused day, you’ll see why this event is a must-attend for anyone in the Ruby community.

Ever hit a roadblock while working on a project? Kinsey discusses common blockers at GitHub and how tools like Sorbet, AASM, and Packwork have transformed their workflow. With insights from experienced organizers like Spike from Rocky Mountain Ruby, you’ll learn about the importance of having a playbook and support system in place. Finally, get inspired to submit your talk for upcoming conferences, leveraging coaching resources to ensure your proposals shine. Kinsey’s enthusiasm and wealth of knowledge make this episode a treasure trove for anyone passionate about tech, community, and personal growth.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Speaker 1 0:01

Hello everyone and welcome to another episode of Code and the Code Encoders. Who Code it? I'm your host, drew Bragg, and I'm joined today by Kinsey Durham-Grace from GitHub and Ruby Central. Kinsey, would you please introduce yourself for anyone who's unfamiliar with you?

Speaker 2 0:14

Yeah, I'm Kinsey. I'm based in Denver, colorado. I currently work at GitHub. I also am a board member for Ruby Central and I am co-chairing RubyConf. That's coming up so super excited about that. When I'm not programming, I am either with my two young children or doing things in the outdoors here like fly fishing and things like that. Yeah, that's me. Thanks for having me.

Speaker 1 0:37

Absolutely. Thanks for coming on. Sounds like you got a full plate, with a full-time job being on a board and two kids A lot.

Speaker 2 0:44

Yes.

Speaker 1 0:46

So we'll get right into it. For anyone who is unfamiliar with the show, the way this is going to work is I'm going to ask Kinsey three questions. I'm going to ask her what she's working on, what kind of blockers she has. If she doesn't have a current blocker, she can talk about a recent blocker she had and how she went about solving it. And then I'm also going to ask her one final question of what's something cool, new or interesting that you've recently learned or discovered. So, without any further ado, Kinsey, what are you working on?

Speaker 2 1:12

In the vein of GitHub work, I am actually currently on call this week, so doing a lot of kind of on-call backlog work and putting out fires and things like that. As far as Ruby Central work, I am working through stuff for the conference that's coming up in November in Chicago for RubyConf. So yeah, super excited about that.

Speaker 1 1:38

What's an on-call week, typically like at GitHub? Is it a lot of just monitoring to make sure the app's not down, or is there a full backlog that you're constantly working through?

Speaker 2 1:49

When you're on call for my team, we specifically are in deployment, so there can be a lot of pages just given where we are in the organization. If a deployment fails, even if it's not necessarily tied to the code that we write or anything like that, we usually get pulled in that sort of thing. So, yeah, it's a full week, seven days, 24, seven being on the pager, so that sort of thing. And then also, if you're not busy with kind of things that come up while you're on call, you're definitely working on backlog work of like bugs that have piled up and different things like that. So yeah, just given that I'm in deployments and internal tooling, we tend to get a lot of, like I said, unexpected urgent work, so yeah, so it can be a lot of the on-call.

Speaker 1 2:35

So the deployment app is an internal app at GitHub, but it's still a Rails application, is that right?

Speaker 2 2:41

Yes, it is. It is. So when you think of GitHub, it is a Rails shop, which is crazy. It's really cool the scale that it supports. So you think of the monolith or we call it com, which is what you see when you go to GitHubcom, but we are a separate Rails app. We're definitely not as big as the monolith, but we are pretty big. There are definitely files in our code base that have thousands of lines of code. It's been around for a while six, seven years and, yeah, also a Rails application. So a lot of apps at GitHub are Rails. We do have some Go application services, things like that, but, yes, a lot of Rails, and that's currently the code base that I work in, and the team that I'm on is definitely a blend of working in Rails but also working in infrastructure type stuff like Kubernetes and things like that.

Speaker 1 3:36

All the fun stuff that I'm so happy that other people work on, so I don't have to because it gives me a headache. So for Ruby Central, you are on the board and you're co-chairing the upcoming RubyConf. I'm super excited for it. It's already looking pretty great. The CFP is currently open. What are you hoping to see come through the CFP as far as talks go?

Speaker 2 4:00

RubyConf has always had a little bit of a stereotype that it's not very technical. So this year we really want to focus on having technical talks that are also accessible but also a wide variety of leveling. So we're looking for talks that would be good for beginners and we're also looking for a lot of talks that would be good for advanced senior staff level engineers, and we tend to not see those as much and if we do, there's not very many of them. So really wanting to see technical talks that are still accessible, still fun, not super boring, which is really hard to do.

Speaker 1 4:36

It is.

Speaker 2 4:37

Making a super technical talk interesting, but, yeah, just something where people can walk away with, like, hey, I'm going to try to implement this in my day-to-day or at my job, maybe I can pitch this to our CTO, I don't know something along those lines. And we definitely still want to have talks that are considered more soft or non-technical, but there will just be a lot less of those than we've seen in previous years. So, yeah, so it should be exciting.

Speaker 1 5:01

Yeah, how many tracks are you going to have at RubyConf this year?

Speaker 2 5:04

We'll have three simultaneous tracks, but we're also doing for those of you who are at RailsConf a similar where we're doing a community day. So there will just be two days of talks and then in the middle is the community day where we'll be doing hackathons and like fun things like pairing with contributors or different companies and things like that. So we are fleshing out the details on that, but really excited. Oh, and we'll also have workshops that day for community day and things like that. And then lightning talks at the end of the day where people can present on stuff that they've done throughout the day. But yeah, just all being in the same space solving similar problems together. And it was a big hit and a big success at RailsConf, so we're bringing it to RubyConf.

Speaker 1 5:52

Yeah, wholeheartedly agree that it was a huge hit at RailsConf. It was an absolute blast. I think everyone I spoke to had very positive things to say. It seems to get better every iteration. I think that was the second time right that it's happened. First time definitely had some rough edges, but was still a lot of fun. I really enjoyed the format and it did seem a lot more structured and organized at Rails Conf and I'm looking forward to it being a continuing trend because I really enjoy that format. Something that you said the lightning talks being at the end of day two Is that what I heard, correct, okay.

Speaker 1 6:27

So, instead of being on the last day, it's going to be day two and it's going to be primarily about what people are working on, or it's still whatever.

Speaker 2 6:36

Okay, it's still whatever. But people might feel inspired to do a lightning talk on something that they did during the day or the problem that they solved, or like, yeah, pairing session, that was awesome or something like that, or something they participated in for community day. But, yeah, definitely still going to be an open format, but switching that around.

Speaker 1 6:56

So Very cool. So how does one go from being a Ruby Central board member to being a co-chair for RubyConf?

Speaker 2 7:05

Yeah, usually it's volunteer-based, so I think everyone on the board is expected to do it kind of rotating and taking turns. So previously it used to be two board members, but the trend for the last couple of years has been someone from the community and then someone from the board. So, yeah, jim Brumsick is my co-chair and he is very well known in the Ruby community. He has a lot of great connections through his consultancy flagrant and then also just being from the Midwest, and he has a lot of connections in Chicago, so it was perfect to be able to pair up with him. He also does Madison Ruby, so he has a ton experience organizing conferences and things like that. So he has a ton experience organizing conferences and things like that. So, yeah, I think that's the model that we'll be doing, moving forward as a community member and then a board member. So, yeah, that's awesome.

Balancing Responsibilities and Conference Planning

Speaker 1 7:55

Yeah, Jim's a great guy, Super excited to see what kind of ideas he brings to the table. How much planning has been done for RubyConf? Is it still sort of like let's see what we get CFP-wise and then maybe we'll tweak and structure X, Y or Z that way, or is?

Speaker 2 8:14

it like no, we're pretty much done. Now we just need to fill out the speakers. Yeah, we're definitely still in planning mode, figuring out different things, but I feel like the main stuff we've talked through a lot, you know, keynote speakers, different things like that. So, yeah, we have an awesome program committee made up with a lot of awesome Ruby veterans and also people who are newer. But, yeah, really excited about the program committee group that we have and I think it's going to be a really good program and, yeah, we're super excited.

Speaker 2 8:45

I think it will look a little different than it has in the past, not only because of the community day, but just given the fact that we're looking for more technical talks and things like that. You know, open to framework talks that aren't necessarily, you know, rails, which hasn't really had a space before. So a lot of things to be excited about. And and we opened the CFP actually way earlier than we usually do for previous conferences, yeah. So, yeah, we just want people to know that they're speaking early, have a longer time to prepare, but also so folks can see what kind of talks there are and hopefully that will drive their ask to their company or if they want to spend money to come to this conference just because it'll have, I think, a lot more technical content than it usually did.

Speaker 1 9:32

Awesome. Yeah, I think that's a great way to help pitch it to the boss.

Speaker 2 9:36

Yes.

Speaker 1 9:37

I'm going to go learn stuff, not just going to go do the hallway track. There's a lot of good technical stuff. I want to go to these talks. This might end up being the blocker question, but I have to ask. I mean we touched on it briefly. You've got a full plate, you have two kids and a full-time job at GitHub, which that's not a hey yeah, it's just something I do, no big deal. And then you're on the Ruby Central board and now you're also co-chairing the entire RubyConf. How do you manage all of that? How do you balance your time? Is it you're just really good at time management or is it like no, I have to find new and creative ways to manage all of my time.

Speaker 2 10:18

I feel like it's kind of a mix of both. I feel like I am good at time management and, yeah, I also work when after my kids go to bed. But I also work from home, so I get to spend a lot of time with them in the mornings and when I take a lunch break I get to do lunch with them and put them down for their naps and different things like that. So I'm really lucky in the fact that I have like a work-life flexibility to be able to do things with them when I need to and still be present. I don't spend like hours commuting and different things like that. So I think that makes a big difference.

Speaker 2 10:51

And then, yeah, I'm kind of a workaholic. Like my idea of like winding down after the day is having like bad reality TV on while I'm still working and doing things like that. But yeah, also I have crazy to-do lists. I also try to use a Pomodoro timer I don't know if you've heard of that and then I can stay focused for a while and then eventually switch to another task. But yeah, I've just found that really just putting headphones on and trying to be as productive as possible in the time that I have really does make a difference, as productive as possible in the time that I have really does make a difference.

Speaker 1 11:30

It just sounds like such a wide variety of things too. Just the context switching alone makes my brain hurt, but that's also why I'm not on any kind of board or co-chairing anything. So I do actually want to ask the full question what kind of blockers do you have? And it can be a Ruby Central style blocker. It could be a blocker of something that you're working on on GitHub.

Speaker 1 11:47

You don't have to tell us any top secret GitHub information but, any kind of blockers that you had or, like I said, a recent one, and how you went about solving it would be awesome.

Speaker 2 11:57

As far as Ruby Central goes, I think a big thing that's been a blocker for us is really just post-COVID. So if you look at the numbers and things like that, a lot more people used to go to conferences. Conferences used to be profitable not profitable, but at least we would break even. Ruby Central would. And now, if you look at the data, it's just after COVID, it's just ticket sales. Everything has gone way down and hasn't made a huge comeback, and I think there are a lot of contributing factors to that.

Speaker 2 12:26

But yeah, I think having that as where we're losing money on conferences versus making money has been a big blocker for us, and you've seen the announcement that RailsConf next year is going to be the last RailsConf and also a lot of reasons that went into that. But the biggest thing is we're just losing too much money and, like any nonprofit, when that happens you have to make changes. So that's been a big blocker and also being aware of that for RubyConf and things like that, and we don't want the experience to be affected in any way and we're just used to the conference how it's always been and that sort of thing. So I think post-COVID it's just a very different era for in-person events and things like that. But yeah, I think it's also been really great and made me appreciate them a lot more too. So pros and cons to that.

Speaker 1 13:14

Sure, I'm very sad that RailsConf is going away, but in a way it does make sense, because that wasn't Ruby Central's kind of mission from the get-go was to run two conferences in the Ruby community. It was to support things like RubyGems and bundler development and security stuff and all that. And the conferences were just to help fund those endeavors. And if they're not making you guys money, it sort of doesn't make sense to actually have them go. But do you think that the sort of the comeback of regional conferences that we're starting to see is impacting the attendance to the bigger conferences or do you think there's enough room for both?

Speaker 2 13:55

I definitely think there's enough room for both. But at the same time, I think it's good that, because we're winding down RailsConf after this year, obviously there will still be RubyConf, but that also gives us room to support those smaller local conferences. And, because I do think they're important, we have the Boulder Ruby Conference here. I love the feeling behind local conferences but also like there's something special about RailsConf and RubyConf and yeah, I think it's smart that we're kind of able to start supporting those. And yeah, everyone doesn't have to keep reinventing the wheel and we have Rails Foundation doing Rails World, so it's like that's covered. But I still think RubyConf continuing is great. Just, we do have that conference that has been around for a long time and can still like fulfill that community aspect and space can still fulfill that community aspect and space.

Sharing Conference Insights and GitHub Challenges

Speaker 1 14:45

Yeah, I think that's a fantastic endeavor that Ruby Central is going on to help support the smaller, more local conferences. Because it is from everyone I've talked to, like Spike running Rocky Mountain Ruby out in Boulder, just talking to him about all the logistics and all the unknowns and all the things that he kind of was blindsided by when he was prepping he put on a great conference but you could kind of tell it was like I'm so glad this is over because that was a lot, but he still wants to keep doing it.

Speaker 1 15:10

So having a support system of very experienced conference organizers sounds like such a weight or a way of dealing with the. I have less unknown unknowns. Now. I have people who will help me when things come up and kind of a playbook to run from. It's got to be a great feeling.

Speaker 2 15:31

Yeah, I really love to be able to support that and formalize that Like here's a playbook for running a conference. You know, here's all the things you need to know, all the stuff that he learned, you know all that and how we can support that.

Speaker 1 15:42

So do we know where RailsConf is going to be yet?

Speaker 2 15:45

No, I actually don't. I don't have any cool insider scoop. A lot goes into it, where hotel affordability is a big thing and different things like that. So yes, TBD Right. It'll be exciting when we finalize it.

Speaker 1 16:01

So yes, yeah, I'm anxiously looking forward to it. I've been pushing for Philadelphia, even though it wasn't on the list, but that's all right, we'll get a conference one of these days. If I have to put it on myself, yeah, hey, there you go.

Speaker 2 16:14

Local Philadelphia conference, there you go.

Speaker 1 16:17

Yeah, cool. What about blockers from GitHub?

Speaker 2 16:26

Yeah, I think and I'm sure a lot of engineers can relate to, this is just the interrupt that happens just in the job. So I'm not talking about interrupt from, like my kids or something happening at Ruby Central or anything like that, but really just sitting down trying to get a chunk of work done but then being interrupted by requests that support requests are like hey, this is broken, can you look at this? Or having to review people's pull requests, and I think that can be a big thing, just because it can take a lot of time to get up to speed on a pull request and then the other person is kind of blocked on their work until you review it. So you become the blocker if you don't review it quick enough. Also, our team is split between Europe and the US. There's really great pros to that. For example, I would have been paged last night, except for my 2am, except for my coworkers in the EU. I saw there was an issue and jumped in and blocked me from getting paged. So I love that aspect of it. But then it can also be hard with time differences. We're not up to speed on the same things that people are working on Not as many people in your time zone to review a PR, to unblock you, to keep going, so I would say interruptions like that whereas it's.

Speaker 2 17:34

Can you help me with this? Or can you look at my PR? Can you do this training? Can you do XYZ meetings, everything. So just really finding good ways and creative approaches to how, as developers, we get time and that sort of thing, just to be able to write code and focus and not be distracted. What you kind of touched on earlier, like switching contexts, can really be a big blocker. So I would say that's something that was on my mind today and blockers that I've been dealing with at GitHub recently.

Speaker 1 18:08

That sounds like a familiar problem. I've had those. I've talked to many people who were like I mean, my biggest blocker is just finding time to focus and I can feel that especially I'm the kind of person who likes to get into my deep work. And there are some people who are like I am good at the Pomodoro technique, where it's like I'm working for X amount of time, I take a break and then I work for X time. I'm like I'm working, I want to work.

Speaker 2 18:33

Yeah.

Speaker 1 18:33

Pop me out of my little bubble. I'm going to struggle to get back into that deep work. So I feel you. What is something cool, new or interesting that you want to share with all of us?

Speaker 2 19:27

I feel like working at GitHub. I have been introduced to gems that I would have never looked into or thought about or hadn't heard about until I had gotten to the scale that I see every day at GitHub Really amazing gems that we use. Obviously, sorbet is one of them. So we've implemented that. Dotcom did that. We've used it. We're now we use it all the time, and I at first really into Sorbet.

Speaker 2 19:54

We've also tried out a gem called AASM, which is about state and state transitions in Ruby. That has made a big difference for us. So definitely check that one out and then another one that I've been looking at but I haven't fully implemented, or when I have the time to spike on. This is like Packwork, which is a Shopify gem. We would love to be able to start containerizing our smaller components of our big, massive Rails application and how can we break this into smaller pieces so if something breaks, the whole application doesn't go down and different things like that. And we've implemented Sorbet a while ago, but AASM is a little newer for us and it's just been introducing gems that have helped us.

Speaker 1 20:39

You said you were kind of annoyed by Sorbet, but now you love it.

Speaker 2 20:42

Yes.

Speaker 1 20:43

Was there a learning curve? Was it just getting used to the added syntax? Or was it something that, like, hey, when it clicked, it went from like how did I ever write code any other way?

Speaker 2 20:54

Yeah, so at the job previous to this I've mostly been doing Ruby in my and at the job previous to this I mostly been doing Ruby in my career. But the job previous to this I was writing in Go, so I definitely have experience with writing code in that way. But I think it was really just the learning curve and the overhead of like, oh, I have to type a signature for everything and it's super annoying. I just want to help our method and I can't just create a helper method super easily anymore. I have to do all this stuff.

Speaker 2 21:18

But yeah, now that I'm used to it and I think a big lift and I didn't do a lot of the lift my coworker did, but the lift of transitioning over to Sorbet too, obviously it's a big lift. But now that we have that implemented and are using it, I don't know how we could go back and it's definitely caught things that I wouldn't have caught going down to production. But yeah, in general it has helped me and just provided that extra layer of security, obviously on top of like integration tests and just manual testing and my own unit testing things like that. It's just been that extra layer of like feeling safe about pushing something out.

Speaker 1 21:57

Do you think surveys still would be good for a smaller team, like with substantially less developers? I think it does. I mean I've never worked at GitHub scale, but when I think about GitHub scale and how many engineers you have working on a single code base at a time, like something like Sorbet makes a lot of sense from that aspect. I start to wonder if, on a smaller team like I work on a team with I think there's like 10 developers do you think the benefits start to become diminishing? Like you said, I just want to make a helper method but I have to do all this extra stuff. Do you think some of the benefits aren't there unless you have a certain size team?

Speaker 2 22:33

Honestly, I don't think so, because I think at any size it's great just because you really get, like I said, all these safety benefits and anyone can make those mistakes not mistakes. Really, it's like you're learning, which is great. But yeah, I think if we had done it earlier in the code base too, it could have been really beneficial. So I really don't see like a downside of, if you have time to invest in it, investing in it now until it makes it even harder, and then every time you create a new file you have it type strict and that sort of thing. So you can know that, moving forward, you're moving in the right direction.

Speaker 2 23:08

And we only have I think there's 8 of us on our team just on my team that works on the base that has survey, on our team, just on my team that works on the base that has survey. So I definitely don't think that there's like you need to have this number of engineers or have this many lines of code. I think the sooner the better. But yeah, just seeing what it's done for us, and I think it could have also shaped things earlier. But again, it's a really big lift and a lot of times at smaller companies you don't have the bandwidth or the time. It's just like you're just trying to keep the lights on, or at least that's how it was when I worked at a startup. We didn't have a lot of time to invest in architecture or making things better, and sometimes at GitHub I feel like we don't have that option either. But yeah, I think it's important and I definitely recommend it.

Speaker 1 23:54

Cool, cool. So and then you said AASM is all about state management.

Speaker 2 24:00

Yeah. So for us it's been a big thing with, like deployment stages, like the state of a deployment, like active deployment, a completed deployment, different things like that. So, yeah, pending all these different states, and it was a little bit of a mess. And then I feel like introducing this gem helped us really define what that looks like and really help us ask some bigger questions to our code base. Helped him see some problems of like this is bad, we need to fix this. So I also feel like it's helped not only make our code base better but also, like help us identify places that we could be better.

Speaker 2 24:45

So for us, like that's also been a big win and it just makes me appreciate gems and that makes me appreciate bundler and just like how important that ecosystem is, which is another reason I wanted to get involved with Ruby Central. So, yeah, it all kind of ties together for me. Yeah, I think those are just like two kind of interesting things that's been top of mind. I'm just like, oh, it's so great that we have these tools that can help us.

Speaker 1 25:11

So I will tack on one more question, because I would love to hear from you on what are you most excited for at RubyConf this year.

Speaker 2 25:20

Oh, that's hard because I'm excited about so many things. You know Matt hasn't been in person since COVID, so that's a big deal. I respect Kent Beck a lot and I'm really excited that he's going to be in person. I feel like he's really knowledgeable. He's going to be in person, I feel like he's really knowledgeable. But I'm also just excited for, like, the community day and just the community feel that RubyConf always has, and Chicago is also going to be great.

Speaker 2 25:44

I think it's a great central location. I've been really surprised at how cheap the tickets are going to Chicago from different cities. I think that's a big thing because a lot of times it's like I don't want to pay 600 bucks to fly over here. So Chicago's, I think, is a really good central location. And, yeah, I'm just really excited to see how having more technical talks go and how folks approach making technical talks more approachable and digestible and things like that. So, yeah, just really curious to see kind of what works and resonates with folks and how we can get better at teaching people very technical things and having them be interesting conference talks. So that's another thing I'm really excited about.

Speaker 1 26:26

A lot of exciting possibilities for a technical talk that's still got the Ruby weirdness or the Ruby whimsy that we've all come to know and love.

Speaker 2 26:36

Yeah, that's one of our tracks still.

Encouragement to Submit Conference Talks

Speaker 1 26:40

I did notice that. I did notice. Anytime I hear someone say weird Ruby, I'm like ah, they're talking my language. It's my favorite part of Ruby. All right, great. So is there anything else that you wanted to talk about? While you have airtime, it is your episode, you can talk about whatever you'd like.

Speaker 2 26:58

Yeah, no, just really want to encourage people to submit a CFP. We also have CFP coaching sessions. If you are just, are you a little intimidated to do? Just submit. We also have speaker coaches and just want to encourage everyone to apply and again, it doesn't have to be a technical talk, we're just really excited. We're also opening early bird tickets soon. So, yeah, keep an eye out for that announcement and keynote announcements. But thank you so much for having me and this has been great.

Speaker 1 27:31

Yeah, thanks for coming on. I definitely want to echo get your CFPs in If you need help. Take advantage of all of the CFP coaching. Take advantage of the speaker coaching. It's awesome resources. I have friends that volunteer on both and they're amazing at what they do. If you are even remotely on the fence of submitting a talk, you should do it. You will not regret it. So, kinsey, thank you so much for coming on. This's a great episode. Great to talk to anyone from the Ruby Central board anytime. Love hearing from you guys and very much looking forward to RubyConf.

Speaker 2 28:06

Awesome, thank you.