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.
9 comments:
Dear sir. I always admire you for the kind of efforts and innovative that you put from your side. I liked the idea of giving small programs rather than the big ones. I think writing a correct first 20 line code is good enough, there is no need to expect a 200 line code in the first few weeks.
Anyway, what made me comment here was the last paragraph. Starting from "Short cuts ... chances." I think that you sometimes overdo in this respect. I myself don't like academic dishonesty. Hence, the very first case, if it ever occurs, should be issued a very strong warning rather than awarding an "F" straight-away (Though I know your take on it ;-) ).
Kshitiz.
@kshitiz, 200 lines is for the end of the semester, not now. We started with 20 lines in lab1 to 40 lines in lab 2, and about 60 lines in lab3 and lab4 (though I must say that weaker students typically write poorer quality code, and write it in a way that it becomes 100+ lines). For example, a simple program to count use of alphabet characters is written by weaker students as a series of if-then-else statements, some 50 of them, while they could have used a bit of character arithmetic to have essentially just a couple of if statements.
I am really being challenged on this dishonesty issue. We used MOSS yesterday and the number of identical codes is amazingly high. I was really expecting that there will only be a couple of students. The message in the hostels is that copying in the labs is absolutely the right thing to do, and the only way to learn, in fact. And our disciplinary body, SSAC, hasn't given (to the best of my memory) any punishment (besides warning) to anyone for copying in the last 5 years. That has really strengthened the "copying is ok" message in the hostels.
So, the students appear genuinely shocked that I think of copying as an issue. And while I am not competing for the "most popular teacher" award, I don't want to be the "least popular teacher" on campus either (though I may not be able to avoid it). Failing 50% of the batch is totally out of question.
Dear Sir, The ESC101 course site is not updated.
Can you please provide the new course site in case it is accessible from outside. I would like to follow.
I see that this course has been changed a lot. In our times (2002) the language used to be Java. And it was not conducted for one batch together.
Manjeet, we no longer use publicly visible server for ESc101 website. In fact, we don't use a stand alone website either. We are using moodle, which is hosted on an internal CSE Department server (and not on CC server). If you are interested, send me an email privately, and I can see if we can find a way to make the moodle site visible from outside, and give you guest account for ESc101 course. I don't promise it, but will talk to lab people.
Your blog reminded me of my sociology teacher Prof K.N Sharma (circa 1977) who used to say his lecture is delivered towards median
ability students. He never put down a student because of his slow pace of understanding the subject.
While admiring your efforts to help weaker students, I am sad (somewhat shocked also!) to note that a size-able number of the students are so poor in their understanding of the class room matter. If this is the case in your course , it must have been the case in other courses too (given a normal distribution ).
I am sad because first IIT limited itself to becoming JEE centric, quite proud of the fact that UG students are world beaters, and then tweaked JEE so hard that you got a large number of students who need a lot of hand-holding .
In fact, I hear that some better informed students choose to leave IIT to take admission in IIIT Hyderabad, BITS, Pilani, IICT,Mumbai (of course depending upon what they were offered at IIT), and importantly , they don't regret it (when they compare notes with their friends in IIT).
I have had the opportunity of interacting with recent grads of various engineering colleges and I have found that some of the IIT grads lacking the fundamental understanding of the subject. This was alarming as this was this was one area IIT system really focused at. Further, social skills , which are so important in the industrial atmosphere, are not developed among IIT students (this is problem in general, though). IIT must pay attention to this aspect also.
I don't really understand the rationale for counting the lines of code. Isn't that counter to your goal of teaching algorithmic thinking? Could you elaborate?
On a lighter note, you might want to avoid teaching linked lists because of patent issues. See http://www.google.com/patents/?vid=Szh4AAAAEBAJ
@jackofalltrades, In order to use computers to solve problems, algorithmic thinking is extremely important, but you cannot use computers unless you learn how to convert your algorithm into a program. So, in such a course, you need to have a balance - don't get lost in syntax and details of a programming language, but at the same time, it shouldn't be a paper and pen course.
Now, if you restrict yourself to a maximum program size of 50 lines, then it severely limits the examples that you can use for developing algorithms. Also, pretty much any real life problem will have several ifs and whys. Students should be able to write down their solutions, both on a piece of paper as an algorithm or a flow chart, and on a computer as a C program, for at least some simple problems that they can relate to.
Hi. Please don't refer to students as "weak". "Students scoring low on class tests" may be a longer but more appropriate term. Or may be something else. Weakness somehow gives an impression of irremediable intellectual incapacity or inferiority. There is a lot more than weakness that causes some students to not perform as good as those who achieve the highest grades.
Sir, first of all, thanks for posting such informative articles. Given your reputation, I never expected such generous amounts of humor in your articles.
I agree with your zero-tolerance policy towards cheating. It is a must. But it is even more important to inculcate "anti-cheating" as a value. It may help if such a stand is uniformly applied across campus life - be it academics or otherwise - and can leverage existing student institutions such as counseling service, gymkhana, etc. Restricting the policy to only your course may by interpreted as "cheat where you can, and not when you can get caught".
Secondly, I think it may help to emphasize the value of "algorithmic thinking" beyond writing a piece of code. The same step-by-step approach also forms the basis to conduct business analyses, articulate thoughts, make insightful presentations, etc. - skills essential in any consulting/ finance jobs. You may harness students' aspirations for these jobs by showing how development of "algorithmic thinking" ability directly improves their chances of realizing their aspirations.
Post a Comment