Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I am finishing up my interview with Richard Schneeman. Richard works on a bunch of Heroku stuff specifically he does Ruby at Heroku and he also helps run the Keep Ruby Weird Conference. He created Co-Triage, he also created docsdoctor.org, he's been working on some Ruby benchmarking tools, a lot of awesome stuff that Schneem's is doing. So follow him on Twitter, SCHNEMS, that's Schneem's, make sure you tweet at him and let him know that you are enjoying this interview on Developer Tea. You can also check out stuff that he's writing on his personal blog, it's Schneem's on open source Ruby and Life, that's once again, SHNEMS.com. While you're listening to this episode, why not go ahead and open up the app or whatever thing that you listen to podcasts in and click or press subscribe. That way whenever a new episode of Developer Teacomes out, you will be able to get it without having to remember to go to Developer Tea. I love you guys going to the site but ultimately who has time to remember to type in things in URL bar anymore. So instead do the lazy easy thing and just subscribe, it's easy. So here goes the second part of the interview with Richard Schneeman. So it's interesting you mentioned Ruby or Python, I was actually going to talk a little bit about Python as well because first of all, Python for those of you who haven't experienced Python before. Python has documentation as kind of like a first class citizen almost in the language, it's really different from what if you've ever written a rate task, that's probably the closest thing to describe it by. But at the beginning of most Python methods, it's a triple quote string that explains what that method does. And obviously some methods don't need that because they're simple enough that they're kind of self documenting. But for things that are abstracted or whatever, it does basically what you would do writing documentation elsewhere. But then you can generate that doc up the chain. And it's been in Python and kind of like a convention that the Python community has agreed upon for quite a long time. But I was going to mention it because I actually when I first started programming, I came upon this really cool. This is like a long time ago, but it was it was delivered as a podcast. It's called Python osmosis. And I was like, I'm a doc doctor because basically the idea was you just kind of sit back and let somebody else tell you things, you know, like in the idea being like, OK, I need to learn Python, but I have no idea where to go. Like I don't have a path, you know, to start and I have no programming experience at all. And maybe you know people listening to the show, you might not have any rails experience. One interesting way to learn rails is to literally just sign up on docs doctor and have it send you these documentation pieces, little chunks of documentation because you'll learn like, you know, as you as it's kind of like osmosis, you kind of let this stuff come into your inbox and read over it. And it becomes kind of like a, I don't know how to explain it. It's like if you read it every day, then you start picking up on things without even realizing that you're picking up on them. Yeah, absolutely. It's kind of like if you go if you go somewhere that speak where they speak a different language and then one day you sit down at the cafe and then you like order something and you just realized that you just totally did that thing. Like without even, you know, in the case of the documentation, it's like, one day you'll get a piece of documentation and you'll be like, oh, I already know about this class. Like I've already, I've already seen it or you'll like be debugging a bug in rails and you'll be like, hey, yeah, this, this totally looks familiar. Yeah. So I'm going to switch gears again real quick. It's still talking about documentation, but from kind of a slightly different angle here. How, if I'm writing documentation for the first time or like the fifth time, if I'm new to writing documentation, I need to know how, how do I write good documentation? There's a lot of talk about how to write good code, you know, like there's plenty of books about that. But getting involved in docs doctor, I think the biggest challenge there is, am I doing this the right way? Like, how do I make sure that I'm writing, you know, enough information or that I'm not writing too much or, you know, that I'm writing in the style that is necessary. You know, what are the conventions, et cetera. So that's a really good question. There's a couple of things that I do. Most of the time whenever I am writing documentation, it's because of I thought the method worked one way and it turns out it works a different way. And one of my favorite things for that scenario is actually putting an example in there that that kind of hopefully shows to other people. If this is also a common case that you're trying to do or something you're actively trying to use, then this is kind of this is how you should expect it to work. So I love putting examples in documentation. And it in rails actually like the examples are probably my favorite part. I almost wish sometimes they would just like not explain anything and just like the only code examples of like kind of the, you know, showing that method used and like how do you set up the class and all these other things. But there's also plenty of other times when an example doesn't make any sense or none of the other code in there makes makes sense. Or none of none of the other code in there is documented with with examples. So I'll sit down with ever note or or text made or something and just kind of write out what I think it does. And and like if you just gave me a method that I have no idea what it does like today. It's like hey go into this class. It's undocumented. And then all after I've done that just like based on the name of the method. I'll read through the the line by line and actually start describing. Okay, like it hears how it modifies the inputs and then eventually we'll say, okay, and here's what the output is. And once I have all of that written down is you know, kind of a super rough draft form, then I'll take a look at how some of the other documentation is written and hopefully it's in the same file. If not, sometimes I'll have to snoop around in rails like it's really common that. What I'm trying to document isn't like anything else in the rest of the file. And so I'll find another function or another method that is that is sort of similar to it. And then I'll just try to rewrite what all of my rough drafts and my thoughts in terms of whatever style they were already using. And also at the same time, if it's like truly a style thing, like the best way to write to document something is to document it like the best way to start writing comments is to start writing comments. And when you submit a poll request, then you know, I'm I know it must have like it's super painful whenever I get anything like closed or they're like sorry, but no thank you. And at the end of the day, like you learn something. And so like you mod it like you know, you now know about this internal method and you know how it's used and how other things kind of fit together. And so it's not a total waste, but on on the scenarios where they're like where they are interested in that piece of documentation, then hopefully if you contribute it to a repository, then someone should say like, hey, like, thanks, I, you know, I'm really happy that you're interested in this. Could we change the wording to do this? Could we maybe add a line break here? Could we, you know, double space this? And they'll work with you. Hopefully, you know, if not, if nobody, if you submit it, and then no one is like responds to it. And nobody says anything, then you should tell, tell everybody to get on code triage for that repo. There you go. Docs, doctor and code triage, solve a lot of problems. Yeah, I mean, it's really they do. It's funny, though, I that that piece of documentation that I told you about actually ended up getting submitted. So from my perspective, I think something that a lot of people don't. I guess what I'm trying to say is don't be afraid to have an opinion. Oh, yeah, because I think a lot of people look at, you know, like the Rails project, you've been working on that for a long time, and you're just now getting commit access, which sounds like, man, it must be like a huge hill to climb to be able to contribute to something as important and, you know, well thought out as Rails, but ultimately the people who made Rails are making Rails with the opinions. And you have opinions and your opinion matters like it doesn't matter how long you've been programming like share your opinion and it's very likely that something about your opinion will either help you to learn why your opinion needs to be shifted. Or it's going to be something that nobody else has thought of before and like, guess what your your commit actually just got accepted, you know, and it's in the history books or whatever. Oh, yeah, yeah, absolutely. Like when I first started, I kept on thinking like, oh, somebody is going to just jump in there and they they know this file like the back of their hand and they're going to like yell at me and make fun of me and it's like, can you get hub account. Yeah, they're going to find out where you live. And show me on Twitter, throw, throw things at you. Like, you know, and it's no, it's like we're very, you know, rubius are one of the most happy group of programmers. Like obviously there's there's some some bad eggs every now and then, but by and large, especially if you're if you're on the Rails project every we go, we really go out of our way to say, you know, thank you. You know, if we're merging your pull request, we say, thank you. Like if I'm if I'm closing your pull request, I say, thank you. You know, submitting the pull request. And yeah, you are probably more of an expert at that moment because you have an opinion and exactly like you said, if you have real actual experience, that is, that's actually how why Rails is so good. And like, like basically 37 signals was like, hey, we don't like how we're developing apps. We're going to make it how we think it should be made. And so like the same thing goes for documentation. It's like, you're like, hey, I don't like how this is currently written. Here's, you know, here's what works for me. And you know, maybe maybe somebody's like that. Yeah, exactly. You said it's great. Perfect. Ship it or there's actually a really good reason it doesn't work that way. Right. Yeah. And a lot of people forget that, you know, Rails was meant to be used by people. Like Rails is not, it's not like a project for itself. It's not so feeding in any way. It's intended to be like used by you. You know, and so your opinion, if anybody's matters, your opinion matters. Yeah. I think that's like, it's not like somebody's pet project. It's meant to be used by everyday developers, you know. It's built to make projects with. Yeah, exactly. Cool. Well, so speaking of Ruby, it's no secret on this show that I'm a big fan of Ruby. I try to generalize some of the things that we talk about here. And I think these apply in a lot of different circles. I mean, yes, Ruby has a particularly interesting community. But that doesn't mean that other language communities are not interesting. So just that's kind of like a, let me back up and make sure everybody knows. If you are developing in Python, you shouldn't be scared to share your opinion either. You know, I think actually you have a particular interesting relationship with Python, right? I'm sorry. You have an interesting relationship with Ruby who has an interesting relationship with Python. Yes. Yes. So my wife's name is Ruby. And she currently is coding in Python right now. Like at your house right now. Yeah, well, at her job. But plenty, plenty of evenings, she is all is like sitting on the couch. Why is this deploy, you know, no working. I did, I did instill like try to bring over the testing culture over into her Python app. And she has also written a lot of Ruby before this. Her previous startup that she, she co-founded was written in Ruby on rails. That's cool. Yeah. That's awesome. So let's talk a little bit about conferences because you happen to be kind of at the helm. You're, you run, but tell me what you're official. I don't know if you have an official title. What do you do for keep Ruby weird? What would you say you do your name did there you go. You're the official name maker, whatever. So office space was actually filmed in Austin. I don't know if a lot of people know that. But that's that line is from office space. Yeah, some of the buildings actually still exist. But anyway, I digress. So so keep Ruby weird is it's a conference we throw in Austin and it's about how great we think Ruby is and keeping it great by, you know, keeping it weird. So we're going on a lot of people focus on the business side of languages and the business side of programming. And like sometimes you just got to go out there and play and that's and that, you know, that's how children learn and grow and develop and like adults aren't any different. So if we don't stop and do that, then we won't advance. And keep it weird started because we got a couple guys together and some beer and then it just happened and brought right and I heard the story on what was it Ruby Ruby wrote knows the thought pot podcast you talked about it on. Yeah, I was sitting down with with Kayla Brit and Terence it at Frank's and we were yeah, we were having just some really good. They have homemade sausage of all different kinds and and Brit was like, hey, we should throw a conference. And I was like, I have the perfect name for it. And so together we've we've all kind of banded together and and we threw the conference for our first year. It was incredibly successful. We sold out in like five hours. And we heard a lot of positive things from a lot of people go to a bunch of conferences. So can you hear that in the background. The whistling sound. My room, but just started I'm going to go shut it off. Okay. Okay. Okay. Sorry about that. I'm back. No problem. Emergency room, but turning off turning off for room is a service. We I got my wife a room for Christmas actually. And it is it is quite loud, but it's funny to watch her interact with it because most of the time she stares and watches it and like supervises it, you know, which is basically the same thing is doing it yourself. Totally. Well, so, so I we I've had a room for a number of years. We actually recently upgraded to a nicer one that has the programmable you can like set it tell it to go on. And one of the things though about being an adult and buying like adult furniture. Like basically I'm buying things that like look look really nice and you're like, oh, the house feels really home like they're like, you know, it feels like a home. Yeah. And then my room, but season, it's like LOL. I'm going to get stuck on that. Like under it or yeah, no, it just it doesn't work at all. So like, yeah, we I actually am actively thinking about getting rid of my like coffee table that I spent months finding like just the right one. Because we I didn't consider it has a metal bar all the way around the base of it. So it's not it's not that it can't clean under it. It'll get one wheel stuck. And then it's so annoying to pick up and move back to the dock that I'll just leave it there. It'll it'll get stuck for a little bit. And then it'll be like, I can't go anywhere. I'm just going to turn myself off. That the automatic scheduler will come back on in the next morning and it'll just like sit there and it's like it's like the most. It could be like a, you know, like almost yeah, yeah, it's like a little short film or something. It's like, oh, poor, you poor little you poor little thing sometimes. Sometimes I just flip it over because it has sensors in the wheels. So the wheels detect when it's like not touching anything and it doesn't run. It's like, okay, just lay lay down. Calm calm yourself. Take a break. Yeah. Go home, Roomba. Yeah, you're drunk. So enough about a room. We're I think we're talking about keep Ruby weird. Yeah. I was going to ask you a question about that. So the conference is about Ruby and it's about the community of Ruby, but also about a ton of other stuff. But I did want to ask you a kind of specific on the spot question. Tell me one thing about Ruby that is just patently weird to you. The one what the one patently weird thing like that, you would have never expected coming to coming to the language. I know I'm putting you on the spot a little bit there. So so from a technical perspective, one of the one of the like I guess weird slash cool things. Is like whenever I would I actually first learned how to do the first object oriented program in language I ever learned was Ruby. And the first exposure I ever had to like the or equals operator, which will basically say like if this if this value is set, do nothing. Otherwise said it said it to this thing. Ruby will Ruby supports that by like actually doing a lot like it doesn't have a special or equals operator. It actually evaluates both of them independently, which makes it a non atomic operation, which actually has some problems with if you're doing concurrency code. But but yeah, no, that's like a super boring like response. No, not at all. Yeah, and I don't know why I like that. I just like that. And I think it is slightly weird that they like decided to do that. And it's like kind of a cool it's like one of those cool continuity things where like everything. It's like everything in Ruby is a method. And it happens to work that way. Yeah, exactly. It's it's it's like like there's no functions like people are used to in like Python. You have it's like like print is like a function. And it's like in Ruby. It's like print is it's like a method on some object up the chart. Yeah, I hope that's right. I think I think it's on like kernel or something like that. Yeah, yeah, I think you're right. Because I've seen puts on the kernel, I think we're we better stop talking. But so my but my what I've been telling people. The reason I think Ruby is really weird is because it's the only programming language that's optimized that the official stated goal of Ruby is is to be optimized for the happiness. Like that's what Matt that's what Matt's the creator Ruby actually says it's like what what do you want Ruby to be like known for and he's like I want I want Ruby Developer To be known as happy developers because they really enjoy using Ruby. And like there's a lot of. There's a lot of. There's there's a lot of thought and effort and energy put put into that you know from from the syntax to the way it's implemented to the ecosystem to there's even a there's even a there's even a saying in the Ruby community that says Matt's is nice so we're nice and and basically like the the community started is one one person created Ruby and that was Matt's and you know if he when he says somebody introduces the programming language just to them if he's not a nice person to them like when they introduce it to someone maybe they won't be a nice person you know and so on and so forth but Matt is just one of those like if you sit down and talk with him for a little bit like you can't help but just like be he's constantly smiling and it's just like he's super sharp you know basically whatever programming thing you want to talk to him about like he has a lot of things like that on opinion on it or like you know he's been all around the world and done all these crazy things he's still super involved in Ruby super and you know with the with the core team and the thing that gets me it's like if you've talked to some some career open source people like a lot of them it's just like they look like they just woke up. And then he's had you know like Bender like they and tired of the projects are working on a lot of the time too which is sad. Yeah and you know so like he's still he's still sticking with it and like obviously he's side projects and like you know hopefully who doesn't everybody should have you know but it's just one of those things where like I you know I wouldn't say I can probably program in like a handful of languages like I wouldn't say that I necessarily know them but every time I like touch another programming language I'm just like oh I just wish you were Ruby. It's funny isn't it yeah it's yeah it just it really and maybe and maybe it just because of the time in in place when I picked it up but it really just fits the way that my brain feels a programming language should should work. Yeah I think I agree and there's other you know I've worked in quite a few languages as part of my degree I worked in some Java you know I've done you know everything. From from that all the way to you know just some a few functional programming languages but Ruby has consistently been again the most enjoyable right like in which that's what it's designed to be is just an enjoyable language and despite some of the whatever the shortcomings are that that brings me back you know yeah absolutely cool that's that's go ahead I was going to say it's enjoyable unless you're trying to write to a file because you have you have to use a block to do that it's just like really there's a file that read why can't we just like have a file that anyway anyway anyway what can you do yeah no you got it you got to pick your battles yeah so speaking of things that you're doing other than Haroku and Ruby and all of those things that we've already talked about are there any are there anything like any books or anything like that that you're reading or particularly interested or have enjoyed recently that you would share with me. So yeah I've been I've been reading through Pat Seanise's book Ruby under microscope it basically is all of the it does a very good job of explaining it like so I don't have a computer science degree and it it walks you through like what you know what is a parser and like here's how Ruby's parser works and here's like examples you can use and and then down through how actual individual features are implemented in the language. Oh I totally should have said the the singleton inheritance chain for the weird thing but no but it's yeah that that's like way too geeky but yeah I've actually tried doing this like self enrichment like 30 minutes of a day where instead of instead of saying okay I'm just going to browse like blogs off and on whenever I get bored like I'm if I like if I'm noticing myself sewn out I work from home so I don't always take full you know hour long long lunches it's like basically for 30 minutes of my lunch like I'll just sit down with a book and like with a timer and just like make myself learn something and so I've been doing that with with a book and it's good it's like other than that just some some reference books I like it's like operating systems I think is one of that I was reading like nice which talks about like how memory management works there's like there's like many multiple chapters on it there's like on physical memory and virtual memory and it's like it's like like hundreds of pages to just memory and originally I was like memory is a is a number and it's like no like like the amount of RAM you use it's like and basically nobody knows like the off like the operating system kind of this like sophisticated of a you know of an operating system like it sort of has an idea of how much memory exactly you're using but like it would be and anyway it was it was really really interesting really eye opening and unfortunately it was very applicable to something I was doing. That's funny. Yeah yeah so I've heard nightmares told about memory memory management I also have a big stack of books on my desk. The art of computer the art of computer programming which I'm sure you've heard of and are at least cursory familiar with it and a pretty good portion of that is pretty much just about memory. Okay but more in the in the classical sense of like how do you write to bits and you know what does that mean and what what would happen if suddenly you had to do like a seven base system like would you know how to do it. Oh that's which has not and I don't know if that specifically is covered but it's things like like making you think that way. Yeah that is really cool though this was all just like the you know how stuff works I guess of of operating systems that's cool. Other than that oh I subscribe to to find woodworking and reddit reddits woodworking subreddit I find both of them incredibly satisfying from a like if you enjoy process and you enjoy like step by step learning things it's totally not programming. But I have not met a single programmer who has not at least been interested in geeking out on woodworking I think the working with your hands and like that kind of a craft there's some sort of innate appeal there I not exactly sure what it is yeah yeah I've actually wondered the same thing because I recently I recently got interested in and I haven't done anything with it yet but instructables I've downloaded the instructables app and I've been just been like. You know like almost in the corner like when I'm supposed to be doing something else I'll open up and instructables and just like scroll down the list and see if I see anything cool that I might want to put on the list of things that I want to build yeah totally totally. I think it's the maker thing inside of us like we we build a lot of software and or whatever you want to call it an app and then like it feels like we go home and it like it doesn't it's sometimes it's hard to see that building. Under our like in front of our faces and we can open up our phones or whatever but like for instance I just got some beacons some Bluetooth beacons and I've spent some time just playing around with those and I threw up a like a Sinatra app and then I think it was a it was actually I was inspired by a talk that was given at RubyConf about Bluetooth beacons but anyway you can just kind of like you know if you don't know what a Bluetooth beacon is basically is just a little bit more. It's like a Bluetooth it's battery powered and it broadcast a Bluetooth signal and your phone can listen out for that signal and then respond to it in some way and so there's a app called beacon with two ease instead of an a and you can send a post request whenever you hit that beacon well I I had it I set it up at work today and basically I walk into a room and I song starts playing on the sonos speakers because there's actually a Ruby Jim who knew that will take over the sonos in the room and it's it's just like this really cool like physical thing that to completely captured my brain for a couple hours that is that is really cool yeah it's a lot of fun what was that what was the song it I just I think I picked like radio active or something like similarly you know fill in fill in the adjective that you'd like to fill in there I don't want to make a judgment on your musical tape I didn't know if it was like I the tiger like I actually OK so I started out with something along those lines I remember exactly what it was it was like AC DC song or something yeah yeah I actually asked all the developers in the room was like hey guys what would be an epic walk in song they had no I like no context for why I was asking this question so they started throwing out random stuff I'm pretty sure I got like a Taylor Swift song in there like you don't understand what I'm asking you this is different than that nice nice yeah kind of let's look one of the old jokes about like picking a song for like your your like what you wake up to it's like OK you know pick the song that you're going to hate for the rest of your life like it's like you got it it's like very carefully right right well awesome this has been enlightening I've enjoyed it immensely so one last question that I like to ask guests and hopefully you will this won't be too much of a all of a sudden kind of question but if you had to sit down with a brand new programmer or somebody who is relatively experienced in the field and give them you know 30 seconds worth of advice what would that 30 seconds be that's really hard is is a really bad if I just give them 30 seconds of silence it's like the best code is the code that you don't write no I think my best advice for just anybody really is and a lot of people forget this is is is like writers right programmers program like the best way to get better and get involved in the community is just to do it go out there figure figure out you know make a goal and say you know like hey at the end of this year like I'm going to get a commit into rails like that's not hard at all like that's that's that's like you're like lowball in yourself and then and then work backwards and say like OK what what are the steps I can take to to do that and then just put yourself out there and take steps to to to doing it and you know it's amazing and a year later you'll look back and be like wow like you know hey I'm a program like I'm a good programmer now or or if you don't then I you know I'll tell you you're a good programmer that's great that's good good advice just in keeping with actually quite a few quite a few guests on the show have had similar responses the best way to become a good programmer is to start programming more yeah it's it's the not advice right it's it's the secret sauce don't let anybody else know awesome well thank you Richard I appreciate your time yeah thank you very much for having me this is great and if there's let me make sure we get all the links in here docs doctor dot org or yeah awesome docs doctor dot org and then what was the other one code triage I don't have my notes in front of me code triage dot com yep dot com dot com there we go and then you've also got this other project that I want to drop in here because you had mentioned it before and it's super interesting to me the benchmarks one oh it's uh I'll send you it's called derailed benchmarks it's on GitHub give dot com slash sneak Schneem slash derailed benchmarks yeah and the basics of that are based on it's essentially you can spin up a rail zap without connecting it to a port and then interact with it in ways that will test it like from a big benchmark perspective not from functional test or you know controller test or whatever but from being able to say you know this code is faster than this code right yeah you can do that one one of the I I'm one of the things I wanted to know is like hey how much does where are taking a step back one of the one of the problems we get a lot of times it's a hero who is people saying like hey my like app is using all this memory all of a sudden and one of the suggestions we get them is hey mate maybe take a look at your gems and see which ones that you aren't using because in everything inside of your gem file gets loaded into memory and I was like oh well hey is there an easy way to see that and so with with this tool you can run if you once you set it up you can run rake and what is it require bench per for a wire bench and it'll show you every single time require gets called in your app and how much memory that require consumed so so if you like if you require and from this we found that you know we had a was using something like 30 or four like you're just requiring the mail gem was was taking up like 30 or 40 megabytes. That's incredible and then from that we were like oh hey we don't need to do this this way we can do it this other way and then we saved mail like anybody who's using the mail gem you know we cut off like 30 30 40 megabytes out of their startup. Even if you're not using it it's still loaded into memory and it's still like you're still paying for it. So yeah it's just it's just a bunch of different kind of stuff like that things that I essentially collection of things that I have found useful. Very cool very cool. Well Richard I appreciate your time and thank you for joining me on the show. Yeah thank you. Thanks so much for listening to Developer Tea and thank you to Richard's names for being on the show. I know that this episode this this interview went longer than the average interview does on Developer Teabut it was jam packed full of value for me and I think it was for you as well. If you're enjoying the show make sure you let others know by going on to iTunes and leaving a review it's the best way to help other developers find Developer Tea. You can always connect with me on Twitter at at Developer Teaou can find Schneem's on Twitter as well it'll be in the show notes which you can find at DeveloperTea.com there's also a contact form there if you want to ask questions or send feedback and until next time enjoy your tea.