02:20 - Eric Normand Introduction

03:31 -    Old vs Young Programmers

05:38 - Teaching Fundamentals

11:02 - Teaching Backgrounds

12:13 - Why is so hard to be a good teacher?

15:54 - Teacher Feedback

19:46 - Asking Questions

25:56 - Community Education

28:20 - Order of Operation

29:36 - Recognizing Students Understanding of Fundamentals

31:25 - Should there be prerequisites?

34:30 - How to Assess Where People Are 

35:43 - Teaching the Teacher

39:10 - Bootcamps 

45:52 - After Bootcamps

Mentoring

52:11 - Skill vs Knowledge

 

More From Eric

Picks

Inoreader (Avdi)
Windows 10 (Avdi)
Sandi Metz's Courses (Avdi)
Avdi Grimm: I have a newsletter. You could subscribe, maybe. (Avdi)
Ian Steadman: Sex isn’t chromosomes: the story of a century of misconceptions about X & Y (Coraline)
Parable of the Sower by Octavia E. Butler (Coraline)
Wunderlist (Jessica)
The Partially Examined Life (Jessica)
Together Tech (Chuck)
Being Intentional (Chuck)
Highrise (Chuck)
Eventual Millionaire with Rory Vaden (Chuck)
Ruby Rogues (Eric)
Yoshiki Ohshima's Youtube Channel (Eric)
Mindstorms: Children, Computers, And Powerful Ideas by Seymour A. Papert (Eric)

Special Guest: Eric Normand.

 

Bears chewin' on the wires again. [sighs]

Damn bears.

Constant problem.

It's what you get living in Yellowstone.

Jellystone.

Jellystone, there we go.

Yeah, yeah.

Don't rub your food on the wires.

Good advice for life.

Hey everybody and welcome to episode 232 of the Ruby Rogues Podcast. This week on our panel we have Avdi Grimm.

Hello from Tennessee.

Coraline Ada Ehmke.

Hi.

Saron Yitbarek.

Hey, everybody.

Jessica Kerr.

Good morning.

I'm Charles Max Wood from DevChat.TV. And this week, we have a special guest, Eric Normand.

Hi, everybody. I'm calling from dark and stormy New Orleans.

Do you want to give us an introduction?

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 a side that I run called LispCast. And I publish the Clojure Gazette. I do a lot of educational courses on Clojure and functional programming. And I'm really happy to be here.

You're a busy guy.

Yeah, tell me about it.

Do you have kids, too?

I have one daughter. Yeah, she's three, just turned three this weekend.

Luckily, kids or no, big deal at three years old, right? Just, super easy.

Oh, yeah. This is, yeah.

Give them a peanut every now and then and everything's fine. [Laughter]

I barely hear about her. She just takes care of herself.

[Laughs] A peanut.

That independent age.

Yeah, you just put kids on auto-pilot, right?

Yeah. They…

Auto-parent.

[Chuckles] Auto-parent.

There's a setting in the back. Most people don't know there's a switch.

So, what are we talking about today?

The topic on the docket is teaching and how we can all do more to teach technical topics.

I take it Eric has some opinions about this.

Yes, I do. I hope they're strong enough. I think that there are a lot of really smart people in our community, in the tech community and programming, and they know all these awesome topics. And they have all this deep expertise. But what disappoints me is the level of teaching skill that we have in our community. And 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 of experience.

Oh, wow.

So, we have this desperate need to teach people very quickly so that we're not just building legacy software every five years.

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 new about it but the new guard doesn't because we don't have enough people teaching them about it?

That is something that concerns me. But I actually don't experience that. I have known a couple of old programmers. And the ones I knew didn't seem to say, “Oh, we knew it all back then. And kids these days just don't get it.” 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. And so now that we have those things, we're rediscovering them. 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.

What I'm really interested in is the 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. It's just some expertise that I've got deep down inside that I've been doing for 10 or 15 years. And I can finally bring it up to the surface and clean it off and organize it well and show people what is actually possible. And hopefully, I get them to leapfrog into more expertise.

Now, how do you think we're teaching those fundamentals today and what's wrong with that?

Oh, that's a really good question, and I don't want this to sound like a lot of complaining. But I'm pretty sure it will.

Old man shouts at cloud computing.

[Laughs] Right. [Chuckles] 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 the best person to teach something is someone who just learned it. And that bugs me, because the reason they're the best is because they don't have teaching skills. And so, they can just talk about what they just learned. And someone who's 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. The act of teaching is to actually break that down so that anybody could learn it given the right prerequisites, et cetera.

And so, 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. 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. So, 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. 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. But you could break it down that far.

You just said there were three things. Could you do a one, two, three on those?

Sure. The first one is to figure out why they need to learn it. So, you 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. Some of the things you're going to break down are physically type at the keyboard this thing, right? But 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. So, you could sit there and do it yourself, I mean in a program. So, 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 parentheses here? Why did I put a comma? Why did I do a method call, et cetera? And you break those down into some learnable chunks. 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. But you want to get to a level where you're pretty sure you can teach each of those chunks.

And then the last thing is to align the activities that you do with the actual learning objectives. So, this classic example 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. And what she did was she made a crossword puzzle or a word search of all the important facts and names and places. And those two aren't really aligned. You're not going to learn. 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. And so, that's very important when we're teaching.

I see this a lot where someone will simply give the syntax of the language, which is purely facts. It's not understanding. And then the next step is, now let's write a web service in this. And there's this huge jump that has to be made by the learner. And 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 parentheses and your curly braces, all the way to, how do you go about designing your models, your views, and your controllers?

Eric, if I'm understanding you correctly, you seem to be indicating that people who teach developers need to have a teaching background. And I can't help thinking of CS programs that do employ teachers with actual training on pedagogy whereas bootcamps tend to employ developers. But in my experience a lot of CS graduates are not really prepared for real-world work. So, where's the gap there?

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. So, the problem there is they're really good at teaching but they're not domain experts. And that's a real shame. We have the opposite problem. It's that you can become a professor of Computer Science by getting a PhD and doing some post-doc. So, 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. I know that a lot of my professors were like that. They were super smart but you had to do the work. And especially in college, we do expect the students to be doing most of the work.

So, when you talked about what it means to be a good teacher and the three steps, it sounds very logical and very straightforward. So, why is it so hard to actually be a good teacher?

That's a really good question. I think it does take a lot of work. And I think… I don't like to talk about people's egos getting in the way. But one of the things is we don't, 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. There are a lot of pejorative terms like, “Oh, you're dumbing it down, or you're over-simplifying it.” And those terms, maybe you're not oversimplifying it. You're just breaking it down. And you're giving it in chunks that someone can understand. And 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. But 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 that no one understands gets.

So, I guess that's one thing that I see here, is that a lot of people are coming in through say the bootcamps where they actually get some kind of traditional-looking training. And then you have other people that are coming in that are self-taught and you mentioned maybe they pick up a course that explains things really well. 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, because I know that they can ask clarifying questions. 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, so the teaching styles have to be a little bit different…

Oh, right.

Just because the media is different. So, is there a way of knowing that one is going to be better for a new programmer than another?

That is a really good question and something I struggle with myself in my own courses. I was trained, like I said before, in the classroom learning style. And the nice thing about that is you get very fast feedback. You can see if your students are learning, if they're getting it right away. And you can move on quickly. You can slow down if they're not getting it. And even, “Okay so this was a total waste. It was way over their head. Tomorrow I'm coming in and we're going to go deeper. I'm going to break it down further.” And you can do that much more iteratively. And so, that's what you get in these bootcamps, 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 [chuckles] if they're going to… who they're going to target, really. I don't know what the audience knows. And I have to do a lot of assumptions, a lot of research figuring out, like am I 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, that kind of thing.

I totally agree with Chuck's point, because I taught Organic Chemistry for a couple of years, which is notoriously a very tough science course. And I think that 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 modify what I did to benefit my students. And when I had to write a tutorial for that online, it was so much harder, because I had no idea at what point the reader was able to follow, at what point they fell off. And so, 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?

It does help that you have previous experience teaching that material. Even if you gave a one-hour talk at a meetup, you would be able to see, do these ideas, are they over someone's head? What were the questions like, that kind of thing. 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. And maybe you could just have a conversation with them. Try to teach it to them on the phone. And see where they have trouble. See where they have gaps in their knowledge that you could fill in, all those things. Get the feedback and try to then cement it into some artifact like a course or a tutorial. And then of course, you got online. Online you can get plenty of feedback.

So, 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. So, we're going into basic Active Record, basics with Controllers and Views. And I put a course together and 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?” And then if they have an issue with another one thing, then it's not so intimidating to move onto 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.

But 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? I can see different media too, like eBooks 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.

I don't have a very good answer myself. I have a forum that I hope 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 ask in the forum because other people can benefit from the answer.” And so, I'm hoping that that will be enough feedback. I do get quite a lot of questions by email. And unfortunately, what I've done in the past is because the course took three months to make and then I just release it to the world, when I would get a question that wasn't answered, I would have to just answer it in the email. And just that one person benefited. And I couldn't change the course. Now that I'm doing weekly lessons, I'm hoping… I just started. I'm hoping that people will ask questions and then that will give me enough material for the next lesson and address questions that way.

Speaking of questions. Chuck, you said something earlier that I found really interesting about how when we are teaching in person, we expect people to ask clarifying questions. That's a responsibility of the learners in a live course.

Yes.

And I think that's challenging for some people. Not everyone feels comfortable interrupting and asking a question. So, on the one hand, some people who are less comfortable asking questions might be better off with the online courses. But on the other hand, for our listeners, when you're in that situation, when you're in a workshop, say, or a bootcamp or even a meeting at work, it's not only okay for you to ask questions. It's your responsibility.

That's a really good point. If you want to learn, you have to deal with the inadequacies of the teacher, I guess is [inaudible]. [Laughter]

You're there to absorb as much as possible and make as much use of the time in front of the teacher as you have. And that's how for instance 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 [chuckles] too much in class. And I'm like, “I'm bored. I need to engage myself here.” But, sorry… JESSICA:

Who would get mad at you?

Oh, other students because they'd be like…

Oh, okay.

“Oh, you're so pedantic. You're asking all these little detailed questions.” And I was going to fall asleep if I didn't start talking. So, that's what I did. I do think that there are techniques that the teacher can use to engage the students. And when the students are awake and participating, you get much more feedback. You're getting much more information back from the students. And 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, right? And it's part of the preparation for your course.

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. But you can tell if someone can do that by saying, well can you even identify where the angle is in this diagram, right? 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. So, let's get up on the board and start tracing this angle.” And you can always break it down more. And you shouldn't move on if they can't do that. You're not going to be able to say, “Oh, that's angle A, B, C,” if they can't even find it on the board.

Saron, you have teaching experience as 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?

Yeah. I ask questions that I'm 90% sure everyone already has an answer to. So, if it's something, just in the very, very beginning of the class, I'll ask just very obvious questions that everyone looks at each other and they're like, “She knows the answer to this, right?” And they look at each other uncomfortably. But then they get in the habit and in the flow of answering questions. And they start to grow in confidence. So, when I get to the point where it's a real question or a tricky question, they've already developed this habit of answering me. And 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 dialog. So, that's what I try to do very, very early on in the session.

I really like that. Is there a way to do that if you aren't in front of people? So, if you're in a video or an eBook, can you ask some questions, like questions that they can just answer to themselves?

Do you think that works as well?

In my courses, what I try to do is always get someone to produce something. It's easy to say, “Oh, I answered that. I know the answer,” when you haven't even formulated it in a sentence. So, it could be, type something into a box, or write down a sentence. But yeah, I want them to be engaged. I

don't want them to be just listening. I think that Saron, 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.

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. So, often it's easy, you're nervous there's a silence and you're wondering, “Are people even paying attention?” And so, 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 raise their hands, to start raising their hands. And then when you call on them, give a non-committal answer. Just say, “Okay, thank you.” And call on another person and let them tell their answer. And then you say, “Thank you,” and you move onto the next person.

And so, 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. And it really helps engage more people. 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. And that's not what you want. You want to create this, and Saron it's a great way to say it, it's a habit, that the class all has to participate or we're just going to sit here and wait.

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, so 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.” So, 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.

Yeah. That's awesome.

So, 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 and how to engage classrooms and how to engage people through other media. And what I really wanted to get into is we have a lot of people that come in through different methods and media.

So for example, we've talked about the bootcamps and we've talked about video courses and things like that. And then you just have people that come in and they're like, “I want to build a website. I'm going to learn Ruby on Rails.” They go and they pick up a video here, a video there, and they self-teach. And they look on Stack Overflow, et cetera, et cetera. And 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. And so, 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? And should we be teaching these people? And why should we care?

Okay. That's a really good question. So, is it a problem in itself that there's a lot of work out there for programmers, a lot of it is, I would say pretty menial? It's building websites, a three-page website. It's the same over and over. Maybe it differs in the design. Why not have untrained people work on that? 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. And I feel like my mix of skills and my interests can help that, in a small way. 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. And I don't think that the concepts are beyond people. So, I feel like in a democratic ideal, I feel like all programmers could know this stuff. And it just hasn't been presented in the right way or the people just haven't had the opportunity to learn them. And I just want to do my part to bring that to people.

Do you think there's an over-evaporation that's important? Do 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 bootcamp and just learned the magical incantations to type to turn something into a web service or is there a problem there?

No, I don't think it's ever too late. You do pick up habits. And I have a lot of bad habits, because I learned programming on my own. I think that might be, 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. And that leads to this insular nature of our community, that we respect the people who 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?” 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 can pull everybody up. You can climb up to the top of the wall and you can reach down and help other people.

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 where students are in their progress or their understanding of fundamentals?

Yeah. I would say that the problem is more that we're lazy. You know, everybody. And so, we see that there are some students who sort of maybe already know it, because they've been working on their own. I listened to this really great NPR radio bit about why there were so few women in Computer Science. And their conclusion basically was that in the 80's, personal computers were marketed to boys as something you could play your video games on. So, they told the story of this woman who, she eventually got an advanced degree in Engineering or something, but she was in Computer Science. And it was the first class of the first 101 and the professor was like, “You don't know that already? You don't belong here.”

Wow.

And she was the only woman. And the reason that she didn't know it was she didn't grow up with a computer. And because they were for boys. And she didn't spend hours a day tinkering with it. And so, I think the bigger issue is people being lazy, they just teach to the 90% of the class who had a computer since they were young, and 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…” 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.

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 an advanced class and, I don't want to turn this into a feminism issue. 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, 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?

Yeah. I do think that you need prerequisites in courses.

Can I challenge that for a second?

Sure. Yeah, please.

I just want to say, I'm not sure that… I could see that being grounds for an after-class discussion, teacher-student discussion.

Yeah, that's fair.

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. And it's probably, even if it maybe was somehow, I cringe at “warranted”, but even if it was somehow warranted for that person, I guarantee you five other people in that class heard it and clamped shut on some questions they were going to ask.

For sure, for sure.

Yeah.

The words, “You do not belong here,” are never appropriate.

Mm.

Yeah, I think yeah. Just generally speaking. [Chuckles] I think that's absolutely right.

Mmhmm.

So, 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?

Or 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.

Okay.

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.

Yeah. I have to agree with you. I think that that's true.

Yeah.

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.

Just in general. So, I run into this situation regularly where somebody has holes, 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 have caught someone by surprise and made them think that I was completely unprepared for where I was. And then, I dropped into a programming position at this big contractor that had all kinds of terminology and TLAs that everybody knew. And I could easily have come across as, “Avdi clearly doesn't belong here,” and yet years of doing great work there and I clearly did belong there. So, I don't know. It's just, 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.

So, 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. So, 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?

I think it all goes back to your preparation. So, I talked about breaking down your material, doing this task analysis. Each of those objectives that you've pinpointed can be further expanded. And 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. And so, those 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. 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. And you can do that for any material. But you do need to have everything broken down.

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. There are things that I know that I don't remember learning, because it was a while ago.

For sure, for sure.

And 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. And it's something I need to teach, but I don't know that until somebody asks me the question. So often, the right response is to say, “Oh, I didn't realize I already knew that. Thank you,” and then you can change the course material.

Yeah. That's a really good point. I'll tell a little story. I was teaching Math and I was trying to teach people how to… they were kids. I was teaching them how to graph coordinates on a plane. And I could tell that they were just so confused. They couldn't do the easiest ones, like (1, 1), like where does that go? And 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 axes. They had never seen a number line. They had never seen a coordinate pair written that way, and know that the first one is the x axis and the second one is the y axis, and that the x axis is the horizontal. There's so many things that they didn't know.

And I was confusing them with this apparently simple task, which was just draw a dot in one little spot. And I realized, “Oh, wow. I need to take 10 steps back.” We need to start just drawing number lines and finding one point on that line. 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 meet where another line would be drawn on the y axis. And just, there are so many things.

That's one of the principles of teaching that you really need to keep in mind, is that 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. And 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% of the time. That's a really important unit to be thinking about. And so, if you notice that they're confused, it usually means that they've got way too much to think about.

So, if you can step it back and you can say, you might give someone a task in a workshop, “Hey, let's write some method calls and we'll chain them together,” and you just see that, “Wow, this is too much for them,” you could just get down to basics. Like okay, “Let's just find all the method calls in this code.” Or, “Let's write one method call.” No arguments, right? And then you add arguments. And you start to build up the skills that they need. And 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.

Hearing this approach makes me despair of a bootcamp ever being able to prepare a student for actual development.

How long is a bootcamp like? Three weeks?

12 weeks.

Oh, 12 weeks.

It's funny…

And we've all seen the graph of things you have to learn to be proficient at Rails. It's this huge spider web graph. And if you're teaching fundamentals like that, like going over and making sure people really understand what a method call looks like and how to write one, I don't see how you could ever complete that in 12 weeks.

I'm going to push this button. How long should it be? How long legitimately do you think it would take?

To do a bootcamp? To teach someone?

Yeah, to do a Rails bootcamp and have somebody come out of there to the level of effectiveness that you think they need to have.

It depends. Are you talking about an apprentice level? Like able to pair with someone?

You used the word competent beginner before. I think that's appropriate.

So, 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, right? You have to understand this client/server thing. You have to know HTML. These are not easy.

What do you think, Coraline? You brought it up, you know, that 12 weeks isn't long enough.

I think that we're misleading people with bootcamps, honestly, in telling them that they can get really great paying jobs right out of the bootcamp and that they're going to be… I think we're lying to them, honestly, in a lot of ways. I don't think that we're generating a lot of competent beginners. I think for certain people who have a certain baseline of experience already and knowledge and are just looking for a formal way to wrap some of that up, bootcamps can be great. But I think 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's ahead of them.

Well, having…

We probably made a whole bunch of people angry.

I tend to agree. And 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 who will after school, so to speak, they go home and they go learn more stuff. They go out and they meet people in the community and they do the extra work. 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.

Yeah.

Yeah, I mean having actually gone through a bootcamp myself, I have to agree with you all. So, when I did the bootcamp, I'd already quit my job and spent three months in my apartment, 12 to 16 hours a day learning to code on my own. So for me, I had that three months. And 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. And even then afterwards, there was still more to learn. So, I think that the good thing is I think that more people who do bootcamps now are not coming at it sitting down for the first time, knowing what Ruby is and they have done a lot of research and 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 is, that's just ridiculous.

I want to throw two more ideas on here. One is I was really hoping you were chiming in to disagree with us, Saron [chuckles].

The other thing is that I do feel like one thing that the bootcamps do give to people is they give them confidence. So, 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.”

It's like The Wizard of Oz? When he gives the Tin Man a diploma.

Yeah.

You do have a brain. [Chuckles]

Yeah.

I don't know. I've seen the opposite of that. I have a channel on IRC called NewToRuby and I see a lot of people who are coming out of bootcamps or coming out of a self-learning phase and then their first job is dealing with legacy code, which is something they have not been prepared for whatsoever. So, I think all their confidence goes away in the face of a legacy application.

Mm.

I think the other part of that though is that I don't think that the industry is really ready for bootcamp grads. In order to be successful myself, I did a hacker-in-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. And then I did the apprenticeship at thoughtbot which was an amazing experience where again, I was taught best practices and really given a nurturing environment.

And I think that after you graduate bootcamp, 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 you need, I think that's just fine. I think 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. And I think 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.

I think that is an excellent point. And that's exactly where I was going. Without that industry-wide support for new people, we're doing lots of people a disservice and costing them a lot of money.

I just want to say I agree with everything I've heard. But I just want to put in the perspective that I remember watching lots of fresh outs from four-year programs, four-year 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 bootcamps with. Don't know how the hell that happened, but it did. And in terms of, even if a bootcamp is a total loss, which I doubt that any of them are a total loss, but even if it is, it seems like a whole lot less of a loss of time and money than some of these four-year programs.

One thing that I think the bootcamps 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. And so, 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. And I think that those things, if we could find them and laser target them, we could do a lot.

I really want to ask this, because… and I want to couch it in terms of teaching because I think that's really what we're talking about here. So, after the bootcamp when they're not quite ready maybe 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? So, is it maybe another after-bootcamp bootcamp?

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 sweatshop, but like an apprentice does all the dirty work, right? They carry the wood for the master and they chop it and they carry the water, that kind of thing. And so, maybe there's stuff like that, like you put your apprentices on updating the readme and monitoring servers and stuff like that. And after a year, they've picked up a little bit of skill here and there just from being surrounded by it. And they see how the day-to-day work actually goes.

Ooh, ooh, ooh. I have a suggestion.

Okay.

[Chuckles] So, you mentioned that there are questions that can take forever to figure out online because you don't even know what to google, but can be answered in 10 minutes. One way to do those is if you have a mentor. If you have just someone you can call, 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, Mario Aquino has started a program. He calls it Lambda Mentors, where he's getting companies to sponsor. And that pays for the time of experienced programmers to help younger programmers. And the money actually goes to charity. It doesn't go to the experienced programmers. But the idea being, if you just have an hour or two a week with someone much more experienced, you can ask those questions. And then maybe…

That's really cool.

Yeah. Cool. Maybe you work on open source projects. But you have someone who can get you unstuck.

I have two people that I mentor on a weekly basis and I like the idea of mentoring quite a bit. But the way I've seen some bootcamps handle mentoring is office hours. And there's no guarantee you're going to get the same person two weeks in a row. I think really mentorship is a personal relationship and if you don't have that personal relationship you're not going to feel comfortable asking those “stupid questions”.

Yeah, for sure. There's actually a study about mentoring that showed 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 and they actually become friends, the mentor and the mentee. And 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.

It seems like what we're talking about with the bootcamps 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?

Maybe. We're young as an industry. We really don't know. If you looked at for instance Calculus, if you tried 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?” And now, you can take a Calculus class and there's a book that has, it's a really thick book with everything broken down, with all the theorems explained, like a chapter on each theorem with lots of exercises for practice. And that's just one of the textbooks. There are a lot of different books on that. And so, 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. And I think that that will happen in Computer Science programming and Software Engineering where you're actually building the practical stuff.

I do think that there is that tendency to think short-term where most software companies are like, a year old. [Chuckles] They just got some startup funding and they just need to get an MVP out there. They don't care about practices and all that stuff blows up in their face when they start scaling and they start having to think about that. And then they have to hire real engineers to come in and figure this stuff out. And so, 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 and they appear. But we don't know how to build that person.

I want to hit mentorship here for a second. I want to just hark back to that real quick and just talk about it. A, how do you find the right people to mentor? 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. And then the other thing is how do you open yourself up so that people can find you if you're willing to mentor people?

Yeah, that's a really good question. So, I teach on my blog. My main technique, my main secret is to go on a forum like Stack Overflow and find a question and answer it on my blog. In IRC, if someone had a question, I'll just write it on my blog and then find the person again and show it to them. And by focusing on real questions in the same language that they asked, I think that that builds trust. 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. But the people who like your style will find you. So, blogging, answering questions that people post in public forums. I think that's the answer.

I'd like to circle back around a bit to something you talked about earlier, because 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. And this is going to be one of those annoying questions where I make an assertion and I'm curious to get your observations on it.

Sure.

Like okay, so here's an example of that, that I've seen. Like, there's a series of books O'Reilly has, the Head First Series. And I've been aware of them for years, and…

Great series, by the way.

Yeah. So, as a programmer, so if you're not familiar with the series, they have these covers that are like, they're always a photo of some really perky looking person who's looking up at the camera ready to learn and stuff. And I used to look at them and write them off in my head as really cutesy and fluffy and not serious programming learning material.

And recently I had reason to look through on 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.” And it's not a style that you see in a lot of programming books. And I found out more recently that one of their rules for these books is to make the reader feel smart on every page. And I think that's one of the things that my snooty programmer brain interpreted as, “Oh, this is cutesy and fluffy.” So, 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.

And I feel like we've got this, in the programmer community, and particularly in the Unixworshipping Ruby community, Ruby, Perl, et cetera, community, we've got this mono-maniacal focus on text as the one true mediating format for all information. 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. And it's all text, text, text, text, text. And therefore, books full of pictures and things are bad. 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?

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. The depth…

Okay, so I have the first book with is 'Head First Java'. And the first chapter is like, what is Java and that kind of thing. It seems very, very light. But it's like a 500-page book. You flip to the middle and they're talking about deep stuff that I don't know if I ever learned in school. Like you actually trace through a garbage collection heap and you have to figure out what's going to be collected and what's not. This is not something that's taught in most Java books. Maybe they mention it. “Oh, it has garbage collection,” and then they talk about, like you're saying, text. They just explain, “Oh, it's a generational garbage collector and it's safe,” or whatever. But this is actually tracing through the execution of this garbage collector. And 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 are actual lines on the page to write in the book. There are pictures. There are little cartoons. There are visual metaphors.

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 this thing that happens where we're able to explain stuff technically so that it's correct. We're very precise with our words. We phrase it in a certain way. 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.

Yeah, we're not conveying what we want to say. We're just saying it.

Exactly.

We're teaching people who are exactly like us and not [inaudible].

Yes, who already know it. We're only…

We can formalize.

Exactly. And someone who already knows it will come and read it and say, “Yes, you're right. That's a good explanation.” But no one who doesn't know it can make any sense of it. And that is, it's a huge failing, that we value this idea of being able to be totally precise with our language. And rightly so, like 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.

There's an explanation in 'Head First Java' of pointers. And it's done with cartoons. And 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 other things can point to the same object but be a different variable, and 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.

Right.

We're too busy talking to ourselves and we wonder why we have mono cultures.

Exactly. Kathy Sierra had a thing. She still talks about it in her talks, about how most… well, I think it's kind of judgmental to say this, but that if you focus on the way the book is started, meaning when the person, when the author had the idea for the book, and the books that really succeed, that actually do better, are focused on the reader. They're focused on, “I want the reader to learn X, Y, Z.” And so, you have to read these paragraphs of obtuse text and say, “Oh, I have to redo this. This is not going to help the reader.” And it's a shame. It's a shame that we start our journey writing a book with this idea of becoming famous for this topic.

Yeah. I have a follow-on to that, which is, and 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, but it's a problem for us doing our jobs, because I really feel like fundamentally, what we're doing, our job is basically just to learn and to teach. We're here to synthesize. We are here to come in and understand the domain, understand a little closed universe that is somebody's problem. And we have to then convey that to the computer. 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. And it's basically what we're doing all day.

And it seems like…

And that's why, Avdi you're totally right.

Yeah.

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, right? 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.

Yeah.

We understand that. We do that every day. So, I think that we can dominate teaching if we wanted to. But we need to do that. We need to work on the skills.

Mmhmm.

Yes. Totally agree that in some ways, you can look at programming as exactly teaching, teaching [inaudible] 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.

For sure. It's all modeling. It's all about ideas. The last thing, it's one of the problems with modern programming languages, is that it's so much typing for… you have an idea that you develop with someone for a couple of hours and then you try to type it and it's going to take you two weeks to type it all in. And 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.

I think that's a great place to wrap this up. I completely agree. Alright, should we do some picks?

Sure.

Alright. Before we get to picks, I want to take some time to thank our silver sponsors.

Avdi, do you want to start us with picks?

Sure. I got a few things saved up. I'll try to be quick. 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. 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. And I don't really have one reason that I switched to it. It was two dozen different things that they just did better. So, Inoreader is cool.

Windows 10. It's what Windows 8.1 was trying to be. I just upgraded today.

And it's, as a Windows goes, it's pretty darn good.

I just got back from helping out at one of Sandi Metz's practical object-oriented design workshops. And I am biased because number one, I really like Sandi. And number two, when I get to help out with them, I make money off of this. But 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. She does stuff that I stand back and think, “Wait, you can tell adults to do that?” And then I realize that techniques that work on kids work on adults, too. And they just fixed something in their memory which I would never have in a million years figured out how to completely fix in their memory. So, it's just, if you ever have the opportunity to take one of her courses, I highly recommend it. They're super cool.

And 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. So, I think that's it for me.

Alright. Coraline, what are your picks?

My first pick, not at all technical, but really interesting. It's an article in the New Statesman called 'Sex isn't chromosomes: the story of a century of misconceptions about X & Y'. So, we're all familiar with the model of XX and XY chromosomes. But 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 life. And the approach to chromosomes, breaking things down to a binary, has been responsible for encouraging reductive, essentialist thinking about sex. And the scientific world apparently has moved past this concept but the popular appeal remains.

The Search for Male and Female in the Human Genome'. 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 [inaudible] years. It's a comprehensive demolition of the very term 'sex chromosomes', a taxonomy that's about a century old and due for revision. So, it was a really interesting read, obviously a subject close to my heart as it deals with sex and gender. But very interesting also from the perspective of what happens when a concept in science is popularized and its popularity outlives its usefulness.

My second pick is a book by Octavia Butler who I've been reading a lot of lately called 'Parable of the Sower'. It's set in a future where government is all but collapsed. It centers on a young woman named Lauren who possesses hyper-empathy, the ability to feel and perceive pain and sensations of others. In the book, civil society has been reverted to anarchy due to scarcity and poverty. And the main character develops a philosophical and religious system during her childhood and the remnants of the gated community in Los Angeles. 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. The novel won the 1994 Nebula Award for Best Novel. It's a beautiful and moving post-apocalyptic novel with a really interesting philosophical twist. So, 'Parable of the Sower' by Octavia Butler. And I'll post a link to the Amazon page on that on the show notes.

Alright. Jessica, what are your picks?

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. But 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. 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.

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 when other people talk to me about philosophy. Now I have some context and can speak intelligently about it. And you could pick it up anywhere. The episodes are pretty independent and it's pretty entertaining. Those are my picks.

Alright. I've got a couple of picks. So, last Friday I was given the opportunity to talk to this Together Tech. It's actually a bootcamp in Cape Town, South Africa. And they bring in underprivileged people and teach them to code. It's a nine-month bootcamp.

Awesome.

And they go out of their way to actually find people who don't have a lot of, or any computer background. And 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. And so, it's really, really cool. And yeah, I just got to talk to them for an hour and it was amazing. So, 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. And this all came off of the Daniel Kehoe episode and the Rails Composer Kickstarter. He backed it and then he asked if I would come and talk to them. He backed it and got some RailsClips months.

So 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. But 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. And just thinking about, “Okay, if nothing changes, if nothing advances, within the next five years, where do I want to be? And then what are the principles behind that and how do I actually enact the parts of this that are critical to that?” And then I can continue to assess and evaluate as time goes on.

But I found that a lot of times, we go onto auto-pilot for a lot of things. And we just expect that we'll pick up what we need to pick up and that things will just work out because they worked out for our parents or worked out for other people that we know. And I find that in a lot of cases, I really have to pay attention to where I want to wind up. And then I have to work toward that and be very intentional about moving toward it. So anyway, I'll get off the soapbox because this is already a long show. But that's one thing that I've really been thinking about.

The next pick is Highrise. Highrise was written by 37Signals. They sold it off. Anyway, it's a pretty awesome CRM. And so, I've been using it and I'm really liking it. So, I'll go ahead and pick that. Just keep in mind, it is no longer owned by Basecamp. Somebody else is running it. But it works great for me.

And then the last pick I have is a podcast episode. The Eventual Millionaire podcast by Jaime 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, is the idea behind it. But she interviewed a guy named Rory Vaden about three weeks ago. And it was awesome. And he really had some things, if you're in business for yourself or you find yourself doing a lot of different 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. So anyway, it blew my mind. [Chuckles] So, I'm going to pick that episode.

Eric, do you have some picks for us?

Yes, I do. My first pick is a podcast as well. It's called Ruby Rogues. And I…

Never heard of it.

I know, it's kind of obscure. You guys wouldn't have heard of it. But 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. So, thank you for that.

My second pick is, it's a YouTube channel that someone has been posting all these old Alan Kay talks. 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. And the other thing about Alan Kay is you have to listen to the same ideas over and over because they're so deep. 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. So, it's nice that there's now a channel that you can just put on auto-play and listen to all of that.

My next pick, a book called 'Mindstorms'. '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. And 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. And by playing with that model, debugging it, you're actually thinking about thinking. So, 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.

Awesome. Alright. Well, let's go ahead and wrap up the show. Thank you for coming, Eric.

Thank you so much. It was a big pleasure.

It was so fascinating to talk about, too. But yeah. We'll wrap up the show and we'll catch everyone next week.