 to talk to you today about teaching. This is not an overly technical talk. This is more of a pep rally, actually. I'm Sarah May. I am a software engineer at Pivotal Labs, but this talk is actually about what I do in my spare time. I somehow have found myself doing a lot of teaching, so I figure I must like it, I guess. In San Francisco, I do a lot of workshops for adults. I've started doing workshops for kids, and I've thought a lot about what it is that it takes to make a good teacher. So I'm here today to convert you all into teachers. So why might you want to learn how to teach programming? Well, and the main reason that I decided I wanted to do it is because I realized that most people who teach programming have no idea what they're doing. And it's really important for someone who teaches programming, I think in particular, more than other subjects, to be a practicing programmer, right? Not someone who just knows about programming and maybe did it once ten years ago, but someone who's doing it, you know, more or less full-time. Because the main thing about teaching and the main way that you're effective in teaching is if you're excited about what you're doing. And I'm really lucky to really love what I do. And I really want to convey that to people. Because I think that a lot of times people, you know, they learn about programming via someone who's just giving them lesson plans out of a book, and it just doesn't work very well. And I also think that programming is going to be a much more important skill in the next maybe ten to fifteen years. So I think it's important to start with kids. Programming, you know, ten years ago, or maybe, you know, fifteen years ago, twenty years ago, typing was a different skill than literacy. These days you can't really be literate without knowing how to type. So they're kind of merged. And I think that programming is approaching that category. I think we're getting to the point where the bar is low enough to get started, the languages are sufficiently English-like that, you know, being able to hack away at software is going to become part of basic life skills. So why should you teach in particular? Well, let's get this one out of the way. Everyone knows about that one. Very rewarding. That's why teachers don't get paid anything. But the more important, I think, is that teaching leads to learning for the teacher. Every time I do a talk, I learn something about what it is that I'm talking about. Even if it's something that I thought previously maybe, that I thought I understood pretty well, I always learn something. For the workshops that I do in San Francisco for adults, we teach a really, really basic Rails application. This application is, you know, two models, one association, a couple of scaffolded views. But every time I teach that app to somebody, I learn something about it. The last time I taught it, someone was like, so why did the instance variables that you declare in the controller, why are they available in the views? I thought action view and action controller were separate class trees. And I was like, that's a really good point. I don't know. Let's look it up. Just really basic stuff that people who are beginners will come in and ask you, and you're like, oh, that's a really good point. So teaching for me was very mysterious for a while. I kind of was like, well, I have a CS degree. I don't have any training in education or instructional design, and I really don't understand what it takes to be able to convey information to someone in a way that they find exciting. But what I discovered is it's really not that hard if you kind of apply a lot of the same techniques that you use in your regular development. So I would argue that you actually already have all of the tools you might need. And you already use all the techniques you might need, but you just use them to a different end. Currently use them to make software. So does this look familiar at all? Set goals, form a plan, expect to adapt, short iterations, continuous deployment. Sounds a lot like making software. It's basically the same set of steps you have to do if you're going to be a successful teacher. So the first thing is goals. And this is really important. So this is something that a lot of people don't do when they sit down to teach somebody programming. You need to have a goal that is specific, immediate, measurable, achievable. So basically what that just means is you need something that expresses like, here's exactly why I am doing this. So here's an example of a bad goal. Whether you could argue whether or not this is achievable. It's certainly not measurable in the short term. It's not immediate. This is not going to work. This is similarly not a good goal to have. It's vague. It's like, what does interested mean? What am I, you know? So here's an example of whenever you argue is a better goal. You have something that you can look and be like, okay, is she going to do this or not? Let's find out. There's another one works pretty well. Here's one that I've heard a lot. Most of this time, most of this comes from people who have much younger kids. But so here's where we're running into differences between teaching kids and teaching adults, right? So a lot of stuff I've talked about so far, and a lot of stuff in the rest of presentation applies equally well, whether you're teaching adults or kids, but when you're teaching kids, you really have to have a different set of goals in general. Your goal has to be, I want this kid to like get super excited about what software can do so that when they get the intellectual capacity to understand some of the more concrete and maybe difficult issues in programming, they'll have this overriding excitement that will sort of ease that any difficulties that they run into. So and another one that might be useful is if you're working with a group of kids, which is, you know, a lot of people end up doing like computer classes after school or whatever. Like a good goal for that is like I want them to leave excited about what they can build and with sufficient tool support to keep exploring on their own. Very important. So now that you've got goals, basically you just have to come up with a plan, like a lesson plan. I gave a talk with this title at RubyConf in November and I actually spent most of my time focusing on here's a lesson plan I came up with specifically using Ruby and shoes for high schoolers. And between then and now I realized that that's the easy part of teaching that coming up with something, you know, coming up with a set of steps to go through and a plan and some code and, you know, breaking it up into little pieces. That's kind of the easy part. There's a lot of resources on the web. So, you know, there's a lot of like, see, so there are some tools that are useful. Shoes, hackety hack. I've been working on something called small Ruby, which is a logo implementation. And I just realized that now that I've mentioned it in public, I should probably put it on GitHub. But the idea is, you know, keep your goals in mind, right, everything you do has to be driven by what your goals are. And there's a lot of tools that you can use with Ruby. So if you look at the tools that I've mentioned, they're pretty much all visual. They pretty much all are interactive. And I've worked with kids of different ages and different genders and this seems to be pretty much true across the board that if they see something that is visual that they can write code and like a window pops up, that is super exciting. And, you know, if it asks them a question, and they can type in an answer, also super exciting. So in summary, IRB compelling for adults, maybe. So the plan that you come up with, I'll just give you a couple of pointers. So install all of the tools that you might use on all of the computers that the kids have access to, right? You want to make it easy for them to explore on their own. You want to start small, you want to start with something that's pretty straightforward. And there's a lot of resources online for programming lesson plans. I think there are much fewer resources that talk about, you know, how you actually teach, which is why I did this talk. So in terms of what you actually want to do when you're teaching, short iterations are very, very important. And what this means is that you want to have little steps of maybe 15 minutes or less each, that each have some kind of visual change to the program that you're writing. And the other really important thing when you're doing this is listen to your customer, your students, your student. And specifically what I'm talking about is you come up with a plan and then don't be afraid to change it, right? So when I was doing this thing with shoes with high schoolers, I had one step early on that was like, okay, we're going to change the background color of the window by adding an attribute to the window. And I was like, okay, and then we'll move on and we'll do something else. But they were super excited about changing the color. And I was like, okay, all right, so let's look for other colors that we can do. And then so shoes has this list of named colors, right? Like, you know, and they have some weird ones like tomato and, you know, clam bisque and weird stuff like that. So we went around and we, you know, we went, we went through them and we tried colors that we could come up with until we found one that didn't exist. Which was, I think they came up with periwinkle did not exist. And so we actually then spent 20 minutes talking about RGB and how colors are composed and how you can make a custom color. And then they experimented until they found an RGB combination that was similar to periwinkle. And then we made a method called periwinkle that have those RGB values in it. And all this was something that I had not planned. But it was the kids loved it. It was really exciting. And I think it's important to just be aware of like, okay, I've got this plan, but I need to get feedback from my students as I'm going along. And we need to, you know, not be afraid to follow what they're interested in. So don't stick to a plan because it's the plan. A lot of the worst teachers in the world do this, right? They've got a plan. They've got an outline. They're going to hit all those points. And they're going to go through them one by one. Don't worry about finishing is the next thing. Like get as far as you can get in the time that you have. Your goal is not to leave them with a finished product, but leave them with enough tools and interests to keep going. And look for the moments that are what they, you know, someone who's a teacher told me, they call them teachable moments, where, you know, you're looking at something and you're like, oh, so then a good example of this is when we're doing the RGB stuff. I'm like, oh, I wasn't planning to talk about how colors are composed when you're programming on a screen in the pixels and the different types of ways that you can compose a color. But, you know, that was interesting. It was good to talk about. And finally, look for signs that they've turned off, right? This is, I think as programmers in general, programmers have the reputation of being a little bit socially clueless and maybe missing social cues. On the other hand, I gave a talk at the Southern California Linux Expo yesterday and I was reminded that Ruby developers on the whole are very socially capable among technical groups, in general. And I'll just leave it at that. But, and that's part of the reason why I think that people who are Ruby developers may be actually predisposed to being good teachers, right? They, people who are Ruby developers tend to have maybe well-developed social skills relative to other engineers. And Sarah, I was telling me in the car on the way over that one of her friends says that Ruby is the programming language for extroverts. I thought, hmm, maybe extroverts among programmers, but yeah. So watch for those social cues. So when I talk about continuous deployment, basically what I mean here is that getting good at teaching takes practice, right? The first time you try it with someone, things aren't going to work, things are going to be clunky. But it's a skill, it's a skill you can learn, right? And just like programming, the first time you try it, there's going to be rough edges, there's going to be things that don't work. So take all the opportunities you can to teach somebody something. And there's a lot of opportunities to do this that you might not consider teaching, but which actually I think are. So there's the basics, there's like, you know, talks to the meetup, pair programming, actually I think one of the reasons it works really well is because you are continuously teaching and learning simultaneously, which makes it a very powerful experience for both people in the pair. There's always summer camps and so on that need volunteers to teach programming and they're usually very, very grateful if you offer to do so. There's a project I've been working on called National Lab Day, which matches teachers up with scientists who want to help in their classroom. You can check that out. And if you're in San Francisco, I always need teachers for the introductory Rails workshops that I teach and they are, as I said, a very straightforward and easy curriculum to follow. And basically I think the most important thing to think about when you're considering teaching is expect sometimes it's not going to work, right? There's going to be kids you can't reach, there's going to be the lesson plans that you try that just totally missed the mark. But it's important to just keep doing it and the more you do it, the better you get at it. It's kind of a virtuous cycle the same way programming is. So let me sum up. You should teach. You can teach. And Agile is for more than just development, right? There's a lot of ways to apply Agile principles to other things. And I think teaching is one of those things that possibly needs it more than other areas. And finally, practice a lot. Any questions? So the question was teaching shoes versus teaching rails. I think it's important to pick something that is achievable in the time frame that you have. For a high schooler, I was teaching high schoolers when I was doing this and I only had half a day. And if we only have three hours together, if we're lucky, then I'm not going to have enough time to really go through all of the files that Rails generates and talk about the complexity of MPC and a Rails app and deployment. And I think I could do it in a day, actually, but I don't think I can do it in half a day. So I know Sarah Allen is working on a curriculum for middle schoolers using Sinatra, which is one option because making a web app actually really is compelling if you talk to kids and you explain what a web app is because usually they're not really aware that like Facebook is a web app and Twitter is a web app. Yeah. And then they're like, oh, yeah, I want to do one of those. So that's usually, you know, web apps are very compelling. I think that they add a lot of overhead and complexity in terms of just the deployment and setup that, you know, some older kids may be able to handle younger kids, maybe not so much. There are, for younger kids, actually I like shoes or hackety-hack. Hackety-hack has actually seen some activity in the last month or so after being somewhat moribund for a while, which is kind of exciting. That was one of Why's projects along with shoes. So, and I think that, you know, Ruby, I think is a great first language for anybody, right? Kids, adults, doesn't matter. I think it's a great first programming language. It's just close enough to English that it's not that hard to, you know, it doesn't have a lot of the overhead of something like Java or even PHP, any sort of C-descendant language, right? So, yeah, there's quite a few tools out there and it depends on the length of time you have to spend with the kids, how old they are, maybe your own expertise, because I think it's very important to be excited about what you're teaching. So, if something is like, you know, it doesn't matter how wonderful, visual basic is for kids, I would have a hard time teaching it to somebody. So, you know, pick something that you're excited about and that'll translate.