Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. 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. And he created CodeTriage and he also created DocsDoctor. So 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 atschneems. That's S-C-H-N-E-E-M-S. Atschneems. 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 that you're 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 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... between... between... between... between... At Georgia Tech, you often will mention that in sort of the beginning of your talk, you'll talk about how you were 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... Sounds 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 spreadsheet to try and predict how energy efficient our refrigerators were going to be. And 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 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. Let's actually run it as if it was in production. How could we do that? And from that experience, I've had a couple of opportunities. I work at Heroku. I maintain the Heroku, the Ruby build pack. And when I started, it wasn't tested at all. Oh, wow. Yeah, no. It's like, hey, change this thing, modify this thing and deploy it and it's going to affect millions of applications. No tests. Make sure you don't have any typos. Oh, man. I mean, granted, we would still spin up an app and how we would test it is manually. We would deploy. So you run 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 2, Ruby 1.8.7, this kind of stuff. And yeah, so the solution to that was actually, I wrote a little framework that helps you spin up Heroku apps and then push code to them and then verify that the deploys worked and you can do some work. And then you can do some other things like run Heroku, run Bash. And yeah, it's been incredibly helpful. Yeah, without tests, that's a support ticket driven development, which sounds awful. Well, I mean, so one of the really nice things is sometimes we get these customers who are just like insane, like their hair's on fire. They're just like so upset and they're just like, hey, it's got to be your, Heroku is like totally messed me up. Like 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, but. Yeah. And then they send you a check for your time. Well, they hopefully stay on the platform. Yeah, 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 for 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 at, I believe you said you worked at Gowalla, right? Yeah. I worked at Gowalla for about two years ish. We got, we got acquired by Facebook and that was kind of the death of Gowalla. 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. That's right. PHP interpreted into a C plus plus, I think, which is, is kind of crazy. Yeah. Yeah. Super fast. I'm sure. Yeah. And all of the joys of the PHP interface. No, I, I, I, I, I, I, I've never actually, I, 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, and also we've, we recently Heroku 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, you have 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, it's like talk, 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 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. Uh, primarily WordPress stuff, you know, uh, it's agency style work. And so our bread and butter has been WordPress sites. And, uh, uh, I worked with Jeffrey way, uh, who does, uh, the Laravel, Lara casts basically. Um, but he worked with me at, um, Tuts plus, which I write, for Tuts plus on occasion. And, uh, he's actually in Chattanooga. So that's where I, I still have a little bit of a bit more respect for PHP than the average, like Ruby developer might would. Yeah. Yeah. I, I, um, one of my favorites, uh, I guess, I guess it's a tradition. Every time I've seen Charlie Somerville at, um, Ruby comp, he always wears a PHP shirt. Nice. That's great. Yeah, totally. And it speaks to the, uh, to the, the humor of the Ruby community anyway. Yeah. Yes, absolutely. So let's switch gears. You, you work on, uh, quite a few open source efforts. Um, not just projects, but I would, I wouldn't call them like, it's not just like a thing on GitHub that people can go and, you know, uh, contribute a pull request, you know, or whatever. You actually have these other kind of conceptual, uh, open source efforts, right? So you have code triage, uh, and docs doctor, both, both of which are kind of encouraging the, uh, the average developer or the, even the beginner developer to get involved with committing, um, you know, code triage being, you know, fixing issues, bug fixes, and then docs doctor being, uh, documentation. Uh, yeah. So, um, I've, I've done a lot with open, open source and, uh, recently got the rails, uh, can commit access. So if you need something merged into master, let me know. Awesome. I'm super excited about that. And, and, uh, one of the things that I, I thought about when I was, when I was joining Heroku is they said, um, you know, okay, we highly encourage you to use the platform and we, you know, we want you to run your own app. 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, um, you know, it basically, if I have free Heroku credits, which I kind of, kind of do for, 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. Um, and, uh, and so, yeah, the, the, the services kind of program programmers, so to speak, it, it, if you're interested in getting involved in like open source, um, or you want to be a better programmer, you can sign up for, uh, the first one I made was, was code triage.com and it will, um, it will send you the one open issue per project per, per day. Um, and we actually added a little bit of rate limiting there. So it's not quite as, if you, 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. We'll like, we'll chill out for a little bit. Um, that's funny. But, uh, yeah, I, I, and, 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, 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. Um, but, uh, yeah. So, so I guess I also want to, I 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, or wherever they're hanging out, wherever I'm hanging out. I guess, otherwise I wouldn't be reading it. And, um, a lot of them are saying things like, Hey, you know, shouldn't Heroku or like, you know, get hub or whoever, like just, you know, throw down a ton of money on, uh, supporting, you know, Ruby or supporting rails. And it's like, well, number one, they kind of already do like Heroku sponsors three, uh, Matt's Nobu and Koichi for Ruby. Uh, and, and then, I mean, I'm not full-time rails, but I, you know, if they pay my salary and let me work on it, which is pretty nice. Uh, but, um, like, you know, it's, uh, the cost benefit there. If, if, if one company, um, stands to gain a tremendous amount by something being fast or performant, or, you know, these new features kind of, um, taking a look at, uh, at V8 and Google, like if, if V8 is fast, then, you know, a lot more people will use Chrome and then, uh, that will gain significant market share for them. And with a lot of other open source projects, it's not clearly such a win. Um, and it, 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, um, it may hope for the best at that point. Even exactly, exactly. Um, it makes a lot more sense for the programmers who are actually running into bugs, or saying, Oh, I really wish this hap, this existed, or I wish it worked this way. I wish there was a better error message. I wish it was faster. Uh, if, if though the people who are actually using it day to day, get in there and, uh, and make it better. And so, so, so I think this mantra of like, Oh, you know, get hubs should totally do something about this or, 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. It's like, I don't have a time for it. Uh, and just, there's all these excuses to getting involved in open source. Um, so one of the things I'm, I'm advocating, I, I, I recently is just telling your boss, like, okay, we're not deploying on Friday or, or like the second half of the day on Friday. Uh, 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, whatever. Yeah, exactly. Like we actually went, um, something that has been implemented at Heroku since I started is it for the build packs is no non-critical deploys on Friday. I like that. That's good. Uh, well, and, and for us, it's like, you might be like, Oh, well you should, 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, we actually do. And then, uh, while you're just sitting there being like, Oh, I really want to deploy. I really want to 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, um, performance profiling. And, uh, so, so I've, I've been calling this, uh, this fun day Friday. And like, I, I'm like, we, we need some awesome designers or something. To make like a fun day 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, um, or, 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. Um, you know, a lot of developers are just bombarded by like recruiter requests, you know, Hey, follow me on LinkedIn. Or, or whatever. And, um, and the, the, you know, companies are actively being like, okay, well besides free sodas, like what can we give you that would like actually make you happy? And it's like, Oh, Hey, you know, like good, we goodwill, uh, 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, I hate the term giving back to open. Source. Yep. Uh, 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, uh, 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, um, this is, you know, parsing something incorrectly. I'm just going to go fix it, which that stuff exists too. But a lot of the time, uh, especially with something that's maturing, uh, it's, it's more like opinion development, right? Yeah, for sure. And, um, like for me, it was such a drastic change in, um, the level of involvement and care, especially with like, with rails, like you submitted the pull, you submit a pull request to 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, uh, and, and learn how to interact with people. And, 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. Um, because I had a lot of people say like, Hey, I want to get involved with rails. And I'm like, uh, 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 pull requests. Nobody's doing anything. You know, it's basically just for, for, for people. And like, if you could do this, it'd be hugely helpful. And I'll be like, uh, yeah. And nobody would, because it's too daunting of a task. And, and this, it's a really small commitment where you're just like, I'm going to get an email. Like maybe I'll open it. Maybe I won't. Uh, and for the first, why, why first I had the idea and I started using my own product, like the first, maybe couple of weeks, I just like lurked. I would just like read it and like look at how people, we're talking. And I'd be like, Oh, okay. You know, I kind of got this. And then, then after a while, somebody opened up a, 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, um, like, you know, rails doesn't take, uh, feature suggestions. If you want a feature suggestion in rails, you have to issue a, a pull request. Uh, so just like letting people know this, this type of information, it's incredibly valuable. And then, and then, the step above and beyond that is going and actually making those contributions. And that can be really challenging and really terrifying. Uh, but, but for, for that, I, I recommend, uh, 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, you, 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 10, like 20 minutes of debugging later, you're like, Oh, that code was wrong. Like, like it, well, I did that today. Like it wasn't, it wasn't on rails, but it was another project. But the doc, the docs are just like five months behind or something. It's awful. And, and so you're just sitting there like, well, this is supposed to be right. You know, like you, you trust the documentation. Exactly. And, and that's one of those things where it really is, even if we, if we paid a dedicated docs writer, like it would, the 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, I ran into an interesting thing. And before I talk about it, I want to take a quick sponsor break. Speaking of, of learning, and we'll do that real quick. What if you could learn to build anything in one month? Well, with one month.com, 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'll learn how to write HTML and CSS and how to use get and the command line. You'll learn about S3 from Amazon web services. You'll 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.com front slash developer, T. Now it's a special URL for developer T listeners that gives you a one time 25% off discount. Enrollment is typically $99. But if you use one month.com front slash developer T, 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.com front slash developer T. So I actually signed up for development. Doc's doctor. I watch, watch your talk and signed up and I got in. There was an interesting situation where I started documenting something because I had never done it before. Actually, the first time that I had, you know, tried to commit documentation. And as it turns out, that thing was marked as no doc and which I feel like is probably a pretty common scenario in rail. 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 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, 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 rail. So rails for, if, 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, um, this is not part of the public API. What 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, uh, four dot two dot. Oh, like it might change in four dot two dot one and we're not going to warn you. Right. Or the method may just not even be there anymore. Yeah, exactly. Exactly. Um, 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, um, 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. Like, yeah. Um, I mean, there, it would be nice if there's a better way. Uh, internally we've talked a little bit. Um, I've actually expressed some interest in moving over to, uh, away from, um, our doc and, uh, to, uh, I think either like yard, I love yard internals. Doc's doctor uses, um, yard internals. And, and I, I guess, I don't know if we've mentioned, but what, uh, what doc's doctor does it, uh, you, you sign up for something like rails or any kind of a Ruby project. And it will run, um, 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're don't feel comfortable doing that yet, uh, 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, a fun little teaching. It's a, it's a method of learning. Really? Yeah. Yeah, absolutely. You know, just kind of bite-sized, uh, chunks. That's, uh, that's the one consistent theme across all of these. Um, I, yeah, I agree. I don't know what to call them. They're, they're projects, they're, they're services. There's, it's like open source services. Um, bases, I guess is a, yeah, yeah. Um, so, uh, it's interesting that you mentioned that, uh, I don't, I didn't mean to interrupt you there. If you were going, going to say something else about docs. Oh, uh, and I did, I did want to say like the, the driving motivation behind, uh, writing docs doctor was, um, I, I mentioned, I worked 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, uh, at one point in time, I, I was talking with our, 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, like we're Ruby. We can, we can beat this. We can do this. Like let's, uh, what, what can we do to make the documentation better? And then, and then docs doctor. Thanks so much for listening to developer T and thank you to Richard, uh, for coming on the show. The next part of the interview will be available in the next episode. Of developer T. If you're enjoying the show, make sure you follow me on Twitter at at developer T and you can always reach out to me at developer T at gmail.com. If you're enjoying the show, make sure you leave a review in iTunes, or if you want to support the show, go to developer T.com front slash donate. Of course, you can always find show notes at developer T.com. Thanks for listening to the show. And until next time, enjoy your tea. Bye.