This is to continue describing my experience of teaching a class of 500+ students. If you are interested, you can read the earlier post.
Last time, I had described my dealing with students who did not know adequate conversational English. This time, I am describing how we are conducting labs.
We have divided the batch into 5 groups, each of about 105 students. There is one lab of 3 hours per week for each group. For each lab, there are 8-9 persons (2-3 5th year dual-degree MTech students, and 6 1st year MTech students) to help students with any difficulties.
Normally, the first 3-4 weeks are hell for students who are looking at a computer screen for the first time. Too many questions, and too few people to help. So we requested all MTech students to do extra duties in the first 4 weeks. First two weeks, there were 6 extra MTech students in each lab, and for the next two weeks, there were 3 extra MTech students in each lab. The labs have gone extremely smoothly as a result, much better than what I could have imagined.
The first week was a bit of chaos. The MTech students themselves were new to campus, and trying to settle down, and understand the computing environment, find out where the labs are, and what they are supposed to do. In the past, instructors have not conducted labs in the first week for these reasons. But I was adamant. I was willing to not have a lab only on the first day of classes. From day 2, labs must start, and those who miss the lab of day 1 would have an extra lab on the weekend. I must say that the dual-degree students were huge help in this week and a couple of students went to lab on each of the five days. Without such dedicated students, I couldn't have managed this course. The first lab was to just remove their fears of the computers. They would learn how to send/receive email, attachments, searching for stuff through google, and a few other miscellaneous tasks, including playing computer games. A bit of linux commands too, and getting familiar with moodle. No programming, not even typing a given program. I didn't want to scare students.
The second week was to learn an editor, typing a program (which was given to them), knowing about the compiler, and running the program. Again, a very comfortable exercise, just to start the love affair between the students and the computer.
But the third week was different. The real labs started now. And the labs were very different from what their seniors had told them. We used to ask them to write 3-4 small programs (20-25 lines sort of stuff) in every lab. By the time they completed the course, they would be comfortable writing a 50-line program. This won't work for me. I would ask them to write at least a 50-60 line program in the lab, and the hope is that by the time they complete the course, they would have written at least one 150-200 line program.
Earlier labs would ask them to write some standard program from the end-of-chapter exercises. But now, they had to understand a more real-life situation and write a program for that. No rocket science. Just produce a telephone bill, or a shopping receipt, or project the train arrival time, or whatever, but a real-life context is important (not always, since I have to think of 5 problems of roughly equal difficulty, all of which can be done with the limited amount of programming that I would have taught till that week).
Since I can't expect students to write a 50-line program in a 3-hour lab, I would announce the lab problems at least 2 days in advance. So they can think about the flow chart, may be even try out some coding in their free time. But announcing the problem in advance has its own critics. Many students spend far too much time on them. Some students, after solving their own problems, even try to solve problems of other lab batches. Some have truly fallen in love with the machine, while others are just trying to catch up with those who already knew programming. Yet others find the air conditioned environment of Computer Center rather conducive to work (and sleep). But it is all my fault that they don't seem to be spending as much time in other courses.
Then the grading. Normally, the grading is the responsibility of the MTech student, who is as new to the system as the first year BTech student. And grading was done in the lab itself, with no record of program that was shown. And it was not surprising that the average of the class would invariably be a healthy 9 out of 10. This meant that almost all students wrote programs for all small exercises that were given in all labs, even though the students were not told about what program they have to write till the beginning of the lab hour, and within 3 hours, everyone had submitted, that too correctly, and had been graded. Something was not right.
I have insisted that all lab assignments must be uploaded on moodle. So if I want to check some submissions randomly, I should be able to do it. I would also give a very detailed grading policy every day - what to check, how many marks for what features including comments and use of proper variable names, etc. And grading should mostly be done offline (which is now possible since all assignments are uploaded), so that the TAs focus only on helping students in the lab. The lab average is a more realistic 6 out of 10 with a proper spread of marks on both sides. But students are not complaining. The amount of help they are getting, again thanks to all the graduate students, is something that they probably did not expect. Some of the TAs would be available even on weekends to help the students with their programs.
While we provide all the help to the weak students, one complaint that we keep hearing in IIT is that we don't do enough to encourage good students. Well, there is something for them too. We are starting the process to identify the best programmer in each section for each lab, and their names will be announced not just to that section, but to all the students. And soon, we will offer these students a chance to do a large project in lieu of the exam.
We tell our students one simple thing. We will work hard to provide all opportunities and support. But they should also work hard. Short cuts won't be tolerated. In other words, copying in a lab is a strict no-no. Some of them don't seem to understand this. Nowhere, the lab is taken seriously, I am told. We start using the services of MOSS server at Stanford today. Since this has been announced that we will use MOSS, and anyone copying will be failed in the course, I don't expect students to take chances.
Last time, I had described my dealing with students who did not know adequate conversational English. This time, I am describing how we are conducting labs.
We have divided the batch into 5 groups, each of about 105 students. There is one lab of 3 hours per week for each group. For each lab, there are 8-9 persons (2-3 5th year dual-degree MTech students, and 6 1st year MTech students) to help students with any difficulties.
Normally, the first 3-4 weeks are hell for students who are looking at a computer screen for the first time. Too many questions, and too few people to help. So we requested all MTech students to do extra duties in the first 4 weeks. First two weeks, there were 6 extra MTech students in each lab, and for the next two weeks, there were 3 extra MTech students in each lab. The labs have gone extremely smoothly as a result, much better than what I could have imagined.
The first week was a bit of chaos. The MTech students themselves were new to campus, and trying to settle down, and understand the computing environment, find out where the labs are, and what they are supposed to do. In the past, instructors have not conducted labs in the first week for these reasons. But I was adamant. I was willing to not have a lab only on the first day of classes. From day 2, labs must start, and those who miss the lab of day 1 would have an extra lab on the weekend. I must say that the dual-degree students were huge help in this week and a couple of students went to lab on each of the five days. Without such dedicated students, I couldn't have managed this course. The first lab was to just remove their fears of the computers. They would learn how to send/receive email, attachments, searching for stuff through google, and a few other miscellaneous tasks, including playing computer games. A bit of linux commands too, and getting familiar with moodle. No programming, not even typing a given program. I didn't want to scare students.
The second week was to learn an editor, typing a program (which was given to them), knowing about the compiler, and running the program. Again, a very comfortable exercise, just to start the love affair between the students and the computer.
But the third week was different. The real labs started now. And the labs were very different from what their seniors had told them. We used to ask them to write 3-4 small programs (20-25 lines sort of stuff) in every lab. By the time they completed the course, they would be comfortable writing a 50-line program. This won't work for me. I would ask them to write at least a 50-60 line program in the lab, and the hope is that by the time they complete the course, they would have written at least one 150-200 line program.
Earlier labs would ask them to write some standard program from the end-of-chapter exercises. But now, they had to understand a more real-life situation and write a program for that. No rocket science. Just produce a telephone bill, or a shopping receipt, or project the train arrival time, or whatever, but a real-life context is important (not always, since I have to think of 5 problems of roughly equal difficulty, all of which can be done with the limited amount of programming that I would have taught till that week).
Since I can't expect students to write a 50-line program in a 3-hour lab, I would announce the lab problems at least 2 days in advance. So they can think about the flow chart, may be even try out some coding in their free time. But announcing the problem in advance has its own critics. Many students spend far too much time on them. Some students, after solving their own problems, even try to solve problems of other lab batches. Some have truly fallen in love with the machine, while others are just trying to catch up with those who already knew programming. Yet others find the air conditioned environment of Computer Center rather conducive to work (and sleep). But it is all my fault that they don't seem to be spending as much time in other courses.
Then the grading. Normally, the grading is the responsibility of the MTech student, who is as new to the system as the first year BTech student. And grading was done in the lab itself, with no record of program that was shown. And it was not surprising that the average of the class would invariably be a healthy 9 out of 10. This meant that almost all students wrote programs for all small exercises that were given in all labs, even though the students were not told about what program they have to write till the beginning of the lab hour, and within 3 hours, everyone had submitted, that too correctly, and had been graded. Something was not right.
I have insisted that all lab assignments must be uploaded on moodle. So if I want to check some submissions randomly, I should be able to do it. I would also give a very detailed grading policy every day - what to check, how many marks for what features including comments and use of proper variable names, etc. And grading should mostly be done offline (which is now possible since all assignments are uploaded), so that the TAs focus only on helping students in the lab. The lab average is a more realistic 6 out of 10 with a proper spread of marks on both sides. But students are not complaining. The amount of help they are getting, again thanks to all the graduate students, is something that they probably did not expect. Some of the TAs would be available even on weekends to help the students with their programs.
While we provide all the help to the weak students, one complaint that we keep hearing in IIT is that we don't do enough to encourage good students. Well, there is something for them too. We are starting the process to identify the best programmer in each section for each lab, and their names will be announced not just to that section, but to all the students. And soon, we will offer these students a chance to do a large project in lieu of the exam.
We tell our students one simple thing. We will work hard to provide all opportunities and support. But they should also work hard. Short cuts won't be tolerated. In other words, copying in a lab is a strict no-no. Some of them don't seem to understand this. Nowhere, the lab is taken seriously, I am told. We start using the services of MOSS server at Stanford today. Since this has been announced that we will use MOSS, and anyone copying will be failed in the course, I don't expect students to take chances.