Hello everyone and welcome to Developer Tea. My name is Jonathan Cutrell. I'm your host and today I'm speaking with Ben Orenstein. Ben is a Rails developer and an educator and quite a few other things, a podcast host, a conference speaker. The list goes on and on. He's just a really smart guy. He lives up in Boston and he works at Thoughtbot. Thoughtbot has been doing stuff, especially in the Rails community for a long time. They are responsible for things like the factory girl, Jim, which I use literally every day. Just a brilliant person and a joy to speak with. We had the most technical difficulties that I've ever had on this podcast and getting started up on the call and Ben was just such a kind and inviting person. He cares so much about his craft and about the things that he does. I believe that you're going to get a lot out of this interview. The interview is split up into two parts, like you're probably used to if you are a regular listener of this show. You will be able to hear the second part in the next episode of Developer Tea. But for now, I'm going to welcome Ben to the show. Thanks for listening. Hi Ben, welcome to the show. Hi, thanks very much for having me. It's great to be here. Virtually that is. Yeah, I'm really excited to have you because you've done so many things with your career, especially in the last, especially most recently with Upcase, which we'll talk about in a little while. Also with giant robots smashing into other giant robots, which is a podcast that I've listened to since podcast for first cool. That's pretty regular still, right? It's a weekly thing. It's done about 120 something of them now. We've been fairly regular. I wouldn't have guessed it would have gone on this long, but I still haven't had a great time eating it. People seem to like it, so it continues. Yeah, no kidding. It's pretty incredible because I think that first wave, I was just talking to a friend of mine the other day. He was saying, why do you think podcasts have become more popular recently and you're a podcaster? So this is relevant, right? And I said, partially because of cereal or whatever. But I think also because it's kind of like when live journal came out forever ago. And it was like the blog thing was sort of popular, but it was mostly among geeky people who understood it. And then it went downhill and then my space came out. And then everybody had a publishing box when Facebook came out. And I feel like this is like the early days of Facebook for podcasting. Yeah, I think so. I've heard it referred to as like the podcast Renaissance. And I think that's obviously that tends to be a positive. I think that progress is positive. Even the downslide to my space as you say. I think it's nice when more and more people can create things and put them out there. I'm a fan of that. Yeah, even if I don't, I'm not going to personally consume all of it, but I think it's good that a platform is somewhat easy to come by. I think that's positive. Yeah, I agree. And that's true for so many things. But so I want to shift gears here because this isn't really a podcast about podcasting. But I think it's I think it's relevant just because of the fact that you do giant giant robots over there. So in any case, most as of late, really, I've been seeing your work kind of heading in this direction of being kind of the ringleader of education about them for anybody who doesn't know about them. Number one, I think you should. And I think Ben would agree. But them as a text editor that was created. I guess was a 1991. So it's been around for a while. I mean, that would be them. But then built the interest of the I improved, which was I think originally, I had 70s. So the core idea is behind them are, you know, 30 or 40 years old. Yeah, that's older than me. I don't know about you, but. Yeah. So I'm older than some of those numbers. Cool. All right. Well, in any case, yeah, well, I'm older than the first, then improved at least. But I think that a lot of people don't really, how do I put this? They don't understand the importance of their daily editor. Like, you know, because I think a lot of us are kind of trained to just, oh, just open a text editor. Right. I think in my early web days, I was told, you know, the most bare bones text editor is all you really need to, I don't know, learn HTML or whatever. But I think that them is for me, at least, it's changing the way that I think about programming. And I'd like to know. What you see as kind of the importance of that daily editor relationship with the programmer. I think it's actually, I think it's incredibly important. I think if you want to be, if you want to be a top level craft person of any kind, you really need to care about your tools quite a bit. So, I've actually spent a lot of time over the years customizing my environment. And that's not just VIM, that's also my shell. That's writing small tools that help me get stuff done. That's writing functions that I call all the time. And I think it's actually kind of my part of my secret sauce of speed with VIM is the fact that I've actually customized it so heavily to my own usage. And I'm actually right now in Denver at the touring school of software and design. And I am impressing, trying to impress upon the students here, how important it is to have an awesome text editor that you really like and then have customized highly for your own workflow. Even when you're sort of new to things, I think it's okay to start in the very beginning with something simpler but quickly move on to a very powerful and full featured text editor. So, if you're a good craft person, you have to care about your tools and really know them kind of upside down, right? Like inside out, just know your tools completely, but also have your tools very well customized to the specific work that you do. Absolutely. It's customized to your own workflow and the things that are unique about you. So one thing that I'm a big fan of is I aliest a lot of my typos. So there are certain commands that I just can't get in my brain to type correctly. And so I have like all aliest the typo diversion of it. Just sort of say, you know what, I'm just going to type this incorrectly some from time to time. I don't want to interrupt my flow. Right, which wouldn't be necessarily applicable to somebody else who has some kind of different muscle memory than you. Exactly. Yeah. I mean, I think your dot file should be like your configuration files for your editor and your other tools should be a personal expressions of what you want and care about and even your mistakes. Yeah, and you actually recently said or semi recently you said something about how if you're first starting out with them, you need to start with basically a blank config file, right? More or less blank. I linked to so I have a blog post called your first of MRC should be nearly empty. Right. And I linked to a minimal MRC because there's a couple of settings that you pretty much have to to set for various reasons, but there's really only three or four that I consider essential and the rest I think you should grow over time. Very interesting. Yeah. It's interesting that you mentioned that because I recently picked up them in our office. There's a few people at whiteboard that have picked up them as well. And we're going through up case series and a few other things. And some of the stuff that we found immediately valuable was the rails bindings that you guys actually put out. So and that was those are things that we pretty much immediately put into our their MRCs. So I feel like, you know, for us, it was a balance of saying, OK, let's hold back on some of the plugins because you don't need like a bundle or if you don't even know what you're bundling. So I think that, you know, it's interesting because I think a lot of people are coming to this completely clueless about what the core functions of them actually are. And so they'll come in and drop a bunch of plugins and then they encounter them in another situation like, I don't know, on a server or something that they haven't set up. And it's like very difficult to use because they've gotten used to the not core them. Yeah, so I've sort of argued against things like Janice for a little while. And Janice is basically a pre configured them. It's a big VMRC with a bunch of plugins sort of pre selected for you. And I understand the counter argument like why you would want something like that? It's like, oh, just give me something that's already set up. And I don't need to make decisions early on, but you have that downside that you mentioned there, which is you don't really know what's what stock and what what's added. And I believe like that your your learning process of learning the editor should start with the basic stuff with almost nothing added. And then you slowly add plugins over time so that you can sort of master them and be aware of the changes that they're bringing in. And again, it's about that customization. It's about personalization where if you start with someone else's giant pack of plugins and VMRC customizations, you are sort of by definition not getting that customized environment. You're getting one recommended environment, but it's not the same as if you had grown it from scratch for yourself. Yeah, it's kind of like getting somebody else's dot files, right, which is literally the case here because it's a dot VMRC, but it's other dot files as well. I've tried like pulling down, you know, and some of this is valuable. So I don't think you know you throw the baby out with the bath water necessarily, but you're like pulling down like the entire what's I don't even know how to pronounce his name, but Matthias Bennett bindings, I think is how you say it. He's got like a huge thing of dot files that he shares on GitHub and it includes stuff like OS 10 defaults and like, for instance, it makes your the automatic emptying strategy for the for the trash can in OS 10 and makes it like hyper secure. So, you know, it takes forever and I find myself constantly like undoing that with like some crazy key binding before I empty my trash and it's like, why did I do that? You know, and it's because somebody said, hey, here's some good things that you should do. And then they weren't the things that I really actually wanted to do. Yeah, and to be clear, I think taking ideas from other people's dot files is great. I think you should absolutely steal liberally from the things that other people are doing, but you should do them piece by piece. Right. And you should you should pick and choose the things that you actually want that makes sense to you. Sure. And my dot files originally cribbed from Ryan Bates. I stole some of his stuff, but I went through and deleted a bunch of things and tried to make it more my own and now they don't even look at all like they use when I first forked them from him years and years and years ago. Right. Yeah, that's interesting. But I'm constantly stealing from other thought butters and other random people that I find so it's still happening. Your dot file should be changing all the time. Yeah, that's interesting. I think a lot of people don't even think about their dot files most of the time. And by the way, like getting started thing is if you're at step zero, which is the configuration for your tools is not in a repo that you can clone and have on any machine, it should be. That's the first thing you should get going because it's that was the biggest change for me was when I when I had my dot files on GitHub and I knew that they that my changes would be sort of I could sink them across all my machines. I still think I'm more aggressive about customizing things because I knew that this work wouldn't really have to be repeated and I was just going to this would be my environment forever on every machine that I went to. Thanks so much again to Ben for being on the show. Of course, you can get the second part of this interview in the next episode of Developer Tea. Thank you for listening to Developer Tea today. I know that you have a lot of things that you can do with your day, but you're choosing to spend some of some of your minutes with me and I sincerely appreciate it. If you are enjoying the show, let me know. You can reach out to me on Twitter at at Developer Teaor you can email me at developertea@gmail.com. Of course, you can give some suggestions for the show while you're there. Let me know what you think if you have any ideas for future episodes and any questions that you'd like for me to answer. If you haven't left a review yet, jump over to iTunes and just leave a review and a rating. The reason why I ask you to do this is because it's the best way to help other developers just like you find this show. If you think that this is valuable, it costs you nothing to help them find the show as well. It just makes the world a better place when we share with each other and hopefully you find the show valuable enough to share. Make sure you go and check out what Ben has been up to online. You can follow him on Twitter at at rook with r00k on Twitter again at rook. Then of course, you need to check out up case. I actually subscribe to up case. They aren't even a sponsor of this show. They're just a fantastic resource for developers, especially Rails developers and iOS developers. People who are just learning to write good clean code. Thank you for listening to Developer Tea and as always, enjoy your tea.