Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell. Today's episode is the second part of my interview with Carlos and Greg, Carlos Souza and Greg Pollock from codeschool.com. If you missed the first part, make sure you go and check out that first part. You can find it in iTunes, of course, also on spec.fm. You can find the show notes on spec.fm. Make sure you check that out before you listen to the second part, because you may be a little bit lost if you try to listen to the second part first. We don't have any sponsors for the episode. Of course, codeschool has sponsored in the past, but I wanted to make sure that you guys didn't think that I was just having them on the show because they are sponsors. In reality, these guys are doing some awesome work. They are educating people how to code every single day. That is what they wake up to do. I hope you enjoy the interview with Carlos and Greg from codeschool.com. The problem that I have run into in trying to promote the educational content for a consultant business, I actually work for a consultancy as well. So often, it seems like, who am I promoting to? Am I promoting to developers or am I promoting to people that I might consult on projects for? Right. Right. I always target the developers and then still clients would land in my lab. I wonder what the pathway is there, because I know that it exists, because pretty much every good consultancy does this, right? All of the ones that you want to be like, they do this. Right. That is mostly because the best clients do research on the technology they want to use, and they will look at the technology ecosystem and who is in it and who speaks loudly in it, and that is how they find you. Yeah, I think it's this concept of establishing authority, establishing legitimacy. Right. That and they go and they ask a friend who is in that community, what consultancy should I pay for, and they go, oh, well, I know these guys, because they educate me every week on Ruby 5. Or it's a small project with one consultant, and then they need to bring on more developers and they go, okay, who do I know? Because it's kind of hard to even target the people that you might be a consultant for, because who knows? Consultancies, we work with all kinds of projects. It doesn't, there's no particular demographic of people that we're targeting with our consultancy, and the message would be kind of strange. Like, hey, if you ever need a developer, we do that. You know, like, oh, great. I don't really care because I don't need one right now. In a year, I might, but I don't need one right now. Right. It's the message is kind of strange. A lot of our interest comes from projects that we've already done anyway, which is similar to what you're saying, right? Like, if you are putting out content that shows how to do something, it's very similar to putting out content of the thing that you've done. Yeah, that's true. You know, maybe documenting the process is one step towards creating that educational content. Would you recommend for developers, you know, younger developers, to create educational content themselves? It really depends on why. Right. I think for developers who see themselves, you know, needing to find a job, right? Or trying to build up your reputation so that they can eventually find that next job, eventually at some point in time. I mean, it's great to have those technical blog posts that show that you can take a topic and explain them, and you write well. And I think that's something I certainly look for in new employees when I'm bringing them in here. If they have a blog, I'm going to check it out. I'm going to see how they explain things well. And a clear writing is a good sign of clear thinking. So they definitely helps. And you know, if you're looking for contract work, if you're trying to advertise yourself, that's another good reason to be blogging. You mentioned that you look for that in the people that you hire at code school. Two questions there. Number one, what is the makeup of the team currently? Like how many of you are developers and how many designers or, you know, maybe you don't have those specific types of roles? I don't know. Can you speak to that a little bit? Yeah, certainly. How many developers do you have? Do you think? I think we have like maybe 15 or 15 or 16 developers. We've got maybe 11 or 12 on the design team, which is broken up into front end team, illustration team, and the newest additions, the UX team, which are causing all sorts of havoc. But that's another discussion. Then we have like three project managers, no four. We have four project managers now. You know, and then we've got a bunch of marketing people. That's like maybe like seven on the marketing team. We got one video editor. Oh, wow. Yeah. That seems like he probably has a pretty long day sometimes. Well, does he? Yeah. No, I don't think so. It's not like it's not like he works as aso. I mean, it works hard, but it's not like he's just like overwhelmed with work. We don't produce that much content, really. Compared to most like online learning destinations, we produce one course a month. And I love the fact that we get to do that, that we figured out a way to put so much effort into one really prime best way to learn something. But you were asking about people who did I miss? We have operations operations. Yeah, that's the project manager's most like. What else? We have an office manager. Yes. Oh, we have it. We have our first HR person. Oh my God. When you get up to 50 people, you get to hire an HR person. And if you land the right person, they are amazing. And they are worth every penny. You don't realize it. It's like the person who cares about so much about culture. She's amazing. She's such a good addition. I never saw it coming. Oh, so, dude, support. We totally forgot support. God. I'm such an asshole. Yeah. We've got an amazing support team. We can support director Joseph Perez. He's amazing. So we've got like four people on our support team, Ish. And our Developer Tea's like broken up into separate, you know, teams. We've got like the course dev team and we have like the dot com dev team and the campus dev team. Yeah. Lots of different components, which you have to break up into when you get big enough. Yeah. I was going to ask you, you guys basically keep developers working together. Where is there some cross-pollination? Oh, we put them on islands. They're not allowed to talk. Yeah. No, we have them rotating. We put themselves on islands. Oh, yeah. But yeah, they rotate around. We try to keep it entertaining because certainly coding, like creating courses is different kind of development from on the dot com. It's a different kind of development from working on the course engine. So we try to get them to rotate around. So no one gets burnt out. It's really important to us that everybody here loves what they do and it's happy with what they're doing. I could talk about culture for hours. It's an important part of actually building something that other people are going to enjoy. Right? If you don't enjoy it, it's going to be hard to get other people to enjoy it. Yeah, certainly. Enjoyment is really an important part of the learning process too. By the way, I know you guys have these, have the concept of like playing a course, right? Yeah. We use, we try to use gamification terms and principles whenever we can. Just because, you know, people don't want to like take a quiz at the end of the chapter, but they'll take challenges at the end of the level, right? They'll, and it just, just those terms, some people just are allergic like me to, you know, chapters and, and quizzes and all that stuff. So we try to make it very much gamified. I don't know. See, I did decently well in school though, and I don't know that everybody has that same experience. You know, a lot of programmers end up going into programming because they're good at putting these systems together, and maybe they completely, you know, hated school because they didn't test well. So now you're creating a different, you know, concept of testing, because testing, like I said earlier, you know, testing is so important and quizzing your brain and being able to recall that information, that's how you actually get it into your brain. Right. But wait, I wouldn't call what we do remotely testing because, you know, code challenge, you're just basically trying to use the tool that we, you know, we're giving you tools and you need to practice those tools so that you can commit them to memory. Yeah. So practice maybe is a, is a more accurate like overarching term. Yeah. Yeah. And I think it's cool because looking back at my years in school, like the tests that I used to take was I do the tests and I hand it over and I forget about it for a week. So I don't have that immediate feedback that we get code school or courses we offer, right? So if you type something and get it wrong, we tell you why you got it wrong and we offer you a hint, we offer you assistance so you can get it right at that moment, right? So it's not like you're handing in a piece of paper and you're hearing about it, you know, a couple weeks later or you're not even hearing about each individual submission. You just, you just get your score or whatever. Hey, you got an F, whatever. So, but, you know, but why did I get an F? Like, can you answer my question about that one specific thing? You know, in code school, we can do that through our courses. You know, that's another insight that I think it's really important about the learning process. That is, you know, if you learn something just for the sake of testing on it, you know, and not actually using it, right? That's just cramming, you know, and cramming doesn't really stick with you. I mean, think back to you, to your school days, anybody who's listening to this right now, you know, think back to it to a test that you crammed for. How much of that do you remember right now? Like, little to none, right? There may be one or two things that stuck out to you because you have some sort of a so shoot of memory with that thing, but little to none of what we cram actually sticks with us. Yep. So you mentioned that you guys are working on stuff all the time. You do one course a month. How do you maintain the focus on that one course per month? I guess what I'm asking you is, what do your days look like a typical day in each of your roles, I guess? So right now, I am currently working on the next JavaScript course that we're going to be releasing. And a huge part of our work for the content development team is organizing our material using keynote, right? So we use keynote here for a lot of what you see in the videos. So all the animations, all that stuff that you see going on behind each teacher, that's you know, keynote. So for the past couple of weeks, I've been spending a lot of time just getting my content from my content book that I gather and listed all the important topics that we're about to teach on this course and putting it on on keynote. So yeah. Actually building presentations or. Yes, exactly. And that's, you know, a lot of people would look at it initially and say, oh my god, that sucks. You're working on keynote. Your developer, you should be coding or rather be coding. But there's a huge part of me that is just a creative. I like creating things, right? I like creating code. I like creating apps. I like creating music. I like creating art. And I see keynote as a creative process. So creating a course, you know, using keynote. How do I express this thing in keynote? Could I use, you know, an error or a text or another visual or just code? So that's equally fun for me, I would say. Yeah. And I think, and when you work really hard at it, sure, it's tough. But then when you see the final product and you see it all put together at the end, it's like, it's like writing a book. You're like, you finally get to the end. You're like, oh my god. This is so exciting. Absolutely. It has so much of my essence, you know, inside and hard work inside this course. And look at all these people that are taking it and look at all these people that are loving it and are learning this topic. So it's, yeah, it's a lot of fun. You know, the interesting thing about what you're saying there to me is, is you're a creator, but even developers, you know, if you think that, if you're listening to the show right now and you think that developers, your only job is to code, you're going to be so early disappointed. That is not your only job. There's part of their job is to code, but a very large part of your job is to be able to communicate, right? Like, communications are fundamental to building anything really because you have to be able to understand communication coming from other people yet to be able to understand communication coming from, you know, your clients or your customers. But then you also have to be able to create things that communicate to other people as well. Otherwise, you can't present, right? You can't actually justify what you're doing in code, for example. You can't write documentation. You won't even be able to write good commit messages if you think that you can only focus on code. And I'm extremely guilty of this, actually. You can go back through my get history and just see stuff, like the word stuff as my commit message over and over and over because I'm not real at, you know, I'm not taking the time to say, okay, part of my job is actually communicating this work. It's not just writing the code, but doing the stuff around the code that supports it. Absolutely. Which goes back to what Greg said about looking at people that write blog posts, that can express themselves through text. And it's not only about expressing yourself through code. It's just about expressing yourself and communicating yourself in the best way possible. You know, anybody who is looking to go and speak at a conference, you're going to need to know keynote or something similar, right? You'll use like the slide slides.js or something. Right. Yeah. But ultimately, you're going to be building presentations, you know, like that is a important part. I would recommend pretty much any developer. You should know how to build a presentation if you're going to be serious about your development career. That's a bold statement, maybe, but I think it's one that any developer who is serious about their career probably knows how to build a decent presentation. Yep. So, what about you, Greg? What does a typical day look like for you? Well, I'm usually involved in different phases of the development process sometimes. So I'm checking in with a lot of the teachers that are teaching various subjects. So right now, I'm working with Alyssa. We were going to do a D3 course, but now we're realizing we need to teach SVG first. And might as well create like an SVG course because other people might just want to learn just that instead of also D3. And then I'm also meeting with Paul on a web design course. So we're trying to figure out how to bring it in right now. We're at the very beginnings of that. We're trying to figure out level one, level two, and figure out the right balance between just making a course about user interface and also bringing in some user experience, which Paul is like an expert in, so we're trying to figure out the right balance there. So I'm working with these guys on their course outline and their course book and then their slides when they get ready for it and then helping them going through the review process over and over again. Yeah, so do you do like granular feedback on slides sometimes? Oh, yeah. And yeah, usually, yeah. So that's people give me the slide decks at the end of the whole review process and it's like my chance to go through them and I am probably just the most picky, I guess, when it comes to teaching stuff. So I go through that and I have tons of notes and then we go through polish one more time. Oh, yeah. And also working on a great MongoDB course right now. So I've been working with Joel who's putting that one together and really stoked about that course. Yeah. Very interested, especially once you guys do the D3 course, I'm interested in SVG overall, but I really love, I'm not sure how to say his name. I just read it all the time. Mike Bostock, is that right? Or is it Bostock? Bostock? No, I don't know what it is. He's the guy who created D3, right? He's at New York Times and he recently did an AMA thread on Reddit and the entire thing is just fantastic. Nice. I'll include that in the show notes, but just a really interesting, very smart guy. Powerful framework too. Or I guess library, D3 is a library. It feels big enough to be a framework sometimes, you know? Awesome. Well, this has been great. I have a couple of questions that I ask all of my guests on the show. So I'm going to go ahead and ask those to each of you individually, I guess. The first question is, if you had 30 seconds to spend with every developer or any developer to give them some kind of advice, what would you say to them? Subscribe on code school.com. That takes three seconds. That was shameless self-promotion. Can you get really tacky on this one and really nerdy and really picky on this one? Go, go, go. I'll spend 30 seconds showing them how to map capslok to control. Oh, yes. Thank you. I do that on every computer that I touch, every single one. Yes. Oh my goodness. Every time I need to show something, someone something on their computer and I start talking on their computer. And then I see like capital letters all around. I'm like, no. Okay, let's go deeper down the rabbit hole. Go ahead and make your leader on Tmux if you use Tmux, control space. And then when you map capslok to control, you can do like pinky thumb. If you look at a keyboard right now, you'll know what I mean. But if you want to jump to something in Tmux, that is so nice to have to just have that control in that pinky position is so nice. That is a good one. I have to give Tmux a try. I used to use cream a long time ago. Yeah, oh yeah. I forgot about that. Yeah. I use Tmux because it's like it's the VIM community's favorite thing to use for that. Right. I don't have any other justification. Other than I can do a.com file and it like I can do my own customizations or whatever. Gotcha. Okay. I got my 30 seconds ready for realist time. Do it. All right. First thing I would say is make sure you're involved with your local community, right? So there's probably user groups in your area, if not Google around for it, check meetup.com. If you're into Ruby, search, you know, and in Orlando, search Orlando Ruby, find the user's group and you know, go hang out with the user's group. All the best jobs you'll ever have, you'll find the user's group because those are the people, you know, people like hang out there, love what they do and are passionate about what they do. That's also where you find all the good mentors is check out those Ruby user's groups. Also of course, check out, you know, our podcast based on what you want to learn, keep up to date with. There's Ruby 5. Oh, you're going to help to help me. Five minutes of JavaScript, iOS, bytes and front end 5. Oh, I did know them all. Yeah. And then also check out codeschool.com if you want to learn on there. I'm glad you mentioned the local community because I wanted to ask you during the rest of the show. So we'll do it now. Why not? Hey, I'm the one who makes the show. I can make this call. That's pretty cool. In terms of finding a mentor, you know, if you're going through code school, if you're going, let's say you're going through the Ruby path on code school and you want to find a mentor that maybe, I don't know, they've either, they either know Ruby or they're familiar with code school and they've gone through Ruby path before you. What would you guys recommend looking for in a mentor for that kind of scenario? I recommend checking out this very cool service called hack hands. They can connect you with a mentor that can help you answer your questions in which you will find hack hands. And you pay a little bit of money, but then you can get access to a mentor or just go to your local users group if you can. Find someone there too. So hack hands, okay. So what kind of person would I look for in a mentor? You know, am I looking for somebody who has more experience in the industry? You know, I've heard that the best teachers for beginners are people that are just beyond beginner level. Oh yeah. And they've just learned the stuff that a beginner needs to learn and maybe the tools have progressed since the people who are more seasoned were beginners. That's a really good point. You know, don't go with, yeah, don't assume that you need somebody who is a master to help mentor you. I like that idea. And I think there's two different kinds of mentors really. There's mentors for the long term, like trajectory of your career or maybe even personal life kind of mentor. And then there's the concrete learning, you know, absolute objectives kind of mentor. They they they had there's another name for these. I can't remember. There's a distinction. It's like, oh, I don't know. Maybe it's just teacher. I'm not sure what it is though. All right. So the next question that I have is if if you could have people ask you or talk to you about one thing more often, what would that thing be? In other words, you know, what do you wish more people would ask you? Or another way of rephrasing it if this helps kind of frame it better is, you know, what is something that you care about that you wish you could talk to people about more? One thing I want to spend some more time documenting and presenting on is creating the culture that we did here and how we went about it because I think without really trying that hard or really knowing in some cases what we were doing and why it was good, we managed to create this environment where people aren't afraid to be themselves and aren't afraid to speak up and it's everybody sort of trusts each other and works hard and has fun. So all that stuff is really important. I'm pursuous excellence and well, all this stuff. So I'm really, I really like that. One thing I'd like to think more about and challenge myself more about is how to inspire people because I think one thing that I realize that I don't do quite enough that some leaders do is speak boldly. I think as an engineer, it doesn't come naturally to make statements that aren't that might not be completely true. So I might say we're going to create the best and I'm confident we can create the best way to do this. This usually don't hear engineers say shit like that. But I think I need to figure that out. Because there's something about saying best that feels difficult. It kind of falls out of my mouth wrong. There's something that keeps me from saying that. Engineers know one thing is better than the other but it's probably not the best. Yeah and there's so much quantification in what we do that it's easy to say what are the real likelihoods of it being the best. I want to dialogue with more people about being their authentic selves. We spend so much time worried about what other people think naturally as humans as well as sugar coating things so we don't hurt people's feelings. But if you're in an authentic environment and you're with a group of people that are trust that you have their best intentions in mind and trust that you're not playing a game and trust that if you're going to make something that sounds like a criticism, it's not that they're putting you down, it's just that they're trying to collaborate effectively. The most authentic work environments are ones where you simply can speak your mind and get shit done and collaborate dramatically and effectively with lots of people without having to sugarcoat anything to worry about someone's ego. There's a whole talk in there. Oh, most definitely. I look forward to seeing that one at a conference somewhere. Awesome. Well, any of the thoughts? That was a long one. Sorry. That was a good one. Yeah, there's no way I can talk that. You're going to say, what do you want to talk about more about? Yeah, I was going to talk about mapping another key in the keyboard but now I'm just kidding. I'm just kidding. I guess maybe talk about some of the soft skills involved into being a developer, some of the stuff that we talked about, communication, being able to admit that you're wrong, being able to suggest something and all that stuff, which is related to what Greg said too. You and I should put together a talk on that topic. We're joking because we actually did put together a talk together on that topic like a wow back. Things they don't talk about in school or something. Yeah, like how to, everything you need to know to be a good coder besides the coding part. There's just so much you need to know. Like you were saying earlier, it's a communication stuff. Yeah. Because people think going back to something where they talked about all you need to do is learn how to code and boom, that's it. If you learn how to code, you're going to get a good job and that's all you need. But there's so much more behind that than, yeah, I'd love to be able to talk to people more about that. Yeah, I like the concept of, you learn a lot in high school but about half of it you learn on the bus. Exactly. Yeah. It's this idea that you're dealing with people and if you can't get people to like you, for example, like if you're bad at just being a likable person, it's going to be tough for you. Right. Yeah. Yeah. So much stuff goes back to childhood. It's ridiculous. Yeah. Great. Well, thank you guys so much for coming on. Do you have any final thoughts or recommendations? Anything else you want to tell the listeners of Developer Tea? No, thank you very much for having us, Jonathan. This was a pleasure. It's been great. Yeah. Yeah, I've really enjoyed it. Thank you guys for coming on. No problem. Thank you so much for listening to my interview with Carlos and Greg. I hope you enjoyed it as much as I did. They are incredibly smart people. They are making a great product at code school. I hope you will go and check out codeschool.com especially if you are trying to learn to code. They have a lot of great content built especially for you. Go and check it out. And if you are seasoned, of course, there are quite a few interesting courses that you can take even to expand your existing knowledge. Go and check it out codeschool.com. Thank you so much, Greg and Carlos, for taking the time to talk to me on Developer Tea. Of course, if you enjoyed the show, I would appreciate a rating and iTunes. This is a huge help to the show. It helps other people find the show more easily. Of course, you sharing your opinion is such a strong statement about how you perceive Developer Tea. It helps the show out immensely. Please take some time to go into iTunes and leave a review. Of course, subscribing to the show is just as easy as clicking a button and whatever your favorite podcasting app is. So I would love for you to subscribe as well because that means you won't miss out on future episodes of Developer Tea. Thank you so much for listening today. For more notes, you can be found at spec.fm and until next time, enjoy your tea.