163 RR Education with Coraline Ada Ehmke and Katrina Owen

01:44 - Coraline Ada Ehmke Introduction

02:30 - Katrina Owen Introduction

05:00 - Katrina’s Teaching Tactics

Blaise Pascal quote
People Who Want To Learn
The Flatiron School

12:14 - Dealing With People

RailsConf 2014 - Artisans and Apprentices by Coraline Ada Ehmke

14:47 - Mentorship/Mastery

23:07 - Responsibilities to Community

24:47 - Organizations/Meetups

ChicagoRuby
Women Who Code
Girl Develop It
Chicago Women Developers
LGBT Community Chicago
“Don’t Be An Asshole” - The Flatiron School
This American Life Episode #370: Ruining It for the Rest of Us

29:26 - “Bad Apples”

34:26 - Mentor/Teacher Relationships

38:20 - Paid Coaching

AirPair

42:50 - Direct vs. Indirect Mentorship

53:30 - Bringing Up Junior Developers

01:01:59 - Putting Code Online

Book Club

Refactoring: Ruby Edition: Ruby Edition (Addison-Wesley Professional Ruby Series) by Jay Fields, Shane Harvie, Martin Fowler, and Kent Beck

Refactoring in Ruby by William C. Wake and Kevin Rutherford

Next Week

Staying Sharp with Dave Thomas

Transcript

KATRINA: I just have to go tweet an overheard. I’ll be right back. [Laughter][This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]**[Snap is a hosted CI and continuous delivery services that goes far beyond letting you do continuous deployment. Snap’s first class support for deployment pipelines lets you push any healthy build to multiple environments automatically and on demand. This means with Snap, you can deploy your staging environment today. Verify it works and later deploy the exact same build to production. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many, many more. You can also use Snap to push your gems to RubyGems. Best of all, setting up your build is simple and intuitive. Try Snap free for 30 days. Sign up at SnapCI.com/RubyRogues.] **CHUCK: Hey everybody and welcome to episode 163 of the Ruby Rogues Podcast. This week on our panel, we have James Edward Gray. JAMES: I’m not currently strapped to the ceiling. CHUCK: David Brady. DAVID: I’m tired. Make up your own intro joke. AVDI: [Laughs] CHUCK: Avdi Grimm. AVDI: Hello from Pennsylvania. CHUCK: Saron Yitbarek. SARON: Hey everybody. CHUCK: I’m Charles Max Wood from DevChat.TV. And we have two guests this week. The first one is Coraline Ada Ehmke. CORALINE: Hi everybody. CHUCK: And Katrina Owen. KATRINA: Hello from Santa Monica. CHUCK: So Coraline, you haven’t been on the show before. Do you want to introduce yourself? CORALINE: Sure. I speak a lot at conferences and do a lot of mentoring and training and teaching. And I’m really passionate about bringing new people into our field while preserving our values. I’ve been developing for about 20 years, which makes me 28 at my last count. JAMES: [Chuckles] CORALINE: And I’m currently working at Instructure doing open source educational software. CHUCK: Awesome. I didn’t realize you work for Instructure. CORALINE: I’m brand new. I just started there two months ago. CHUCK: Oh. So, we’re practically neighbors, even though you’re in wherever. CORALINE: I’m working from the satellite office at Chicago, but I’m in Utah every other month. CHUCK: Awesome. DAVID: Oh, wow. CHUCK: Side note. Dave and I want to do lunch. DAVID: Yeah. CHUCK: Alright. CORALINE: Let’s do it. CHUCK: And Katrina, what have you been up to for the last six months? KATRINA: I quit my job. CHUCK: Yay. [Laughter] KATRINA: Well, it was really sad and really awesome at the same time. It turned out I’m not a very good teacher, which probably didn’t surprise people who knew me really well but came as a little bit of a surprise to me. So anyway, I learned a ton at Turing. I had a lot of fun. I think I was able to help a lot of individuals and I did a huge amount of work on there, on revamping the first six weeks’ worth of curriculum to help the ramp up period of teaching people how to program. So, that was awesome. But I can’t actually handle people all day, every day. [Chuckles] So, I had to bail. And so, I’m back to shipping code all the time, every day, all day. And it’s awesome. And I’m working for Splice out of Santa Monica, who makes source control for electronic music production. CHUCK: Interesting. JAMES: Wow, that’s so awesome. Source control for electronic music production. I’m trying to imagine that in my head. CHUCK: Git push midi. SARON: Gee, I find that really interesting that you said you’re not a good teacher because I was watching your talk at, was it Railsberry from 2013? When you were explaining testing, and I watched that and I was like, man, that’s a really good explanation. She must be a great teacher. [Chuckles] SARON: So, I’m very surprised that you didn’t enjoy teaching. KATRINA: So, it’s interesting. My talks, I prepare for them for so long. And I probably shouldn’t give this away. This is my secret to giving a good talk, is prepare forever. JAMES: [Chuckles] KATRINA: And so, for a 30-minute talk, I will spend months preparing the content, working on the slides, and going through over and over and over again to figure out the flow so that I can actually tell people something that makes sense and makes them not feel stupid. But on the fly, in person, trying to come up with a way to explain something to a group of really, really, different disparate people, I don’t have that skill. SARON: Huh, interesting. Okay. CORALINE: I actually think that homeschooling really influenced my ability to work with people and teach them, because I tend to do really well in small groups and definitely one-on-one. And I think the patience of being a parent and working with a child has really influenced both my interest and my ability in teaching. JAMES: Coraline, are you saying you were homeschooled or you’re homeschooling your children? CORALINE: We homeschooled my daughter for about ten years. JAMES: Gotcha. Yeah, cool. CHUCK: If you can’t tell, we’re talking about education today. [Chuckles] JAMES: Yeah. We just jumped right into it. So Katrina, I would actually say the amount of energy you put into your talks to make them understandable is the definition of good teaching. It doesn’t apply well on the fly. I get what you’re saying there. But that you know to bring that down to an understandable level is something, what’s the famous quote? Sorry about the link to this letter. I didn’t have time to make it shorter? CHUCK: Yeah, I think it’s, I didn’t have time to write you a short letter so I wrote you a long one. Mark Twain said that. DAVID: Blaise Pascal. Yeah. CHUCK: Oh, Blaise Pascal? DAVID: Yeah. CHUCK: Quote wars. JAMES: [Chuckles] DAVID: No, I love hearing… I don’t love but I’m going to say that anyway. I love hearing Katrina say that she’s a bad teacher because I went to gSchool and watched her teach and interact with students. And I observed how good she is at it. And I also observed how much it took out of her. And so, I agree and violently disagree with her self-assessment that she’s not a good teacher. JAMES: I too find it exhausting. [Laughter] JAMES: Just the constant social interaction takes a lot out of me. SARON: But is it satisfying? Do you feel really good about it afterwards? JAMES: That’s a good question. I’ve definitely had classes where I really felt like I did well and then classes where I really didn’t. And I think for me, the biggest challenge has been I don’t do it regularly and people don’t come to me for a specific purpose. So, I think for me the challenge has very much been getting in front of the right group of people who want to learn whatever it is I’m trying to teach them at the time. And when I do that well, it goes well. KATRINA: That’s really interesting that you bring up the want to learn piece. I think that’s one of the things that the boot camps like Turing [inaudible] boot camp and all of these shorter term academies do well is that they bring in people who really, really care about this and want to learn. Whereas in other teaching situations, if you’re forced to be there, it’s not going to be very useful. JAMES: Yeah, so I actually want to talk about that a little bit if we can, because I have this opinion. I’ve watched these schools, the Turing and Flatiron Saron went to, and stuff like that. And I look at the students they take in and the things those students do. And I don’t mean to say this in a bad way, and I can’t think of a way maybe not to make it sound that way, but I’ll do my best. It seems to me, after looking at what those students do to get in, that those students becoming developers is almost an inevitability at that point. SARON: Cool, interesting. JAMES: I feel like the schools select for the sure thing. Is that crazy? I think that’s a great thing. I’m not saying that as a bad way. It’s exactly what I was just saying about me getting in front of the right group of people. When I have the right audience that’s ready to go, then we can just go and I can do that. CORALINE: I think that’s true to the degree that they have the energy and enthusiasm to pursue it. But I honestly don’t think that everyone has the problem solving capability to be a great developer. JAMES: That’s an interesting point. Let’s talk about that. CORALINE: I think that one of the interesting things that I’ve noticed in my career is that people who come into software development from nontraditional backgrounds bring with them problem solving sets that are incredibly potent and incredibly unique, depending on their individual backgrounds. And I think that people who come to software development without some sort of innate problem solving ability or problem solving abilities that they’ve picked up through some real-world experience are going to struggle more, because they don’t have the mental toolbox to deal with the challenges that are placed before them. KATRINA: This matches my experience very, very well. We have students who we didn’t specifically break down how, we didn’t work on a toolbox for problem solving specifically. We gave people a lot of exercise that might help them learn problem solving ability and we gave them big problems that they had to learn how to break down. But towards the end of my year with Jeff at gSchool, we discovered that there were people who had gone through six months of training and still couldn’t break down a problem because we hadn’t been specific enough about how to approach it for the people who didn’t already have some sort of innate or learned skill in how to break a problem down. SARON: That’s a really good point. And that’s something that has been brought up by many other boot campers that I know, is boot camps not necessarily addressing the, “How do you break down a problem?” I think it’s really easy for programmers to say, “Oh, you just have to break it down.” But what does that mean? What does that involve? And I definitely think that for me, having come from a more science background where I did biochemistry and organic chemistry and taught and did research, that was a skill that I already had and that made my journey so much easier. And one thing that I worry about is in terms of selection process for boot camps, are you picking people who already are familiar enough with computer science or with that skill that, like you said James, that they’re probably going to do well anyway? And if you are, you’re limiting who the future developers are going to be. And that, I find very troubling. CHUCK: Well, I have to push back a little bit there, and that is, is it the job of the boot camp to teach people how to solve problems? Or are they teaching people who already know how to solve problems how to program? JAMES: So, that’s a great question. And I would say, yes. It is our job when we teach programming to teach problem solving. In fact, I would argue that the programming part, the language that you’re using, that’s the insignificant bit. That’s the bit that… think about it. Ruby has 60-some keywords. We’re not talking about a massive language here. We’re not talking about French. We’re talking about a small little thing. Sure, there are lots of methods and various syntax gotchas that you’re going to run into eventually. But still, compared to the ability to take a problem, divide it, make some plan for getting through it, moving to this step, to this step, to this step, that’s the hard part about being a programmer, learning to think like a computer or things like that. And once you can do those things… that’s why experienced programmers, when a new language like Dart or Swift or whatever comes out, the experienced programmers sit down, they play with it for a few days, and they’re off. Not writing expert code immediately of course, but it’s that they’ve already done the hard part. They’ve already learned how to think about problems and think like computers. And that is the heart of programming. CORALINE: I have to agree and disagree with you there, James. I think that there’s actually a dichotomy in terms of the heart of programming. You have to know how to talk to a computer. You’re absolutely right about that. But you also have to learn how to talk to people. And I think that’s another skill that boot camps have a responsibility to teach, because as programmers we’re generally not working in isolation. And if we don’t have good social skills, if we don’t have empathy, I think that we’re not going to be the kind of developers that other people are going to want to work with. DAVID: That’s right. CHUCK: I still want to push back here just a little bit, because it feels like, and I’m not saying you’re wrong, but what I am saying is, these boot camps, a lot of them are selling that you can become a programmer in three months or six months. And so, what I’m wondering is, is it realistic to teach all of the syntax and structure that we need in order to solve the problems, along with how to solve the problem and how to interact with other programmers, in that timeframe. Or should these boot camps be longer in order to accommodate that? And how does that affect the overall atmosphere of boot camps if we did that? KATRINA: I have an answer to that. Yes. JAMES: [Laughs] DAVID: Good answer. JAMES: Wait, what? KATRINA: [Laughs] Yeah. I think that it is the boot camps’ job to teach those three things, the how to communicate both with people and computers, and how to break a problem down. But in three or six months, you’re not going to become a fully-fledged programmer. You’re going to become some sort of junior seed of a programmer that is now capable of taking their education into their own hands and learning in an environment that is perhaps not specifically geared towards education but that nurtures people who are willing to take responsibility for their own learning in a work situation. CORALINE: I would add to that, that if we don’t catch people at the very beginning and emphasize to them that values such as empathy and community, citizenship and so on, are important, they’re probably not going to pick that up in the workplace. CHUCK: So, should they extend the timeframe a little bit in order to accommodate that curriculum? CORALINE: I would like to see boot camps become a resource for people as they develop their career. Not just a way into the field, but actually a way of supporting them and sustaining them as they move through various plateaus of learning and advancement. KATRINA: I want to hear so much more about that. CHUCK: I was actually going to ask about… I was holding off a little bit to ask about this, but yeah. What does education look like for people who have been doing this for a while? And that segues into what your vision of boot camps, when they’re that kind of a resource as people move through their careers. CORALINE: In the talk that I gave at RailsConf, I compared boot camps to the guild system of 12^th century Europe. And I think that one of the things that the guild system did right that I think we can learn from is that they had the boot camp period where you worked for a master for a certain period of time to learn the craft. But you were actually guided through your career and supported through your career all the way up to you becoming the master as well. I would like to see boot camps become a segment or a part of a larger educational effort that actually supports people throughout their entire careers. I think that at every level, we need support and at every level we have learning opportunities that should be taken advantage of and should be fostered. So, I’d like to see us pick up more of that. I think the boot camps are just a first step in that direction. KATRINA: So, what does the bridge look like, between the boot camp and… how do you extend that metaphor, if you will, into the modern day boot camp programming/engineering type world? CORALINE: My word for that is mentorship. CHUCK: Yeah, but it seems like the 12^th century guild model, it had a lot more structure than what I envision as mentorship which is a whole lot more ad hoc. Is there some structure that we could put around that to actually make it pay off in the way that we want it to? CORALINE: I really think that if we hooked people up with resources and people who cared about their ongoing development when they’re at that early stage, so for example at Dev Bootcamp, there’s a mentorship program. And the way it used to run was every mentor had two boots that they worked with. And I still work with one of the boots. [Inaudible], Feministing on Twitter, I still work with her. Not so much in a mentorship capacity, but in a friendship and co-working capacity. And I care about her ongoing development. And I think she was introduced to people who cared about her ongoing development and the impact that she could make on the field. And I think that if we put those sorts of resources at people’s disposal, that they can take advantage of as they progress. I think we could formalize that a bit in terms of hooking people up with mentors who are very much in line with what their goals are or are role models to them. I don’t think we need to formalize it to the level that guilds did. But I think something less informal than what we have today would serve the community and the individuals much better. DAVID: Yeah, I was going to point out that it seems like around 1999, 2000, Y2K that time period, we started seeing extreme programming, pragmatic programmer, that kind of stuff coming out. And the message was like an inverse mentorship, basically. The message was you are responsible for your own education. A craftsman is responsible for maintaining their own tools and keeping them sharp and that sort of thing. Pragmatic programmer explicitly includes a chapter on your knowledge portfolio has a half-life of 18 months, which means half of what you know right now will be useless in 18 months. So, if you’re not continually learning, you’re continually falling behind. And I took that very much to heart and dove headlong into finding mentors and finding people that could teach me, and finding new languages that could make me, force me to grow. And I like what you’re talking about, about guilds, where we’re actually now looking at this in a forward-facing mentorship where we… I just said forward-facing and now I’m going to say turn around, but where you turn around and say, “Okay. Now I’m going to mentor those coming behind me to make it easier.” In 1990, your only option was big education. Go to a four-year university and get a CS degree or whatever. And being a self-taught programmer was a weird way to tackle that. And Katrina just posted in the chat channel, a good way to say forward-facing is pay it forward. I like that. That’s really good. Yeah, so to make it a forward-facing mentorship model is to pay that forward to other people coming up. JAMES: I’ve been reading ‘Mastery’ by Robert Greene, because Katrina told me to and she’s still teaching me things. But he talks a lot about how in modern society we have this idea that if we didn’t do it ourselves, that that’s somehow lessens it. There’s pressure on it. Well, you should be able to take this programming book and figure it out. And if you can’t do that, then that’s a lesser thing. But he talks about how silly that is. Having a mentor as somebody that you have this relationship with, like Coraline’s discussing, is this emotional investment on both sides. And because they’re invested in you and because they know you, they can tailor the path in front of you and move obstacles out of your way at the right time, or tailor the instruction to exactly what you need. And because of that, you can actually learn much faster, because the instruction is tailored to you and specific. And it’s not without faults of course. The mentor system also has problems. But still, it’s a very valuable way to onboard and level somebody up at a great speed. KATRINA: One of the other interesting things with mentorship is that if you are in the same room with another person who is very expert at something, you’ll notice that they do things and they don’t understand what they’re doing. They know it so well, they have this deep instinct because they have years and years and years of experience and observations to build on that they will be doing things that they’re unable to articulate the reason for why they’re doing that. Or they’ll be unable to explain it. But because you’re there and you can observe, you can start to imitate them. And having the conversation, both imitation and having the conversations with them about why they do the thing, are both things that can help them discover why the things they do work. And you learn to do the subtle things that work. CORALINE: I think that actually works both ways, too. When I work with someone one-on-one, I tend to adopt the Socratic Method. And so, instead of saying, “What you should do is blah,” I say, “what do you think we should do to solve this particular problem?” and I like to listen to their solutions first and then question my own solution. Because I actually think that I have a lot to learn from newcomers who have a different way of looking at a problem. And a lot of those instincts that we evolve may not be the best way to do things all the time or the best way to model a given problem. So, I think education, when you’re in that one-on-one situation, is definitely bidirectional. KATRINA: I completely agree. And I’m trying to learn how to do this much, much better. I tend to monologue and I tend to be very autocratic and directive and say, “Do this. Do that.” But asking the question is such, it’s a much, much, much better way of allowing someone to discover the answers for themselves. And often, you will be surprised at the things that come out of it. JAMES: I agree. DAVID: James and I were talking a week or two ago. And he introduced me to the concept of if you’ve got a solution that’s worked forever, you’ve got this good idea, but when do good ideas expire? And how do you know when your good idea is old and busted? And you’ve had this great way to do it and you know how to do it and you’ve done it for years and years and years. And then all of a sudden you realize, “Wait a minute. I’m a generation behind current thought.” How do you know that? And a great way is yeah, interacting with somebody who is junior, who’s going to question what you’re doing and say, “Why are we doing it this way?” JAMES: I saw a great gist once. There was a hack due to some issue in one of the versions of Mac OS X or something like that breaking. Some part of the Ruby ecosystem. I can’t even remember the details. But they had written a gist and it was a little bit of shell code that worked around the problem or whatever. But they wrote it in such a way that when to problem was fixed, it would blow up so that you would remove the thing that they stuck in there. DAVID: Nice. JAMES: And I thought “That is so clever.” They made their thing self-expiring, that it would fix itself by breaking, in this case, when it was no longer needed. How cool is that? SARON: You know when we talk about mentorship, Coraline I went to your RailsConf talk. I thought it was really well done. I really enjoyed it. And you talk about apprenticeship and mentorship and paying it forward. I wonder in the context of boot camps and individual programmers, whose job is it, whose responsibility is it? It is the boot camps? Is it me as a developer? Is it the companies that will in the future profit from having more developers who are skilled? How do you think about that responsibility? CORALINE: One of my key values as a developer is good citizenship. And I think that really fostering the new people who are entering our field is an incredibly important responsibility that all of us, all of the individuals and groups that you mentioned, have a responsibility for. If we want to preserve the culture of the particular group that we’re in, like for example the Ruby community, we have to ensure that new people who are coming in are instilled with those same values. And we want them to be successful so we have to make sure that they have the right skillset. It’s a shared responsibility, because they are the people who are coming in and going to be representing the community. And they really represent the next generation of developers. If we don’t foster our values as well as our skills in them, then we’re obsoleting our culture. CHUCK: So, how do we do that? It seems like the answer is at least partially communication in the way that we do that. And it’s the same with when David was asking how do we know it’s a generation behind? And it’s, well, you talk to the people who are in the trenches and you find out. But yeah, how do we instill those values into people and avoid, I don’t have a good term for it, but the kind of people that I worked with at one of my jobs. They just showed up and collected a paycheck and that was all it was really about. And things could have been so much better for them at work and better for me at work if they had been a little more involved. CORALINE: I think one of the ways that I personally have tried to do that is to ensure that the people I work with and are mentoring at a learning capacity get involved with organizations in the local area, the ChicagoRuby meetup for example, or Women Who Code, or Girl Develop It, or Chicago Women Developers. My focus is more or less on women and people on the LGBT spectrum. But connecting with other people who are there and who are doing active work to promote certain segments of the community, also giving them speaking opportunities and teaching opportunities. It’s really easy to be an assistant at, for example a Girl Develop It class where you’re teaching someone Git or teaching someone JavaScript and really getting involved and giving back really, really early on. Even at the point where some people think they don’t necessarily have much to give, showing them that they really do and enforcing this good habit from the habits of good citizenship. CHUCK: So, you have to catch them early and then do that stuff? CORALINE: I think that that has to be one of the first things that they learn at the same time that they’re learning syntax. They need to learn how to interact with the community and how to be a good citizen. DAVID: Can you teach that? Or do we just try to select for that? KATRINA: Dev Bootcamp teaches it. They’re good at it, too. DAVID: How? How? KATRINA: I don’t know. I didn’t go there and I wish I knew [chuckles] because I need empathy so bad. JAMES: [Chuckles] KATRINA: So, Dev Bootcamp, one of the founders was a counselor. And so they know a lot about interactions and helping people become better at it. CORALINE: Dave Hoover actually runs, there’s a once a week empathy workshop for all the boots at Dev Bootcamp. SARON: Yeah. At Flatiron School, we actually had this one lecture. It was my favorite lecture. It was called “Don’t Be an Asshole”. [Chuckles] SARON: And it was great. It was 30 minutes. I ended up actually kind of in tears at the end of it. But it was talking about the responsibility that we all have as we enter programming to be inclusive and to be open-minded and to not just take that initiative on our own but to call other people out when they are not being inclusive and when they are putting other people down. And that was very early on in the program, so it really, really set the tone for, we don’t tolerate assholes. And our goal is to be the best and to bring out the best in other people. And I think that message was emphasized by the fact that every Friday we have what we call Feeling Fridays and we talk about what we’re going through and how we can help and support each other and the emphasis on pair programming. And like Dev Bootcamp, we’re very involved in the community and giving talks and giving back. So, I think that earlier we talked about, do you make time for this? Do you add on extra weeks or months to teach the citizenship part? And the thing is I don’t think that it takes an extra curriculum. I think it’s something that should be built into every activity that you do, to every app that you build. I think it’s just part of how you learn and it shouldn’t necessarily be a separate skill that you take a week to master, so to speak. KATRINA: Totally agree. There’s another aspect to this. I was reading some research, probably yesterday I think, about how the bad is stronger than the good in the sense that we experience negative emotions. They affect our life. And they measure it as 5 to 1. We need five times as many good experiences to outweigh one bad experience. And that this goes across all parts of our life, from the really insignificant to the really, really huge life challenges. JAMES: That’s funny, because I was listening to a This American Life episode the other day. It’s an old one called ‘Ruining It for the Rest of Us’ I think. It was about these studies they did where they would have these groups and they would set them with some 45-minute task. And then in some groups they would introduce a problem personality, so someone who was lazy, or was depressive, or whatever. And this personality was actually just an actor that was a bad apple, as Katrina says. And this person was an actor playing a part. And it just, it’s amazing how it would just tank the entire group. And it was almost flawless. Now, it was turned around in one case that they pretty much had to throw out as an outlier. But in that special case, there was a very positive influence in the group, a person who was just used to diffusing situations and getting people to work together. And it turns out that that person’s, I think it was their father, was a diplomat. And so, they had grown up in that environment and knew how to do that very well. And in that one case, they were able to counter the effect of the bad personality that was introduced. But most of the other cases, that doesn’t happen and it drags the entire group down. DAVID: I think everybody has a bad memory of doing the group project in school. JAMES: Oh yeah. DAVID: I wonder if that’s a testament to the bad apple being so effective at tanking the group that you become the bad apple just thinking about joining the group. [Laughter] CHUCK: I think we’ve all been on teams where there was ‘that guy’, right? DAVID: Yeah. CHUCK: And nobody wanted to work with that guy because, whatever. It could have been personality. It could have been something else. And it just really sucked to be on the team with them. CORALINE: In a way, that bad apple is going to be working with you on some team that you work with in the future. So, maybe it’s a good idea to learn how to work with them early on. JAMES: Yeah, I think that’s true a lot of the time. And I think a lot of the time communication can mitigate the problem, or at least help. And then there are some times where you just have to realize the value of not working with that person, I think. AVDI: Yeah. There’s a big culture, team culture factor here, which is if you have somebody who is clearly dragging other people down by their attitude or something along those lines, and nobody in management is doing anything about it, that does say something about the team culture. And there’s a limit to how far you can go if the people who are managing things don’t care about that kind of behavior. And if you see a lot of that behavior, it might mean that the whole company, or at least the whole group, has a culture problem that those in charge don’t care about. And I think there’s a limit to how far you can go towards reforming that if you’re not in charge. SARON: Do you guys think that bad apples know that they’re the bad apple? KATRINA: Not always, no. SARON: Because I think that’s the other problem, is just being honest with your group mates or teammates and saying, “Your style of communication or whatever it is, just isn’t working for us. And maybe if you made some adjustments and we made some adjustments, we can all work better together.” KATRINA: I think that that is probably the first place to start. It doesn’t have to be done in any hard ass mean way either. It can be some really gentle adjustments. And a lot of people will respond to them. I know that for my own part, I often don’t realize how my interactions are affecting other people. But if someone actually just tells me, “Hey, when you say that thing it makes me really frustrated,” I can stop saying the thing. It’s totally fine. SARON: Exactly, exactly. I often wonder, and especially if I’m working with new people who either don’t know my style or I don’t know, there’s, “I hope that didn’t come off as mean. I hope that didn’t come off as too aggressive. I hope they understand.” So, just even getting that feedback either way was really helpful. KATRINA: After working with Jeff Casmer for a year, [chuckles] he once told me that, “You know in the beginning, your feedback was so blunt that I wanted to tell you, you know I’m the boss, right?” [Laughter] JAMES: I actually find myself worrying in social situations now. I’ll be in a social situation, we’re all having a discussion, and I’ll stop and think, “Oh my gosh. Am I the bad apple in this situation?” [Chuckles] DAVID: Yeah. CHUCK: Yeah. AVDI: There’s probably some rule about if you ask yourself that, you probably know. CAROLINE: Exactly. DAVID: It’s like the poker rule. If you’re in the group and you don’t know who the bad apple is, it’s you. JAMES: Right. [Chuckles] AVDI: There’s something I worry about with regard to mentoring, which is just the question of are there enough mentors? I worry about that, because I’m a big fan of the idea and I’m a fan of the idea of apprenticeship, of letting people pair up and work with somebody who’s much more experienced, maybe move around a bit from one experienced person to another. But I regularly turn down requests for mentorship from people. And I say that because I just don’t have time. I’m in a position where people occasionally write to me and say, “Do you possibly have any time to do mentoring?” and I have to say no. I’m really sorry, but I don’t. And I feel like the more advanced you are as a programmer, as anything really, the more in demand you’re going to be. And it might not be, I’m in a sort of public position, but you might just be more in demand in your company and have many responsibilities. And then there are other people who might be ready and willing to do mentoring, but they’re in a company that’s just pushing really hard. It’s a startup or something, that’s pushing really hard, and just all of their time is devoted to getting that product out. And I think that’s probably common in a lot of places. And I feel a little bit, almost hypocritical or something, when I say, or like I’m saying, “Let them cake,” when I say, “Yeah mentorship. Yay,” because are there mentors out there? If I’m a young developer just getting out of a boot camp, how easy is it going to be to find a mentor? CORALINE: I think you’re addressing a common misconception about mentoring. Dave Hoover and Adewale Oshineye, and I’m probably totally [inaudible] his last name, wrote a book called ‘Apprenticeship Patterns’. And one of the things that Dave Hoover is really emphatic about is that you shouldn’t think of developers being on either end of a spectrum and only the most advanced, most experienced developers working with beginners, because actually a beginner can learn more from someone who is a couple of years ahead of them than they can necessarily from someone who’s ten years ahead of them. So, if you imagine a box car arrangement of people at various levels helping those who are just behind them and being able to relate to them more, that’s actually not only a more effective model but also a more sustainable model. CHUCK: Andy Hunt said basically the same thing in ‘Pragmatic Thinking and Learning’. JAMES: Right. CHUCK: Where he lays out the Dreyfus Scale. And yeah, somebody who’s a level or two ahead of you can explain things better because they still understand that pain and they’re still closer to that place than somebody who’s at the top of the scale. JAMES: I actually want to go back to Avdi’s question, because I don’t think it’s all that simple. I find myself in a similar position. And when I was younger and not as far along, basically every one of those requests that came in like that, I tried to do as much as I could. And then it finally just reached the point where it overwhelmed me and now I can’t keep up with them. And so now, all the time, I tell people no. And it’s terrible, because I feel like a terrible person all the time, because I want to help everyone with the things they’re doing. And having to say no all the time really eats at me. “Oh, I’m not helping these people do these things.” But as I said, I’ve been reading this ‘Mastery’ book by Robert Greene and he talks about this. He says it’s very normal that the higher you get in a particular area, the more demands you’re going to have on your time. And part of the mentoring/mentee relationship is having a mentee that recognizes that. So, they recognize that you’re in this position and that you have these demands on your time and stuff. And they think about what they can bring to you as well as you can bring to them. So, in a good matchup, you have this scenario where the mentor is often also getting something out of the relationship. So, maybe just to give an example, in my case I’ve been thinking for years, I need to go back and refactor highline because it’s grown over time. It changed. And now I understand how it should be. And I didn’t way back when I built it or whatever. So, maybe a successful relationship for me would be someone who comes in and wants to do that refactoring guided by my oversight or something, like me telling them what I think it could be and then them noodling with that and then feedback flowing back and forth and stuff. And the advantage they get is to work with me and understand what I think. And then the advantage I get is that it takes care of something that I never seem to find the time to do. And it’s just a random example. I’m not even saying that’s a real thing. But you get the idea, that there should be some kind of flow back and forth both ways and that both sides should be getting something out of the relationship, according to Robert Greene. KATRINA: Robert Greene actually has an apprentice, interestingly. Someone who does a lot of the legwork, a bunch of the research, a bunch of rough drafting based on stories that they find, writing stories onto index cards, and helping organize that. I think that is a relationship that goes both ways, because they get the guidance and the wisdom that Robert Greene has, and Robert Greene gets a lot of research organized and legwork (footwork?). Which one is football and which one is research? [Laughter] KATRINA: Anyway, basic work done. CHUCK: Well, I think another much more straightforward example of this is paid coaching. You have AirPair.com and the people who get on and do the mentorship, they get paid. Or I do quite a bit of paid coaching. For me, it’s just that I have so many things going on that somebody has to make it so that I can’t tell them no. And it’s not because I don’t want to help people out. It’s just that I have all of these other things going on where I feel like I’m contributing to the community or working on things that pay my bills so that I can continue to focus on what I really care about. And so, in order for me to take some attention away from that, it has to be worth it. And then another example, and this is very close to what James brought up, is I had somebody that I formed a relationship with. And he’s now actually a subcontractor of mine. But lately he’s been working on one of my personal projects. And so, we get together and we talk about that periodically. And we sit down and we just goof around with code for a few hours every week. And it’s that kind of stuff, where I learn stuff from him because he’s much better at Emacs than I am. And so, I learn stuff from him about that. And in turn, I help him learn some things about code and about Ruby. So yeah, just to pile on there. If you can’t find somebody, pay them. And if you can’t pay them, then find some other way for it to pay off. CORALINE: I totally agree mutual benefit is an essential part of it. I want to address something that both James and Avdi brought up though. They both used the word guilt. And I really think that guilt is poisonous. DAVID: Yeah. CORALINE: I saw a talk a couple of years ago where they laid out, they were asking the question of what happens to developers once they turn 40. And as someone who is 28, uh 42, yeah. [Laughter] CORALINE: I can tell you I was really intrigued by what they had to say. And basically, and I wish I remember whose talk it was, they laid out three paths. The first one is mastery, where you become a master of your craft and you contribute to the community by code, by projects, by being an exemplary developer. The second is management, and I think a lot of people disappear into management when they get to a certain point. And the third is mentorship where you are working directly with people. You’re writing books. You are doing blog posts. You’re doing one-on-one mentorship as well as teaching. And I think that all of us have a blend of these three things in us. But there are multiple paths to being the master craftsman, the master artisan. And I feel bad that anyone would feel guilty about not embracing all or one particular one of those paths. SARON: It’s interesting because when I think about my programming mentors, the time that I spend with them is a lot less of straight coding or paring and it’s a lot more high-level conversation. It’s a lot more, “I’m thinking about solving this problem, how would you go about solving it? Here are my options. What’s your feedback?” Or maybe even something like, “I’m considering this position versus this one. What skill makes more sense for my future career?” It’s a lot, I guess, less demanding than the types of mentorship that you guys are talking about. And Coraline, it makes me wonder, when you’re talking about mentorship and how that’s a citizen responsibility of everyone, which one is it? Are you talking more about the more active project-based we’re working together side by side or is it more of feedback and leveraging your experience on a higher level? How does that work together? CORALINE: I think those are aspects of mentorship and it really depends on the relationship that you have with your mentee. I don’t think they’re mutually exclusive at all. JAMES: It’s a really good point though, Saron, about how in programming especially every rock you overturn has a giant Alice in Wonderland style rabbit hole under it. And just knowing which ones you can safely avoid for now is often very helpful. DAVID: Yeah. JAMES: So, just hearing somebody talk out a problem and be like, “Oh yeah. Just look up whatever,” and they send you in the right direction, or “Oh yeah. Have you seen that one gem?” And then boom, you’re so much better off than you were before that conversation. SARON: Exactly, exactly. That’s really the biggest value is, “I want to make a discussion board in this app and these are the three gems that I’m thinking about. Which one would you totally avoid based on your experience?” instead of me spending hours finding it out the hard way. Those are the things that I think are really, really helpful in getting from mentors. CORALINE: That really is about creating that culture of education where we’re all responsible for each other’s advancement. CHUCK: I want to go back to something that you winked at a minute ago, Coraline. And that was that people go, they get into the mentorship and so they’re writing books and making videos and stuff. And that to me, when I talk about mentors, I think this is where a lot of people miss the boat a little bit. And that is that your mentor doesn’t even have to know that they’re your mentor. So yeah, you can go and contribute to an open source project and you can get feedback from somebody and then that’s a form of mentorship and that’s direct mentorship. But a lot of the things I’m learning about in business and in other areas come from the fact that I am listening to audio books or reading actual books or watching videos or taking online courses or things like that, where I’m not really directly interacting with the person who’s giving me the knowledge. Instead, I’m actually just going and consuming something that somebody’s already put out there. And so, you don’t necessarily have to have one-on-one time in order to get that mentorship. You just have to consume whatever it is of value that they’re putting out there and then apply it to your coding practices, your business practices, your life, whatever it is. CORALINE: That’s one area where we’re very different from the 12^th century in that we have technology that provides a multiplier effect and multiplies the number of people we can reach with the same or similar amounts of effort. JAMES: And there are ways to use what Chuck’s talking about to your advantage. Again, it’s in ‘Mastery’. They talk about this a bit, of how you can do more to get extra out of a book or a video or something you’re consuming. At the same time, generally speaking, it’s not as effective as person to person communication and stuff just because there’s so much nuance we can pick up on when we’re having that interaction. When you’re asking me that question, I can see if you’re totally deflated. And then if you are, I can be like, “Oh, no, no, no. This is easier than you think,” and give you a couple of hints or whatever. And it makes a huge difference. CHUCK: Alright, I’m going to talk to Robert Greene then, instead of reading that book. DAVID: Yup. [Chuckles] DAVID: There’s also a perspective I think, that a mentor can bring to the table that you wouldn’t necessarily get as you’re doing research. There are three phases that programmers go through. There’s the beginning phase when they don’t know how to write a framework. Then there’s the middle phase when they need to get it out of their system. And then there’s the end phase of a programmer’s life cycle when they know better than to write a framework. JAMES: [Laughs] When to I get to that point? [Laughter] DAVID: But if you don’t have somebody who’s been to see the elephant and come back from it, you don’t have that somebody to say, “Oh, no, no, no, no. don’t go down that rat hole,” and later on to say, “You know better than to go down that rat hole,” and in the middle to say, “Yeah, get it out of your system. You know what? Go for it.” CHUCK: Early in my career though, I had a mentor that actually told me to go and write an ORM. And I was pretty early on coding and stuff. But it wasn’t for the fact that I was going to successfully write an ORM that people were going to use. It was, go and learn the lessons that you’re going to learn by doing the hard part to that. DAVID: Right. Right, the world doesn’t need your ORM but you need to get this out of your system. And you need to learn the lessons from it. Yeah, absolutely. JAMES: Mark Andre I believe it is, teaches a class that’s basically that. He rewrites a couple of the key parts of Rails so that you can better understand what’s going on. DAVID: There is a point we touched on a few minutes ago talking about, [chuckles] the conversation got to a really down point because we were talking about bad apples and about how it brings us all down. And I’m like, “Man, this is getting depressing.” And I started thinking as we were talking about that if there was some way to, I need a better phrase for this, or maybe this is the best phrase for it, but I want to find a way to ‘weaponize goodwill’. And what I mean by that is there is a trick that I have used in the past to great effect, which is that if you assume that somebody is better at something than they think they are at that thing, there will enter into the interaction a sense of they feel appreciated and you feel grateful. And the opposite emotion of this is contempt, right? And it’s been shown in relationships that when contempt is present, it’s a 90% predictor that the relationship will fail. You can spot people who are dating and say, “Oh, there’s contempt. Your marriage is not going to last.” They haven’t even gotten married yet and you already know it’s going to end in tears. And the opposite of it is to assume that somebody is better at what they are than they think they are. And I don’t know how much of this is the Clever Hans Effect where just because of the way you treat somebody, they tend to step up their game a little bit, and how much of it is like less placebo. I don’t know. I don’t know how to describe it. But I wanted to ask Coraline or Katrina or any of the other Rogues, how do you, I don’t want to say how do you avoid bad apples, I just want to say, how do you keep the apples fresh? When you move into a new, or Saron, when you move into a new apple cart, is there a way to bring positive energy to move the mentoring forward and exchanging with your peers? SARON: For me as more of a mentee than a mentor, I find it really, really refreshing when I feel like my opinions and my thoughts are valued. So, half the time when I’ll ask one of my mentors a question, they’ll respond with, “Well, what do you think?” or “Well, these are the three different options,” and it’s not a definitive end-all, be-all answer. It’s not, “This is what you should do and this is how it’s done and if you don’t listen to me, you’re an idiot.” DAVID: Yeah. SARON: It’s very conversational. And even though that person is way more experienced and just knows a ton more, telling me that even as a relatively new person that what I think and how I approach things is just as important really, really helps. And it helps me in my pairing and my working with other people, because I want to do the same thing for everyone else. So, anyone I work with, whether they’re more beginner than me or not, it encourages good habits because it makes me go, “Well, this is what I think we should do first. What do you think?” And that just keeps paying itself forward. KATRINA: I think that Carol Dweck’s ideas around growth mindset and fixed mindset are really important in this type of situation. If you can help encourage an apple cart to keep the growth mindset, I think that helps keep things fresh. JAMES: So, for those who aren’t familiar Katrina, I know because I’m a new parent, but maybe give an example. KATRINA: If someone accomplished… so, one of the things that can be very difficult is people who grow up thinking that you’re born the way you were born. You’re as smart as you’re ever going to get and if you’re able to do it, it’s because you’re smart enough. And if you’re not able, you’re just not smart enough or not good enough. And the growth mindset is much more of a, well if I didn’t manage to do this, I didn’t work hard at it, or I didn’t ask the right questions. Or for some reason, I can try something else and maybe get better at it. And one of the ways in which this is encouraged with children is to focus on the effort, not necessarily on the outcome, to say, “Wow. You’re working really hard,” or, “You solved the puzzle. You must have thought really hard about this,” or something like that, instead of saying, “Wow. You’re really smart. You solved the puzzle.” JAMES: Right. The importance of that is that if you grow up thinking “I’m really smart, I’m really smart,” and then you fail a test, then what? DAVID: Yeah. Yeah. JAMES: Then what do you do? Then you’re just done. It’s game over. Now you’re dumb or what? DAVID: No, now you hide the results. JAMES: Right. [Chuckles] Yeah. KATRINA: And now you also take much easier challenges because you might fail at the harder ones. JAMES: Right. That’s right. DAVID: Yeah. JAMES: You purposefully set yourself up to keep looking smart because the alternative, that’s bad, right? Whereas if you’ve been told, “Oh, you worked hard on that. You worked hard on that,” and then you fail, you’re like, “Oh. I didn’t work hard on that. I guess I need to work harder” and you know the path forward. It’s that you know what happened there and you know how to make it not happen again if you want. You can choose to work harder. DAVID: You seek out the things that you get rewarded for. And you seek out, I don’t know if this makes sense, but you seek out the easiest path to get the thing that you want, or the most direct path. And if you are “smart”, yeah you’re going to find the easiest way to get an A so that you can prove that you’re smart. If you are rewarded for working hard, this is going to sound weird, but you’re going to find the easiest way to work hard. JAMES: That’s actually accurate. Dweck has done studies showing that depending on… she gives children a test and then half of them she’ll praise, “Oh, you’re smart,” and then the other half, “Well, it’s clear you worked hard on that.” And then she’ll give them an option of taking an easier follow up or a harder follow up. And more often, the ones that were told they worked hard will take the harder follow up because they don’t have as much to lose. They can work hard and try to get it, whereas the ones told that they’re smart, they’ll usually take the easier one to maintain their status. DAVID: Yeah. CORALINE: I had an English teacher in high school my senior year in honors English who in every paper I turned in gave me a 95. And I was like, “Damn it. What do I have to do to get 100 out of this class?” And so, every time I worked a little bit harder and a little bit harder. And she finally told me at the very end of the class that she didn’t want to give me 100 because she didn’t want me to coast. [Laughter] CHUCK: Yeah. One other thing that I’ve seen though is that people like that success. And everybody has some area at which the can excel. And so, I’m thinking in particular with the last fulltime job that I had, I actually worked with David there. I came in and I had some particular skillsets that were needed on the team. And so, I wound up setting up the CI server, Jenkins. And I wound up doing a bunch of other things that were sys admin stuff that the rest of the team really didn’t excel at. And so, even though I was probably years-wise or experience-wise junior to most of the team, I was able to contribute and then come up to speed in the meantime. And so, they benefited from what I could contribute and at the same time, I benefited from working with them over that time period. JAMES: Yeah. That’s definitely true. We’ve talked a lot in the past about the value of junior developers and their place in the ecosystem. And I think the whole mentor relationship is another great example of that. But to Avdi’s point, are there other choices other than mentoring? [Chuckles] CHUCK: As senior people or as junior people? JAMES: I was asking other ways we can bring junior developers up. CHUCK: Okay. JAMES: Because obviously, mentors are a limited resource, yes. CORALINE: I think one of the ways we can do it is by serving as good examples. I talk a lot about values. Basically, I believe that if you don’t act on your values, it’s not really a value, it’s a conceit. So, by behaving in a way that we want junior developers to emulate, I think we’re doing our part as well. And that’s not so much a one-on-one effort but just being visible in the behaviors that we tolerate and the behavior that we engage in ourselves, the people that we encourage, the people that we call out when they make mistakes. By living those values, we are reinforcing those values. By admitting that we make mistakes, we make people more willing to own up to their own mistakes. Those sorts of actions and activities I think go a long way, just as much as being an excellent coder would inspire someone else to become better, being a better citizen will inspire better exercise of values in the community as well. AVDI: I feel like one of the things I’m taking away from this is that if you’ve been on the job for a year or three, you’re not off the hook, as far as the responsibility for bringing up even less experienced developers. CORALINE: Absolutely. It’s a shared responsibility across the board, regardless of where you are technically speaking. Because just because you’re a junior developer or a midlevel developer doesn’t mean you don’t have social or interpersonal or cultural or community skills. AVDI: Right. And I think that’s a big deal, because I think when I was at that level and at that age, I don’t think that I would have thought of myself as being responsible for bringing up more junior developers. I would have thought, “Well, I’m junior. I have nothing to add. It’s the older people’s responsibility.” SARON: I think that mentorship is great, but the other thing is there’s a lot of stuff that junior developers can learn from each other, too. At RailsConf when I gave my talk about code club, the real takeaway wasn’t so much that reading code is important. The value in code club when we meet every week is that we get to leverage each other’s information and experiences. There are five of us. We have very different roles or different positions at different jobs and we’re all working with Ruby on Rails but we are learning. And we’re learning both on the job but also we have our own mentors that we learn from. And so, every week we get to swap. We get to share information and learn and build. And because we’re so excited, we’re very eager to share that. And so, I feel like mentorship is important and very great, but I think that junior developers have a responsibility to other junior developers to share the information as they get it. And that way, we don’t have to rely so much on senior developers for that experience and that knowledge. KATRINA: I work on a team where I’m probably the most junior developer there. And even though this is a team of quite experienced people, we have every day at 5 o’clock we do our five at five, five minutes where we say what we learned today, just one thing that we learned today. And that’s really interesting. SARON: Oh, I love that. That’s a great idea. JAMES: They do that in my daughter’s gymnastics class. [Chuckles] KATRINA: That’s awesome. [Chuckles] JAMES: Yeah. It’s for the very young kids though. Show them gymnastics stuff and then every day they ask them what they learned today. What did you figure out? It’s funny how that never seems to go away. Dave and I did this video. DAVID: Oh yeah. JAMES: Just the other day. We’re like, “Hey. Let’s sit down and read some code because Saron told us to and it’s a good idea.” And so we did. We read through some code. And I feel like an experienced developer, I think, some days. And we were on the call five minutes before David showed me a new trick. It’s like, “That’s amazing. He has a great idea.” [Chuckles] KATRINA: I did a Google Hangout a couple of weeks ago that was two hours long where basically I just looked at and talked about with other people how to calculate leap year in Ruby, how to write a solution to the leap year problem in Ruby. Two hours of looking at different ways to approach the problem. And what’s interesting about it and what’s difficult to read about it and what makes things more confusing and less confusing. Two hours. And it’s a one-liner. JAMES: [Chuckles] Yeah. It’s dates though, right? [Chuckles] KATRINA: Well yeah, it’s modulo math. JAMES: Right, yeah. DAVID: The video that James and I did is a really good example of this deliberate weaponization of good will where James and I, well hang on, I’m presuming that he has any respect for me. [Chuckles] I think of James as one of my heroes. And so, he’s like, “You want to go read some code?” and I’m like, “Heck, yeah I want to go read code with you. This would be awesome.” And so, we started doing this. And the reason we did it is because Saron said it was a really good idea. And here’s Saron who’s fresh out of a boot camp and has this large life experience compressed into a tiny footprint of programming experience. And she’s saying you need to read code together because it’s freaking awesome. And so, James and I listened to that and said, “That is valuable. We’re going to act on that advice and respect that.” And so, we went off and we read this. And we read code by Dan Cub and Eric Michael Zober and Myron Marston, and [inaudible], I forget his name, Marcus Sherp. And James posted the video online. And I think it was Marcus that wrote back and said, “I’m almost afraid to watch the video because I don’t want to see the critique that you guys laid down on our code.” And I wrote back and I said, “No, you don’t get it. We’re reading your code because we wanted to learn. And we’re totally fan boys of you guys.” It’s like a strange loop, only instead of rock paper scissors where you have to go all the way around the circle to get back at the top, it’s every direction is up. It’s like from me to James it’s up because I have respect for him. But going the other direction, from James back to me, it’s up because he has respect for me. And from us to Saron, it goes up because we have respect for what she contributed. And that’s what I’m talking about, about using goodwill as a way almost to create a place where, a space where vulnerability can exist so that learning can happen. Because when you, if you tell somebody, “You’re stupid,” vulnerability goes right out the window and you drop out of learning mode and you go immediately into defense mode. And in defense mode, all you can do is execute what you already know. You don’t learn and grow. You can’t appreciate what somebody has to offer to you and grow from it. JAMES: I want to say how valuable it was. I was blown away. I’ve read code a million times. DAVID: Yeah. JAMES: But it never occurred to me that this should be a ‘do it with your friends’ activity until Saron said it should be. So, I went and did it. I think I learned more in that session that I have from lots of pair programming sessions. SARON: Oh wow, that’s awesome. JAMES: So yeah, I thought it was absolutely great. We’ll definitely do that again. DAVID: Oh, yes. S** ARON: But I love that you recorded it, too, and other people get to see that journey with you. JAMES: So, we actually had that conversation when we started the call. We’re like, “Oh, we’re already taking on Skype. Should we just start a call?” and it’s like, “Well, if we switch to Google Hangouts, we can click one button and anybody else who wants can watch along. So, why not do that, too?” SARON: Nice. DAVID: Yup. KATRINA: This is what I want Exercism to be about, about the conversations that you have together looking at code in detail and learning from that. CHUCK: Well and I can tell you, just as a plug for Exercism, we’ve done this in two or three of the users groups here, two or three of the user groups meetings, where we’ll write the code and then we sit down and talk about it. And we’re reading each other’s code. We’re not reading code that people actually use in production. And it really does, you used the leap year example and we did that work on one of the things there. And yeah, we talked about it for an hour and a half. Is this easier to read? Does this make better sense this way? And some of the other ones, even the first example, the Bob example, it’s just, “Okay. How do you organize it and where do you put stuff?” It’s really fun and interesting to see where the conversations head to. And it does inspire those conversations. And you can participate with them online too, with the nitpicks. JAMES: Agreed. SARON: Actually Katrina, that’s one question that I did have for you, because Exercism is based on the idea that I’m okay putting my code out there and having people nitpick it, if I understand the concept correctly. And so, how do you, through the app, address the issue of, as David wonderfully put it, vulnerability being okay and that being something not to be embarrassed about? How do you do that? KATRINA: **I haven’t figured that out yet. The prototype that I have out there hasn’t addressed anything. [Chuckles]**KATRINA: It’s basically just a form that you write words into and a button. It’s terrible in terms of user experience. There’s no product design done around it. I haven’t been able to address the most important things, which is how do you create a community where it’s safe to have these conversations? How do you encourage people to start having the conversation even though they might think they have nothing to contribute? How do you turn it into a conversation rather than a, “You should do this because it’s better, because I know, because I’m older than you,” or whatever. And really, when the conversation becomes something that goes both ways, the experience is incredibly rich and the learning is incredibly rich. But when it’s not, or when it’s two people who don’t know what they’re doing who are leading each other down a rabbit hole, it can go really badly. And I don’t know how to address it. CAROLINE: As someone with impostor syndrome, I would be terrified of Exercism. I wonder if allowing some anonymity in terms of submitting a particular exercise would help in that regard in terms of not feeling as vulnerable. JAMES: **Yeah, but the internet and anonymity, right? [Chuckles]**KATRINA: Yeah, it’s a really hard problem. JAMES: I hear what you’re saying. KATRINA: **So much, I was talking to a friend of mine who was like, “Oh, your new job. It sounds like it’s really hard problems,” and I was like, “Yeah. Big files. Totally hard problems. But you know what? People are much harder problems.” [Chuckles]**JAMES: It is tough. It’s very cool. It’s amazing. And don’t let this conversation scare you off of trying Exercism. You should absolutely try it. It’s mind-blowing. CAROLINE: Definitely. KATRINA: But I will keep the anonymous idea around. It’s like, is there some way that we can address the vulnerability part or the, “I’m scared. I feel like an impostor part,” because it’s huge? CHUCK: Alright. Should we get to the picks? JAMES: Yeah. CAROLINE: Let’s do it. KATRINA: **I’ve been saving up for six months. Let’s do it. [Laughter]CHUCK: James, what are your picks? JAMES: So, when Dave and I did our video, one of the cool things we discovered on the projects that we were looking at is they have these awesome badges in their readmes showing things like the build state and the documentation, and stuff like that. So, it was really cool. And now, I’m obsessed with badges and putting badges on everything. So, there are some cool sites for that. There’s a neat one called Inch Pages and it’s a meter of how well-documented your project is. And then there’s a badge service that you can call out to that will basically summon badges for whatever you need in whatever colors and stuff like that. And so, those are two awesome services and a way to start putting badges on everything, which is cool. And then for a non-programming pick, I got to see Yo-Yo Ma in concert recently, which is about as great as it sounds. It was really, really good. And one of the things I love about Yo-Yo Ma is just how many incredible things he has tried, different kinds of music and just getting into different things. Truly amazing. He did this album called Hush with Bobby McFerrin that I didn’t know about until recently. And that is absolutely as cool as it sounds. Bobby McFerrin’s cool voice plus Yo-Yo Ma’s amazing cello. And yeah, I think that’s about all I need to say. You should check this album out. That’s it. CHUCK: Awesome. David, what are your picks? DAVID: So, I’ve got two picks. But because Katrina’s got a bunch and she’s been saving up, I’ll do them very, very quickly. One is I’m using Prelude for Emacs. And I’m absolutely loving it. It’s caused me to throw out all of my five, ten years of Emacs configuration cruft over the years and replace it with a really clean, slick, modern updated version of all the cool tools and a lot of neat stuff. If you’re used to Emacs, it does take a lot of getting used to. If you’re getting started with Emacs, I recommend you start with Prelude, because then you just don’t have to relearn the bad habits that you’re going to learn, et cetera. And the other one, I cannot believe this has never been picked. I had to actually go to the website. But I’m going to pick Charles. Not the Rogue, but the app. CHUCK: I was going to say, I love you too, Dave. DAVID: Yup. No, CharlesProxy.com. On the Mac, on OS X it’s Charles.app. But they have it for Windows and they also have it for Linux. And it’s a web proxy that will sit between your machine and the rest of the internet. And when you are trying to write a web scraper or figure out why your AJAX callbacks aren’t working right, this thing will get between your browser and the server and log everything for debugging. You can see time sequences. You can see payloads, packets, cookies that were set. You can even set an SSL certificate on it and it will execute a man in the middle attack. Your browser will say, “Hey, the certificate doesn’t match,” but you say, “I know. That’s because I’m man in the middle attacking myself.” And you say, “That’s okay,” and it goes through. And now you can actually debug through https. And I have been finding this extremely useful working with my new client who’s got me doing a lot of web scraping on some really crazy insane web services. And I can’t believe it hasn’t been picked. So, now it has. CHUCK: You can also use it to spy on your iPhone apps by setting a proxy through your computer if you’re on the same network. DAVID: Nice. CHUCK: Handy tool. Saron, what are your picks? SARON: Sure. So, I have one today. So, I’ve been really, really interested in design from the UI perspective, how to take your awesome features and your functionality and making the design on the frontend more than just a skin that you throw on. And so, I’ve been reading ‘Design for Hackers’ by David Kadavy, if I’m saying his name right. And it’s been really, really good. If you’re interested in going beyond just throwing on a bootstrap theme on your app, I highly recommend it. He talks a lot about the history of design and pulls from all kinds of resources and is very well researched. And it’s design for programmers. So, if you’re interested in that I’d highly, highly recommend the book. CHUCK: Sounds like something I need. Avdi, what are your picks? AVDI: I just have one little programming pick today. I generally am not a fan of specialized templating languages for generating webpages. My general view is usually what happens is somebody decides that they want to mix programming code with HTML. And so, they come up with a new language and now you have three problems, or at least you have three languages to keep track of in your head. However, I’ve been playing with Slim lately, which is sort of similar to Haml. It’s like Haml only believe it or not, they slimmed down the syntax even further, partly by realizing that most of the time what you’re doing with something like Haml is markup. And so, the markup doesn’t have sigils and the content does, because usually you’re getting your content from the database or something. You’re not spelling it out in the template. But it’s got some nice features to it. It seems to have fewer gotchas than Haml. And it has a pretty neat logic-less mode which totally basically forces you to put your data into data transfer objects, hashes or simple objects or whatever. And then it populates the page with that data without actually having any ifs or eaches or anything like that in the page, which is kind of neat. So, as templating languages go, Slim doesn’t suck. And I think that’s I have today. CHUCK: Alright. I’ve only got one pick this week. It’s the Tab Corral. It’s a plugin for Chrome. If you find yourself with three different Chrome windows open and they all have 15 tabs open on each of them, Tab Corral is nice because if you don’t use the tab for a while it’ll close it. And you can actually whitelist the tabs. So, certain websites won’t get closed. But I’ve really liked that. And if you need to bring a tab back, you just click on the little tab corral and then you just click on whichever thing you want to bring back and it’ll open it back up again. So, that’s my pick. Coraline, what are your picks? CORALINE: Sure. I have a couple. One is the book that I kept mentioning today, ‘Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman’ by Dave Hoover and Adewale Oshineye. It’s available on O’Reilly and it’s also creative commons licensed. And it really is about exploring soft skills and learning techniques that are essential to anyone to further their career in software development. The second resource I wanted to talk about is brand new as of this week. It is ATUnit, ATUnit.org. Basically, there’s a group of people who are building a sustainable funding community specifically aimed at providing financial support to people working to make tech open and welcoming to marginalized people. It’s at the very beginning phases and could really use help from the community to blossom and bloom into something that will help sustain all of our values as a community. CHUCK: Alright. Katrina, what are your picks? KATRINA: So, the first pick is a video on YouTube. It’s called ‘15 Sorting Algorithms in 6 Minutes’ and it is amazing. It’s a visualization and audible-ization of sorting algorithms, like your total standard quicksort and merge sort and all of those. And it’s just mind-blowing. So, watch that and then watch it again. And I think I’ve probably watched it 10 or 12 times right now. My next one is almost as awesome and it’s a website that uses D3 to visualize how Git works. So, it lets you actually type in Git commands and then it gives you a graph of what Git looks like when you’ve done that. It’s super awesome. It’s called Explain Git with D3. And it’s by a guy named Wei Wang. In relation to the visualizing Git with D3, there’s a video that is kind of a pick. The quality, the sound quality, is kind of bad and it’s two hours long. So, you might not get to it. But I found it incredibly useful for understanding how Git is put together, or just getting a mental model of how Git works. It’s called ‘Git for Ages 4 and Up’. And it is by Michael Schwern. And it uses Tinkertoys in order to illustrate the internal model of Git. And then my last pick has nothing to do with programming. It’s very much related to Carol Dweck. It’s a block by a woman named Janet Lansbury who writes about babies essentially, from birth to about year two, and ways of feeling less guilty as a parent and being less stressed out about having to teach your baby Mozart and all of those crazy things. And she talks about a very laid back respectful approach to thinking about this without really giving specific, I mean she gives some guidelines but it’s not like recipes for interacting with babies. It’s more of a very small set of things to think about. And she writes really well. She has some awesome articles. I’ll link to one specifically called ‘Don’t Stand Me Up’. My sister, I don’t have kids, but my sister has a couple of kids. And she’s been using, thinking in this way with her two children. They’re one and three years old. And they’re both incredibly confident, incredibly self-driven, motivated by their internal drive to discover things. And it’s been really incredible watching them explore, to the point of, I’m actually going to upload a little picture. When my niece was less than a year old, she was probably ten months old, and she hadn’t figure out how to walk yet, she was already climbing. And she would climb up wherever she could, onto chairs and tables. And she works really, really hard at it. And my sister does the thing where she doesn’t praise and say, “Oh, you’re such a good climber.” If she says anything at all, she’ll be more like a sportscaster. “Oh, you picked it up. Oh, you climbed up.” And so, the kiddos are really just interesting to watch as they explore their own limits on their own terms. That’s all I’ve got. CHUCK: Awesome. Well, thanks guys for coming. It’s been really… DAVID: Yes. CHUCK: Really fun to talk about. DAVID: This was a good show. CHUCK: Yeah, I’m going to have to definitely listen to this one again and learn this stuff. CAROLINE: It was so much fun and I can’t tell you how much I appreciate being given the opportunity to speak with you guys. So, you’re all heroes to me. SARON: Aww. CHUCK: [Chuckles]**DAVID: Aww. See, this is what I’m talking about. It’s uphill, oh, that’s how you phrase it! It’s uphill both ways. [Laughter]CAROLINE: Edit, edit, edit, edit. DAVID: Yeah. [Chuckles]CHUCK: It’s a conversation I think that needs to be had every so often. And hopefully, we inspire some folks to go out and further their education and we inspire some people to make it a little easier for folks to get into the community and the industry. [This episode is sponsored by Codeship. Codeship is a hosted continuous deployment service that just works. Set up continuous integration in a few steps and automatically deploy when all your tests have passed. Codeship has great support for a lot of languages and test frameworks. It integrates with GitHub and Bitbucket and lets you deploy cloud services like Heroku, AWS, Nodejitsu, Google App Engine, or your own servers. Start with their free plan. Setup only takes three minutes. Codeship, continuous deployment made simple.]**[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]**