Hey, everyone, and welcome to Developer Team. My name is Jonathan Cottrell. Today's episode is the second part of my interview with Carlos and Greg, Carlos Sosa and Greg Pollack 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. And you can find the show notes on spec.fm. So 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. So I hope you enjoy the interview with Carlos and Greg from Codeschool.com. The problem that I've run into in trying to promote the educational content for a consultant business, I actually work for a consultancy as well. And so often, it seems like, well, 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, right. I always target the developers and then still clients would land in my lap. 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. And that's mostly because the best clients do research on the technology they want to use. And they'll look at the technology ecosystem and who is in it and who speaks loudly in it. And that's how they find you. Yeah, I think it's this concept of establishing authority, establishing legitimacy. Right. They go and they ask a friend who's 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, right? Because who knows? I mean, consultancies, we work with all kinds of projects. There's no particular demographic of people that we're targeting with our consultancy. Right. 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. 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. Yeah, that's true. You know, maybe documenting the process is one step towards creating that educational content. Mm-hmm. 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 their 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 clear writing is a good sign of clear thinking. So they're definitely... It 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 CodeSchool. 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. 15, yeah. 15, 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've got one video editor. Oh, wow. Yeah. That seems like he probably has a pretty long day sometimes. Well, yeah. Does he? Yeah. No, I mean, I don't think so. It's not like he works his ass off. I mean, he 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. Yeah, operations. Those are the project managers, mostly. What else? We have an office manager. Yes. Oh, and 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 so much about culture. She's amazing. She's such a good addition. I never saw it coming. Oh, dude, support. We totally forgot support. God. I'm such an asshole. Yeah, we've got an amazing support team, an amazing support director, Joseph Perez. He's amazing. So we've got like four people on our support team-ish. And our developer team is like broken up into separate teams. We've got like the course dev team, and we have like the .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, do you guys, do you guys basically keep developers working together, or is there some cross-pollination between the teams? Oh, we put them on islands. They're not allowed to talk. Yeah, no, we have them rotating. They put themselves on islands probably. Oh, yeah, no kidding. But yeah, they rotate around. We try to keep it entertaining, because certainly coding, like creating courses, is a different kind of development from on the .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 is happy with what they're doing. I could talk about culture for hours. Yeah, 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 the concept of playing a course, right? Yeah, so we try to use, gamification terms and principles whenever we can, just because people don't want to take a quiz at the end of the chapter, but they'll take challenges at the end of the level, right? And just those terms. Some people just are allergic, like me, to chapters 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 everyone else did. I don't know that everyone else did. I don't know that everyone else did. I don't know that everyone else did. I don't know that everybody has that same experience. A lot of programmers end up going into programming because they're good at putting these systems together and maybe they completely hated school because they didn't test well. So now you're creating a different concept of testing because testing, like I said earlier, testing is so important. Quizzing your brain and being able to recall that information, that's how you actually get it into your brain. Right, but I wouldn't call what we do remotely testing. That's how we do it 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 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 test and I hand it over and I forget about it for a week. So I don't have that immediate feedback that we at CodeSchool, our courses, we offer, right? So if you type something in, you're going to 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 of weeks later or you're not even hearing about each individual submission. You just get your score, 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 CodeSchool, 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, that's just cramming, you know, and cramming doesn't really stick with you. I mean, think back to your school days. Anybody who's listening to this right now, you know, think back 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 associative 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 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, that we're about to teach on this course and putting it 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, you're a developer, you should be coding or I would 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 tool. Creative process. So creating a course, you know, using Keynote, how do I express this thing in Keynote? Should I use, you know, an arrow 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 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. Yeah. It's a lot of fun. You know, the interesting thing about what you're saying there to me 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 sorely disappointed. That is not your only job. Developers, 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. You have 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, 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 realizing, 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, to go and speak at a conference, you're going to need to know keynote or something similar, right? Maybe you'll use like this. What is it? Slides.js or something. Right. Yeah. But ultimately you're going to be building presentations, you know, like that, 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, that's a bold statement maybe, but I think it's one that, that any developer who is serious about their career probably knows how to build a decent presentation. Yep. So what, what about you, Greg? What does a typical day look like for you? Well, I'm usually involved in different phases of the develop, like course 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, with Paul on a web design course. So we're trying to figure out how to bring 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's 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 go through the review process over and over again. Yeah. So do you do like granular feedback on slides sometimes? Oh yeah. And yeah, usually the, yeah. So that's people give me these 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 had tons of notes and then we go through polish. And we're like, Oh yeah. And also working on a great MongoDB horse right now. So I've been working with Joel who's putting that one together and really stoked about that course. Yeah. I will be very interested, especially once you guys do the D3 course. I'm interested in SVG overall, but I'm, 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, he's at a, at New York times and he recently did an AMA thread on Reddit and the entire thing is just fantastic. Nice. If anybody out, 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, on the show. So I'm going to, I'll go ahead and ask those to you, 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, that takes three seconds. No, that was, that was shameless self-promotion. Um, can it get really tacky on this one and really nerdy and really picky on this one? Go, go, go. I'll, it's been 30, 30 seconds showing them how to map caps lock 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, and make your, uh, your leader on team mucks. If you use team mucks control space. And then, uh, when you map caps lock to control, you can do like pinky thumb, like, uh, you'll, if you look at a keyboard right now, you'll know what I mean. Yes. But if you, if you, if you want to jump to like something in, in team mucks, 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 a team mucks a try. I used to use screen, a long time ago. Yeah. Oh yeah. I forgot about that. Yeah. So I use team mucks because it's like, it's the Vim communities favorite thing to use for that. Right. I don't have any other justification other than I can do a.com file and, and it like, I can do my own customizations or whatever. Gotcha. Okay. I got my 30 seconds ready for real this 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 users 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 users group for me, you know, head go hang out at the users group, all the best jobs you'll ever have. You'll find that the users group, because those are the people that, 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, those Ruby users groups. Also of course, check out, you know, our, our podcasts based on what you want to learn. Keep up to date with there's Ruby five. Oh, you're going to help to help me five minutes of JavaScript, iOS bites and front end five. Oh, I did know them all. Yeah. And then also check out co-school.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 this show. I can make this call. That's pretty cool. And in terms of, of finding a mentor, you know, if you're going through Google, 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. And yeah, that's real time hack hands and you pay a little bit of money, but then you can get access to, you know, a mentor or just go to your local users group. If you can find someone there too. So hack hands. Okay. So what, 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, I've heard that the best teachers for beginners are people that are just beyond beginner level, right? Because you know, you're not going to be able to do it. You're not going to be able to do it. Because 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, don't don't go with that. Yeah. Don't assume that you need somebody who is a master to help mentor you. I like that. I like that idea. And I think there's two different kinds of mentors. Really. There's there's mentors for the longterm, 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. 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 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 and pursues excellence. And 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've realized 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. Right? So I might say, we're going to create the best and I'm confident we can create the best way to do this, right? You usually don't hear engineers say shit like that, right? So, but, but I think I need to, I need to figure that out. So. Yeah, because there's something about saying best that feels, I don't know, difficult, right? Like, it kind of falls out of my mouth wrong. There's, there's something that, that keeps me from saying that. Engineers know. You 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, like, what are the, what are the, 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, you know, naturally as humans, as well as, you know, sugarcoating 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, you know, if you're going to sound, 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, right? So 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. That's, there's a whole talk in there. Oh, most definitely. Well, I look forward to seeing that one at a conference somewhere. Awesome. Well, any, any other thoughts? That was, that was a long one. Sorry. No, it was a good one. Yeah. There's no way I can top that. You're going to say something? What do you want to talk about? I was going to talk about mapping another key on 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, you know, communication, being able to, you know, admit that you're wrong, being able to suggest something and all that stuff, which kind of is related to what Greg said too. So, you know, you and I should put together a talk on that topic sometime. We're joking. Because we actually did put together a talk together on that topic like a while back. Things they don't taught you in school or something. Yeah. Like, you know, how to, everything you need to know to be a good coder besides the coding part. Yeah. There's, there's just so much you need to know. Like you were saying earlier, it's the communication stuff. Yeah. Because people think, you know, going back to something you already 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. Yeah. Behind that, then, yeah, I'd love to be able to talk to people more about that. Yeah. I like the concept of, you know, you learn a lot in high school, but about half of it, you learn on the bus. Exactly. You know, like, 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, it's ridiculous. Yeah. Great. Well, thank you guys so much for coming on. Do you have any final thoughts or recommendations and anything else you want to tell the listeners of Developer Tea? No, thank you very much for having us, Jonathan. This was a, it 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 CodeSchool. 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 in iTunes. This is a huge help to the show. It helps other people find the show more easily. And 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 in whatever your favorite podcasting app is. So I would love for you to subscribe as well, because that means a lot to me. And I'll see you in the next episode. Bye. you won't miss out on future episodes of Developer Tea. Thank you so much for listening today. Show notes can be found at spec.fm. And until next time, enjoy your tea.