A couple of issues with this approach:
- Make sure your material is good. Bugs in the material led to me repeating myself 1:1 a lot, and having to pause the class occasionally. Which leads to:
- Pausing the class is hard! People are at different stages of the material, so it's hard to find a good stopping point, though I did it a few times when something was either not resonating, or folks were going too fast and I sensed they were copy-pasting rather than fully understanding the point.
- The solution to this is to have 'core' material and then 'extra credit' stuff, but people feel behind if they haven't done all the material; nobody's happy only doing the core. In general, fear of "not keeping up" was a big issue in my class.
- Finally, some folks do learn differently, and you have to account for that. I spent a lot of time 1:1 with a couple particular students who weren't getting the tutorial format. Another felt like class was just "doing homework" and dropped out. I got around this by sending videos in a flipped-classroom approach between classes, but my students didn't have a lot of spare time and I couldn't rely on them doing anything outside class.
He goes into why he started exploring the idea at first (students got 5's on their AP physics exams and had strong problem-solving skills — plug-and-chug — but poor conceptual understanding), the many iterations of the approach, and the data he collected on the way (significant increases in open-ended, conceptual problems, including at other schools that adopted the approach). Really fascinating.
I haven't watched the shorter version, but someone edited they key points down to 18 minutes: https://www.youtube.com/watch?v=rvw68sLlfF8
This isn't to say that the other style of teaching doesn't have its place , but at its core (IMHO) resides in a more imposed tradition of social order, military influence, etc..
I teach a course introducing students to making plain webpages in HTML/CSS/JS. We haven't tried the group aspect yet, instead we have people pair program - one laptop between every two students, with them switching 'drivers' every 10 minutes or so, driver types while the other person narrates what's to be done and points out typos etc.
When a pair reaches the goal for a particular task, I ask to high-five loudly. Not only does this help them get more comfortable with each other (they're complete strangers and only come together for this single day course), but it livens up the room a bit while giving me feedback and without being too threatening to those who are still working.
Obviously this isn't very scalable to a larger group though. I'm depending on the grassroots effect to take hold at some point and for others to spread that knowledge. Its effective, but not as quickly as I'd like. I may have to try some sort of workshop style like this in the future to get us to the point faster.
The bigger kids will learn first from the teacher, and in turn, turn around and teach the younger ones.
At least according to this article, it works. Maybe high school can also benefit from this.
2. I find it intriguing that a professor say this:
> Third, it’s fun for them. They can laugh and joke with each other, rather than sit in silence as I repeat information that’s right in front of them anyway.
Usually the teacher is doing his best to get the class as quiet as possible.
For my programming courses, I give 3 different types of assignments each week: a typing exercise, a Q/A style set of questions, then a problem. No "make a loop print the numbers 1 to 5", but something like "implement standard deviation".
I've talked about the typing exercises before on HN, give the students a picture of code and make them retype it. They can't copy-paste, which is one of the mistakes of beginners, plus it gives them a fully functioning implementation of that week's topic. It doesn't have to be huge, something like 50-100 lines (this is Java, so that isn't as much as it seems). Students have given it a positive response this past semester and I'll be adding it to some other classes as well.
The Q/A questions are traditional multiple choice/true-false/fill in the blank style questions. I won't lie, it's blatantly taken from MIT's Open edX 6.01 course, though tweaked to prevent Googling. The questions range from simple concepts like what is the end result of a conditional statement, to number of loops, to having to implement a small amount of code to determine the next integer in a seeded random. McGonigal discusses how in a game, the risk of failure is reduced by allowing the player infinite tries. If they fail, they don't get slapped with a 0, they are free to try the question set as many times until they get the 100%. You have to be careful, otherwise you'll get the person that just guesses, but overall it is a successful tool.
Finally, the problem sets are again similar to MIT's 6.01 course. This is actually my current pain point, as I need to implement an automatic grader to repeat the infinite tries from above. They are given the problem, along with some test cases of what to expect. This is the first assignment that doesn't have a clear A to B section, which is done purposely to facilitate their problem solving skills. To help, I do the same thing as the author by making my class time lab time. I do like the ideas of paired programming and Post-Its, so I might look to implement them in the future.
The big thing I'd same McGonigal's book suggests is "Make the assignment seem attainable". This helps defeat the stereotype threat. If step 1 each week is literally "retype this program", it gets harder for a student to say "I can't do this".
After that, I go full on into SQL. This was initially motivated by the fact that SQL is a pretty important skill, and it is one of the most succinct ways to describe the concept of computationally joining two datasets to find interesting insights...which is basically the core of journalism (e.g. a list of names of business owners and a list of names of political campaign contributors)...but I've found it's a great way to teach computing in general. For most of these students who have never programmed, SQL is the first time that they've had to tell a computer exactly what they want. For example, I used to think it was a pain to have to specify every column you want to see with a `SELECT` statement...but this is in perfect contrast with how Excel works. The latter by default shows everything, and this has implications with not just computer performance and dataset size limitations, but in data filtering...that is, you're forced to see all the data columns at once, even if it's far too much to consume. With SQL, it's about knowing exactly what you want to see and telling the computer to do it exactly the way you want.
On the teaching side, this makes things far easier for me. I no longer have to teach a GUI, which is a long series of me saying "Click here...unless you're on PC/on version 2011X/have a window size less than 1024px wide" and writing tedious guides of screenshots. With SQL, I just write SQL. And the exercises can be stated in plain English.
For the exams, I basically made them write out a bunch of queries on real-world datasets which I described in plain English...I gave them the expected results, and so they had to write the queries that got the answers. Very easy to grade and very easy to give them help on (they were take home exams):
Baby name data: http://2015.padjo.org/assignments/midterm-babysteps-sql/
Medicare data: http://2015.padjo.org/assignments/midterm-wsj-medicare-walkt...
And to comment on the author's experience with the "stereotype threat", in which students of traditionally minority groups hesitate to speak up because they feel they are being judged by that group, e.g. xkcd #385 http://xkcd.com/385/...this is definitely a phenomenon. Last year I had a nearly all female class and they had no problems at all speaking up/out at me. In elective programming classes with more males, they generally were more reserved.
My experience lies in "quick start" technical training, largely centered on CAD software for engineers. They are generally a tough crowd, and they demonstrate many of the behaviors mentioned in this great piece.
Over time, I also centered in on not having a follow along. It just never works! People are too diverse in their skills and how they process information. Plus, there are the ones who are able to follow me perfectly, but don't seem to catch the concepts at the same time. I see them rushing through bits here and there attempting to get it their way, or at their own pace.
There are a few things I would add to this method:
1. Play foot ball coach. There is this task ahead, and it's the documented one. Show 'em the highlights and talk through "the play", setting expectations and putting them on watch for a few "gotchas" they may experience. Don't do the whole thing. Just the highlights as a mixed mode, lecture for concepts, quick demo to actualize key things they want to know. Leave the easy stuff to their own self-discovery.
2. This one may be a bit controversial, but I've had awesome results with it.
Prepare to leave the room. You will actually leave for a few minutes too. Setup a simple problem for them to solve, and lecture through the bits they need to solve it. Provide documentation on those same bits.
Just prior to leaving, tell them why and that you will be right back in 10 minutes or so.
The reason you are leaving is to get them to question. In fact, the more they question, the better it will be when you return! Instruct them to write their questions down, or queue them however they want to, and to talk among themselves, and finally, that you will demonstrate one or more solutions to the little problem they are about to attempt.
If they attempt it and have success, that's great. If they attempt it and fail, those questions are exactly the ones they need answers to, and the best way to get at them is to actualize the struggle well enough for them to pose them meaningfully.
Then just leave. It doesn't have to be long, nor should it.
Be sure and return while they are still supposed to be working. You can hand out a little help individually, and or share experiences with some of the students who did see success and are choosing to do the same.
When the time is up, it's up.
Direct their attention to your part of the room, and walk through the solutions. This will generally be an interactive experience, filled with their comments, questions, comparisons and contrasts of solution methods, etc...
Then grant them a little more time to take one of those solutions and solve with it. The ones who didn't have success will likely get some, and those that did will explore a different solution.
3. Take time to lecture on some of the best practices, and the why and how behind how things are. These can be very informative and helpful sessions. Often, there are ways to think, and there are the ways the software or system creators think. Understanding both of those can really help with intuitive discovery and solution finding.
In these, the basic ideas behind whatever it is get put into context, case studies, work experience stories, whatever makes sense.
4. Free time allowance.
Each day, make sure there is some unstructured time. People often want to explore something they discovered in class, or they just didn't have success with one or more of the lessons and concepts.
This allowance of time is for closure that day. They can get some remedial help to get past a problem area, or they can free style and apply what they learned, etc...
If appropriate, allocate a larger block of this time near the end of the course and encourage them to bring problems to class. Everyone collaborates, shares and builds, or writes, or whatever it is with you facilitating productive activity.
I have found these things to be extremely helpful and productive in adult learning scenarios of various kinds.