Getting the gist through to students

There is an interesting paper by Prof. Michael Loui, Prof. Craig Zilles and J.T. Longino entitled Student Misconceptions in an Introductory Logic Design Course.. It's pretty short -- 12 pages -- but it covers a lot of ground. It shows that there are indeed concepts in Logic Design that most students miss. In fact, I will admit, that there are some concepts that I missed when I took that course as an undergraduate.

While the paper does describe and analyze some misconceptions that students have, I felt that the main reason that some students do not get Logic Design is because they become overwhelmed by the homework. I remember having lots of homework for the ECE class that I took and it took a lot of time to complete them. Even after completing them and having them handed back, sometimes I was not really sure whether my answer was the best approach to solving the problem. While answers are provided for those homework questions, we did not always go through the process of coming up with those answers. We will see the step-by-step solution by there was no justification why that method was chosen (or how that method was synthesized). It would have been better if the lecturer went through some of the harder problems and show how to solve it. Preferably, this would be a live session with pen and transparencies over the projector. It would be even better if it could be recorded so the student can replay this later when they were revising.

Lecturers should seriously avoid doing too much hand-waving while solving those problems. I have found that class with a lot of hand-waving are the most frustrating classes that I have taken. Classes that utilize only PowerPoint slides also tend to be less interesting that those that use normal chalkboard or even transparencies. It is important that each step for approaching the problem domain is properly articulated for the new students.

From my own experience, sometimes, the homework problems seem so repetitious. There was no mention of the motivation for doing those homework problems. Sometimes it was more of doing it for the sake of doing it. The lab component was particularly useless since it focused more on how to use the tool (click, drag, type) instead of showing why people would use those tools. And those tools were too cumbersome to be used for most problems.

For the programming course that I am teaching, I try to motivate deeper understanding by asking students how they approach the problem. It does not matter if the approach is simplistic or naive-- what is important is that the approach works. Getting a working program is important because it forces you to actually get all the details in. It is simple to have a high-level overview of the solution but until you implement it, a lot of details can be easily overlooked. In discussion section, we would then discuss the merits of each approach. I usually have my own solution which I would use as the base for comparison purposes. Students then get another week to make improvements to their program following the discussion that we had. I have found that

I discourage complicated solutions that utilize a lot of heavyweight frameworks or libraries. I made the assignment so that they can be easily solved using basic C/C++/Java knowledge from a prior 100 or 200 level course. Using frameworks hides a lot of the implementation details and makes for a rather terse discussion section. Unless other students are familiar with the framework, what they say will not make sense to the other students. I believe that if you understand the basics, using any framework will be almost trivial (except for those that require proprietary components which must be purchased separately).

I also try to make the examples more motivating that a typical machine problem. Machine problems tend to be really boring. They usually focus on only one concept and do not require much thinking on the part of the student. Some of the machine problems are also either hit-or-miss: meaning that they only have one solution. That hinders students from trying to experiment with their own solutions. Instead, they are more concerned if their solution is the right solution. My machine problems tend to involve lots of visual feedback: images, graphics, interaction. This is based on my own motivation for doing computer science: so that I can create all those cool programs like games, applications, etc. Without this intrinsic motivation, students are less likely to have fun doing the machine problems. I have yet to hear students from other classes calling their machine problems fun.

I realize that it is easier to make programming classes more fun that Logic Design. After all, a lot of the jargon that we use -- XML, Object-Oriented Design, GUI, etc. -- have become rather common parlance for most computer-savvy kids. And there is an abundance of open-source projects where students can actually contribute and draw examples from. But for Logic Design, concepts like duality, Karnaugh Maps, sum-of-products are less well-known. More effort has to be to be taken to motivate the importance of such concepts. It is a shame that there are few open source projects on Logic Design (I might be wrong on this but I have to find anything called logicdesignfourge.net as compared to sourceforge.net