Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell. I'm your host and today I have the privilege of interviewing Richard Schneeman. Richard works at Heroku. He works on Ruby stuff at Heroku. He also helps run keep Ruby weird. It's a Ruby conference. He created code triage and he also created docs doctor. He's very active in the open source world. And in general he's just a smart and entertaining person. So I really enjoyed interviewing him. Make sure you go and follow him on Twitter at ACHNEMS. That's SCHNEMS. ACHNEMS. And let him know how much you are enjoying his interview on Developer Tea. With just a massive barrage of tweets. While you're listening to this episode, why not go ahead and open the app they are listening to the episode in. And if you haven't already subscribed, just click subscribe. I guess you're probably going to touch subscribe. And what that'll do is it'll allow you to automatically have some kind of alert or notification whenever in the next episode of Developer Tea is. And that happens to be most likely the second part of the interview with Richard Schneeman. So if you like this particular interview, then you probably want to listen to the second one. Click subscribe and you won't miss out on the second one. Now I'm going to introduce Richard Schneeman. Thanks for coming on the show Richard. Hey, thanks for having me. I'm really excited to talk to you because I've watched quite a few of your talks online. And it's interesting because a lot of what you've talked about has been like kind of crossbreed talks between your experience at Georgia Tech. You often will mention that in sort of the beginning of your talk, you'll talk about how you're at Georgia Tech and then you'll relate an experience or like a practice from another field with something in Ruby Land. And I've always thought that was really interesting. One of them was about like a refrigerator and testing and how can you tell me a little bit about that. Yeah, so I used to make I used to make refrigerators for general electric. If you're like a blast. Yeah, if you have a general electric refrigerator right now and there's something wrong with it, it's totally my fault. But yeah, we had this really complicated like spreadsheet to try and predict how energy efficient our refrigerators were going to be. And like we like it. Yeah, that was kind of my first introduction into programming from a mechanical engineer standpoint. It was not pretty. At the end of the day, we had to figure out and verify like, hey, are all of these equations correct? Did we model everything correctly? And they turned around and they would actually load up a refrigerator full of full of stuff and put thermocouples in it and then put it in a room with a very controlled temperature and they would actually test it and run it through its paces. And so sometimes whenever I'm coding, I'm like, man, I just can't test this thing or I can't figure out how to do this thing. I'm like, let's put it in a hot room. Like let's actually run it as if it was in production. You know, how could we do that? And from from from that experience, I've had a couple of a couple of opportunities. I did the I work at Heroku. I maintain the Heroku Ruby build pack. And when I started, it wasn't tested at all. And one of the. Yeah, no, it's like, it's like, hey, change this change this thing modify this thing and deploy it. And it's going to affect millions of applications. And I'm like, I'm just, no tests. Make sure you don't make sure you don't like like have any typos. I mean, granted, we would still spin up an app and like how we would test it is manually, like we would just we would deploy. And then we would just use the app with this build pack and make sure the app work. But then you kind of run into all these edge cases and like edge cases on edge cases like rails to Ruby 187. This kind of stuff. And yeah, so the solution to that was actually I wrote a little framework that. And then it helps you spin up Heroku apps and then push code to them and then verify that that, you know, the deploys worked and you can do some other things like run Heroku run bash and. Yeah, it's been incredibly helpful. Yeah, without tests that support ticket driven development, which sounds awful. So, so one of the really nice things is sometimes we get we get these customers who were just like insane, like, you know, their hairs on fire, they're just like, you know, so upset and they're just like, hey, it's got to be your, you know, the Heroku is like totally messed me up. It was working now it's not working. And like if we only get one of those tickets, I can guarantee you it's not Heroku like most well 99.9% of the time it's like, oh, you know, hey, look, you put a single equal and instead of a double equal here or something, you know, like that. And then they send you a check for your time. Well, they hopefully stay on the platform. Yeah, yeah. I use Heroku literally every day. So it's, I mean, what you've, I'm sure the value that you've added by putting tests in that build pack or the multiple build packs, I guess, infinite number of them is untold from me personally even I'm sure so that's awesome. So you went from building refrigerators to working at Heroku somewhere in the middle, you worked somewhere else that I believe you said you worked at goa right. Yeah, I worked at goa for about two years, we got, we got acquired by Facebook and that was kind of the death of goa and apparently, yeah, sad day, sad day. Yeah, apparently Facebook doesn't hire a ton of Ruby developers surprisingly enough. Yeah, supposedly everything is still kind of on a PHP core over there. Yeah, yeah, well, they say they're doing they actually have their own VM. It's a hip, hip hop VM. It's like, oh, that's right. PHP interpreted into a C++, I think, which is kind of crazy. Yeah, yeah, super fast. I'm sure. Yeah, and all of the joys of the PHP interface. So I, I, I, I, I, I, I, I've never actually, I've modified some WordPress plugins and whatnot. So I can't really, I can't really talk. And it is PHP is a great language. It's a lot of people, a lot of people use it. It is by far way more popular than than Ruby in terms of the number of users. Oh, sure. Yeah. Yeah. And also we've, we recently, Haruku in the, in the past year, maybe two years, I, I, I'm not a time. I have a really hard time keeping track of time. Like, it's been support for PHP, right? Yeah, we have support for PHP. And we have a dedicated maintainer for it. And that's actually why I know so much about like hip hop VM and, you know, all of these things is like, is like talking to him. And I have such a, a newfound respect for, you know, for PHP and like, everything that it, it can do. And just, you know, kind of out of the box. It just, so it's like, it's blazingly fast. And you, you know, you can just like, you connect your database right into your view and just like go for it, you know. Yeah. Well, it's interesting because I, I actually have a love hate relationship with PHP, a good portion of my job every day. I'm writing PHP. Oh, wow. I'm primarily WordPress stuff, you know, it's agency style work. And so our bread and butter has been WordPress sites. And I worked with Jeffrey Wei, who does the Laravel, Lara casts basically. But he worked with me at Tuts Plus, which I write for Tuts Plus on occasion. And he's actually in Chattanooga. So that's where I still have a little bit of a bit more respect for PHP than the average like Ruby developer might would. Yeah. Yeah. I, one of my favorite, I guess, I guess it's a tradition every time I've seen Charlie Somerville at Ruby comp. He always wears a PHP shirt. Nice. That's great. Yeah, totally. And it speaks to the, to the, the humor of the Ruby community anyway. Yeah. Yes. Absolutely. So let's switch gears. You work on quite a few open source efforts, not just projects, but I wouldn't call them like just it's not just like a thing on GitHub that people can go and, you know, contribute a poor quest, you know, or whatever. You actually have these other kind of conceptual open source efforts, right? So you have code triage and docs doctor, both, both of which are kind of encouraging the, the average developer or the, even the beginner developer to get involved with committing, you know, with code triage being, you know, fixing issues bug fixes and then docs doctor being documentation. Yeah. So I've done a lot with open source and recently got rails commit access. So if you need something urgent to master, let me know. Awesome. I'm super excited about that. And, and one of the things that I, I thought about when I was, when I was joining Haroku is they said, you know, OK, we highly encourage you to use the platform and we, you know, we want you to run your own apps. So you get to, you know, dog food it and, and like real apps, not just like a test app or whatever. And I was like, oh, what, you know, what could I build that would, you know, it basically if I have free Haroku credits, which I kind of kind of do for this kind of stuff, it's like, you know, what could I give to the community or build for the community that would, would make some sort of a lasting impact. And, and so yeah, the, the services kind of program programmers, so to speak it, if you're interested in getting involved in like open source or you want to be a better programmer, you can sign up for the first one I made was, was code triage.com and it will, it will send you the one open issue per project per day. And we actually added a little bit of rate limiting there. So it's not quite as if you want to take a break, it's fine. It'll kind of, it'll be like, oh, you haven't opened up your email for like three days will like, we'll chill out for a little bit. That's funny. But yeah, and that's kind of a lot of people were like, hey, can I tell it when to send me an email and like, I want to tell it when to send me an email. And then I was like, okay, I hear what you're saying, but I think I have a better idea. And then I implemented that and then everybody's like, they're pretty happy with that. Yeah. Yeah. But yeah, so, so I guess I also want to want to talk about recently, I've, I've heard a lot of people, I guess, just, just talking out loud or on Reddit or hacker news or wherever they're hanging out, wherever I'm hanging out, I guess otherwise I wouldn't be reading it. And a lot of them are saying things like, hey, you know, shouldn't Haroku or like, you know, GitHub or whoever, like just, you know, throw down a ton of money on supporting, you know, Ruby or supporting Rails. And it's like, well, number one, they kind of already do. Like, Haroku sponsors three Matt Snowbu and Kowichi for Ruby. And then I mean, I'm not full time Rails, but I, you know, they pay my salary and let me work on it, which is pretty nice. But like, you know, it's the cost benefit there. If one company stands to gain a tremendous amount by something being fast or performant or, you know, these new features kind of taking a look at V8 in Google, like if V8 is fast, then, you know, a lot more people will use Chrome and then that will gain significant market share for them. And with a lot of other open source projects, it's not clearly such a win. And it makes a lot more sense to actually spread out the instead of just one company saying like, you know, here you go, here's, you know, massive paychecks to whoever. It may hope for the best at that point, even exactly, exactly. It makes a lot more sense for the programmers who are actually running into bugs or saying, oh, I really wish this happen this existed or I wish it worked this way. I wish there was a better error message. I wish it was faster. So, if the people who are actually using it day to day, get in there and make it better. And so, so, so I think this mantra of like, you know, GitHub should totally do something about this or, you know, insert company name here is just sort of like some people just just taking kind of a backseat and being like, oh, it's too hard for me. I don't have time for it. And just there's all these excuses to getting involved in open source. So one of the things I'm advocating I recently is just telling your boss like, OK, we're not deploying on Friday or like the second half of the day on Friday. And when he's like, why it's like, oh, because I don't want the entire team to be here on, you know, till Sunday Saturday morning, like debugging whatever, you know, what I exactly, like we actually went something that has been implemented at Heroku since I started is for the build packs is no non critical deploy is on Friday. Like that. That's good. Well, and for us, it's like, you might be like, oh, well, you, your automated test should catch that and these other things should catch that. And it's like, that is true. I guarantee you we have every, like permutation of every edge case of a customer running it on our platform. Like we have anyway. So yes. So this is, this is something like we actually do. And then while you're just sitting there being like, oh, I really wanted deploy. I really wanted deploy. It's like, oh, hey, guess what? I'm going to go fix this, this bug that I ran into in rails or I'm going to go fix it in rack or I'm going to check out and do some performance profiling. And so, so I've been calling this this Monday Friday and like I'm like, we need some awesome designers or something to make like a Monday Friday, like website and then like print out like business cards and you can hand it to your boss and be like, hey, it's an official thing and. Or even like asking what like when you're getting interviewed and being like, hey, do you do anything like this? Is this something that you, is this something that you support and like putting, putting these types of contributions on the table? You know, a lot of developers are just bombarded by like recruiter requests, you know, hey, follow me on LinkedIn or whatever. And, and the, you know, companies are actively being like, okay, well besides free sodas, like what can you give you that would like actually make you happy? And it's like, oh, hey, you know, like good, we good will and working on a community project and actually getting smarter at the same time and. And it's not like you're just throwing away like I hate the term giving back to open source. Yeah, but it's like for me, it's totally giving forward. I am so insanely selfish with all of my contributions. I am like future Richard does like never wants to see this air ever again. Yeah, absolutely. Well, and I mean, I think a lot of people, they don't understand that this isn't just you going and fixing a bug like you normally would in your own bad code. Like that's not what this is. This is like going and putting your opinion in something and like making that become usually it's something that like you don't like the way that it works and it needs to work in a different way that is better. You know, it may not necessarily be like this is you know, parsing something incorrectly. I'm just going to go fix it, which there that stuff exists too. But a lot of the time, especially with something that's maturing, it's it's more like opinion development, right? Yeah, for sure. And like for me, it was such a drastic change in the level of involvement and care, especially with like with rails, like you submitted the poll, you submit a poll request for rails and people are actually looking at your code. Like there's an actual code review process where you know some other places like I've with some other people I've worked with it's kind of just been like a rubber stamping and like you get you get to develop different code styles. And learn how to interact with people and some of this is actually it's not terribly easy and it's not terribly doesn't isn't just like the most common sense thing and that's and to bring it all back. That's actually why I ended up writing code triage because I had a lot of people say like, hey, I want to get involved with rails and I'm like. And if you talk to at the time, I wasn't a contributor and if you talk to the contributors, they're like, oh, hey, we have a ton of open issues. No one is reading them. No one is looking at poll requests. Nobody's doing anything. You know, it's basically just for for people and interesting like if you could do this, it'd be hugely helpful to be like, yeah, and nobody would because it's too daunting of a task and this is a really small commitment where you're just like, I'm going to get an email like maybe I'll open it. Yeah, I won't and for the first why why first I had the idea and I started using my own product like the first maybe a couple weeks, I just like lurked, I would just like read it and like look at how people were talking and I'd be like, okay, you know, I kind of got this. Then after a while, somebody opened up an issue and I was like, oh, you know what, I know one of the other contributors is going to tell you this like, you know, I forget what I forget what it was, but it's like. Like, you know, rails doesn't take feature suggestions if you want to feature suggestion in rails, you have to issue a poll request. So just like letting people know this, this type of information, it's incredibly valuable and then and then a step above and beyond that is going and actually making those contributions and that can be really challenging and really terrifying. But for that, I recommend people start with documentation like it's hugely hugely valuable. Like how many times have you like found rails API or something and you're reading through the documentation and like you're like, you just assume the documentation is right. And so you kind of like, I don't know copy and paste that little snippet or something and then like 20 minutes of debugging later, you're like, oh, that code was wrong. Like, yeah, like it. I did that today. Like it wasn't it wasn't on rails, but it was another project, but the doc, the doctor just like five months behind or something. It's awful. And so you're sitting there like, well, this is supposed to be right. You know, like you trust the documentation. Exactly. And that's one of those things where it really is, even if we pay to dedicated docs writer, like it with documentation is not going to be nearly like even half as good as people. It's like if you hit a bug, if the documentation was confusing, like, it's a really weird mindset, but like you can go out there and it's it's malleable. You can change it. You can you can help everyone, which is such a such a powerful concept to me. Yeah, most definitely. I ran into an interesting thing and before I talk about it, I want to take a quick sponsor break, speaking of learning. And we'll do that real quick. What if you could learn to build anything in one month? Well, with one month calm, you can. One month students learn to code by building real rails and iOS apps. You know how I feel about education and learning. And let me tell you something. One month is a fantastic place to start. And that's because one month provides focused, accelerated learning courses entirely online, which means you don't have to ask your boss to give you off days to go learn. For example, in the one month rails course, you'll learn Ruby and how to build applications with the rails framework. You learn how to write HTML and CSS and how to use Git and the command line. You learn about s3 from Amazon Web Services. You learn how to add user registration support to your application and launch it on Heroku. In addition, one month has a bunch of other classes like HTML and iOS programming. And the best part is, if you get stuck, there's a real person ready to guide you while you learn. That's a real person, not an automated machine. So go now to one month calm front slash Developer Tea. It's a special URL for Developer Tealisteners that gives you a one time 25% off discount enrollment is typically $99. But if you use one month.com front slash Developer Tea, you'll get 25% off. That means that you'll be paying less than $3 a day and learning how to build a real rails application in just one month. One month. So I actually signed up for docs doctor. I watch watch your talk and signed up and I got and there was an interesting situation where I started documenting something because I had never done it before. Actually is the first time that I had, you know, tried to commit documentation. And as it turns out, that thing was marked as no doc. Which I feel like is probably a pretty common scenario and well, you know, almost any project because there's all these private methods that are being called that aren't intended to be public. And I actually made the point and I'd love to know what you think about this in a comment thread. I made the point that even private methods should be documented. Right. Because there's people inside of the rails team that need to know what those methods do. Yeah. Oh, yeah. I totally agree. And so I, I, I wholeheartedly agree and I will also say it's really difficult just because it like this is actually a legacy problem with rails. There, I have totally documented no doc classes. Like I did a bunch of work in an active record class that hadn't been touched for months and it was just all of the use cases were really, really, really confusing for it. And so the way I learned it was by going through the tests and then writing documentation for it. So I knew so it made sense to me like once I knew it well enough, I could write documentation for it. And they actually did accept that documentation, but that was mostly because it was nowhere near public facing. It was like very, very obvious. You should never use it. Right. But rails. So rails for if you don't know rails has this thing where you can just put a comment and then say no doc and rails is using this instead of just saying, hey, this doesn't have documentation. That is how rails designates and says this is not part of the public API. We basically we can change this and we don't have to notify you if you're if you're using this in rails for dot 4.2.0 like it might change in 4.2.1 and we're not going to warn you. Right. Or the method may just not even be there anymore. Yeah, exactly. Exactly. So I mean, I do agree that we need some kind of a way of like standardizing and telling people that, but like it's it's kind of a lot of people don't even know that. Like they just use any method and they're like, oh, no, doc or like they don't even. But, but you know, from a from documentation standpoint, it is good to be able to go back and say like, hey, you can't be too upset. Yeah, I mean, there it would be nice if there's a better way internally. We've talked a little bit. I've actually expressed some interest in moving over to away from our doc into to I think either like yard, I love yard internals, docs, doctor uses yard internals. And I guess I don't know if we mentioned, but what what docs doctor does it. You sign up for something like rails or any kind of a Ruby project. And it will run. It will parse the documentation and find methods that have missing documentation. It's like, hey, this method doesn't have any documentation. Maybe you should write some or alternatively if you don't feel comfortable doing that yet, it'll just send you documented methods and you're like, oh, cool. I didn't know rails had this method. And like you get to read some documentation. It's kind of a fun little teaching. It's a method of learning really. Yeah, yeah, absolutely. You know, just kind of bite-sized chunks. That's that's the one consistent theme across all of these. Yeah, I agree. I don't know what to call them. They're their projects. They're their services. It's like open source services. Code bases, I guess, is a yeah. Yeah. So it's interesting that you mentioned that. I didn't mean to interrupt you there if you were going going to say something else about docs doctor. Oh, and I did I did want to say like the did driving motivation behind writing docs doctor was I mentioned I work with a whole bunch of different people in different languages. And they love their language like more than any other language in the world. So it's really interesting talking with these people. And at one point in time, I was talking with our main Python guy and he was like, okay, why I was like, why is Python the best language in the world? And he's like the documentation. And I was like, okay, fine. Like, we're Ruby. We can we can beat this. We can do this. Like, let's what can we do to make the documentation better and then and then docs doctor. Thanks so much for listening to Developer Tea and thank you to Richard for coming on the show. The next part of the interview will be available in the next episode of Developer Tea. If you're enjoying the show, make sure you follow me on Twitter at at Developer Tea. And you can always reach out to me at developertea@gmail.com. If you're enjoying the show, make sure you leave a review and iTunes or if you want to support the show go to DeveloperTea.com front slash donate. Of course, you can always find show notes at DeveloperTea.com. Thanks for listening to the show and until next time, enjoy your tea.