Learning to Think
The average undergrad course is an info-dump; you take in the material, learn the facts and the figures by rote and then unleash your mental fury in the final. This gets tedious because, in this information age, knowledge is freely accessible. The information that I can absorb during a lecture, I can get online in far less time. The university as the ultimate source of knowledge is an outdated concept; while the discovery of new knowledge is still very much its domain, the acquisition and sharing of discovered knowledge is a sphere which is dominated by the Internet. Granted, the university is a powerful player in the field of Internet learning, for example a professor can leverage his association with an institution in order to lend credibility to his work. But whether you learnt it at uni or you learnt it on Stackoverflow, the fact is that you know it; and where that knowledge came from makes no difference as long as it’s whole and correct.
In light of all this, my favourite course so far has been Operating Systems Architecture (COMP3301 for those UQ guys out there). This course was not like any other I’ve taken; it was not a barrage of information, it was an exercise in common sense. In this subject I didn’t learn what to think, I learnt how to think. Specifically, I learnt how to think in the context of operating systems. Edifying students in an approach to thinking is the edge which universities have over independent learning. Teaching yourself is not very effective; learning to think requires interactivity.
Interactivity is a very effective learning tool, and through the use of mass communication or distribution it can be very efficient as well .
Even without a technological solution to the interactive learning problem at hand, there are still things that can be done in order to make the traditional classroom more effective, while maintaining an appropriate level of efficiency.
Smaller Class Sizes. A large class is efficient; information can be disseminated to students at a rate which is directly proportional to class size. Unfortunately, a large class hampers interactivity, and a lack of interactivity reduces the effectiveness of learning.
The COMP3301 class was small, about 25-30 students, which allowed for each student to have their say, get involved and not get lost in the crowd. The small class is mostly due to the fact that OS architecture is quite a specialty subject; an introductory English course would probably have over 1000 students enrolled. It’s up to the school to ensure that an effective balance is reached between interactivity and the cost of smaller classes.
It may be expensive to split a big class into smaller ones, but if a VC’s annual salary can exceed $1M, I think there’s some wiggle room.
- Fast-track the Information. Skip the info dump. We don’t need 2 hours of exposition; we can get that online (probably faster). We want to get better at whatever it is we’re learning about, and simply absorbing the content is not an effective way of achieving that. Instead, we need to solve problems, we need to practice and we need to receive feedback as we go.
In my experience, most lectures are 98% exposition; 10 slides a minute for 49 minutes with 1 minute for questions at the end. An ideal lecture would have, say, 15 minutes of exposition where the topic is introduces and key concepts explained, followed by 45 minutes of discussion, where the class is made to arrive at the solution themselves.
A typical OS architecture lesson went like this:
Lecturer: This is X. It’s an important concept is OS architecture because blah blah blah…. A common problem with X is A. How do you think we could solve A?
Student 1: Well, we’ve seen a solution to B when we studied Y. Could we use that?
Lecturer: Sure, but what about security?
Student 2: We know λ from high-level programming. We could combine λ with B to achieve A.
Lecturer: What happens if an interrupt occurs, or your process is pre-empted by the scheduler? Have you considered the overhead of a context switch?
The lecture would continue in this manner until the class arrived at the correct solution. In doing so, the students not only learnt about the new concept, they learnt how to think about it in terms of operating systems. It’s important to understand the difference here between teaching yourself, and learning through interactive discovery (which can sometimes feel like you’re doing it independently). By being forced to think about the concept and develop solutions yourself, you learn to think correctly. If you have an expert (e.g. lecturer) to tell you when you’re wrong and reward you when you’re right, the process becomes much more effective.
Give Feedback, early and often. Feedback is the magic ingredient which takes an expository teaching style and makes it interactive. A series of weekly, small tests, as opposed to the monolithic exam, is great because it allows a student to receive constant feedback on their progression. If a student is consistently performing poorly then they are obviously doing it wrong and deserve a grade to match; you can be confident that they weren’t just having a bad day, they’re not getting it. On the other hand, if the student performs poorly just once, the most they will lose out on is the grade for that week’s assessment. A good student can take the lecturer’s feedback and change their approach. If they’re performing well by the next week, then congratulations are in order; the lecturer has taught the student how to think.
Last year I attended about 1% of my classes, simply because I could get the same information online while avoiding the 1 hour of commute time. I wish all classes were like OS Architecture. I was able to stop saying “What the hell is this?” and instead say, “Oh, of course! I’d never thought of it that way before.”
1]. Chris Crawford has been pushing for computer games as teaching tools