This document summarizes and comments on the 6.170 mid-term course evaluations. We appreciate that many students took the time to provide us feedback on how the course is going, what works well, and how other aspects can be improved. In this document, course staff responses are indented.
There was no consensus regarding the speed of lectures. Most people did not feel the need to comment on them. Of those who did, about equal numbers thought Professor Guttag's speed just right and on the slow side, and about equal numbers found Professor Ernst's speed just right and too fast, though several judged Ernst too slow as well.
Some students found the lecture slides too telegraphic.
The slides are intended to be an aid to notetaking, to prevent you from having to frantically copy down material. The slides are not a replacement for the book -- which you should also read, since it contains more complete explanations of most of the ideas covered in lecture, and you may find its slightly different approach helpful in understanding the material. In any event, your own notes are likely to be more useful to you than more text on the slides would be.
Additionally, the version of the slides on the website contains additional material beyond that in the version handed out in class. For instance, the website version contains answers to questions asked during lecture, by the lecturer or by the class. The website version may also contain extra examples that the lecturer anticipates there will not be time to cover in class.
Most students agreed that Professor Guttag should hand out notes before lecture, for ease of notetaking.
Professor Guttag will hand out these notes for the remainder of the term.
Several comments requested that the lecturers connect the class better to industry, giving anecdotes or information that will be valuable in the business world.
We believe that the conceptual material that helps you get programs right is the best possible preparation for a programming-related job -- particularly because so few people in the industry seem to have this background! Later lectures will discuss software process, project management, and related issues. Additionally, two guest lecturers will relate their experiences in industry. Rick Poyner of Vanu speaks on Wednesday, April 25. (Joe Chung of ATG had to cancel for Tuesday, April 3, but we are attempting to reschedule.)
Some liked the book, finding it well-written and helpful. Others didn't like it or didn't bother to read it.
The average time spent by students ranged from a low of 10 hours per week to a high of 50 hours per week. Most students averaged 18-20 hours per week, but there was another, smaller peak in the distribution around 30-35 hours.
Developing quality software is not easy, and it can be time-consuming, but 6.170 provides you tools for managing its complexity and doing the work effectively. If you are spending 30+ hours per week on the class, then you have not learned the lessons, and you are not using the tools and resources effectively.
As an analogy, suppose that in elementary school you were given a math problem to perform: compute 77 * 101. You might complain to your teacher that this is an unreasonable burden, because you wrote out "77" 101 times and found adding them up to be very difficult and time-consuming. In fact, there is a better way that requires less time and effort, once you understand the proper technique (multiplication).
As another analogy taken from Stephen Covey, a woodsman was trying to saw down a tree with a dull saw that made very slow progress through the wood, despite strenuous effort. A passer-by asked, "Why don't you pause and sharpen the saw? Then you will be able to fell the tree more effectively." The woodsman answered, "I don't have time for that! I have to get this tree cut down!"
The staff of 6.170 does not want you to spend extraordinary amounts of time on the course. Furthermore, we do not believe that you need to. We have set you problems that will be difficult or impossible if you do not use the intellectual tools we are providing you (or if you are sloppy in their application), but which are manageable if you work in a disciplined and careful manner. The point of giving these problems, which are similar in many respects to others you will encounter in your career, is to reward students who have absorbed the course material and to encourage the others to learn and apply it.
If you find you are spending a lot of time on a particular problem, stop! Then, examine the problem, figure out what is at its core, and think about other ways to approach it. You will find that this is a much more effective problem-solving strategy than bullishly plowing ahead with unproductive activities.
As one example, if you are debugging a problem, stop and write more test cases in order to find the simplest one that reproduces the error. Perhaps the most time-effective way to approach your problem, if you have written a buggy, hard-to-understand piece of code, is to throw it out, come up with a better design, and carefully implement that instead. (If this sounds like a waste of time, you are not thinking about the problem correctly, because your goal is to have a working, well-documented system, not to avoid throwing away code at all costs.)
TAs and LAs have reported numerous situations in which students actively resisted writing test suites and applying other tools that 6.170 teaches. As a result, those students had much more difficulty than they needed to. If you can use your own methodology and find it successful for producing correct, easy-to-understand code, that's great! Many different programmers have different successful styles. However, if you find you are having difficulty, and you still resist the suggestions given by the 6.170 staff, then the fact that you are spending a lot of time is your own fault, not the fault of 6.170.
Also, remember that the course staff is available to help you. LAs and TAs have set hours, and the lecturers are happy to speak to students by appointment. The course staff be able to make useful suggestions to you -- but don't be resentful if they don't offer a silver bullet that corrects all your problems magically.
Many students highly praised the LAs for being available and accessible, for solving problems and explaining concepts, and for giving good, constructive tips that changed the way that students looked at problems. However, quite a number of comments were less favorable, criticizing the LAs for being curt, unhelpful, condescending, or unavailable.
We are extremely concerned to hear that some students do not find the LAs approachable. This is an extremely serious issue which we are now taking active steps to correct. Unfortunately, with one exception, the comments did not specify what was wrong or how the LAs could fix it. If you have a complaint, please bring it to the lecturers, preferably via email or in person. However, if you are uncomfortable with that, you may use an anonymous feedback form. (If you use the anonymous feedback form, we cannot reply, ask for clarifications, give explanations, or even know that it is really a current 6.170 student making the comment.) If you can point out specific problems or make concrete suggestions (about the LAs or any other aspect of the course), then we have a much better chance of correcting the problem.
We recommend that you speak to LAs in person. Unfortunately, zephyr is a very poor medium for communication. Compared to personal contact, zephyr doesn't permit a real conversation and is more prone to misunderstandings (on both ends), which can lead to frustration or bad feelings. Talking in person is much more likely to give the LA a feel for what you know and what you are having trouble with, and so you are likely to get a response that is more useful for you in your situation. Furthermore, the LAs give priority to students who visit them during their lab hours; LAs answer questions on the instance only when there isn't a student there in person. You shouldn't be surprised if you don't always get an instant response to zephyr questions, even when an LA is on duty. Also, please respect the fact that staff members may be online -- they may even helpfully answer a question or two -- when they are not on duty. Please do not take advantage of the LAs' generosity by imposing on them during their off-duty hours. (Check the LA lab hours and/or ask whether the LA is on duty before bombarding the LA with questions.)
The LAs will help guide you and show you the way to solve your problems, but they won't do your work and you shouldn't expect them to sit with you for an hour to debug your program. (Besides, if you have already written good test suites, representation invariant checks, and the like, debugging most problems shouldn't take an hour.) It's reasonable for an LA to ask you to go back and do some of the tasks that we have taught in this class, such as writing a test that exposes the problem. However, if you have followed the 6.170 methodology, you should always be able to get attention and a useful answer from an LA; if that isn't the case, we want to hear about it. Also, if the LAs do not treat you courteously, let the lecturers know, because that is unacceptable behavior.
When you ask a question of a 6.170 staff member, give all the relevant information, and list all the things that you have done in order to solve the problem yourself. By presenting the full context, the staff member will not have to waste time repeating tests or experiments that you have already performed, and the staff member may be able to quickly point out an incorrect assumption that can permit you to solve the problem on your own. For instance, you should give an overview of the tests you have run and other strategies you have tried, and why you decided they were not correct. (It can be helpful to present an argument that demonstrates conclusively that there is a bug in the staff libraries, the Java compiler, or the Java Virtual Machine; in the course of constructing this proof, you may discover that you have made an incorrect assumption, or you may find the error in your own code.)
If frustrations with the LAs have caused you to stop asking questions of them, please give them another try (keeping in mind the imperfections of zephyr, the heavy demands on the LAs' time, and that their goal is not to do your work for you but to suggest strategies that you can use to solve your own problems). Let the lecturers know if you continue to have difficulties.
A few students suggested that problem sets should permit collaboration.
In past experiments, it has been our experience that when students work together, they don't get as much from the course. In particular, many weaker students never really learn the material, but use their partners as crutches. (Another problem is that sometimes students get bad advice from other students; you are more likely to get good advice from the course staff.) We are asking you to work alone during the first part of the semester to permit you to learn by doing, which is more effective than learning by watching, and to develop your own style.
The labs are intended to be done in pairs, so that is a time you can learn from and work with other students. You will get a lot of experience working with others during the final project. Most importantly, you can ask the LAs and other members of the course staff for help, guidance, and feedback when you are stuck.
Thanks again for the comments which you wrote on the comment forms; we found them very useful. We have taken several specific steps to correct problems identified on them, and we plan to do even more later on. Please feel free to make additional comments, keeping in mind that specific examples and concrete suggestions are far more useful than generalities. We look forward to your continued feedback.