Best practices for teaching and learning
Jan. 18th, 2012 08:47 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
terrikoI'm taking an online course on How to teach webcraft and programming to free-range students taught by Greg Wilson, who some of you may know. If you don't know him, you might want to listen to this talk he gave at CUSEC several years ago. Anyone who's ever thought about the world critically will probably get something out of that talk, though it was geared undergraduate software developers.
Our first assignment is to look at these recommendations about best practices to improve student learning and Greg's post about which of these he's managed to apply, then write about how we have or haven't managed to incorporate these ideas into our teaching.
Due to a hand injury, I had to completely change the way in which I learned as a teenager. First my friends took notes on carbon paper for me, but later I transitioned to using a laptop. This was an unusual sight at the time, and drew suspicious glares from many teachers.
If you'd tested me then, you'd have found that those teachers' instincts were right: I was having trouble absorbing material with the computer in front of me. But it wasn't because I was goofing off (constant hand pain and risk of permanent damage made that nigh impossible anyhow) it was because I'd been taught to type like a secretary: if you don't think about the letters in front of you, you can type much faster. I had to concentrate differently and retrain myself to absorb material while typing rather than relying on the physical motion of my pencil to help me commit things to memory. A year later, you could have tested me and found that the computer was just as mighty as the pencil.
The reason these recommendations make me think of this story is that they're all clearly geared towards students sitting in a traditional setting with desks and books and rules. They've studied that situation well. But that doesn't mean that these are going to be all the best practices when teaching "free-range" learners, just like it turned out that the pencil was not the best tool for me even though note-taking had worked so well for so many before. With that in mind, I'm going to talk about these recommendations both from my experience teaching in the classroom (at the university) and separately in my experience mentoring folk outside the classroom. I'm using as my example my experience mentoring summer of code students, but trying to draw on other less structured experiences I've had teaching as well.
So here's the recommendations, with my thoughts on what I've managed to use and not use.
1. Space learning over time.
In the classroom, yes. As a mentor, maybe not as much -- my mentees pretty much learn and do, learn and do, and don't tend to come back to the same subjects much that I notice.
I suspect I could force this by arranging tasks so that some of the later tasks use earlier skills. If this were presented as a "You did such a great job with X, can you set up Y for me?" it might be feasible without being obnoxious (I always hated being forced to repeat the same sorts of tasks; that's why I like computers where I can automate repetition.) I'm not sure I'm clever enough to arrange things to X and Y need doing at the right times, but it's worth keeping an eye out for opportunities.
2. Interleave worked example solutions with problem-solving exercises.
Classroom, yes. We'd often give students partially complete code and let them finish it, sometimes by looking at how other pieces worked to solve the problem. As a mentor, sometimes. Sometimes I can point out "here's somewhere that this worked" to go with "can you solve this problem?" but I suspect I could do this more. With GSoC students, we mostly seem to throw them in the deep end code-wise so they're finding their own worked examples within our code base. Finding and pulling out *good* examples might be easier for the mentor team and could help the students along.
3. Combine graphics with verbal descriptions.
Classroom, yes. I can't explain recursion or many other things without drawings (which made it extra frustrating that sometimes computer labs have no functioning pens for the whiteboards/chalk for chalkboards... I learned to carry my own set.) As a mentor, pretty close to never. We could probably do some of this with more teleconference meetings, but the time zone spread tends to be incredibly problematic once we've got a couple mentors and a couple mentees. Perhaps worth thinking about one-on-ones or preparing videos? Sadly, videos are really really not my expertise.
4. Connect and integrate abstract and concrete representations of concepts.
I try, but sometimes this is the hardest material to get through in any form, since all my students are focused on the concrete task at hand. I was surprised to find that it's actually my game development students who were most interested in the abstract, since they felt understanding the higher level stuff would help them make their games faster and better. Many of the best learners I've ever encountered were in the gamedev program at my former university, and I find the correlation interesting.
5a. Use pre-questions to introduce a new topic.
I personally rarely did this in the classroom -- the tutorials were the part where the students were supposed to dive right in, and I have no idea if they got pre-questions during their classroom sessions. I have on occasion used it with mentees, though, just to get an idea of their background so I don't over or under-explain.
5b. Use quizzes to re-expose students to key content.
My classroom students obviously got this (although not directly from me). I never give quizzes to my mentees, and it would feel awkward and forced to me if I did. However, we *do* ask them to write up periodic summaries of what they've done so that we can have an idea what they're up to, so they at least do some revision themselves as they prepare those blog posts/emails.
6a. Teach students how to use delayed judgments of learning to identify content that needs further study.
With my classroom experiences, I'm wondering if someone isn't teaching them something quite different: my students sometimes get seriously distressed when presented with content that they haven't been taught. One of the early lessons of the first-year tutorials involves giving them larger codebases they can't yet understand and asking them to solve a smaller problem within this incomprehensible code. We meant it as a lesson in how they're likely to have to jump into other people's codebases while out in the work world, so we teach them how to ignore those parts, and where to look if they want to learn more. (I am always shocked that many of my classroom students won't use google to search for stuff in tutorial until I explicitly tell them it's ok. I don't have all the Java/C#/whatever classes memorized either, kids!)
I've never explicitly tried to teach this to my mentees outside the classroom, though, possibly 'cause I tend to get students who are very self-reliant already?
6b. Use tests and quizzes to identify content that needs to be learned.
This happens in the classroom, but there aren't tests when I'm mentoring. I do think some of the students use their weekly reports as a time to re-evaluate what they're doing, though, so that's something.
7. Ask deep explanatory questions.
I got to do this occasionally in the classroom setting, but more often it was the students who were asking me the deep explanatory "why doesn't this work?" -- when I didn't know the answer, I'd use it as an excuse to get some of the other students involved (later on in the course after I'd taught them that helping others was just as good a way to get a mark as studiously doing their own code). Sometimes we made the most hilarious theories, but sometimes we touched into how the language was created and the expectations of the underlying systems. I'll have to think about how to do this a bit more intentionally, though.
Conclusions?
So, lots of these things work and are common practice in my classroom experience, but not so many as far as mentoring goes. I think a few of them could apply more if I was looking for/creating opportunities for discussion and revision, but the past couple of years I haven't kept close enough tabs on my summer of code students' work to be effective at leading them down those paths. Definitely food for thought! But i feel like some of it, like quizzes, would feel incredibly forced outside of the classroom environment. Plus, repeating stuff just isn't that much fun... but maybe it could be?
Ages ago, a friend was telling me about a role-playing game she was in where she had to level up her Jedi (or maybe it was Sith?) by doing things like making web pages or doing photo editing and taking quizzes on the software she learned. I thought it was interesting that this group of people was clearly trying to help train their members outside of the game while they were training their characters in it, a gamification of life long before I'd ever heard that term (or, perhaps, before the term had been invented, though I do so love the assertion that Weight Watchers with its points is one of the most well-known examples of gamification of life). Anyhow, her game included little photoshop and story writing contests and such that seemed to keep her engaged and interested in her game "assignments" -- I wonder if there would be ways to bring some of that to free-range programmers? We have contests, but not at learner levels. We sort of have ranks as open source developers sometimes (bugs solved, commit access, invited to maintain $foo), but they're often not explicitly defined so it's hard to use them as motivation.
This might be interesting, but I can't shake the feeling that trying to force things like quizzes to work for free-range learners might be like clinging to the pencil as a way of learning.
Our first assignment is to look at these recommendations about best practices to improve student learning and Greg's post about which of these he's managed to apply, then write about how we have or haven't managed to incorporate these ideas into our teaching.
But first, a story...
Due to a hand injury, I had to completely change the way in which I learned as a teenager. First my friends took notes on carbon paper for me, but later I transitioned to using a laptop. This was an unusual sight at the time, and drew suspicious glares from many teachers.
If you'd tested me then, you'd have found that those teachers' instincts were right: I was having trouble absorbing material with the computer in front of me. But it wasn't because I was goofing off (constant hand pain and risk of permanent damage made that nigh impossible anyhow) it was because I'd been taught to type like a secretary: if you don't think about the letters in front of you, you can type much faster. I had to concentrate differently and retrain myself to absorb material while typing rather than relying on the physical motion of my pencil to help me commit things to memory. A year later, you could have tested me and found that the computer was just as mighty as the pencil.
What did that have to do with anything?
The reason these recommendations make me think of this story is that they're all clearly geared towards students sitting in a traditional setting with desks and books and rules. They've studied that situation well. But that doesn't mean that these are going to be all the best practices when teaching "free-range" learners, just like it turned out that the pencil was not the best tool for me even though note-taking had worked so well for so many before. With that in mind, I'm going to talk about these recommendations both from my experience teaching in the classroom (at the university) and separately in my experience mentoring folk outside the classroom. I'm using as my example my experience mentoring summer of code students, but trying to draw on other less structured experiences I've had teaching as well.
The recommendations...
So here's the recommendations, with my thoughts on what I've managed to use and not use.
1. Space learning over time.
In the classroom, yes. As a mentor, maybe not as much -- my mentees pretty much learn and do, learn and do, and don't tend to come back to the same subjects much that I notice.
I suspect I could force this by arranging tasks so that some of the later tasks use earlier skills. If this were presented as a "You did such a great job with X, can you set up Y for me?" it might be feasible without being obnoxious (I always hated being forced to repeat the same sorts of tasks; that's why I like computers where I can automate repetition.) I'm not sure I'm clever enough to arrange things to X and Y need doing at the right times, but it's worth keeping an eye out for opportunities.
2. Interleave worked example solutions with problem-solving exercises.
Classroom, yes. We'd often give students partially complete code and let them finish it, sometimes by looking at how other pieces worked to solve the problem. As a mentor, sometimes. Sometimes I can point out "here's somewhere that this worked" to go with "can you solve this problem?" but I suspect I could do this more. With GSoC students, we mostly seem to throw them in the deep end code-wise so they're finding their own worked examples within our code base. Finding and pulling out *good* examples might be easier for the mentor team and could help the students along.
3. Combine graphics with verbal descriptions.
Classroom, yes. I can't explain recursion or many other things without drawings (which made it extra frustrating that sometimes computer labs have no functioning pens for the whiteboards/chalk for chalkboards... I learned to carry my own set.) As a mentor, pretty close to never. We could probably do some of this with more teleconference meetings, but the time zone spread tends to be incredibly problematic once we've got a couple mentors and a couple mentees. Perhaps worth thinking about one-on-ones or preparing videos? Sadly, videos are really really not my expertise.
4. Connect and integrate abstract and concrete representations of concepts.
I try, but sometimes this is the hardest material to get through in any form, since all my students are focused on the concrete task at hand. I was surprised to find that it's actually my game development students who were most interested in the abstract, since they felt understanding the higher level stuff would help them make their games faster and better. Many of the best learners I've ever encountered were in the gamedev program at my former university, and I find the correlation interesting.
5a. Use pre-questions to introduce a new topic.
I personally rarely did this in the classroom -- the tutorials were the part where the students were supposed to dive right in, and I have no idea if they got pre-questions during their classroom sessions. I have on occasion used it with mentees, though, just to get an idea of their background so I don't over or under-explain.
5b. Use quizzes to re-expose students to key content.
My classroom students obviously got this (although not directly from me). I never give quizzes to my mentees, and it would feel awkward and forced to me if I did. However, we *do* ask them to write up periodic summaries of what they've done so that we can have an idea what they're up to, so they at least do some revision themselves as they prepare those blog posts/emails.
6a. Teach students how to use delayed judgments of learning to identify content that needs further study.
With my classroom experiences, I'm wondering if someone isn't teaching them something quite different: my students sometimes get seriously distressed when presented with content that they haven't been taught. One of the early lessons of the first-year tutorials involves giving them larger codebases they can't yet understand and asking them to solve a smaller problem within this incomprehensible code. We meant it as a lesson in how they're likely to have to jump into other people's codebases while out in the work world, so we teach them how to ignore those parts, and where to look if they want to learn more. (I am always shocked that many of my classroom students won't use google to search for stuff in tutorial until I explicitly tell them it's ok. I don't have all the Java/C#/whatever classes memorized either, kids!)
I've never explicitly tried to teach this to my mentees outside the classroom, though, possibly 'cause I tend to get students who are very self-reliant already?
6b. Use tests and quizzes to identify content that needs to be learned.
This happens in the classroom, but there aren't tests when I'm mentoring. I do think some of the students use their weekly reports as a time to re-evaluate what they're doing, though, so that's something.
7. Ask deep explanatory questions.
I got to do this occasionally in the classroom setting, but more often it was the students who were asking me the deep explanatory "why doesn't this work?" -- when I didn't know the answer, I'd use it as an excuse to get some of the other students involved (later on in the course after I'd taught them that helping others was just as good a way to get a mark as studiously doing their own code). Sometimes we made the most hilarious theories, but sometimes we touched into how the language was created and the expectations of the underlying systems. I'll have to think about how to do this a bit more intentionally, though.
Conclusions?
So, lots of these things work and are common practice in my classroom experience, but not so many as far as mentoring goes. I think a few of them could apply more if I was looking for/creating opportunities for discussion and revision, but the past couple of years I haven't kept close enough tabs on my summer of code students' work to be effective at leading them down those paths. Definitely food for thought! But i feel like some of it, like quizzes, would feel incredibly forced outside of the classroom environment. Plus, repeating stuff just isn't that much fun... but maybe it could be?
Ages ago, a friend was telling me about a role-playing game she was in where she had to level up her Jedi (or maybe it was Sith?) by doing things like making web pages or doing photo editing and taking quizzes on the software she learned. I thought it was interesting that this group of people was clearly trying to help train their members outside of the game while they were training their characters in it, a gamification of life long before I'd ever heard that term (or, perhaps, before the term had been invented, though I do so love the assertion that Weight Watchers with its points is one of the most well-known examples of gamification of life). Anyhow, her game included little photoshop and story writing contests and such that seemed to keep her engaged and interested in her game "assignments" -- I wonder if there would be ways to bring some of that to free-range programmers? We have contests, but not at learner levels. We sort of have ranks as open source developers sometimes (bugs solved, commit access, invited to maintain $foo), but they're often not explicitly defined so it's hard to use them as motivation.
This might be interesting, but I can't shake the feeling that trying to force things like quizzes to work for free-range learners might be like clinging to the pencil as a way of learning.
There was an old woman who swallowed a ...
Date: January 23rd, 2012 02:59 pm (UTC)import sys from animals import HORSE, FLY class OldWoman: def swallow(self, x): if x == HORSE: sys.exit(-1) else self.swallow(x.find_bigger()) a = OldWoman() a.swallow(FLY)(Deleted and reposted with more complete code.)