[00:00:00.00] SY: Big announcement! Early bird tickets for our CodeLand conference are now available. You can get them at CodeLandConf.com. It's our second annual conference, happening in NYC, May 4 and 5 of 2018, so get your tickets while supplies last. Link is in your shownotes. (Music). Welcome to the CodeNewbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host Saron, and today we're talking about open source. (Music). We've talked about open source quite a bit on the show. We've had developers talk about working on small, personal projects, and really big ones - like Django. But this episode is different.

[00:00:47.02] RS: My name is Richard Schneeman, and I own the Ruby language for Heroku.

[00:00:51.25] SY: Richard doesn't just work on open source - he has a project that's entirely dedicated to helping you get started in open source. It's called Code Triage, and here's how it works. You sign up for your favorite repos, and you get notified when there's a new issue. And for many of these repos, contributing doesn't require expertise or a lot of time. Today, we're talking about getting started in open source, through small but meaningful contributions. Richard also shares some amazing stories - both good and bad - from his many years working on open source projects. After this.

[00:01:27.03]Flatiron school teaches you how to code from anywhere. They've got an awesome community of career-changers, and a number of different options you can pick from to become a software engineer. They've got full-time in-person courses, self-directed introductory courses, and a remote online web-developer program. They even have a free, 75-hour online prep course, so you can dive into JavaScript, Ruby, and interview prep. To learn more, go to FlatIronSchoolNewbies.com. That's FlatIronSchoolNewbies.

[00:01:57.07] When I first learned to code, all I wanted was to be a developer. But then I actually learned to code and realized that you don't become a developer. You become a front-end developer, or a Rails developer, or a full-stack engineer, or a back-end engineer, or the million other job titles that involve coding. So how do you pick? And once you get that first job, how do you turn it into a career? You can use the Dice Careers mobile app. This is the tool I wish I had when I first started. You pick the tech skills you either have or hope to have in the future, you type in your designer job title, and Dice helps you find other job titles you might also be interested in and maybe didn't know about. But they take it a step further, by telling you what skills these job titles require, how much they pay, and based on your profile, they tell you what skills you might want to learn so you can one day apply for those jobs. They simplify a lot of the chaos of job-hunting, and it's totally free. So check out the Dice Careers mobile app. Go to dice.com/CodeNewbie for more info. That's dice.com/CodeNewbie.

[00:02:54.14] So today we're going to talk about one of the projects that you do called Code Triage. What is that?

[00:03:00.18] RS: Yeah, so Code Triage is a way to get people who are interested in contributing to open source but don't know how to get started.

[00:03:07.27] SY: So when people say they want to contribute, what does that actually mean? Does it mean they want to make an impact in the open source community, does it mean that they want the coding experience - how do you interpret a general interest in contributing?

[00:03:22.01] RS: For the purposes of Code Triage, we're not just focused on commits. Most people when they think of open source contribution, they think, oh, I'm going to spend years working on this huge feature and then everybody's going to love it and it's going to be amazing, and so much of open source happens in the issues. What Code Triage does is we try to outsource a little bit of that process of figuring out exactly what are the important issues and getting enough information to the maintainers of a project, instead of them trying to spend five or ten minutes trying to reproduce a bug, whenever they get to an issue, it's all right in front of them. The idea is basically, you want to save five minutes of their time by giving five minutes of your time.

[00:04:04.22] SY: So is it really that simple? Is it really that simple as giving five minutes of my day to potentially making a really big impact on a contributor?

[00:04:13.05] RS: Yeah, absolutely. So whenever you sign up for Code Triage, you tell us what projects you're interested in. And I'll start getting random issues in my mailbox. Unfortunately, we do just kind of dump you into the deep-end when you first get started, so my best advice for that is - just lurk, essentially. Click on the issue, read through it, it's almost better if it's already people who are having a conversation about it, and try to read that conversation and understand oh, did somebody ask a question, why did they ask this question. Coming from the other side of the table, being an open-source maintainer, just being able to look at the pull-request and say alright, this is totally ready to go, we're going to merge it, it's just really nice.

[00:04:55.12] SY: So, one of the things that probably misconceptions that I have about trying to contribute to open source is, I feel like I need to understand everything about the project before I can be useful. Is any part of that true? How much context do people need in order to be impactful?

[00:05:12.18] RS: If that was my bar, I'd still be waiting for my first issue comment. I've been developing, writing Ruby for about ten years, I've been working at Heroku for about five years. And I think one of the big values that working in open source has brought me from a coder level is being able to jump into an unfamiliar code base. I know that there's all of these other black boxes, and they're doing whatever they're doing, but I can just focus in on this one subset and for a lot of it, if you just do that, then that's a hugely, hugely marketable skill and that's really kind of it. I will say, though, even if you know nothing, you can just read issues, even if it's just - you have a typo here, did you mean connection or controller? Like that kind of basic stuff - it sounds, it almost sounds like oh, that's too good to be true, that's too easy. But it's like doing anything. Start anywhere.

[00:06:10.16] SY: So the other big hurdle with starting is not just the knowledge, but it's also - will people be mean to me? Is a huge concern. And I think open source has a negative reputation in being kind to specifically to beginners or people who may say something that doesn't make sense once in awhile, or give wrong information, or incomplete information. Is open source a generally unfriendly place?

[00:06:39.06] RS: Overwhelmingly, I would say no. For instance, Rails even implemented a bot, that whenever you open up a pull request or I think an issue - I'm not sure if it distinguishes between the two, it sees if you've ever contributed before and it actually says, thank you. Some of it is also being mindful of how you're interacting with the maintainers. Whenever I'm communicating in open source land, I try to take emotions out of my statements. And try to just stick to statements, and generally things like - this is what happened, this is what I expected to happen, and this is why those two things did not match up. There's ways to enumerate that without having to say I can't believe you did this and you messed this up. It isn't open source, but I did have a really negative experience when I was first starting coding, I heard that IRC was the place to get help. I logged into IRC and I'm not going to introduce myself or anything, I'm going to start off by asking my question. But someone just immediately responded back with "Well, why don't you go ask in the volleyball channel?" or something. Basically like, your response has literally nothing to do with this channel or any of the universe that is touching this channel. That was ten years ago, nine years ago, and I've never gone back on. I think when I was first getting started, there were a lot of people like that, and a lot of people who didn't really stop and consider their actions and how they would affect other people. And these days, in all of the major, major open source projects that I see, people are very - at least they try to be conscientious of how they're making other people feel and how they're coming across.

[00:08:24.28] SY: Yeah, and I think it's one of those things where there's a power dynamic that maybe people aren't aware of all the time. As someone who's new to the IRC channel or new to the project, or just new to coding in general, I don't have the same agency, the same power, the same confidence, definitely, as someone who's been there for a while. So, just generally being aware of that power differential can be really helpful.

[00:08:49.04] RS: Oh yes, and I had a number of interactions semi-similar to that. I grew up in a time before Stack overflow, before people would downvote your question if it was a bad question. Previously, they would verbally insult you. So I, when I first started getting involved in open source, I was very timid, and that's actually how I ended up getting commit to Rails, is basically I signed up on Code Triage, I would just comment every once in awhile, and once I got relatively comfortable with lurking and seeing ok, I've seen this person interact with other people a lot, this person is on it. Ok, I feel, even if they don't know me, at least I understand them a little bit to be able to predict the reaction and response that I get.

[00:09:38.25] SY: Yeah, and kind of adjust your communication style accordingly, as well.

[00:09:41.27] RS: Absolutely.

[00:09:43.08] SY: So, you mentioned that hopefully open source people are nice and kind and all that, but I think there are things that newbies can do to also help that relationship. So, in your experience, what are a couple things that a newbie might get wrong?

[00:09:56.25] RS: I think you kind of want to go in as an inquisitive person and ask questions, as opposed to make statements. Like, if someone opens up an issue and it's about database connections, unless you've actually reproduced the issue and you're pretty sure and can actually point to this line of code is where the problem is, making some sort of statement is just sort of distracting. Like, almost any time I'm going to make a comment on open source, I kind of stop and ask myself, can I figure this out for myself. So, that is really helpful. Oh, and I was also going to say - just be really nice to maintainers please - pretty please!

[00:10:41.24] SY: Yeah. Y'all have a lot on your shoulders, because the one thing I didn't really appreciate until I started having friends who are maintainers is that it's not just about I'm a maintainer so I'm a really great coder, it's I also have to be a really good project manager and a really good communicator, and I have to manage the road map and the project itself, but also all the very random people from all over the world who want to help out who have different personalities and expectations and skills and expertise and so, yeah. Being a maintainer, it feels like it's tough.

[00:11:16.15] RS: Yeah, the very last thing that someone tweeted at me was hey, I have this very specific problem with this library that you wrote seven years ago and haven't touched in the last couple of years. Can you give me help? I can try to help, but Stack overflow is a pretty good place, if no one take anything away from this podcast except for this, is that example apps are amazing. Oh and I also, guess I didn't mention this, we've been talking about contributing in terms of helping with issues, but even opening issues I would consider contributing. Don't consider that, oh, I'm running into this bug, a thousand people must've hit it before and it's going to be reported and it's going to be annoying if I report the same thing, but like, it probably hasn't and nobody's seen it probably except for you and it won't be fixed unless you report it.

[00:12:05.04] SY: So tell us more about the value of example apps.

[00:12:07.14] RS: Basically, as a maintainer, let's say I get maybe an hour, maybe two hours a day to work on open source, well I'm going to open up my issues and if I see somebody submitted a bug report, the very next thing for me personally to be able to do absolutely anything with your bug is to reproduce it. The basic question of is this actually even a bug, or maybe something else in your application that's not related to my library or framework is causing some kind of bad actors or some bad behavior. And one of the biggest benefits of this strategy is not only is it easier for me as a maintainer, but whenever I go through this practice, and I'm gonig to submit a bug, I probably find about fifty percent of the time, I actually find that the issue is not where I thought it was. Sometimes I even just solve my problem just by trying to reproduce it.

[00:13:01.06] SY: So you mentioned earlier that when you first started contributing to open source, you were a very timid contributor. How long did it take you to stop being timid and to be more confident?

[00:13:12.09] RS: (Laughs)

[00:13:15.22] SY: Are you still timid? Is that what you're about to tell me, Richard?

[00:13:16.02] RS: Yeah, basically. I commit to Rails, I'm in the top fifty contributors, and like I'll get these things and I'm like, I don't know the words that they're using.

[00:13:25.01] SY: Really?

[00:13:27.03] RS: It's just that I've never touched that specific part of the code base, I don't know what's going on. And like especially the active record internals, it's like I can do work there, it's just I'm not very effective or efficient so there are cases where previously I said, hey every little bit helps, and that's generally true. But there are cases where, if you have two specialists, somebody who has looked at this bug, the person reporting everything about it and the other specialist is like oh, I'm the maintainer of this, I work on it day in and day out, and sometimes somebody can just describe the behavior they're having to me and I'll say, oh my gosh, I've seen this before, here's the exact line, here's the exact problem. I'm very conscious of not trying to go in and do too much on those types of issues and sort of kind of getting out of the way and letting the other maintainers, where that their speciality, focus on. I will say, I'm very comfortable nowadays with my process of making an example app, reproducing a problem, and then I spend a lot of time on how I word my issues. And I focus a lot on that, so I'm fairly confident that if the issue makes sense to me, then hopefully it should make sense with the maintainers and provide them with the maximum amount of information that they need. But I'm still kind of timid whenever I, as a maintainer, these days, I have to tell people, no I'm not going to merge your pull request. And I feel so bad -

[00:14:59.13] SY: I was going to say, that sounded cold. When you decide not to merge a pull request, are there usually common reasons why you make that decision?

[00:15:08.28] RS: So the best reason why a pull request gets merged in is if it fixes a bug. Say, this is currently how your library or framework should behave, this is how it does behave, and this fixes that. And then after that, for not getting merged in, if it's not a bug fix, then it's a feature. And features are a lot harder. It helps if you have some buy-in, basically, and you can say - well, it depends on the project. Some people like an open discussion before any kind of new features, and in Rails, generally, it's like you can try to have an open discussion but ultimately we need code. And one of the problems as a maintainer is you get all of these people suggesting all of these features - oh my gosh, this would be cool, I'm going to do it. And you say, great, do it, and then you never hear from them ever. So I think starting off sticking to bug fixes, documentation is also amazing - if you fix a typo, if you add an example, I personally think that the best contributor is someone who's using something. My best contributions were when I felt a pain with some software and I found the source of that pain - it happened to be inside of a library, and then I went and did something about it. Ninety percent of the time, I would actually say it's documentation. And actually, if you're dead set on making a feature, one really good alternative to a pull-request directly to the project is to make some sort of a plug-in or a library.

[00:16:47.12] SY: Yeah, yeah. Coming up - Richard tells us about some of the open source projects he's working on. He also tells us the hilarious story of his very first coding project, and how he lost the code twice. Yeah. After this.

[00:17:02.13] Getting a job is one thing. Building a career is another. With Dice, you can do both. They've been helping tech professionals advance their careers for over twenty years, which means they have a ton of data and tools to help you navigate yours. Looking for a job right now? They've got thousands of positions available from top companies, like AT&T, Dreamworks, Adobe, IBM, and Dell. Wondering what's next in your career? Use their career pathing tool to find new roles based on your profile and see how much more money you can make. Not sure if you're getting paid what you're worth? Use the dice salary predictor to see real numbers on what your skills are worth. Don't just look for a job - manage your career, with Dice. For more info go to dice.com/codenewbie.

You keep saying you're going to get serious about learning to code, but where do you start? Flatiron school's got the perfect thing. They're offering their free, 75-hour online prep course, where you can dig into JavaScript, Ruby, and more. If you're not sure where to start, start there. And when you're done, you can keep learning, with their online courses, their online programs, or their in-person bootcamp. Whatever your schedule, they've got options to help you reach your coding goal. To learn more, go to FlatIronSchoolNewbies.com. That's FlatIronSchoolNewbies.com.

[00:18:17.15] So you mentioned that you're a contributor to Rails. What are some other projects that you work on?

[00:18:24.14] RS: I have a bunch of my own gems - most of them just kind of scratch a need.The one that someone pinged me about the other day was called Wicked, and that is a way to turn a Rails controller into a step-by-step wizard. So that one's fun. I had some benchmarking gems. One of them is called de-Railed benchmarks, and it's a way to benchmark Rails apps from the command line as opposed to actually having to spin up a browser and click to refresh and that sort of thing. I am kind of maintainer of Puma, I have commit to Puma, which is a web server in Rails. And actually in Heroku, in my day job, I maintain a thing called the Ruby Build Pack, and whenever you do git push heroku master and all of that stuff flies through the screen, like bundle install, as it's pre-compiled, that's me furiously typing at a computer. So all of that logic is in a script called the build pack, and that's open source, and that's been tremendously great. People will just pop out of the woodwork and say hey, look, what about this about what about that.

[00:19:31.09] SY: So, do you remember your first open source contribution?

[00:19:35.13] RS: Yes, I do actually.

[00:19:38.15] SY: What was it?

[00:19:38.15] RS: So, it was a - counter to everything I've ever said, ever, in the history of this podcast, it was a very minor feature request to Rails.

[00:19:48.13] SY: Damn it, Richard.

[00:19:48.24] RS: (Laughs). And it's also in the most not reproducible way ever, which was I went to a conference - my very first conference ever - and one of the speakers was saying oh, I'm a core member of Rails, and afterwards I went up to him, can I ask you like this question, do you think this should behave like this, and I had actually already done all of the work, I already had a patch, in my head I was like, I can't contribute this because it was such a minor change, it would basically be impossible to test it, and I showed him that, and he's like oh yeah. The change was in Rails I think one, it used to actually say the verb for the request - like git or put or patch in an error message, and then at some point in time that went away. So I just added it back in, so I guess technically, maybe it was a bug fix. So ok, we'll say that, it was definitely a bug fix, and I did not break my own rules.

[00:20:44.12] SY: Yes, now we can eventually publish this interview, because otherwise, I don't know if we can put this out there. So this is good, we can write this up, this is good.

[00:20:52.24] RS: I definitely understand - it does feel, I felt like I needed permission if I hadn't gotten that validation that day, then I would probably be like, I don't know, an accountant or something? Like I would've just quit programming all together.

[00:21:06.00] SY: Yeah, but it really is interesting, though. I feel like so many people are one pep talk from doing awesome things. That's all it takes - all it takes is a little bit of encouragement, a little pep talk, some positive words - it really can potentially change the direction, the trajectory of someone's career. So yeah, I think we saw that live just now.

[00:21:25.03] RS: Yeah, absolutely.

[00:21:25.26] SY: Ok, so now let's move on to some fill-in-the-blanks. So you ready? Number one - worst advice I've ever received is?

[00:21:32.29] RS: The worst advice I've ever received was in my first job, my manager at the time - with basically zero managerial experience - like literally, he started like three months ahead of me - pulled me over to the side and he basically just told me to be less sure of myself, he told me I was being - I guess you could call it cocky. And he was basically like, just don't be cocky, don't put yourself out there, don't - I'm not exactly sure of the details, but that was kind of the gist of it, and I kind of took that a little bit too much to heart. And in some ways, sure, it's helpful to go slowly and get validation and be somewhat timid. In other ways, though, I think in hindsight it's really held me back. Like there were a lot of times, especially in open source, where I approached the conversation and was like, oh, would you mind if you please fix this bug, like maybe, and they're like, yes please do it, like yesterday! Like quit talking to me, quit asking me questions - just do it!

[00:22:47.15] SY: Go code!

[00:22:47.26] RS: And so that, that is a almost, one of those you should know a thing totally before you start doing it. Actually to this day, so I blog a lot, I've been trying to write a blog post a week and that's been pretty challenging, and one of the things I get relatively frequently, is people - I'll post on Reddit or somewhere else, and the other day I had one about front-end stuff. And I know nothing about front-end and I even said that straight-up in the post. I'm like, this is not a front-end post, and some people had some really negative, nasty remarks, so you have to try and not let that happen. And basically, they just said something to the tune of well, you should've learned how to do front-end before making this blog post. But if I had waited to - before I became a "expert" in this field, before I made the blog post, then I never would've learned that.

[00:23:41.16] SY: Yeah, that's a good, that's a very good point. Yeah, that's a good way to look at it.

[00:23:44.28] RS: And to those people, I tried to say, I tried to back them down a little bit and be like, thank you very much for telling me about blank, blank, and blank. And then normally I'll say like, I'll happily disregard your advice to have not done this, otherwise, I would not have gotten your advice. So, you know, it's jerks.

[00:24:07.11] SY: It's good. I would easily look at that and think, I'm never blogging again, unless I'm one hundred percent sure I have all the facts. But looking at it the way that you did gives me a lot more confidence and allows me to look at a potentially hurtful situation and really take it in stride.

[00:24:25.08] RS: Yeah, sign up for my mailing list today. Schneems.com. Listen to me be wrong all the time.

[00:24:30.16] SY: Yes. (Laughs). Number two - my first coding project was about?

[00:24:34.20] RS: Oh, my first coding project - it was going to make me a million dollars.

[00:24:38.13] SY: Definitely.

[00:24:38.23] RS: I actually asked my roommate, who was in Computer Science at the time, what is Dig written in, and he came back and told me Rails. So Dig was a website -

[00:24:48.18] SY: I did not know that.

[00:24:49.25] RS: Yeah, Dig was originally written in Rails, so that is why I learned Rails.

[00:24:54.19] SY: Oh, very cool.

[00:24:55.19] RS: That was my - I had, basically in hindsight, it was very easily described as an Urban Dictionary knock-off, I was like, oh, you know what? There's an Urban Dictionary, but there's not like an Urban Thesaurus. So I thought I was so smart and like, eventually I figured out that nobody cares. No one cares. But I did, my pivot was to a kind of slang translation service. So I ended up calling it - I think the end project was United Dictionary, because that was a website that was available at the time.

[00:25:35.06] SY: I was going to say, that's not what I would guess that that does.

[00:25:38.01] RS: And it was awful. It was awful. I did get some, I got some contributions and it was kind of, vaguely - the code was horrible. I had an upvote/downvote feature, for some reason I was so dead set on that feature being one method that handled the upvote and the removing of an upvote and the removing of a downvote. It was like hundreds of lines long and just everything was so gnarly and so awful, and I think the code is still open-sourced on line somewhere. But yes, that is the first thing that I did that was going to make me a million dollars and you'll just have to find out if it pans out.

[00:26:22.08] SY: (Laughs) So a lot of times we make solutions for problems that we personally have. Were you having a hard time figuring out different ways to use the word shade? Was that was that was? Was that for you?

[00:26:33.21] RS: I honestly have no idea. I just, so this was in 2006, I guess, when I initially got the idea. And this was the second dot com boom, and I'm not joking when I said I was going to make a million dollars, like I actually thought that just having any kind of a semi-reasonable application, it was just going to be great. So it didn't last very long, but the valuable thing for me was that I had kind of an idea in my head of like, is this even possible to make? Ok, you're probably not going to strike it rich with this, but even if you don't, the worst thing that's going to happen is you're going to end up with this really marketable skill.

[00:27:16.15] SY: Very cool. Number three - one thing I wish I knew when I first started to code is?

[00:27:20.17] RS: Ok, one thing I wish I knew when I first started to code is that there is not a best way to do things. There are better ways and some things can be considered "harmful" or be anti-patterns, maybe, but as I was sitting there, in my apartment, alone, on a Friday night, making this totally not beneficial to humanity in any way, shape, or form website, oh and I lost the source code. Twice.

[00:27:53.26] SY: What? Wait, how do you do that?

[00:27:57.27] RS: I had to rebuild the entire website from scratch, twice. So I had never heard of - source control was not really a thing. Git was just sort of becoming mainstream, and everything I'd ever heard about subversion or Perforce was just negative and awful, and I didn't really understand the value of it. Github was kind of not a thing. So I did all of my coding on one laptop, and then that laptop got stolen out of the back of my car -

[00:28:24.20] SY: No!

[00:28:25.03] RS: Yeah.

[00:28:26.26] SY: Did you have like a window down or something?

[00:28:29.11] RS: No, I needed to take it back to the Apple store for some repairs, so I put it back in the original box and so I just had this what looked like a brand-new - it didn't work, at all. Which is kind of funny.

[00:28:44.02] SY: Jokes on you, thief.

[00:28:46.20] RS: And, on the same trip, I thought I would be clever and save some time and so I got groceries as well, I was in college. I was bringing those into the house, I had just came out, and my windshield was shattered. It was unlocked people. The car was unlocked.

[00:29:03.09] SY: Oh no, that was the first time. What about the second time?

[00:29:05.14] RS: And so the second time, it was also stolen.

[00:29:11.09] SY: Really? You must not live in a great neighborhood.

[00:29:12.25] RS: I went to school in Georgia Tech, which is in Atlanta. It was actually fine, but it was the student area, which is not as fine.

[00:29:23.24] SY: Oh yeah, kids are trouble.

[00:29:24.06] RS: In that case, I did have back-ups, I think I emailed myself the entire code-base every so often, after a while you kind of just forget about it, right. So I think I lost maybe a month or a couple months of work. Yeah. And then after that I invested in Apple Time Capsule, and I actually used that for source control for the longest time.

[00:29:47.06] SY: Ok, so you learned your lesson and you came up with a solution, that's great.

[00:29:50.00] RS: What was the original question?

[00:29:51.12] SY: (Laughs). One thing I wish I knew when I first started to code was?

[00:29:56.15] RS: So I'm changing my answer to use source control and back up your software.

[00:30:02.19] SY: (Laughs). I think that is great advice. When you rebuilt it the second and third time, was it better?

[00:30:11.04] RS: Oh yeah, yeah.

[00:30:12.24] SY Well that's good.

[00:30:13.03] RS: It felt very futile. It just felt like, seriously? Seriously? But for some reason, I didn't give up, or I didn't switch to a better idea. I guess I kept going and I was kind of a little excited to clean up some of it, honestly. And I do think it got better and better. But the one thing that I kept on having in my head, I had this mythological idea that people got paid to be programmers knew what they were doing.

[00:30:43.00] SY: Yeah, yeah.

[00:30:44.09] RS: And I was convinced that if I ever got on a team, I would be able to ask them this question and they would know the answer and I kept up that misconception all the way to my first programming job and then I showed up and I was like, I think you should do it like this, and they're just like, I don't' know, try it.

[00:31:02.12] SY: Yeah, I remember my first time when I was at ThoughtBot and I had a mentor and we were pairing together, and the first time he said, I don't really know if that's going to work, let's try it, I was shocked. I was like, what do you mean? If you don't know, then who knows? It was a very startling moment for me.

[00:31:23.01] RS: You mean I'm it? I'm the source matter expert? No no no no no.

[00:31:29.24] SY: This is the best we got? No, there has to be more. (Laughs). Well, thank you so much for being on the show, you want to say goodbye?

[00:31:37.12] RS: Thank you very much for having me on the show and thank you all for listening to my horrible ideas and awful interview advice. I hope you got something out of this.

[00:31:49.14] SY: And that's the end of our last episode of Season Two! Let me know what you think. Tweet me @CodeNewbies, or send me an email, hello@codenewbie.org. If you're in D.C. or Philly check out our local CodeNewbie meetup groups, we've got community coding sessions and awesome events every month, so if you're looking for real-life human interaction, look us up on meetup.com. For info on the podcast, check out www.codenewbie.org/podcast, and join us for our weekly Twitter chats. We've got our Wednesday chats at 9 PM ET and our weekly coding check-in every Sunday at 2 PM ET. Thanks for listening, see you next season. (Music).