Teaching
In this episode we talked about old vs young Programmers, Teaching Fundamentals, Bootcamps, and many more. Please listen to the full episode of the podcast here:
Transcript
**Avdi Grimm**: [00:00] Bears chewing on the wires again.
**Charles Max Wood**: [00:02] Embarrassed.
[00:04] [laughter]
**Avdi**: [00:04] Constant problem.
**Coraline Ada Ehmke**: [00:05] That's what you get living in Yellow Stone.
[00:07] [laughter]
**Coraline**: [00:08] Jelly Stone.
**Charles**: [00:10] Jelly Stone, there we go.
**Solania Burke**: [00:11] Yeah.
**Jessica Kerr**: [00:12] Yeah.
**Charles**: [00:12] Don't rub your food on the wires.
[00:14] [laughter]
**Coraline**: [00:17] Good advice for life.
[00:18] [background music]
**Charles**: [00:18] This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand Tech Companies in San Francisco, New York, and LA have been on Ruby Developers providing them with salary and equity upfront.
[00:34] The average Ruby Developer gets an average of five to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations.
[00:52] It's totally free for users, and when you're hired they give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you'll get a $4,000 bonus instead.
[01:07] Finally, if you're not looking for a job but know someone who is you can refer them to Hired and get a $1,337 bonus if they accept the job. Go sign up for the hired.com/rubyrogues. Snap is a hosted CI in continuous delivery that is simple and intuitive.
[01:28] Snap's deployment pipelines deliver fast feedback and can push healthy bills to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores and testing frameworks. Snap uploads your application to cloud services like [inaudible] , AWS, and many more.
[01:47] Try snap for free. Sign up at snap-ci.com/rubyrogues. This episode is sponsored by DigitalOcean. DigitalOcean is the provider I use to host all of my creations. All the shows are hosted there along with any other projects I come up with. Their user interface is simple and easy to use.
[02:08] Their support is excellent, and their VPSs are backed up on salt safe drives and are fact and responsive. Check them out at digitalocean.com. If you use the code rubyrogues, you'll get a $10 credit. Hey everybody and welcome to episode 232 of the Ruby Rogues podcast. This week on our panel we have Avdi Grimm.
**Avdi**: [02:31] Hello from Tennessee.
**Charles**: [02:32] Coraline Ada Ehmke.
**Coraline**: [02:33] Hi.
**Charles**: [02:33] Solania Burke.
**Solania**: [02:34] Hey everybody.
**Charles**: [02:35] Jessica Kerr.
**Jessica**: [02:36] Good morning.
**Charles**: [02:37] I'm Charles Max Wood from Devchat.tv, and this week we have a special guest, Eric Normand.
**Eric Normand**: [02:20] Hi everybody. I'm calling from dark and stormy New Orleans.
**Charles**: [02:25] Do you want to give us an introduction?
**Eric**: [02:27] Sure, why not? My name is Eric Normand. I'm currently a Clojure Programmer at a company called Democracy Works. I also have a company on the side that I run called LispCast. I publish the Clojure Gazette. I do a lot of educational courses on Clojure and functional programming. I'm really happy to be here.
**Avdi**: [02:49] You're busy guy.
**Eric**: [02:51] Yeah, tell me about it.
[02:54] [laughter]
**Jessica**: [02:54] Do you have kids too?
**Eric**: [02:56] I have one daughter. Yeah, she's three just turn three this weekend.
**Coraline**: [03:00] Luckily kids are no big deal at three years old, right? Just they're super easy.
**Eric**: [03:04] Yeah, this is yeah that...
**Coraline**: [03:06] [inaudible] every now and then and everything is fine.
[03:08] [laughter]
**Eric**: [03:10] I barely hear about her. She just takes care of herself.
[03:13] [laughter]
**Coraline**: [03:14] That independent age.
**Jessica**: [03:17] Pretty much.
**Charles**: [03:17] You just put kids on autopilot, right?
**Eric**: [03:19] Yeah.
**Avdi**: [03:19] Auto parent.
**Charles**: [03:21] Auto parent.
[03:21] [laughter]
**Eric**: [03:21] There's a setting in the back, most people don't know there's like a switch.
[03:24] [laughter]
**Coraline**: [03:27] What are we talking about today? The topic on the docket is "Teaching and how we can all do more to teach technical topics."
**Avdi**: [03:36] I think Eric has some opinions about this.
**Eric**: [03:39] Yes, I do. I hope they're strong enough. I think that there's a lot of really smart people in our community and the tech community in programming, and they know all these awesome topics and they have all this deep expertise. What disappoints me is the level of teaching skill that we have in our community.
[04:02] I was just watching a talk by uncle Bob, where he talked about how the reason there aren't so many older programmers is that the number of programmers doubles every five years, which means at any given time, half of the programmers in the world have less than five years' experience.
[04:23] We have this desperate need to teach people very quickly, so that we're not just building legacy software every five years.
**Charles**: [04:33] I have to say that. I keep hearing people say, "Oh, well, there were all these breakthrough things written 20 years ago and nobody knew about them and then we're rediscovering them." Is that part of this issue that you're talking about here where the old guard knew about it, but the new guard doesn't because we don't have enough people teaching them about it?
**Eric**: [04:51] That is something that concerns me. I actually don't experience that. I have known a couple of old programmers, and the ones I knew didn't seem to say like, "Oh, we knew it all back then and kids these days just don't get it."
[05:06] It's more that the reason we don't see those things nowadays is that they were impractical on the computers of the day and you needed more memory, you needed faster processors, better networking. Now that we have those things, we're kind of rediscovering them.
[05:24] Also, there was a lot of funding for computer research — basic computer research — that we don't see anymore. The government is just not, the military mostly is not spending the money on those basic things.
[05:37] What I'm really interested in is the sort of fundamentals. I always like teaching the fundamentals because it feels like I'm churning through all this muscle memory, deep-seated knowledge that I don't really have a good grasp on.
[05:51] It's just some expertise that I've got deep down inside that I've been doing for 10 or 15 years. I can finally bring it up to the surface and clean it off and organize it well and show people what is actually possible. Hopefully, I get them to leapfrog into more expertise.
**Charles**: [06:13] How do you think we're teaching those fundamentals today and what's wrong with that?
**Eric**: [06:17] That's a really good question. I don't want this to sound like a lot of complaining, but I'm pretty sure it will.
[06:23] [laughter]
**Charles**: [06:25] Old man shouts at child computing.
[06:28] [laughter]
**Eric**: [06:29] Right. I'm a big fan of Kathy Sierra. I remember when she was blogging, and she had a lot of great posts about how we're inadequate with our teaching. I think I would characterize most of it as really smart people just talking about stuff they know. There's a rule of thumb that like the best person to teach something is someone who just learnt it.
[06:53] That kind of bugs me because the reason they're the best is because they don't have teaching skills. They can just talk about what they just learnt and someone who is just there ready to learn it, who's right below their level in that particular skill, can pick it up because they're right there.
[07:14] The act of teaching is to actually break that down so that anybody could learn it, given the right prerequisites etc. That's really the problem I see is that people just talk about what they know. They don't take the time to break it down to figure out a motivation for why you would want to learn it.
[07:34] They don't present activities that would let you build the skills in yourself, and those are the three things that really help somebody learn. I have a bit of classroom teaching experience, and these are the things that they taught us. That you really have to break down the skill. You can never really get granular enough.
[07:54] It's just at some point it becomes impractical to start teaching people how to reach for a pencil and write by holding the pencil in a certain way. You could break it down that far.
**Jessica**: [08:04] You just said there were three things. Could you do a one, two, three review on those?
**Eric**: [08:09] Sure. The first one is to figure out why they need to learn it. You kind of start with the end in mind. You give something in their life that would be different, that would be better if they had this skill. The next thing is to break the material down into learnable objectives, and any skill can be broken down.
[08:30] Some of the things you're going to break down are like physically type at the keyboard this thing. Some of them are going to be purely decisions like how did I make this decision? Let's say you wanted to teach how to figure out if a number is even or odd. You could sit there and do it yourself. I mean in a program.
[08:51] You can write this program and then go through line by line or expression by expression and figure out why did I write that? What was the decision that I was making? Because there were other choices. Why did I open parenthesis here? Why did I put a comma? Why did I do a method call? Etc. Then you break those down into some learnable chunks songs.
[09:16] Maybe your audience already knows those chunks, and you can maybe just remind them or make sure that they know it by testing them a little. You want to get to a level where you're pretty sure you can teach each of those chunks. The last thing is to align the activities that you do with the actual learning objectives.
[09:37] When I was learning how to teach in a classroom, the classic example was a teacher who has the objective of getting kids to understand what caused the American Revolution. What she did was she made a crossword puzzle or a word search of all the important facts and names and places. Those two aren't really aligned.
[10:03] You might learn how to spell names and learn that George Washington was important in the American Revolution, but you're not going to understand. You just know the fact of his name. That's very important when we're teaching.
[10:16] I see this a lot where someone will simply give the syntax of the language which is purely facts. It's not understanding. The next step is let's write a web service in this. There's this huge jump that has to be made by the learner.
[10:40] These techniques of breaking it down and then, determining an appropriate aligned activity for those objectives can actually give you a path between the simple knowledge of where to put your parenthesis and your curly braces, all the way to how do you go about designing your models if using your controllers.
**Charles**: [11:01] Eric, if I'm understanding you correctly, you seem to be indicating that people who teach developers need to have a teaching background. I can't help thinking of CS programs that do employ teachers with actual training on pedagogue whereas boot camps who now employ developers.
[11:18] In my experience, a lot of CS graduates are not really prepared for real world work, so where's the gap there?
**Eric**: [11:24] We have a reverse problem of what happens in elementary school. Just to play off of your idea, in elementary school what happens is everyone has a master's degree in teaching, but they don't have a math degree. They don't have an English degree.
[11:39] The problem there is they're really good at teaching, but they're not domain experts. That's a real shame.
[11:45] We usually have the opposite problem. You could become a professor of Computer Science by getting a PhD and doing a Post Doc. You're very deep in your knowledge, but then, when you come to teach, you might not have had any formal training in how to teach.
[12:03] I know that a lot of my professors were like that. They were super smart, but you had to do the work. Especially in college, we do expect the students to be doing most of the work.
**Solania**: [12:13] When you talked about what it means to be a good teacher and the three steps, it sounds very logical and very straightforward. Why is it so hard to actually be a good teacher?
**Eric**: [12:26] That's a really good question. I think it does take a lot of work. I don't like to talk about people's egos getting in the way. One of the things is, just naturally as humans, we don't tend to focus on the learner — the person we're trying to teach. It becomes very easy to just think about yourself and how you look and making sure that you look smart and sound smart.
[12:54] There's a lot of objurgative terms like you're dumbing it down or you're over simplifying it. Maybe you're not oversimplifying it, you're just breaking it down and you're giving it in chunks that someone can understand.
[13:10] People who do make more basic books, they aren't given as much credibility. If you look at someone who writes how to do machine learning in Ruby, high level concepts in a popular language, they're going to get to go on the conference circuit.
[13:29] If you have someone who's just like here's a really good, solid course on basic Ruby that anybody could pick up, walk through by themselves and become a competent beginner, they're not going to get the same accolades that someone who wrote this book did know and understands gets.
**Charles**: [13:50] I guess that's one thing that I see here is that a lot of people are coming in through the boot camps where they actually get some kind of traditional-looking training. You have other people coming in that are self-taught and, you mentioned, maybe they picked up a course that explains things really well.
[14:05] Do the teaching styles vary from one to the other? Is one better than the other? For example, if I'm teaching somebody in person, I'm going to approach things in one way. I know that they can ask clarifying questions.
[14:17] I can look over their shoulder while they're doing the work and correct them as needed versus the person who is picking up a course that I wrote. The teaching styles have to be a little bit different just because the media is different. Is there a way of knowing that one is going to be better for new programmer than another?
**Eric**: [14:37] That is a really good question and something I struggle with myself in my own courses. I was trained, like I said before, in a classroom learning style. The nice thing about that is you get very fast feedback.
[14:51] You can see if your students are learning. If they're getting it right away. You can move on quickly. You can slow down if they're not getting it. This was a total waste. It was way over their heads. Tomorrow, I'm coming in and we're going to go deeper. I'm going to break it down further. You can do that much more iteratively.
[15:12] What you get in these boot camps is the fast feedback. The teachers can adapt very quickly. One of the challenges I face with my courses is that they take three months to do and I don't know [laughs] who they're going to target. I don't know what the audience knows.
[15:35] I have to do a lot of assumptions, a lot of research figuring out like in answering questions that people are actually asking, that kind of thing, which is why I'm transitioning away from longer courses into shorter lessons and get a lot of feedback. Hopefully get a lot of questions.
**Solania**: [15:54] I totally agree with Chuck's point. I taught organic chemistry for a couple of years which is notoriously a very tough science course. One of the biggest skills that I used while doing it was listening to that feedback and making sure to pivot and change directions and to modify what I did to benefit my students.
[16:15] When I had to write a tutorial for that online, it was so much harder. I had no idea at what point the reader was able to follow, at what point they fell off. For a lot of people listening who I assume are doing more of that style of teaching, whether it's writing a blog post or giving a talk and aren't necessarily in a classroom, what are some things that they can do to get that feedback or simulate that feedback to make sure that they are doing a good job teaching?
**Eric**: [16:46] It does help that you have previous experience teaching that material. Even if you gave a one hour talk at a meet-up, you would be able to see do these ideas, are they over someone's head? What were the questions like?
[17:05] The other thing is to pick someone you know. That is really helpful. Just pick someone you know and make them the ideal prototype of who you're teaching. Maybe you can just have a conversation with them. Try to teach it to them on the phone and see where they have trouble.
[17:22] See where they have gaps in their knowledge that you could fill in — all those things. Get their feedback and try to then cement it into some artifact like a course or a tutorial. Of course, you've got online. Online, you can get plenty of feedback.
**Charles**: [17:38] If I put together a course, let's say it's a course on Rails just because this is a Ruby podcast and it teaches some of the fundamental building blocks of a Rails app.
[17:46] We're going into the basic after record, basics with controllers and views and I put a course together. I break it up...I like breaking it up into smaller modules so it's like, "Look, did you get mastery of this one thing?"
[18:01] Then if they have an issue with another one thing, then it's not so intimidating to move on to the next thing because you may or may not be building on what came before, but it's another just one thing that you can get hung up on or not hung up on.
[18:16] Let's say that I'm doing that. How do I get that feedback? Do I want to be putting some kind of feedback form on the page next to the video or a comments section? If it's text, is it a comment section?
[18:30] I can see different media, too, like e-Books where you may or may not actually be able to put that right in front of them and say, "Hey, I really want to know what you thought or what was easy and what was hard and how to get that."
**Eric**: [18:41] I don't have a very good answer myself.
[18:46] I have a forum that I help people ask questions. People ask me questions by email. What I'm doing in my new course which just launched is on every page next to the video, I'm putting a link to the forum, and in every communication I say, "I prefer you to ask in the form 'cause other people can benefit from the answer."
[19:08] I'm hoping that that will be enough feedback. I do get quite a lot of questions by email. Unfortunately, what I've done in the past is because the course took three months to make and then I just released it to the world.
[19:22] When I would get question that wasn't answered, I would have to just answer it in the email and just that one person benefited. I couldn't change the course.
[19:31] Now that I'm doing weekly lessons, I just started, I'm hoping that people ask questions and then that will give me enough material for the next lesson and address questions that way.
**Jessica**: [19:45] Speaking of questions, Charles, you said something earlier that I found really interesting about how when we are teaching in person, we expect people to ask clarifying questions.
[19:56] That's a responsibility of the learners in a live course. That's challenging for some people. Not everyone feels comfortable interrupting and asking a question. On the one hand, some people who are less comfortable asking questions might be better off with the online courses.
[20:18] On the other hand, for our listeners, when you're in that situation, when you're in workshops, or boot camp, or even a meeting at work, it's not only OK for you to ask questions, it's your responsibility.
**Eric**: [20:32] That's a really good point. If you want to learn, you have to deal with the inadequacies of the teacher.
[20:37] [laughter]
**Eric**: [20:40] You're there to absorb as much as possible, make as much use of the time in front of the teacher as you have. That's how friends...
[20:48] Since I've always gone through school is people would always get mad at me because I would ask too many questions and talk to the teacher directly [laughs] too much in class. I'm like, "I'm bored. I need to engage myself here," but...
**Solania**: [21:00] Who would get mad at you?
**Eric**: [21:02] Other students, because they'd be like, "Oh, you're so pedantic. You're asking all these little detailed questions. I was going to fall asleep if I didn't start talking, so that's what I did.
[21:10] I do think that there are techniques that the teacher can use to engage the students. When the students are awake and participating, you'll get much more feedback, you're getting much more information back from the students.
[21:27] If you've really prepared your material, like you've broken it down, you can tell, "I shouldn't be able to move on if they can't answer this question." It's part of the preparation for your course.
[21:39] I want to give a concrete example. If you want to teach about how to identify angles. I'm sure that a large portion of the audience has had to name an angle A, B, C based on the three vertices of the segments. You can tell if someone can do that by saying, "Well, can you even identify where the angle is in this diagram?"
[22:04] You can ask that question. It's a quick question. Maybe they get it, you just move on, if they don't, then you have to say, "Aha! You can't even find the angle. Let's get up on the board and start tracing this angle."
[22:18] You can always break it down more. You shouldn't move on if they can't do that. You're not going to be able to say, "No, that's angle A, B, C," if they can't even find it on the board.
**Jessica**: [22:27] Solania, you have teaching experiences well. Do you have any techniques that you've used to help people feel comfortable asking questions or to find out whether they're following along?
**Solania**: [22:39] Yeah. I ask questions that I'm 90 percent sure everyone already has an answer to. In the very, very beginning of the class, I'll ask very obvious questions that everyone looks at each other and they're like, "She knows the answer to this, right?"
[22:56] Then they look at each other uncomfortably, but then they get in the habit and in the flow of answering questions. They start to grow in confidence.
[23:04] When they get to the point where it's a real question or a tricky question, they've already developed this habit of answering me. They've developed trust that I'm not going to make them feel stupid or I'm not going to talk down to them and I expect a dialogue. That's what I try to do very, very early on in the session.
**Coraline**: [23:20] I really like that. Is there a way to do that if you aren't in front of people? If you're in a video or an e-Book, can you ask some questions that they're just going to answer to themselves? Do you think that works as well?
**Eric**: [23:31] In my courses, what I try to do is always get someone to produce something. It's easier to say, "Oh, I answer that. I know the answer," when you haven't even formulated it in a sentence. It could be type something into a box or write down a sentence. I want them to be engaged. I don't want them to be just listening.
[23:54] I think that, Solania, what you said is great. Get them in the habit of answering easy questions that gets their guard down, so they start answering the hard ones even if they have to guess, it's better than silence.
[24:05] Another cool technique if you are in a classroom setting is to ask a question and then not call on people until you get a lot of hands. Often, it's easy...
[24:18] You're nervous there's a silence in your...You're wondering, "Are people even paying attention?" You just want the first person to answer and you move on, but wait, just let people think for a little bit and you'll get the people who are less quick to start raising their hands.
[24:39] Then when you call on them, don't give a non-committal answer. Just say, "OK, thank you," and call on another person and let them tell their answer. Then you say, "Thank you," and you move on to the next person.
[24:50] You can get a lot of people answering the same question. People can hear the variety of responses. They can modify their answer from what they've heard other people say. It really helps engage more people.
[25:06] If you have a class of 30 people and one-person answers, you're getting into this habit of people waiting for that one smart person to raise their hand first. That's not what you want. You want to create this [inaudible] , it's a great way to say it's a habit that the class all has to participate or are just going to sit here and wait.
**Solania**: [25:27] I love that. One of the things that I also do, because for organic chemistry, there's a lot of chemical reactions that you have to map out, and it generally takes a little bit of time to have an answer anyway.
[25:37] I'll say, "Let's take two minutes. Everyone pull out a piece of paper, brainstorm, talk to your neighbor and we'll take answers in a bit." There's this expectation that everyone's going to work on it. Everyone's going to be engaged and you're giving everyone a chance not just the few people who always have their hand up.
**Eric**: [25:54] Yeah, that's awesome.
**Coraline**: [25:56] I want to go into a little bit more of the why. We've talked a lot about the how and how to engage audiences, how to engage classrooms, and how to engage people through other media. What I really want to dig in to is, we have a lot of people that come in through different methods and media.
[26:15] For example, we've talked about the boot camps and we've talked about video courses and things like that. Then you just have people that come in and they're like, "I want to build a website. I want to learn on Ruby on Rails." They go and they pick up a video here, a video there. They self-teach. They look on Stack Overflow, etc., etc.
[26:35] It sounds like, Eric, one of your concerns is that they're coming in and they're learning these techniques without actually knowing any of the fundamentals of programming or understanding why we do some things the way we do some things.
[26:49] I'm wondering, eventually a lot of these folks wind up to be competent programmers. They may not be able to articulate to you the fundamentals even though they perform them well, is that a problem? Should we be teaching these people and why should we care?
**Eric**: [27:04] That's a really good question. Is it a problem in itself that there's a lot of work out there for programmers? A lot of it is, I wouldn't say pretty menial, it's building websites, three-page website, it's the same over and over, maybe it just differs in the design. Why not have untrained people work on that?
[27:27] I don't think that's a problem, but what I prefer, what I focus on is more of a view that a rising tide lifts all boats, that having a more educated community, a more educated population is just better for everybody. I feel like my mix of skills and my interests can help that in a small way.
[27:48] I think that there's a lot of fundamental stuff in programming that I use all the time that I'm very grateful to have. I'm privileged to have an advanced degree in computer science. I don't think that the concepts are beyond people.
[28:05] In a kind of a democratic ideal, I feel like all programmers could know this stuff, and it just hasn't been presented in the right way or people just haven't had the opportunity to learn them. I just want to do my part to bring that to people.
**Avdi**: [28:19] Do you think there's an over evaporation that's important? You think we should be teaching fundamentals first and then the practical skills that build on top of them? Is it too late if you've gone to a boot camp and just learned the magical incantations that type to turn something into a web service, or is there a problem there?
**Eric**: [28:37] No, I don't think it's ever too late. You do pick up habits. I have a lot of bad habits because I learned programming on my own.
[28:46] To stray from your point a little bit, I think that might be one of the bigger issues is that a lot of people that are in programming today didn't need a classroom setting, they didn't need a formal education, they just learned on their own.
[29:03] That leads to this insular nature of our community that we respect the people who could just figure it out and don't need to talk to other people and don't need to help other people learn. They don't see the value in that. I didn't have that, so why would other people need that?
[29:22] I think that part of the ideal of education is that you can pass everything down. You can pass everything to other people. You can help others. You pull everybody up. You can climb on to the top of the wall and you can reach down and help other people.
**Avdi**: [29:36] How much of it is on teachers to understand what the baseline of understanding is? Is there a problem there that we're not really recognizing whereas students are, and their progression to understanding of fundamentals?
**Eric**: [29:47] I would say that the problem is more that we're lazy, everybody. We see that there are some students who maybe already know it, because they've been working on their own.
[30:01] I was listening to this really great MPR radio bit about why there were so few women in computer science, and their conclusion basically was that in the '80s, personal computers were marketed to boys as something that you could play your video games on.
[30:19] They told a story of this woman who eventually got an advanced degree in engineering or something, but she was in computer science, and was the first class of the first 101.The professor was like, "You don't know that already? You don't belong here."
**Avdi**: [30:36] Wow.
**Eric**: [30:36] She was the only woman. The reason that she didn't know it was she didn't grow up with a computer and because they were for boys. She didn't spend hours a day tinkering with it.
[30:49] I think that the bigger issue is people being lazy. They just teach to the 90 percent of the class who had a computer since they were young. They probably programmed in basic or made some web pages or something and just say, "I don't need to go deeper. I don't need to..."
[31:08] It's not about fundamentals. It's simply that we just haven't had to talk about how to type, how to close your parentheses, how to put a semicolon at the end of your line. Those things are assumed knowledge even at the first course in college.
**Charles**: [31:25] I have a quick follow-up to this because I think it is relevant to the discussion of teaching though. What if this had been sort of an advanced class?
[31:36] I don't want to turn this into a feminism issue if we do need to cater to everybody coming in, despite their experience or level or wherever they're at, but say this was an advanced course where the expectation was that you actually would have that it's not the entry-level class.
[31:51] Would that be an appropriate response then to a student who didn't seem to have all the requisite knowledge to be in the class?
**Eric**: [31:57] Yeah, I do think that you need prerequisites in courses.
**Avdi**: [32:02] Can I challenge that for a second?
**Eric**: [32:03] Sure. Yeah, please.
**Avdi**: [32:05] I just want to say I'm not sure that I can see that being grounds for an after-class teacher-student discussion...
**Charles**: [32:13] Yeah, that's...
[32:13] [crosstalk]
**Avdi**: [32:13] but this kind of public shaming, no matter how "warranted" in the circumstances somebody managed to find themselves in a place that they don't seem to be qualified for, number one, I don't think it accomplishes anything.
[32:29] Maybe it was somehow [inaudible] warranted, but even if it was somehow warranted for that person, I guarantee you five other people in that class heard it and clamp shut on some questions that we're going to ask.
**Charles**: [32:41] For sure.
**Solania**: [32:43] The words, "You do not belong here," are never appropriate.
**Avdi**: [32:47] Yeah. Just generally speaking, [laughs] I think that's absolutely right.
**Charles**: [32:52] The appropriate response would be to take them aside after class and say, "You know, programming 101 is a prerequisite for this course," or something like that?
**Avdi**: [33:01] Just get a better feel for where they're coming from, why they seem to be coming into this unprepared and see if you can find a way to help them, but not in a way that just shuts them down potentially for the rest of their career and also has ripple effects to the rest of the class.
**Eric**: [33:19] Yeah, I have to agree with you. I think that that's true.
**Charles**: [33:22] Yup.
**Coraline**: [33:23] Thank you so much for bringing it up, Avdi. I think we do so much social damage to people who are entering our industry through unthoughtful actions like that. I think that's something we definitely need to address.
**Avdi**: [33:34] Just in general, I run into the situation regularly where somebody has big, weird holes in their knowledge. I had a weird educational background that I'm not going to go into here, but it resulted in me having all this advanced knowledge in some areas and then holes in other areas that could've caught someone by surprise and made them think that I was completely unprepared for where I was.
[33:57] Then I dropped into a programming position at this big contractor that had all kinds of terminology and TLAs that everybody knew. I could easily have come across as, "Avdi clearly doesn't belong here," yet years of doing great work there, I clearly did belong there.
[34:17] I don't know. It's not always a cut-and-dry case. When somebody has a question like that, that they don't belong there, it may just be that they, by some accident, have holes in their education.
**Charles**: [34:30] Assuming that's the case, I want to press this because I want to make sure that I understand it and that our listeners understand it. In that case, what questions should we be asking so that we can accurately assess where people are and help them where they're at?
**Eric**: [34:45] I think it all goes back to your preparation. I talked about breaking down your material. You're doing this task analysis. Each of those objectives that you've pinpointed can be further expanded.
[35:01] You can see the whole structure of knowledge of what needs to be known to be able to do this task, at least in the way that you want to teach it. Often, if you just turn it into a question or like a challenge to the class, they become feedback mechanisms to understand where the class is.
[35:23] Just like how I said, "I'm going to teach how to name an angle given the three points, but first can you even find the angle on the board?" That kind of thing is very common in classrooms. You can do that for any material, but you do need to have everything broken down.
**Solania**: [35:43] There's an opportunity here for the students to teach the teacher something because we think fairly often about known unknowns and unknown unknowns, but this is a case of where the teacher has unknown knowns.
[35:58] There's things that I know that I don't remember learning because it was a while ago. I don't realize that that's something that, no, it's not common sense. It's not built in. It's something I know.
[36:12] It's something I need to teach, but I don't know that until somebody asks me the question. Often, the right response is to say, "Oh, I didn't realize I already knew that. Thank you." Then you can change the course material.
**Eric**: [36:28] Yeah, that's a really good point. I'll tell a little story. I was teaching math. I was trying to teach people how to...They were kids. I was teaching them how to graph coordinates on a plane. I could tell that they were just so confused. They couldn't do the easiest ones, like one, one, where does that go?
[36:49] What I realized was that there were 10 new things that they're trying to learn at the same time. They had never seen a coordinate plane with axis. They'd never seen a number line. They'd never seen a coordinate pair written that way and know that the first one is the x-axis, and the second is the y-axis, and that the x-axis is the horizontal.
[37:12] There's so many things that they didn't know. I was confusing them with this apparently simple task, which was just draw a dot in one will spot. I realized, "Oh, wow, I need to take 10 steps back." We need to start just drawing number lines and finding at one point on that line.
[37:31] We need to talk about not really projections but being able to walk down the number line and then move up from that space and sort of meet where another line would be drawn on the Y-axis.
[37:47] There's so many things. That's one of the principles of teaching that you really need to keep in mind is you don't want to overwhelm them. You've got this great opportunity to teach in an hour. You want to be teaching one skill.
[38:03] That depends on their level what that one skill means but something that they can learn in that one hour, that they can master, that they can get right over 90 percent of the time.
[38:16] That's a really important unit to be thinking about. If you notice that they're confused, it usually means that they've got way too much to think about. If you can step it back, you can say...You might give someone a task in a workshop, "Hey, let's write some method calls. We'll chain them together." You just see that, wow, this is too much for them.
[38:40] You could get down to basics like, "OK, let's just find all the method calls in this code," or, "Let's write one method call with no arguments." Then you add arguments. You start to build up the skills that they need. Then you just practice it over and over because you need to be able to get to a mastery level in that hour, or you can repeat the lesson and get it in a few times.
**Coraline**: [39:10] Hearing this approach makes me despair of a boot camp ever being able to prepare a student for actual development.
**Eric**: [39:18] How long is a boot camp like, three weeks?
**Coraline**: [39:20] 12 weeks.
**Eric**: [39:21] Oh, 12 weeks.
**Coraline**: [39:22] It's funny. We've all seen the graph of things you have to learn to be proficient at Rails. It's this huge spider web graph. If you're teaching fundamentals like that, like going over, making sure people really understand what a method call looks like and how to write right one, I don't see how you could ever complete that in 12 weeks.
**Charles**: [39:39] I'm going to push this button. How long should it be? How long legitimately do you think it would take?
**Eric**: [39:44] To do a boot camp to teach someone?
**Charles**: [39:46] Yeah, to do a Rails boot camp and have somebody come out of there to the level of effectiveness that you think they need to have.
**Eric**: [39:52] It depends. Are you talking about an apprentice level, like able to pair with something?
**Coraline**: [39:57] We used the word competent beginner before. I think that's appropriate.
**Eric**: [40:00] I don't know. A year? It's really hard to say for a number of reasons. I don't know Rails. I do know there's a lot of moving parts in Rails. You have to learn HTTP. You have to understand this client server thing. You have to know HTML. These are not easy.
**Charles**: [40:21] What do you think, Coraline? You brought it up that 12 weeks isn't long enough.
**Coraline**: [40:26] I think that we're misleading people with boot camps, honestly, in telling them that they can get really great paying jobs right out of the boot camp and that they're going to be...We're lying to them, honestly, in a lot of ways. I don't think that we're generating a lot of competent beginners.
[40:41] For certain people who have a certain base kind of experience already and knowledge and are just looking for a formal way to wrap some of that up, boot camp is going to be great. We're doing a great disservice to a lot of people by charging them a lot of money and turning out people who aren't really ready for the work that there is ahead of them.
**Charles**: [41:00] We probably made a whole bunch of people angry. I tend to agree.
**Solania**: [41:04] [laughs]
**Charles**: [41:05] The thing that I'm seeing is the people who come out as that competent beginner or who are capable of picking up a job, generally, they tend to be the people who are the go-getters. After school, so to speak, they go home, and they go learn more stuff. They go out. They meet people in the community. They do the extra work.
[41:25] Otherwise, most of the people that I talk to, it takes them several months after they graduate to get enough experience on their own to get the job that they thought they were going to get when they graduated.
**Solania**: [41:37] Having actually gone through a boot camp myself, I have to agree with you all. When I did the boot camp, I'd already quit my job. I'd spent three months in my apartment 12, 16 hours a day, learning to code on my own.
[41:51] For me, I had that three months. When I was sitting in class learning about the MVC model and all that, I was hearing it for the third time. I wasn't coming out completely unknowledgeable.
[42:04] Even then, afterwards, there was still more to learn. I think that the good thing is that more people who do boot camps now are not coming at it, sitting down for the first time, knowing what Ruby is. They have done a lot of research.
[42:19] They're using it more to formalize their education, but I think that the pitch that you can go from nothing to competent beginner in three months, that's just ridiculous.
**Charles**: [42:28] I want to throw two more ideas on here. One is I was really hoping you were chiming in to disagree with us all.
[42:35] [laughter]
**Charles**: [42:36] The other thing is that I do feel like one thing that the boot camps do give to people is they give them confidence. After three months, they've really seen, "I'm smart enough to do this. I'm good enough to do this. I can figure this stuff out."
**Solania**: [42:51] It's like "The Wizard of Oz," when he gives the Tin Man a diploma.
**Eric**: [42:56] [laughs] "You do have a brain."
**Charles**: [42:59] Yeah, I've seen...
[43:00] [crosstalk]
**Coraline**: [43:00] I've seen the opposite of that. I have a channel on IRC called new2ruby. I see a lot of people who are coming out of boot camps who are coming out of a self-learning phase. Then their first job is dealing with legacy code, which is something they have not been prepared for whatsoever. I think all their confidence goes away in the face for legacy application.
**Solania**: [43:23] The other part of that though is that I don't think that the industry is ready for boot camp grads. In order to be successful, myself, I did a Hacker Residence Program for seven months where I had a lot of room to make a lot of mistakes, and to learn very quickly, and to really own my learning.
[43:40] Then I did the apprenticeship at thoughtbot, which was an amazing experience, where, again, I was taught best practices and given a nurturing environment.
[43:49] After you graduate boot camp, if you're able to get a junior-level position, or an apprenticeship position, or something where the expectation is you know enough to add value, but there's still a lot more, that you need a lot more support, I think that's just fine.
[44:06] The bigger issue is that there aren't a lot of junior developer positions. There aren't a lot of apprenticeships and internships unless you're a college CS major. Just the lack of support and on ramps for people who really want to break in, and who want to be successful, and who are willing to put in the work, I think that's a really huge problem.
**Coraline**: [44:24] I think that is an excellent point. That's exactly where I was going. Without that industry-wide support for new people, we're doing lots of people disservice and cost them a lot of money.
**Avdi**: [44:33] I just wanted to say I agree with everything I've heard, but I just want to put into perspective that I remember watching lots of fresh-outs from a four-year program for your computer science programs who had spent way more money and way more time getting to a level that was less proficient than I see people coming out of boot camps with.
[44:52] Don't know how in the hell that happens, but it did. In terms of even if a boot camp is a total loss...I doubt that any of them are total loss, but even if it is, it seems like a whole lot less the loss of time and money than somebody's four-year programs.
**Eric**: [45:09] One thing that I think that boot camps can fill in is there are real hurdles like obstacles that you might not be able to get over on your own. Having someone hold your hand during some of those hard parts could be really helpful.
[45:26] Even though you do have to work on your own, and you do have to study and practice and make a lot of mistakes, there are some really basic things that could just be passed to you, that would take you weeks to figure out but someone could tell you in 10 minutes. I think that those things, if we could find them and just sort of laser target them, we could do a lot.
**Charles**: [45:51] I really want to ask this because...I want to couch it in terms of teaching because I think that's really what we're talking about here.
[45:58] After the boot camp, when they're not quite ready for that junior-level job or maybe they're just having trouble finding that junior-level job, is it another learning environment that they need or is it something that looks a whole lot more like a job, like an internship? Is it maybe another after-boot-camp boot camp?
**Eric**: [46:18] It's a good question. Do we, as an industry, know what people need to know? Would you want to put someone through a...? I don't want to say sweat shop, but an apprentice does all the dirty work, right? They carry the wood for the master. They chop it. They carry the water, that kind of thing.
[46:39] Maybe there's stuff like that. You put your apprentices on updating the README and monitoring servers and stuff like that. After a year, they've picked up a little bit of skill here and there just from being surrounded by it. They see how the day-to-day work actually goes.
**Jessica**: [47:01] Ooh, I have a suggestion.
**Charles**: [47:03] OK.
**Solania**: [47:03] [laughs]
**Jessica**: [47:04] You mentioned those questions that can take forever to figure out online because you don't even know what to Google but answered in 10 minutes. One way to do those is if you have a mentor, if you have just someone you can call.
[47:20] Sometimes, it's even hard to identify those questions, but when you do, yeah, I think a little bit of personal attention might make a big difference at Lambda Lounge, which is the best user group in St. Louis.
[47:32] Mario Aquino has started a program. He calls it Lambda Mentors, where he's getting companies to sponsor. That pays for the time of experienced programmers to help younger programmers.
[47:49] The money actually goes to charity. It doesn't go to the experienced programmers, but the idea of being if you just have an hour or two a week with someone much more experienced, you can ask those questions. Then maybe you...
**Charles**: [48:03] That's really cool.
**Jessica**: [48:04] Yeah, cool. Maybe work on open source projects, but you have someone who can get you unstuck.
**Coraline**: [48:12] I have two people that I mentor on a weekly basis. I like the idea of mentoring quite a bit, but the way I've seen some boot camps handled mentoring is office hours. There's no guarantee you're going to get the same person two weeks in a row.
[48:23] I think mentorship is a personal relationship. If you don't have that personal relationship, you're not going to feel comfortable asking those "stupid questions".
**Eric**: [48:26] Yeah, for sure. There's actually a study about mentoring that showed that lots of companies have mentoring programs because they feel like they have to, but the ones that are effective are the ones where there's a personal relationship. They actually become friends, the mentor and the mentee.
[48:49] If that doesn't happen, they don't really care about each other. They're just going through the motions of having office hours like you were saying.
**Coraline**: [48:55] It seems like what we're talking about with the boot camps and with the lack of pedagogy, is this symptomatic of the tech industry not being willing to make investments but looking for quick solutions to problems?
**Eric**: [49:09] Maybe. We're young as an industry. We really don't know. If you look at, for instance, calculus, if you try to read the first calculus books, they're impossible to understand. I mean, not impossible. They take a lot of study. You're actually studying like, "What did he mean? What did Newton mean when he wrote this?"
[49:29] Now, you can take a calculus class, and there is a book. It's a really thick book with everything broken down, with all the theorems explained, a chapter on each theorem with lots of exercises for practice. That's just one of the textbooks.
[49:48] There's a lot of different books on that. We've learned over time how to teach the material not in the way that it was discovered but in the way that helps students. I think that that will happen in computer science programming and software engineering where you're actually building the practical stuff.
[50:09] I do think that there is that tendency to think short term where most software companies are like a year old. [laughs] They just got some startup funding. They just need to get an MVP out there. They don't care about practices.
[50:24] All that stuff blows up in their face when they start scaling. They start having to think about that. Then they have to hire real engineers to come in and figure this stuff out.
[50:34] At no point was there ever this gradual process of getting someone new all the way up to that point where you're hiring the 300,000 half-a-million-dollar-a-year engineer to scale your app. We just don't know how to do it. We just find them. You put out a job with a lot of money behind it. They appear, but we don't know how to build that person.
**Charles**: [50:57] I want to hit mentorship here for a second. I want to just talk back to that real quick and just talk about it. How do you find the right people to mentor?
[51:07] In other words, people who will fit your style, and fit the way that you approach problems, and fit the way that you explain topics? Then the other thing is how do you open yourself up so that people can find you if you're willing to mentor people?
**Eric**: [51:22] Yeah, that's a really good question. I teach on my blog. My main technique, my main secret is to go on a forum like Stack Overflow, find a question, and answer it on my blog. In IRC, if someone had a question, I'll just write it on my blog, then find the person again and show it to them.
[51:44] By focusing on real questions in the same language that they asked, I think that builds trust in people. They want more of what you have. The people who want it will find you. A lot of people will not like your style, and that's fine. The people who like your style will find you. Blogging, answering questions that people post in public forums, I think that's the answer.
**Avdi**: [52:11] I'd like to circle back around a bit onto something you talked about earlier. It's something I have a lot of interest in, which is the way that there are a lot of programmers with a great deal of knowledge, but who don't have a lot of skill at teaching.
[52:24] This is going to be one of those annoying questions, where I make an assertion. I'm curious to get your observations on it.
**Eric**: [52:30] Sure.
**Avdi**: [52:32] Here's an example of that that I've seen. There's a series of books that O'Reilly has, the "Head First" series. I've been aware of them for a year.
**Eric**: [52:41] Good series, by the way.
**Avdi**: [52:44] As a programmer, if you're not familiar with the series, they have these covers that are always a photo of some really perky looking person who's looking up at the camera, all ready to learn and stuff. I always used to look at them and write them off in my head as really cutesy and fluffy, not serious programming learning material.
[53:12] Recently, I had reason to look through one at great length, and I was really impressed with it. They do a lot with mixing things up, mixed media, a lot of pictures, a lot of changing gears, a lot of, "Here's a quiz, here's a little game, here's a little inset box answering some questions, here's a little box about some more advanced things."
[53:33] It's not a style that you see in a lot of programming books. I found out more recently that one of their rules for these books is to make the reader feel smart on every page. I think that's one of the things that my snooty programmer brain interpreted as, "Oh, this is cutesy and fluffy."
[53:51] It's actually really good material I thought and way better than some of the dry programming guides that I've read in the past.
[54:00] I feel like we've got this, in the programmer community — and particularly like in the sort of Linux worshiping Ruby community, Ruby parole etc. community — we've got this monomaniacal focus on text as the one true mediating format for all information.
[54:17] We all want to get back to the command-line. GUIs are bad, IDEs are bad, UML is bad, diagrams are bad, MICE are of the devil. It's all text, text, text, text, text, and therefore books full of pictures and things are bad.
[54:32] I feel like this is a poverty among programmers. It's not just about teachers particularly, or people that are writing books but the fact that we don't use mixed media to transmit our ideas at all. It seems like we're really shortchanging ourselves. Do you feel anything like that?
**Eric**: [54:52] I have to agree with everything you said. Head First is one of the biggest inspirations for my video courses and now my mentoring course. I have the first book which is Head First Java. The first chapters like what is Java and that kind of thing. It seems very light, but it's like a 500-page book.
[55:18] You flip to the middle, and they're talking about deep stuff that I don't know if I ever learnt in school. You actually trace through a garbage collection heap, and you have to figure out what's going to be collected and what's not.
[55:32] This is not something that's taught in most Java books. Maybe they mention that it has garbage collection and they talk about like you saying text. They just explain it's a generational garbage collector and it's safe and whatever. This is actually tracing through the execution of this garbage collector.
[55:53] I'm just constantly surprised by the depth that they can go into while making it fun, while making it interactive. There's exercises every few pages. There's actual lines on the page to write in the book. There's pictures, there's little cartoons, there's visual metaphors.
[56:14] All of these things like you're saying, we just don't use them enough. We are focused more on getting the knowledge down, and there's a thing that happens where we are able to explain stuff technically so that it's correct. We're very precise with our words. We phrase it in a certain way.
[56:34] We use a lot of such that's and stuff like that so that we're saying exactly what we want to say, but it doesn't teach anybody.
**Avdi**: [56:43] We're not conveying what we want to say. We're just saying it.
**Eric**: [56:45] Exactly.
**Coraline**: [56:45] We're teaching people who are exactly like us and not...
[56:47] [crosstalk]
**Eric**: [56:47] Yes, and who already know it.
**Avdi**: [56:50] We can formalize.
**Eric**: [56:51] Exactly. Someone who already knows it will come and read it and say, "Yes. You're right. That's a good explanation." No one who doesn't know it can make any sense of it. It's a huge failing that we value this idea of being able to be totally precise with our language and rightly so. You have to be on a computer in a programming language, but we don't value visual metaphor, which is a huge way of teaching.
[57:20] There's an explanation in "Head First Java" of pointers, and it's done with cartoons. The ability to build up this visual language for explaining how you can have a variable that has a pointer to another object and that the other things can point to the same object but be in a different variable.
[57:45] How now you can have an array of pointers to objects. All of this stuff is done totally visually, and it's instant understanding. I talked about avoiding cognitive overload. This is how you avoid cognitive overload. Is, you don't make them read three pages of text explaining what pointers are. You give them a metaphor that just instantly installs this understanding in their brain.
**Avdi**: [58:10] Right.
**Coraline**: [58:10] We're too busy talking to ourselves, and then we wonder why we have monocultures.
**Eric**: [58:13] Exactly. Kathy [inaudible] had a thing, and she still talks about it in her talks. I think it's judgmental to say this, but that if you focus on the way the book is started, meaning when the author had the idea for the book.
[58:35] The books that really succeed that actually do better are focused on the reader. They're focused on, "I want the reader to learn XYZ." You have to read these paragraphs of obtuse texts and say, "Oh, I have to redo this. This is not going to help the reader."
[58:55] It's a shame. It's a shame that we start our journey on writing a book with this idea of becoming famous for this topic.
**Avdi**: [59:05] I have a follow-on to that. It's another of those things I want to state it and get your take on it. I feel like this problem we have as programmers in teaching is a big deal not just for the new programmers that are coming up. It's a problem for us doing our jobs.
[59:28] I really feel like fundamentally what we're doing, our job, is basically just to learn it to teach. We're here to synthesize. We are here to come in and understand a domain, understand a little closed universe that is somebody's problem.
[59:45] We have to then convey that to the computer, or we have to convey it to the other people on our team. We have to convey the facts and practicalities of the computer back to the customer. These are all learning and teaching processes. It's basically what we're doing all day. It seems like...
**Eric**: [60:03] Avdi, you're totally right. That is why programmers can actually make really awesome teachers. Is, we understand that any skill can be broken down into steps, and the decisions can be made mostly systematically. Even if there's some element of randomness in there, it's like, "Oh. Well, just choose one. It doesn't matter." That's like an algorithm. Right?
**Avdi**: [60:27] Yeah.
**Eric**: [60:27] We understand that. We do that every day. I think that we can dominate teaching if we wanted to, but we need to do that. We need to work on the skills.
**Solania**: [60:38] Yes. Totally agree that in some ways you can look at programming as exactly teaching. Teaching on a computer, teaching the people to read our code or the people who come and later read our code, teach the people who use our user interface how to work with the software we're creating. It's all teaching at some level.
**Eric**: [61:00] For sure. It's all modeling. It's all about ideas. One of the problems with modern programming languages is that it's so much typing. You have an idea that you develop with someone for a couple hours, and then you try to type it. It's going to take you two weeks to type it all in.
[61:20] The typing dominates the actual important part which is to come up with the great model of the problem so that you could solve the end-user use case.
[61:29] [background music]
**Charles**: [61:30] I think that's a great place to wrap this up. I completely agree. All right. Should we do some picks?
**Coraline**: [61:37] Sure.
**Charles**: [61:38] Before we get to picks, I want to take some time to thank our silver sponsors.
[61:44] This episode is sponsored by Code School. Code School is an online learning destination for existing and aspiring developers that teaches through entertaining content. They provide immersive video lessons with in-browser challenges which means that each course has a unique theme and story line and feels much more like a game.
[62:05] Whether you've been programming for a long time or have only just begun, Code School has something for everyone. You can master Ruby on Rails or JavaScript as well as Git, HTML, CSS and iOS. More than a million people around the world choose Code School to improve their development skills by learning or doing. You can find more information at codeschool.com/rubyrogues.
[62:30] Avdi, do you want to start us with picks?
**Avdi**: [62:34] Sure. I've got a few things saved up. I'll try to be quick.
[62:39] I don't think I picked Inoreader last time. I feel like I picked it somewhere, but I didn't see it in the history.
[62:30] Anyway, short version. I, like many people, am a Google reader refugee for reading my RSS feeds. Went to Feedly like a lot of people did and got increasingly dissatisfied with it. Recently, I switched to Inoreader. I don't really have one reason why I switched to it. It was two dozen different things that they just did better. Inoreader is cool.
[62:47] Windows 10. It was Windows 8.1 was trying to be. Just upgrade today and, as the Windows goes, it's pretty darn good.
[62:56] I just got back from helping out at one of Sandi Metz Practical Object-Oriented Design Workshops. I am biased because, Number One, I really like Sandi. Number Two, when I get to help out with him, I make money out of this.
[63:11] I will say that her courses are fantastic and very much apropos of this episode. I have learned so much about teaching from her, from watching her. She's done a lot of research into teaching methods.
[63:23] She does foot stuff that I stand back and think, "Wait. You can tell adults to do that?" I realize that the techniques that work on kids work on adults, too. They just fix something in their memory which I would never in a million years figured out how to completely fix in their memory. If you ever have the opportunity to take one of her courses, I highly recommend it. They're super cool.
[63:45] The only other thing I'll say is that I started a newsletter recently. It's weekly-ish and if that sounds interesting to you, I'll put a link in the show notes to the blog post where I introduced it.
[63:57] I think that's it for me.
**Charles**: [63:58] Coraline, what are your picks?
**Coraline**: [64:00] My first pick, not at all technical, but really interesting. It's an article in New Statesman called "Sex isn't Chromosomes — The Story of a Misconception. The Century Misconception about X and Y."
[64:10] Often, we hear with the model of the XX and the XY chromosomes. What the article describes is that it's actually founded on faulty principles. It's a simple concept complicated by the realities of biology and lives.
[64:23] The approach to chromosomes breaking things down to binaries has been responsible for encouraging reductive and essentialist thinking about sex. The scientific world apparently has moved pass this concept, but the popular appeal remains.
[64:36] The article talks about a book by Sarah Richardson who's an Historian and Philosopher of Science. The book is called "Sex Itself. The Search for the male and Female in a Human Genome."
[64:45] The book talks about a very public debate that happened between scientists in the early part of the 20th century where the concept of sex chromosomes actually emerged and what happened in the intervening years. It's a comprehensive demolition of the very term of sex chromosomes. It attacks on [inaudible] . It's about a century old and due for revision.
[65:04] It's a really interesting read. I would say a subject close to my heart as it deals with sex and gender. Very interesting also from the perspective of what happens when a concept in science is popularized and its popularity outlives its usefulness?
[65:18] My second pick is a book by Octavia Butler, who I have been reading a lot of lately, called "Parable of the Sower." It's set in the future where government is all but collapsed. It centers on a young woman named Lauren who possesses hyper-empathy — the ability to feel perceived pain and sensations of others.
[65:34] In the book, civil society has been reverted to anarchy due to scarcity and poverty. The main character develops a philosophical and religious system during her childhood in the remnants of the gated community in Los Angeles.
[65:47] When the community's security is compromised, her home is destroyed, her family is murdered and she travels north with some survivors to start a new community based on her religion.
[65:55] The novel won the 1994 Nebula Award for best novel. It's a beautiful and moving post- apocalyptical novel with a really interesting philosophical twist. Parable of the Sower by Octavia Butler. I'll post a link to Amazon, page on that on the show notes.
**Charles**: [66:10] Jessica, what are your picks?
**Jessica**: [66:11] I've been reading "Getting Things Done" lately because I actually decided that I want to get organized which is a big change for me and a step in my eventual adulthood.
[66:26] What I want to pick is the Wunderlist app. It's a to-do list done really well. That's Wunderlist, W-U-N-D-E-R. It's also created by a really awesome company. Chad Fowler has been leading the development team there. Even though it's now owned by Microsoft, it's still awesome.
[66:45] Did I pick Wunderlist already? I think I did, but you know what? I'm picking it again because it totally goes really well with Getting Things Done and creating organization in my life so that I can stop running through all the things that I need to do. In my head, when I'm in the shower, I would rather reserve the shower for ideas.
[67:02] My second pick is a podcast. It's Partially Examined Life. It's a philosophy podcast that basically goes over classical philosophy text, but you don't actually have to read the text. You can just hear them talking about it and then, have a clue.
[67:17] When other people talk to me about philosophy, now, I have some context and can speak intelligently about it. You can pick it up anywhere. The episodes are pretty independent and it's pretty entertaining. Those are my picks.
**Charles**: [67:31] All right. I've got a couple of picks. Last Friday, I was given the opportunity to talk to this Together Tech. It's a boot camp in Cape Town, South Africa. They bring in underprivileged people and teach them to code. It's a nine-month boot camp. They go out of their way to actually find people who don't have a lot of or any computer background.
[67:58] What they're trying to do is they're trying to create role models in the community that have steady work and can contribute financially to the area. It's really, really cool. I just got to talk to them for an hour and it was amazing.
[68:16] I just want to throw that out there because they are doing great work. I was actually invited by one of their founders to speak to them. This all came off of the Daniel Kehoe episode and the Rails Composer kick starter. He backed it and then, he asked if I would come and talk to him. He backed it and got some Rails clips months.
[68:35] Anyway, the next one is — this is something I've been thinking about lately, so it's one of those there's no link for this. There's no book for this. It's just something that I've been thinking about. Just being intentional, just thinking about where you want to wind up. Especially within the last few days, I've been thinking about this with my kids and with my business.
[68:53] Just thinking about if nothing changes, if nothing advances within the next five years, where do I want to be? What are the principles behind that? How do I actually enact the parts of this that are critical to that then I continue to assess and evaluate as time goes on. I found that a lot of times we go onto autopilot for a lot of things.
[69:17] We just expect that we'll pick up what we need to pick up and that things will just kind of work out because they worked out for our parents, they worked out for other people that we know. I find that in a lot of cases I really have to pay attention to where I want to wind up. Then I have to work toward that and be very intentional about moving toward it.
[69:35] Anyway, I'll get off soapbox because this is already a long show but that's one thing that I've really been thinking. The next pick is "Highrise". Highrise was written by 37signals. They sold it off. It's pretty awesome CRM. I've been using it, and I'm really liking it. I'll go ahead and pick that. Just keep in mind it's no longer owned by Basecamp.
[69:55] Somebody else is running it, but it works great for me. The last pick I have is a podcast episode. The "Eventual Millionaire" podcast by Jamie Tardy. It is awesome, and I listen to every episode that I can. The idea is that she interviews millionaires about basically how they do things to help other people become millionaires. It's the idea behind it.
[70:20] She interviewed a guy named Rory Vaden about three weeks ago, and it was awesome. He really had some things...if you're in business for yourself or you find yourself doing a lot of different kind of mundane tasks, then this is an outlook on things that allows you to put off the right things, work on the important things and delegate the things that you don't have to be doing.
[70:45] It blew my mind. I'm going to pick that episode. Eric, do you have some picks for us?
**Eric**: [70:50] Yes, I do. My first pick is a podcast as well. It's called "Ruby Rogues".
**Charles**: [70:56] Never heard of it.
**Eric**: [70:58] I know. It's kind of obscure. You guys wouldn't have heard of it. I really like it. I'm a big fan, and I try to listen as much as I can. I don't always understand because I'm not really in the Ruby world but great hosts, great guests. Thank you for that. My second pick is a YouTube channel that someone has been posting all these old Alan Kay talks.
[71:23] One of them is from 1972. It's amazing that he's been speaking for so long, and it's basically the same topics that he's been talking about. The other thing about Alan Kay is you have to listen to the same ideas over and over because they're so deep.
[71:39] When I first started listening to him, I didn't really understand what he was talking about but because he gives similar talks over and over, same topics, you start to get what's going on. It's nice that there's now a channel that you can just put on autoplay and listen to all of that. My next pick, a book called "Mindstorms".
[71:58] Mindstorms is Seymour Papert's book about his research at MIT into the logo programming language and how it can help education. I know there's a lot of talk these days about learning how to code and we need to all learn how to code.
[72:17] His point in using computers in education wasn't that programming in itself should be the aim, it's that — sort of like what we were talking about — making models. If you can make a model on a computer, you are actually cementing your understanding. By playing with that model, debugging it, you're actually thinking about thinking.
[72:38] This book talks about how that can be and his explorations of different kinds of things you can teach using logo back in the day.
**Charles**: [72:49] Awesome. Let's go ahead and wrap up the show. Thank you for coming, Eric.
[72:54] [background music]
**Eric**: [72:54] Thank you so much. It was a big pleasure.
**Charles**: [72:57] It was so fascinating to talk about too. But we'll wrap up the show. We'll catch you around next week.
[73:05] Hosting the 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 C-A-C-H-E-F-L-Y.com to learn more. Would you like to join the conversation with the Rogues and their guests? Want to support the show?
[73:31] 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/pilot.