Code and the Coding Coders who Code it
We talk about Ruby, Rails, JavaScript, and everything in between. From tiny tips to bigger challenges we take on 3 questions a show; What are you working on? What's blocking you? What's something cool you want to share?
Code and the Coding Coders who Code it
Episode 31 - Elise Shaffer
It's time for another Ruby on Rails podcast crossover episode! This time I'm joined by the RoR Podcasts new host, Elise Shaffer. Elise interviews me about the game show I've been giving, I offer my thoughts on doing "weird talks", and we chat about how I got started podcasting. We then flip the script and I interview Elise about her new course on Test Driven Development (TDD), her podcast, and her thoughts on teaching and learning. Elise also had some great tips for getting started (or getting better) with Vim.
Links:
Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.
Ready to start your own podcast?
This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.
Hello everyone and welcome to another episode of Code and the Code Encoders.
Speaker 2:You're listening to the Ruby on Rails podcast. We're here with Drew Braggs the special crossover episode.
Speaker 1:Where I'm talking to Elise Schaefer of the Ruby on Rails podcast. So some of you remember we've done a crossover episode before, but that was with the old host, brittany Martin. Brittany, we miss you very much, but we're excited to have Elise here. Elise, how's it going?
Speaker 2:It's going well. I just got back from RubyConf yesterday, so kind of adjusting to normal non-conference life still, but things are going really well. How about you?
Speaker 1:Going well, got the post-conference slump where I just kind of miss all my friends, even though I'm really tired from interacting with so many people for multiple days. So it's that weird. I'm so happy to not be there anymore, but I'm also missing it terribly.
Speaker 2:So I think we've kind of met a few times at this point. The first time I met you, I think, was at RubyConf Mini maybe. Yeah, like you have this wonderful game show that you do, and I'm just curious where the idea for that game show came from, and because it's like a great part of the conference. When it's there, I always appreciate it. So I'm just kind of curious, where did the idea come from?
Speaker 1:Yeah, I appreciate the kind words. I am consistently surprised and blown away by all the overwhelmingly positive feedback I get about the game show. It really was an accident that it happened. In a way, I had told a friend of mine, jason Sweat, that it was on my bucket list to one day speak at a conference he was putting on a conference called Sin City Ruby, and he asked me to speak at it and I was like sure, but I have no idea what I'm going to talk about.
Speaker 1:So I racked my brain for two or three weeks trying to come up with what do I want to talk about? Am I an expert in something, or am I good enough at something to talk to a room of other Rubyists about something I don't know? I have very low self-esteem and self-confidence so it's hard for me to say I'm smart enough to talk about X or I know enough about Y to tell it to a room. The one thing that I did have that I was really interested in was a collection of weird Ruby snippets. I had a company with a 17-plus year old code base. It was like Ruby 1.8 and Rails 2 when it started, so it's super old and it's always been a really lean team. It was a little outdated when I got to it and it just kind of meant that as I started doing the upgrade, I was just touching files that hadn't been touched in 17-plus years. So there was really weird Ruby and it was awesome.
Speaker 1:I learned so much, but there was a lot of stuff that I noticed. Hey, I don't even know how to Google this syntax. I know nothing about this syntax. I don't know what's called. I don't know how to describe it. To Google this was pre-chat GPT days, so you had to do your own Googling.
Speaker 1:Yeah, so I had that and I was like I wonder if I could do a talk about that. Hey, readability in Ruby is super important. Ruby's a wonderful language for making it readable, but you can still be weird with it, which is also great. But it's sort of important. You're leaving behind this legacy of code. You kind of need other people to be able to read it. So I knew I had that, but I didn't know how to make it a talk and I thought maybe I would do it like a circus act, because why not, we're in Vegas, I can be as weird as I want.
Speaker 1:The talks also weren't being recorded, which was a godsend, because if they had been recorded, I probably would have just bowed out and been like no, no one can see me do this ever. But it was like I wasn't sleeping one night and I just, middle of the night, was like and I just was like I can do it like a game show. I can do it like some, like just pick a game show I can, doesn't matter the format, I just I have this weird Ruby and that's what I can do is like what is this output? Like what happens when you run this Ruby or what is this shit called? I worked on it for a few weeks and gave it a sin city and everyone was like it was fun. Brittany, the old host, was my first contestant. She did great. It was a lot of fun. My friend, Chris Seaton was in the audience and anyone who remembers him he's prolific at knowing Ruby syntax and he admitted afterwards that I stumped him on one. So it was like life achievement mode there.
Speaker 1:I got great feedback so I decided to do it at many, which is where you saw and participated I appreciate that in it and it's been going strong. I've done it a few times. I have a few more instances of it scheduled, so I'm excited by how many people have seen it and enjoyed it. I'm excited by the fact that people tell me they continually get something out of it. But yeah, it's a great. It's heavy audience participation. I bring people up to the stage. So it's not just some guy that you don't know talking at you for a half hour, which is that can be a great thing when it's like Kevin Newton talking to you for a half hour, but when it's me, it's, I don't want to do much of the talking.
Speaker 2:I like the audience participation aspect of it and also it's typically I don't know if this has been true every time, but it's been true the couple of times that I've seen it it's been at the end of the day and it's like a nice little energy rejuvenation thing right before everybody goes to dinner or goes to karaoke or whatever they're going to do. It's like it like brings the energy of the conference up, or at least it did the two times that I was there and I think that's like part of it. It's also just really funny because some of the questions are just wild, like wild Ruby questions. It's good. I know a lot of people like the game show, so I hope you keep getting to do it. I like the idea that it was just like a midnight epiphany of like it could be a game show.
Speaker 1:Yeah, and I think it's a good. I think it's a good message too to pass on to anyone who's trying to come up with a talk and they're like I don't know if I can do a technical talk or if I don't know if I know enough about this topic. You also don't have to stand up there for a half hour and just talk at people. You can come up with fun stuff. Nick Schwatterer gives some of the best talks I've ever seen and he just kind of mimics what Y used to do, which was really weird. You sort of don't know what's going to happen next. You're like fully engaged in this performing arts act of Ruby, and those end up being some of the best of the conference because there's a ton of really great technical talks and non-technical talks and every time there's something that isn't a traditional talk, it ends up being so good and so fun. So I would say to anybody who's thinking about talking and don't know how to come up with an idea be weird, embrace the weirdness.
Speaker 2:Yeah, I mean, I like that Ruby is weird.
Speaker 1:Absolutely.
Speaker 2:That's a strength of the language and of the community is that we're weird sometimes. So let's talk about code and the code encoders who code it. Because this show is really interesting. You've got kind of a standard format. It was the inspiration for the show.
Speaker 1:I had tried blogging. That didn't work out too well writing and writing consistently, or not anything that I've been terribly strong at in my life so I didn't think that blogging was gonna happen. I also didn't think that there's a lot of time and effort that goes into Chris's Go Rails videos, so I didn't think I had the organizational skills to do something like that. But I really wanted a way to contribute, even if it was in a not terribly meaningful way, and this was just my own. I just wanted something to give out, to give back to the community, and I kind of just thought about the idea of podcasting because I had a ton of respect for podcasters.
Speaker 1:Podcasts really got me through the pandemic. I probably would have lost my mind a lot more than I did if I hadn't been able to go for a walk and listen to other engineers talk. Like I listened to a ton of the remote Ruby podcast. I list a ton of the Ruby on Rails podcast, jason Swett's podcast. There were so many podcasts that really just kept me from going a little stir crazy. Also because no one in my family speaks code, so just having someone saying it just being a fly on the wall. So I just was like well, maybe I'll give it a shot. I like talking to people like I like hearing their stories and hearing what they have to say. So maybe if I just have a podcast and I just ask a quick question and let them talk for a half hour and then release it, maybe other people will enjoy that as much as I did. And yeah, that was like how I decided to make my contribution back to the community a podcast.
Speaker 2:Conversations are always so interesting because you're asking the same three questions but every episode is completely different because the person you're talking to is like working on something different or they've had a different blocker or they share fun things. And sometimes you have people who share things that are not even the cool thing they share is not even code related, and those are always really fun too. So appreciate kind of the standard format but like how much variation there is from guest to guest.
Speaker 1:That's really for me in a way and it ended up being like great for the show. But that was really. I need enough structure to not get lost in my own show. I need enough structure to offer something resembling a structure to guests to set them at ease. But I needed it to be open enough that we can have good, meaningful conversations and I feel like unless you're really type A, it's hard to do that. It's hard to have a really good, meaningful conversation when you've already planned every single question out and every single answer and things like that, Like some folks do it incredibly well. I know that's not me, so I was like I need structure, but not so much of it. Let's do it sort of stand up-y. And yeah, the last question, the what's something new or interesting doesn't have to be coding related is my favorite question. I get such awesome scope of responses to that.
Speaker 2:I agree with you about structure, though, because what I try to do since I've taken over the show, what I've been trying to do is have a list of questions that we're going to ask, but kind of follow it but not follow it too closely and piggyback off of stuff and sort of try to find a casual sounding conversation in the midst of having a structure. So I'm doing the same thing and I feel like it's worked out pretty well so far and, yeah, the conversation is always going in interesting directions. Right, it's always fun to get to chat to people. I think there's an element of it, too, where it's you know, I resonated with what you said about having people to talk to and having something in the community and trying to find something in the community, because that's very much where I was when Brittany asked me. But there is like a selfishness to it too. It's like I get to talk to really cool people 100%.
Speaker 1:Yep, yeah, I've definitely had excuses to talk to people that I don't think I would have gotten to talk to otherwise, or at least talk to them in the depth that I have. So, yeah, there's definitely a selfishness that comes along with the podcast. It's like I want to talk to that person. Well, I have a perfectly legitimate excuse to talk to them now.
Speaker 2:So, yeah, it kind of gives you like legitimacy in a way. You know, I'm walking up to like random people at RubyConf last week just saying, hey, do you want to do a quick three minute interview. It kind of gives you legitimacy to sort of be like hey, look, I don't want to just ask you one question after your talk. I'd love to go really deep on this for 30 minutes, and having a podcast kind of gives you a license to do that in a way.
Speaker 1:Yeah, it's definitely one of the huge benefits and the nice thing is, I think a lot of podcasters at least in this community, the podcasters that I know we all recognize that we're fortunate to have that ability and then we use it mostly for good. I don't think any of us has been like using it for evil or anything, but we use it to. A lot of the podcasts have people who've never been on podcasts before or who just gave a talk and was like, hey, come on the show and let's talk about more about this. I've never been on a podcast before. Well, great, I have an avenue to give you a voice.
Speaker 1:That's the thing that I love the most about Ruby for All Julie and Andrew's podcast. Like they're super good at giving people voices and Julie asks all the questions that, like I've always was too scared to ask and had to learn on my own and it's a wonderful podcast and I think that kind of it's not that it's junior centric, it's just it's great for early career devs who have a lot of questions and might be feeling like, oh, I can't ask them because I listen to these podcasts and it's two senior engineers talking about stuff that I don't even comprehend the basics of. And then there's this podcast where it's hey, let's talk about this, but in a way that everyone, regardless of where you are in your career journey, can learn something from, and I love that podcast for that.
Speaker 2:Yeah, definitely. I also love that podcast and I think it's very. It is an exceptionally accessible show too, so keep doing what you're doing, julie. We're viewing Andrew shout out. Go subscribe to Ruby for all.
Speaker 1:Absolutely so. For those who have you, who are unfamiliar with my show maybe are coming from this, from the Ruby on Rails podcast side, where this is gonna work, cause I'm gonna ask at least three questions. I'm gonna 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 the last question is what is something cool, new or interesting that you've recently learned or discovered or potentially even built? It doesn't have to be coding related, but, as the name of the show gives away, it totally can be coding related. It's kind of what we do here. So let's get this party started. Elise, what are you working on?
Speaker 2:Yes, that's a very good question. So obviously I have the podcast and that's been a big part of new things in my life. But probably a more interesting thing to talk about is that I've started putting together a course on test driving rails applications. So I've got the first couple lessons done and I'm like working on getting a few more episodes done before I put that into early access for folks to kind of give early feedback on, and yeah, so that's like the kind of big project that I'm working on currently.
Speaker 1:Very cool. So when you say test driving a Rails app, do you mean TDDing a Rails app, yeah, or getting okay cool.
Speaker 2:Yeah. So the idea is that I get asked a lot like I'm a big test driven development advocate and I'm like big on testing and kind of testing methodologies and how to think about testing. But I often get a lot of questions from people when I am talking to them about testing, about sometimes I don't know how to start the test or like how do you test this specific subset of things that are complicated to test because it relies on X, y and Z or whatever, and I always have and like usually the answer to those is like I have to talk about more details of the situation to kind of help break through it. But I've been consistently getting series of the same types of questions and the same types of topics came up over and over again.
Speaker 2:There's clearly a gap in education on this point because like don't learn testing in school? I mean, I didn't learn it when I was in college. I didn't do a boot camp but like most of the people that I've talked to who've been in boot camps have said they covered testing a little bit but they didn't really go deep on what does test driven development look like. So I kind of felt like there was a little bit of a gap here for a course to be made to help people walk through it. And then also in testing a lot of the really interesting test scenarios, like the really interesting subject matter where you want someone to like help you learn, it is kind of difficult unless you're working on something real Like. A lot of test examples in conference talks or in textbooks even are kind of contrived.
Speaker 2:So one thing that I've been trying to do is picked a project to test drive from beginning to end, so over the course of the whole course. It's the same project and the hope is that you kind of started the beginning so you get an idea of like how do you test drive when you have nothing? But then I'm hoping that by the end it's kind of more like got X, y and Z feature set and now I need to add feature A and that interacts with features Y and Z and like how do I test that and make sure I don't break anything? So that's kind of the goal. I've structured it sort of similar to a lecture series. So I have the first part of it is slides about concepts, so we cover like the red, green refactor cycle and then there's like a demo and then there's like an exercise and then I show you like potential solutions to the exercise and then we move on to the next lesson. So that's kind of the structure of it. But yeah, it's been fun so far.
Speaker 1:That is very cool and I agree with you. I think there is a gap in that. I know I did do a boot camp. I did some programming in high school. There was no TDD back in that.
Speaker 1:But when I went to a boot camp to like actually get into this as a career, we did TDD in so far as like they would give us tests and we would have to write the code, the past tests, which is essentially TDD. But like the biggest gap that I had coming out of that was like I didn't know how to write those tests without code. Like I knew what code would cause these tests to pass and I knew what. If someone gave me tests, I could write code to pass it. I couldn't write a test unless there was code and I would honestly kind of suspect that I sort of can't do that. I can do it better now, but I definitely am. There's huge gaps in my knowledge on doing proper TDD. So that kind of course is interesting to me, even at my level. I've been doing this for years now and that stuff is still good, so I think that's going to be an awesome course and hugely beneficial to folks.
Speaker 2:Yeah, I think for me it's like interesting because I have the opposite, where I kind of get paralyzed if I don't write the test first. At a previous job we had these one-off scripts. This is funny. I told this, recorded an episode with Julie for all while we were at RubyConf and I told the same story about how we'd run these one-off scripts, like they would literally only ever run once. But when I was setting it up I was like I had to write tests for it. And this is a situation where, like I had multiple people ask me like isn't it kind of a waste of time to TDD this? And I was like I don't even understand the problem until I've written the test. Like I was like maybe it is a waste of time, but like the tests helped me understand the whole problem and also give me like a checklist for solving it. And so I have kind of the opposite, where if I'm trying to do something without writing the test first, I kind of get stuck a little bit.
Speaker 1:Right, right, and I can see that like it's just a way to break down the problem ahead of time. Right, I think we all do that in whatever our avenues are. We have to break down a problem, and yours is. I break it down via TDD, so in a way, two birds with one stone you already have your tests now. Eric Havillerson did a lightning talk on a different methodology of what it's called PDAC or something of breaking down a problem, and it sounded super similar to TDD. As I'm sitting there, I'm just like this sounds like TDD minus the actually physically writing the tests. So I think it's maybe confirmation of my suspicion that like it's just an excellent way of doing your problem breakdown. But hey, this sounds like it and you're saying, yeah, I have a blank canvas, I don't know. Tests give me the structure to start doing the work and that makes a lot of sense.
Speaker 2:I feel it is kind of one of the real big superpowers in coding is like TDD, I think. I look at the type of coding that I did before and the type of coding that I do now and I can move so much faster with tests At least I can. I'm not super dogmatic about a lot of things in code, but TDD is one of the things where I just try as much as possible to convince other people. I think of it as a thinking tool more than anything else. It helps me think through the problem. Then, once I've thought through the problem, it acts as a verification that I haven't broken anything.
Speaker 1:Right, absolutely.
Speaker 2:Another argument that I usually make is that if you have tests where you have a high bar of confidence in them, you don't really need to hold all of your code in your head, because the tests will do the verification for you. If you have good tests and you trust them, you can just wing it for most of the development cycle, as long as none of the other tests fail. You can push to production at any time, right, right, but getting to that confidence is the key, or the tricky bit.
Speaker 1:Yeah, you said that doing TDD speeds you up, do you think it's sort of like that? I'll just call it the VIM paradox of when you first start with VIM everything is so much slower because you're learning all these things. But once you know VIM people who use VIM habitually are super fast, moving through their editor faster than I am with a mouse. Do you think it's the same deal with TDD, where it's like in the beginning you're actually a little bit slower because you're still kind of thinking through how to use the tools at my disposal. And then, once I've got those habits good habits in place, now the speed up comes.
Speaker 2:It's funny that you say that, because I am a VIM user. So yeah, I actually do think it. I think it's exactly like that. I think Martin Fowler in the Test Driven Development Book has like a graph where he says like early on in a project it is more expensive to start with tests, and then later on in a project this is going to be weird because it's an audio podcast, but the line is like there's a crossover part and then quickly they diverge like very fast on the other side of that line and he's like, until you get to the crossover point it is faster to just write the code, but afterwards it is unbelievably slower.
Speaker 2:And I think that there's a part of this where it's kind of the fastest thing for you to be able to do is to do the thing that you have a habit of doing. So do you think in a very similar way to VIM starting out with TDD, if you're not used to testing, if you don't have the skill level built up and you haven't practiced it a lot, it can feel like it's moving, like you're moving so slow and you can kind of feel like I don't understand why everyone wants to do this. It feels like it's taking me forever. But at some point you kind of get used to it. You've done it enough, you are practiced enough at it. You've run into enough awkward testing things.
Speaker 2:Which I think is what really trips people up is that there's not enough examples of weird testing stuff when you're learning. So then you reach a weird testing thing, but now you have to figure out how to solve that thing. But once you've run into a lot of those and you just have a lot of practice and you kind of have internalized all that stuff, are able to move faster, in the same way that, like the day one you start using VIM, nothing is gonna get done that day, but by the end of the month you're probably as proficient as with your previous editor and another month later you're so much faster than you were before. So yeah, that was a good connection.
Speaker 1:I think that's a pretty big hurdle for a lot of people is like telling them hey, you have to go slow first, you have to go slow to go fast. Slow is for women's fast common saying. But there's been more than a few times and I'm like I should start using VIM. That's what all the cool kids are using. I should use it. And I'm like two days into learning VIM and I'm like I just need to get shit done. So what do you think if someone was to say like, yeah, well, I just need to get stuff done. So I can't stop and learn how to TDD. I can't slow down to do TDD and get used to it? Like what would you say to someone to convince them otherwise?
Speaker 2:So I think that there's a couple of things to consider here. One of them is you have to get stuff done and so you can't slow down for TDD. Is that because of a constraint that you are placing on yourself, or is that an organizational constraint? Or is that a code constraint? And the way that I like to think about this is like one. It is gonna impact your productivity in the beginning, and if that is not a thing that your organization can afford at the moment, if you're under a tight deadline, if you're in the middle of an incident and you just need to fix it and you can't, then clearly do the thing you need to do to get done as quickly as possible but hopefully you're not in a situation where everything is always get it done as fast as possible and there is some room and also just kind of understand that like, yeah, it's gonna take a while, like anything that you do, right, I love to cook and I learn new cooking techniques, and the first couple of times I make something new it's awful, it's not good, but then you get used to it. Learn not to burn the rice while I'm trying to whatever. But it takes time and it takes practice and that is part of the journey. And so I would say one if you're really under the gun and you really have a tight deadline and you're under a lot of pressure, maybe don't worry about the test right now, but then, when you have a little bit more breathing room, start with a small area of something that you're working on where, like, it's kind of bounded and you can kind of feel out the edges of it and it's like gonna be not super expensive to test, and then worry about the big things.
Speaker 2:And then, if it's an organizational thing, like your organization doesn't think there's time for testing, the only thing you can really do there is to lobby leaders within the organization.
Speaker 2:The thing that I've seen work most often in that context is to tie it to some quality metric. So say, hey, we have this area of code that's really hard to understand and it's really complicated and there's no tests around it and nobody wants to touch it. Every time somebody touches it, that feature takes twice as long as it should or whatever right, twice as long as we expected. And, especially if you've done the first part that I just mentioned about, find a small area where you can add some tests, if you can show even the smallest amount of quality or speed improvement as a result of TDD, you can usually get buy-in from your leaders to do the more complicated one, and then in that case, if there's something that is changing a lot and it's super critical to the business, you should be able to get leadership buy-in on testing it. And if you can't, then at some point you kind of have to pick your battles, I guess.
Speaker 1:But yeah, those are good suggestions. I definitely float on the man. I wish I was better at TDD, because I know a fair amount of people who TDD and it makes a big difference. I do write tests, like I write the code and then I write the tests, and then I run my test suite to make sure it and break anything, which so I love having the tests. I'm 100% with you, which is the writing the tests first is not a skill that I have yet. So I for one, will be checking out your course to try and up those particular skills that I feel like I'm lacking. So what kind of blockers do you have? Now, it doesn't have to be a blocker on that course, it could just be blockers in general, but I am also interested in the idea of course development. So if you do have a blocker while building the course or a recent one, that would be great to share, but any blocker will do.
Speaker 2:Yeah, I think a blocker that I'm running into right now is there are things that I know are awkward to test and trying to work those things into the course and like finding good ways to work them into the course. If you start with TDD and you start the project, it's kind of easy to have the test just sort of evolve in the correct way. But, like oftentimes, the things that are tricky to test are like oh, we designed this thing and no one ever thought about using it for this other thing. We designed this billing thing but no one ever thought that we might use it for single purchases instead of just subscriptions, as an example or whatever. And so what does that look like and how do we make sure we don't break this other thing? Those are the really interesting things. And trying to shoehorn those into the course and come up with relevant examples.
Speaker 2:That's the thing that I struggle through and I'm still struggling through. And then kind of the way that I work through it is I just sort of stare at the screen for a while and then go for a run or a bike ride or whatever I get on Zwift. But those are some of the trickiest parts for me and this is the first time I've ever put a course together too, so there's like a part of me that's like trying to balance. This is an interesting testing scenario with. This is an accessible thing for people who are not used to testing or haven't learned a lot about testing, like those are things that I'm like struggling with at the moment, I think.
Speaker 1:Have you reached out to anyone else that does courses, or like just picked brains of people who do those types of content, whether it's video or just lesson based? Is that a strategy that you're taking, or?
Speaker 2:Yeah. So our friend, you actually work with Andrea. I've asked Andrea a couple of questions about this, about, like, how do you come up with a good example and how do you like structure things? Definitely talk to her about it, manage to have a chat with Chris a little bit at RubyConf, so I'm trying to get advice from people who are kind of doing content that's similar. That actually has been pretty helpful, like I think that they've given me a little bit of stuff to think about in terms of how to structure it. I'm working through it. It's good, and I take that advice and I let it marinate in my brain a little bit and then eventually I figured out.
Speaker 1:Usually, I think the course development stuff is sounds like the end result is so amazing. But the amount of work that goes into it, I just feels like it's so much work because you're not just sitting there and going hey, let me write a quick blog post on X Not saying that blog posts don't also take a ton of time and organization and structure. But as we talked about when we were like, hey, why do you ask the three questions? I do need that structure, but I also perform better without it. Like I like being able to free form things but kind of can't do that with a course. So it just sounds like a ton of work. And when you're saying like I don't really know how to structure this or how to shoehorn that, and I'm just like how do you even solve that? And that's why I was asking like, is that something that you go to other people for, or is there a course on making courses?
Speaker 2:That's what I should do. I should make a course about making you know what I should actually do. I should blog about putting the course together. Yeah, yeah, and that's what I should do. That's a good idea. I want to go back to Vim. Yeah, yeah.
Speaker 1:Please do.
Speaker 2:If you are interested in getting good at Vim. The piece of advice that I typically give people is are you using VS Code? I'm a okay, I tell people, whatever editor you like, don't jump into terminal Vim right away. Whatever editor you're using, use the Vim plugin for that editor. So VS Code has a very decent Vim plugin. The benefit of that is that if you do get into a time crunch where you've got a ticket, that's you got to get it out the door today, or it's a bug fix or in an incident or something, you can turn it off and you just have your normal environment and it gives you a little bit of a safety net of you're not stuck, so you can turn it off and then you have your normal environment and so if you have an emergency you can get that stuff done and it gives you kind of a safety net of like I don't have to be perfect at Vim.
Speaker 2:Starting out, which is like can be, it's very Vim is very intimidating because, like you know, I've definitely been in pairing sessions where I do something and I don't even realize that, like the person who's watching my screen, like it just moves and people don't. They don't know that I press four different keys to make something happen, but a bunch of stuff changes on the screen. And Try to get better at this, where I try to explain Before I do some operation. I'm gonna move this down to here or I'm gonna change what's inside these quotes, whatever. I try to get better at explaining stuff, but it does take a bit to get used to it. So if you are interested in Vim, I highly recommend use the plug-in for your editor and then just turn it off when you need to and then turn it back on when you're interested.
Speaker 1:I will have to give that a try. That sounds good. Yeah, done that too, where I'm pairing with people who work in Vim and I'm like we're using tuple, it's great, you can go back and forth really easily, and but if they're using Vim I'm just like I know how to move back and forth with a couple of keys, but that's about. I can do a little bit of visual mode stuff. I don't even know how to copy and paste in it, so just I'm useless, you drive. But it'd be nice to at the very least be like have a baseline with Vim where it's like cool, whatever editor You're using, I can jump in and do at least basic editing. I feel like for most editors or most IDs, I can do that. Vim is the one where it's just like well, I know enough to get myself into trouble. I know how to save an exit, but that's the extent of my knowledge.
Speaker 2:It's so much different than every other editor and I think that's the thing. Like you don't have another example of an editor or any, really any software that works that way, and you really have to Kind of train your brain a little bit. And that's, you know, similar to TDD. It takes, just takes practice.
Speaker 1:Yeah, it was the original keyboard shortcuts, right? Yep, for a while everything was, there was no mouse, and then we had a mouse and everyone used the mouse for everything, including when the web was new. Like everyone, it was just you use the mouse. You very rare you touch the keyboard if you filled out a form. The more and more we're seeing like websites that are just like hey, here's your keyboard shortcuts, keyboard commands to do this stuff instead of having to touch your mouse, which is really cool to see and it just makes me go man, it does enhance my experience on this website to be able to do all these keyboard commands once I know them. In my editor I do the same thing, but Vim is like next level stuff. I don't even have to take my hands off the keyboard. So that could be cool. But, yeah, learning curve. So the last one, though, my favorite the what is something cool, new or interesting that you've learned, discovered, created, read about. Anything doesn't have to be coding related, it can be anything. What do you got?
Speaker 2:One thing that I learned recently. I was visiting some friends in Milwaukee and they made this like rice dish called kanji, and it's like a Kind of like a rice oatmeal, so it's like a breakfasty dish and I learned how to make that and it's basically it's six parts. Like normally when you're making rice it's like two parts water to one part rice. This is six parts water to one part rice gets kind of creamy and it's kind of a savory dish. You put like different things as toppings on top of it, done like a poached egg and shaved scallions and stuff. That's kind of the newest sort of recipe that I've learned how to make and I enjoy it because it's like kind of easy and forgiving. It's kind of hard to overcook it. If you're overcooking it, you just add water and it'll get pretty good. So that's kind of like the newest ish thing that I've learned. That's like a big one.
Speaker 1:This was a lot of fun. I like doing the crossovers. It's a lot of fun, and I'm glad I got you on my show at least a condensed version because I wanted to pick your brain a little bit.
Speaker 2:So thanks for the invite and setting it all up you've been listening to the Ruby on Rails podcast and Code and the coding coders who code it. Thanks to Paul, our wonderful editor over at peach tree sound, for making a sound like Professionals and thank you for listening. You're a gem.
Speaker 1:See you later.
