-
Notifications
You must be signed in to change notification settings - Fork 16
Teaching Principles
It's essential that students use the time before class to expose themselves to coding concepts. Per the human learning principle that it's best to get related knowledge in advance, they will be FAR more likely to retain information the second time they're exposed.
I use a pretty extensive set of prework that covers psychology, programming, and tools like git and the command line. I've never had a student say that it's too much, so I like to err on the side of more rather than less.
It's also extremely important to get accountability in place during prework (more on accountability below). Some students will ignore it if left to their own devices, so I have them complete one survey near the beginning and one at the end. I tell them that they have to have the last survey done a week before class starts, and I email them two weeks before class starts to remind them.
As a side note, the initial survey also serves the purpose of getting the students started, and just starting is the best way to fight off procrastination.
As a side side note, the final survey has questions that ask them to reflect on what they just studied. Specifically, I ask them to say which they liked the least and whicth they liked the most. This is, of course, a great way to get feedback for next time (more on feedback below), but there are also some type A students who get mildly bitter when they're asked to do things that they consider boring. Giving them an immediate avenue to get that off their chests helps.
Doctors get sued far less often when they provide their patients with orienting statements about the future. "First we're going to test X, then if it's positive we'll try Y, etc, etc, etc." Humans want to know where we are and what future steps will be, so there's no reason why we as teachers shouldn't take advantage of that.
This applies at the macro scale, so it's helpful to plan out your curriculum in advance (e.g. tell students on Monday what's coming during the entire week). However, it also applies on smaller scales. Letting students see the evening's assignment before or during the lecture can keep them engaged because they see where it's all going.
Although not lecture-related, this is especially important as they approach and work on final projects. Check-in structure and iteration planning make huge differences. More to say on final projects in a different forum.
Every time I've tried an open-ended assignment in the first three weeks of class, it's been terrible. Not only are students unclear on how to apply what they've learned, but they also get really stressed out about it. An example would be a first night's assignment of "Write out the instructions to Battleship in your own words. Try to think like a computer."
This bugged me at first ("they're just using explicit completion criteria as a crutch!"), but I've come to accept it. They've got enough pressure when acclimating to a whole new type of education, and there's value in focusing effort on practicing what was just learned.
That being said, I open the doors back up for the 4th weekend assignment. Students are asked to invent and build their own novel API, and at that point in the schedule, it goes well.
There's something to be said for permanence. I have two whiteboards in my classroom, and I use one of them as the list board, which shall not be erased before week 10. Here's an example:
This board starts blank and accumulates information over the course of the cohort. Sometimes I add things to the list as we learn them (e.g. classes/data types), and sometimes I write them all up at first and then star them as we cover them (e.g. folders in Rails). Regardless, I use the board as a reference point during future lessons, and will sometimes walk over and gesticulate wildly at it to point out that the day's topic is linked to something we covered a week ago. This concept "spiraling" is good for learning, and the consistent physical location of these lists in the classroom helps students reference them.
Some students are going to breeze through all of your early assignments. You're likely to feel guilty. Then you'll decide to ramp things up... and you'll lose the bottom students.
When it comes to assignments, the best way to deal with this is to write a normal assignment, but append features or complications in optional sections. Like most of the Iron Yard staff, I write Normal, Hard, and Mightmare modes on all of my assignments. I've written one "Apocalypse Mode."
(Well... "all" is not entirely true. As the class progresses and assignments get more open-ended, explicit hard/nightmare modes are less critical.)
Despite having to spread the difficulty of each assignment like this, I've found that it's NOT necessary to move the difficulty of the lecture upwards. The top students seem to be able to glean nuance out of any lecture, so I consistently lecture to the bottom-middle of class.
I think there's a lot of value in assigning pairs for students rather than letting them choose their own. Sometimes you can avoid problems, sometimes you can strategize who learns what, and always you can avoid someone being the odd-person-out.
I avoid pairing top students with bottom students. I sometimes pair the best with the best, and I sometimes pair the middle with the top (and the middle with the bottom), but I try not to have the skill disparity be too large. Every now and again you get lucky with a top student who is also a patient teacher, but let's be honest: they're paying a lot to do this, so you want them to be in a position where they can stretch their own skills as well.
Let's suppose that you're married. You come home 15 minutes late one day, and you're worried that your spouse is going to be angry with you. However, your spouse says nothing. You think maybe you got lucky, and your spouse hadn't checked the clock. Then you show up late the next day, and your spouse still says nothing. After five days of this with no feedback, you start to think that it's an okay habit, and that maybe it's cool. Then, on the sixth day, your spouse explodes with anger, and you end up sleeping on the couch. Sound familiar?
The point of that story: we as humans need to be immediate feedback in order to manage our behavior. If a student doesn't turn in an assignment, say something immediately. If code is sloppy, say something immediately. If behavior is inappropriate, say something immediately (although not always in a public forum). This, of course, means that you have to be paying attention to student work every day.
The most surprised I've been on this job was when an instructor said "I just can't get my students to turn in their homework. I don't know why." If you find this happening, it may be because you didn't hold your students accountable to their work from the beginning.
This is a tip that's a bit hard to quantify, but it's always helpful to students if you can verbalize what's going on in their heads, and even better if you can give it a name. For example:
- "I know, you're looking at this code and saying 'What in the heck is that?' Here's what's going on..."
- "Look, this is your first time you've tried to use classes, so I know you're all thinking 'I can do this just fine without writing any classes...'"
- "That assignment was hard, and it probably stressed everyone out. The issue was that it had just enough complexity that you couldn't hold it all in your head at one time. THIS is why it's best to solve a simpler problem first and then build on it."
- "It's week 6, and I bet you're tired. I bet you're all thinking, 'these weeks just keep coming, don't theny?'"
- "Did anyone wish that they had a way to test this code rather than clicking through it again and again?"
It might seem goofy, but this is the sure-fire way to re-engage a tired class class and get them all nodding again.
I record all of my lectures using the Mac's built-in Quicktime Screen Recording functionality. I use the internal mic on my laptop, pause during breaks, and just cope with the fact that they can't hear me well while I'm at the board. I upload the videos to YouTube over lunch, and put links on the course website around 5pm. I don't put them up immediately because (a) I like to force the students to perform some recall on their own (which enhances memory more than review), and (b) YouTube takes a while to process the videos.
I would never record separate audio and video tracks, as I don't want to put any extra time into this. I record, save, upload, paste link.
Students love having a way to watch lectures again, even if I don't put them up until 5. Some choose to set it on 2x speed when they watch it again (which seems right to me, because I sound glacially slow when I listen to myself after the fact), and a good trick for those writing notes is to write down the time at which I say something important. Then they can easily index back into the video by watching the system clock in the upper-right of the screen.
I don't intend for the videos to be used by people who weren't in the class. I see them as only being valuable to those who were present in the room, and don't try to make them general resources for the world.
I gather student feedback all the time. It helps them feel listened to, gives them a chance to vent frustrations, and helps me change my approach in the future.
As mentioned above, I start with prework surveys, and I use them to (a) gauge my students' progress and (b) figure out if parts of the prework are any good.
Once class starts, an important metric I use is the comfort-to-panic score, which I explain here. The TA gathers this score for each lecture, and the second half of that video is an analysis of one cohort's data.
I also gather this score for each assignment, but it's part of a bigger survey which they fill out each evening. This survey accomplishes a lot of good things, including curriculum adjustment for future cohorts.
Finally, I ask the students for substantial feedback at the end of each cohort using this survey.
I'll discuss homework review later, but in short, I end up reviewing homework side-by-side with each student about once every two or three days. Despite this built-in contact time, I think it's important to rigorously hold one-on-ones.
I hold one one-on-one each day, so each student has one every three weeks when I have full class. Each one is 15 minutes long, and I tell them that we're not suppose to talk about technical questions or areas of confusion. I ask them how the class is going, and if they have any thoughts, concerns, criticisms, or suggestions which they'd like to share. I explicitly for modifications to my teaching style.
Even though this officially totals 45 minutes per student per cohort, it makes a big difference in the quality of interactions. I think that it accomplishes the following:
- They make it clear that I'm happy to talk on a non-technical level
- They encourage a class-wide culture of openness to constructive criticism
- They allow for any venting that might need to occur
- It makes them more likely to approach me at other times
- I get a better understanding of student personalities
- I find out how I'm messing up!
Of course, rigor and consistency in holding these meetings is important. Otherwise, none of those benefits are guaranteed.
This is a quick thing to say, but an important one. I don't let students ask me questions by themselves during lab time. They first have to ask another student (or the TA), and if they can't figure it out together, they have to come to me together. This is good because (a) students who know something get to practice teaching it, which solidifies it for them, (b) they get to know each other, and (c) I answer questions once instead of twice. When I tell students all of these reasons, they seem happy to abide by the rule.