Can I Stop Lecturing Now?

In Fall 2010 I’ll teach my Advanced Embedded Systems course for the fifth time.  This is a class that I enjoy teaching and that students generally enjoy taking.  I created it from scratch and am fairly proud of it.  There’s just one problem: I’m ready to stop giving the lectures.  First, although I tweak and improve them each year, I’m getting somewhat bored with them.  Second — and much more important — I’ve become convinced that (in this case, not necessarily in general) lectures aren’t the best use of class time.  For one thing, even when students are actively engaged with the material, it’s hard for them to sit still and listen to someone for 75 minutes.  For another, the thing I really want students to get from the class is a taste of real-world embedded systems design and implementation.  They should be learning skills such as working in a team, understanding requirements, evaluating software architectures and other implementation choices, creating maintainable code, debugging in challenging environments, reviewing code, and figuring out how to test complex combinations of hardware and software.

Here’s my idea.  First, while giving the lectures this fall, I’ll arrange for good-quality videos to be recorded, so I can put them online.  Second, after this fall, I’ll give few or no lectures but rather ask the students to watch at least some of them online, outside of class.  Then we’ll spend the class periods — typically two 75-minute sessions per week — working out the design and implementation of a more open-ended and aggressive collection of projects than I had previously given (note that there are 3 hours of lab time per week in addition to the lecture time).  Also, after teams get their projects to work, I’ll require them to integrate these projects with each other, for example using a serial line or CAN bus.  Previously, when I have required interaction between different teams’ projects, this has turned out to be far more challenging than the students anticipated, even for relatively simple projects such as distributed time synchronization or a consensus protocol.  Also, I’d like to spend a fair amount of time in class doing code reviews.  It turns out that for a variety of reasons, such as the fact that they always get to throw away code after writing it, a lot of junior/senior-level CS and CE students are not exactly the kind of coders I’d hire for an ambitious embedded project.  Regular code reviews can help turn coders into real programmers. One final idea that I keep wanting to try, but haven’t yet, is to force teams to exchange code bases with each other partway through the semester.  This is basically evil and will probably cause me to take a hit on the teaching evaluations, but I think it is guaranteed to be a character-building experience.

Anyway, it’s possible that this experiment will make my course more awesome, or it may tank miserably.  I’d love to hear feedback and advice from readers, either in the comments here or in email. In a couple years I’ll let you all know how it went.

11 thoughts on “Can I Stop Lecturing Now?”

  1. I think its an excellent idea!

    In my experience lectures are simply not effective for most students. I think it’s partly because its too much information density for them to absorb and partly because they have the option of just tuning out and not really using their brains (which many do as soon as they get confused.)

    Doing something where students actually have to THINK is usually a much better use of the limited class time e.g code reviews and projects as you are thinking or solving problems in class or a debate or anything else interactive.

    I think the only advantage of lectures is that you might be able to cover more material if you are willing to accept that students won’t gain much more than the gist of the idea from the lectures themselves.

  2. This does sound like a really good idea.

    Will you still have exams? If so, will they focus on things people should be learning from the lectures or things should be learning from the labs? If not, what else will count towards their grade besides the lab? Maybe you could do non-traditional exams, like an in-class timed project.

    I agree that your idea to switch code bases is truly evil. However, if you devote a bit of time to establishing a coding standard and enforce it in the code review then your class will shine brightly as a great experience on your student’s resumes.

  3. Hi Prof. Regehr
    This sounds like a very interesting idea. I’d be curious how it is going to turn out. When I was a TA at USC, the teaching staff attempted to reduce the lecturing hours by being more involved in the projects from the beginning. Instead of having three hours of lecture, we would have two hours of lecture and an hour dedicated to discussing with individual project teams (4 teams per hour – 15 mins each). I thought that helped us give more instant feedback for individual projects and also helped the students do better projects because they get stuck with issues during the semester that usually dont get addressed until closer to the end of the semester when the project is due. I certainly felt that the productivity of the average project was up. Here is the class website:

    I am however apprehensive of code sharing and combining projects. That always seems like a harder task – even within a project team let alone across the whole class. Code reviews might alleviate this problem a little. I would like to know how much of a hindrance you think this would be to the process after the course.

    The other tradeoff is how research oriented the project is to how much engineering is being done. More code reviews etc. make the process more streamlined which might not be congenial for testing out toy designs because you need to decide your interfaces etc. early in the process. Many schools seem to solve this problem by having courses that are tailored to senior/masters students training to go to the industry while others which are more research-oriented that target the Phd students.

    However, I really look forward to you posting the lecture videos online – for more selfish reasons than anything else 🙂

  4. Hi Karthik, Nathan, Mugizi– Thanks for the feedback!

    I hadn’t really figured out what to do about exams. One possibility is exams are the stick used to motivate students to watch the online lectures. However, Karthik’s idea about reducing instead of eliminating the lecture time is perhaps a better answer. It might even be OK to split the 75-minute periods in between lecture and project activities, since 75 minutes is a long time to listen even once a week.

  5. Matthias Felleisen (Northeastern, my and Matthew’s advsior) and I
    have been developing a similar kind of course for
    twelve years now (starting at Rice in 1998). Our experience says that what
    you suggest works really well: students improve their technical
    communication skills, something most of them lack; students improve their
    coding skills, because they don’t want to be faulted in public and because
    of the added pressure of integrating their component into an overall
    system; and students get better at reading and inspecting code.

    Our course differs from what you propose in that it focuses entirely on
    software development: pair programming; code walks with 24 hour warnings;
    code inspection; a thorough emphasis on unit testing including “test
    fests”; and repeated indoctrination with a basic programming process. We
    lecture for a third of the semester; most of the time is spent on code walks.

    We eschew domain content, other than that students must be willing to play
    games such as Bazaar, Carcassonne, Scrabble, etc. Also we do not
    hand out a complete specification at the beginning but change the specs
    over time. If students don’t pay attention to the basic design process that
    we teach (in “How to Design Programs”, scaled up), they will pay for it
    with a lot of additional coding hours. It sure teaches a lesson on good
    design and good practices. The integration happens late in the course when
    their server runs with others’ players (over the net) and vice versa. We
    also throw in broken and malicious players (with warning).

    Our target is the “junior” level (late second, early third year), i.e., a
    course that comes after an aggressive introductory programming
    sequence. Since it isn’t concerned with software engineering content, we
    dubbed it “program development” or “software development”. We assume that
    students see yet another intensive programming course later (for a specific
    domain such as “embedded systems” or “compilers”) and ideally an SE course.

    When you run such a course, one thing to watch out for is the nature of
    public criticism during code walks. The presenters tend to take criticism
    personally to the point; they may feel “hurt.” To counter that, we often
    hand out Weinberger’s chapter on “egoless programming” and try to remind
    them of it often. In the end, most students understand the idea of the
    course, learn a lot, appreciate the extra hours, and walk away thinking
    that this course truly prepared them for industry. Oh and don’t worry; the
    teaching evals tend to be fantastic.

  6. Thanks Robby! This is great stuff. Of course, conversations with Matthew helped me formulate my idea for this course.

    I envy your situation where you have this fairly controlled programming environment for students to play in. Also, very cool that it supports rapid development of things like broken and malicious players. I need to figure out how to create equivalent things in the less controlled embedded development environment we use.

    I’ll probably be coming to you guys with questions as I try to implement this!

  7. Brilliant!!!

    Your ideas, and ideas of other commentators, really helps to infuse the real world into an academic environment.

    I like the idea of switching code bases. It gets students used to dealing with other people’s code. They’re going to have to learn how to come into the middle of a project and building off of, and maintaining, code from other people.

    I like the idea of having to integrate their projects with others’ projects. Again, very real world stuff.

    I like the idea of changing the requirements mid-class. That happens all the time in the real world. Please don’t let the students know about this before hand!

    I’m not sure about the exams part. In my mind, the best way to learn any programming, and anything in embedded systems, is by doing. The theory (lectures) should be a support for the praxis. Why exam on the theory alone? In my job, I don’t get paid by spouting off a bunch of theory. I get paid for making results. The theory that I have learned helps me in making results better and faster. I am not an teacher/academic, but I wonder if there is a way to evaluate the students on how far they were able to move along the project (achieved milestones), and the quality of each milestone, and then maybe a way they could relate how the theory helped them at each milestone.

    Anyway, I like where you’re going with this! 🙂

  8. Hi Prof Regehr,
    This is an excellent way of teaching. Typically students don’t bother about Valgrind or gprof or version controls like SVN. But these are cool skills to have for a student and absolute must for a pro, and it looks to me that your course would provide a practical situation where some or all of these would need to be used.

    Great going!


  9. Don’t ever think your lectures are going un-appreciated. I’ve learned more about proper C code this semester (Fall 2010) than ever before. These are topics I’ve never considered before. Even though your lectures are based on embedded systems, I use the content for all types of development. My vote is to keep the lectures.

    As for the code reviews, this is a great idea. My coding standards have improved greatly over this semester but it would be really awesome if someone else (like you) could verify this improvement.

    I think your labs should have more to do with your lectures. I feel like I learned a lot during the lectures but didn’t have the chance to implement what I learned. One idea is to have the labs build on each other such that it turns into a library for that given microcontroller. I would have loved to end the semester with a home built RTOS!

  10. Thanks for the comments Nic!

    Regarding tying the labs closer to the lectures, I see your point. The current situation happened because both the lectures and labs have evolved over time, and have sort of diverged. Also, some of the interesting topics (DSP, real-time, CAN bus) come so late in the semester that I can’t think of a way to base any labs on those. Anyway, you’re right, I should work on this.

  11. Although I sympathise with your boredom, videos (and films) of lectures are known to be a particularly ineffective teaching method.

    Although there were some extrodinarly good training films made in the 40’s and 50’s, they didn’t look anything like lectures. (And they were not dramatisations, so don’t go down that path either)

    If you are unwilling to discard lectures, an alternative might be to pay a teaching assistant to deliver your content. Having a live person deliver content is qualitatively different to watching a computer screen.

Comments are closed.