In our department we're looking at the class requirements for Ph.D. students, and in particular breadth requirements.
I'll state clearly that my opinion is that breadth requirements are a good thing. Breadth requirements for Ph.D. students are like vegetables for kids -- they don't always like them, but they're good for them. When I was at Berkeley the breadth requirements were reasonably onerous and I think they were very positive for me (even if, as contemporaries will suggest, it seemed like I slept through most of them). I especially think it's good for theoretical people to have a background in many areas of computer science outside theory, and classes are arguably the best way to get that background. And certainly I would argue that people in systems need some theory in their background.
I'd enjoy hearing arguments from the other side. You can argue that breadth requirements in general are a bad idea, or specifically that theory people shouldn't have to take classes in other CS areas (they should be allowed to just do all theory!), or that systems people shouldn't have to take a theory class. Any EE readers or readers from other areas should chime in with arguments based on their experiences as well!
Subscribe to:
Post Comments (Atom)
24 comments:
I don't think that anybody seriously believes that students should not have to take breadth requirements. Your PhD is in Computer Science, not CS Theory. You should be able to demonstrate some understanding of areas outside of your own.
No, but these requirements shouldn't be formal. If you've already taken these classes as part of a BS degree (say, at a different school), you shouldn't have to repeat them in the PhD program.
I would argue that students should already have this background when they enter the PhD program. Those who don't, can be required to take remedial "breadth" courses, but there is no point in making theory people take the same OS or SW. Eng. class (or an analogue of it) twice, when they should be concentrating on research. How many times do you want to go through the same mind-numbing sequence of OS, AI, PL, SWEng, etc.?
Short version: I like breadth requirements, but not the way they're implemented at my school (UT).
Long version: Even with the breadth requirements I don't think students get enough breadth exposure. As a grad student who doesn't work in theory but keeps abreast of the result and hangs out with theorists, I think I'm qualified to say that I repeatedly come across theorists modeling some supposedly real world problem but getting it wrong in the essentials. Further, I think some programming knowledge can be of great help to a theorist.
I have been helped immensely by classes outside of my field; I'm glad that I chose classes that were challenging and I was genuinely interested in instead of doing what 'most everyone else did and taking the easiest classes that satisfied the requirements.
That said, I hate the way it's implemented -- a rigid partition of classes into 'theory', 'systems' and 'applications' with only 5-6 classes in each group. I don't think there's a need to automate the breadth requirement; rather, whether or not a student has completed the breadth requirement should be judged on a case-by-case basis depending on what the research area is. This is the way they evaluate the depth requirement, so it's not like they don't have the resources to do so; I don't know why breadth is trivialized.
I ended up having to take at least one theory class that was too easy for me and one systems class that didn't teach me very much.
I agree with anon 2, the BS degree is for breadth, the PhD degree is for depth. For a PhD, a student should only have to take courses that can directly help with research. What's the point of taking an OS or SW. Eng. class if it's just going to be forgotten after 4 years of research in something else? Phd programs at many schools get too carried away with course requirements. Students should dive into research right away and overloading students with too many requirements prevents that.
To anony 2:
I thought the breadth requirement in PhD program is taking some courses outside the theory area that have research flavor. e.g., a second course in OS that requires students to submit a small research paper.
To prev. anon:
Think again. If you are taking three or four breadth courses outside of your research area, do you really expect to make contributions to and submit small research papers in each of the four different research areas in one semester?
Usually these courses are intended to have some research flavor to them, but at most institutions there isn't much difference between the undergraduate and graduate version. For example, at Princeton, you can even take the undergraduate version to satisfy the requirement (and for many of them there is no graduate version). At other places it is the same as the undergraduate one, e.g. the Columbia graduate algorithms course is the same as the MIT undergraduate one. So an MIT undergrad who ends up doing a CS PhD at Princeton or Columbia will have to be bored to death again with the same courses he/she may have already taken.
I would second Arvind. Automated course requirements are a very very bad idea.
Michael, the way you state this, it seems that Harvard is trying to move to automated, course-partitioning type of system for breadth requirements. Why is this happening? Isn't the current breadth requirement system good enough. Was it the result of some junior faculty activism, or the Committee on Higher Degrees doesn't think it's doing an adequate job at verifying/enforcing the current breadth requirement?
The only reason to change the requirements would be to relieve the CHD of the burden of sifting through programs of study every month and to delegate the task to the secretary/computer at the Registrar's Office, who would only need to check a few boxes to verify that the requirements are met.
Also, why do you compare grad students to children who don't know what's good for them? When these people apply to the PhD program, you expect them to be mature, independent, and motivated. They should also have some vision of the field and should have developed some interests and know what they want to study so they can be matched with a potential adviser. Why change this assumption when it comes to breadth requirements? Isn't this a little counter-productive?
Anon 1 -- as you can see from Anon 4 (the 4th comment), there certainly are people who seriously believe that students should not have to take breadth requirements. Roughly, the two philosophies I'm aware of are:
1) As a computer science Ph.D., you are part of the broad computer science community, and you should actually know some computer science outside your specialty.
and
2) As a researcher, your goal is to produce the best research possible. All of your efforts should be going into your research; classes are useful only to the extent they have an (immediate) impact on your research.
There's nothing inconsistent with philosophy 2. I just disagree with it. I think long-term theoretical computer science needs to be connected to the rest of computer science; classes help accomplish that. Similarly, I think the systems side of computer science requires training in theory, mathematics, etc. Classes accomplish that. To me Philosophy 2 is like trying to build a star basketball team with a huge center but no guards or forwards to go with him. Some teams are successful that way, but most aren't, especially long term.
Several commenters have roughly said: "I agree there should be breadth requirements, but I don't like how they're done." A clear problem is that people enter CS with very different backgrounds. Some are CS majors that have already taken multiple graduate-level CS courses; some are entering from other fields and need to review undergraduate-level material. It is difficult if not impossible to please everyone.
I agree that breadth requirements should be reasonably flexible, and that graduate courses should be offered that fulfill the breadth requirements that are clearly different in nature than corresponding undergraduate courses; there is no sense in making people repeat courses at new institutions. But the implication in Anon 2's comment that for example an incoming theory student who has taken undergraduate OS, AI, PL, etc. knows enough and has nothing to gain from taking advanced classes in these fields strikes me as wrong, unless we expect theory people to work in isolation from the rest of CS.
Anon 7 asks:
Isn't the current breadth requirement system good enough.
For those who don't know (and why would you?), the Harvard breadth system for years has been you have to take at least 1 theory course and at least 1 systems course -- and "systems" and "theory" aren't even clearly defined for the purposes of the requirement. (There was a total requirement of 12 courses, 2 of which could be independent study.) No, I don't think that was good enough. Very broadly speaking, without regard to specific individuals, I think the result has been that we've been producing graduates who are not sufficiently broad in their training; I've indeed heard comments from faculty at other institutions who have brought up the point. In particular, we've been producing theory students who don't know enough computer science outside theory, and systems people who don't have enough theoretical/mathematical foundations.
Also, why do you compare grad students to children who don't know what's good for them? When these people apply to the PhD program, you expect them to be mature, independent, and motivated.
I think few entering graduate students have the maturity you suggest, and many do not know what's good for them professionally. (That's one of the reasons they get advisors.) Graduate school, almost by definition, is isolating; most students would happily toil away only on their research given the chance, and not explore outside their subspecialty, since the payoff for such exploration is distant and fuzzy while the research payoff is clear and immediate. One advantage of breadth requirements is to reduce such isolation in graduate school, and beyond. (That was certainly a benefit for me at Berkeley!)
At Harvard, under the current requirements, a substantial fraction (I'd guess a majority) of systems people skate through with 1 theory class, and the majority of theory people take little to no systems. That doesn't seem like a mature decision to me. In this respect, I think entering graduate students need some clear guidance, in the form of breadth requirements.
>> "...the Harvard breadth system for years has been you have to take at least 1 theory course and at least 1 systems course -- and "systems" and "theory" aren't even clearly defined for the purposes of the requirement"
As far as I remember this wasn't all there was to it. You were also required to have your courses in a major (8 courses) and a minor (4 courses) area. If you were a theory person, you'd take at most 8 in theory, and the other 4 would have to be in systems or something else (PL, AI, etc.) This should give sufficient breadth and coherence to your program.
Of course, whether this rule is enforced or not, is a completely different matter, but in principle, it sounds like a very good thing for a PhD program.
Maybe people at other institutions are just jealous/bitter that Harvard treats its students with dignity by giving them more freedom and not making them jump through arbitrary hoops.
Since I'm one of Michael's students, I feel it is my duty to at least try to say something provocative here.
I think it's important to note that Ph.D. students at Harvard tend to have only one or two different advisers over the course of their Ph.D. (That's what I've seen anyway, but I could be wrong.) Furthermore, every student must obtain their advisor's approval for courses every semester. Thus, it seems natural to leave the issue of breadth requirements to the advisor's discretion. If the department trusts it faculty to be good advisers to students, why is it necessary to formally bind the advisers' training methods?
Also, I worry that the department can easily fool itself into thinking that it is training Ph.D.'s with a broad and integrated view of the field, without actually doing so, simply by adding breadth requirements. Breadth requirements only force the students to take courses in many different areas. If the department wants students to have a broad outlook on the field, the courses themselves must teach that. (For example, Michael's Algorithms at the End of the Wire course is a great example of a class that teaches students to think across traditional sub-field boundaries.) I'm concerned that if the department adds breadth requirements, a typical graduate course instructor may view those requirements as absolving him or her of the responsibility to incorporate some "breadth material" into the class itself. If that happens, the students may eat their vegetables now, but they'll still hate them when they grow up!
Response to Comment 11: Yes, there is some nominal major/minor out of the 12 classes, but it's essentially a creative writing assignment. (Explain why these classes should be considered a consistent grouping...) It's not a breadth requirement.
I do agree that with 12 required classes, students are forced to get some sort of breadth at Harvard, just because our group is still sufficiently small that you can't get close to 12 classes in a single area. Part of the reason this is coming up, however, is because this requirement is being reduced to 10 classes.
Maybe people at other institutions are just jealous/bitter that Harvard treats its students with dignity by giving them more freedom and not making them jump through arbitrary hoops.
Oh, please. Requiring a student to take a class is not an insult to dignity. It's called training. And the whole point is it's not arbitrary; there's a clear rationale behind breadth. As for the idea that people at other institutions are jealous about how Harvard treats its students, I can only respond, hunh?
Adam, Adam, Adam... as usual, I completely disagree with 1/2 of what you say, and love the other 1/2. (Sounds like our research meetings! :) )
Do you recall at any time me telling you, as your advisor, that if you didn't take class X or Y that I would stop being your adviser and that you were on your own? I hope not. An adviser's leverage is limited and should be used carefully. One of the reasons to have these requirements is so that faculty (namely, me) don't have to argue with each and every incoming student about the importance of breadth as if it's a brand-new issue. The requirements (along with an explanation of them) will be all set up for us, ensuring a reasonable minimum. As an adviser, I want this. (And, quite frankly, for most students, it's a valuable protection from an adviser that wouldn't or wouldn't care.)
The rest of your comment is really quite interesting and insightful. (No surprise there, of course.) Perhaps the best way to implement a breadth requirement isn't saying "you, theorist, go take some operating systems" and vice versa, but creating courses that specifically bring people from different areas to work together and think across sub-field boundaries, preferably on research-level problems that need such a team approach. Done right, it builds up knowledge of other fields naturally, and shows how useful collaboration across subfields can be. Just thinking about things in that light suggests some possible changes for Algorithms at the End of the Wire for next time. We have had some courses that have worked like that at Harvard, but I hadn't thought about that in the context of breadth requirements. Provocative, indeed...
Michael seems to place too much confidence in the opinions of advisors.
Hi,
I think that breadth requirements (BDs), defined as requiring PhD students to take courses from several areas, are not a bad idea, but are not a terribly good idea either. Basically, I think that the main goals of such requirements can be better achieved in other ways, while avoiding negative side effects.
As I understand it, the main two goals of BDs are: (i) quality control (making sure that graduating students know enough to avoid embarrassment) and (ii) developing appreciation of other fields of CS. I believe that BDs do OK on (i) but not so well on (ii). In fact, they often have adverse effect on (ii). I had a nice sentence about possible side-effects of being force-fed broccoli, but I see that Adam scooped me here. Let me just say that I know enough theory students who hate programming after being forced to take system classes, to know that the issue is real.
What are the alternatives ? For quality control, one can require a broad set of exams that need to be passed over the first few years of a PhD program (with taking courses as a possible alternative). This takes care of different backgrounds, and is relatively painless compared to taking a full course. Also, this enables to test essential knowledge, as opposed to nitty-gritty details required from a student within the area.
As far appreciation is concerned, I believe that carrots work much better than sticks. For example, organizing a student retreat, perhaps of research nature but with lots of informal interactions, could do wonders on this front. At least for me, informal interactions were the key to understand and appreciate problems and issues in different areas.
Cheers,
Piotr
Hi Piotr. I'd add another benefit of breadth requirements -- getting to know people (not just ideas/techniques/research, which I'd lump into your appreciation benefit ii) outside your research area. This helps start up the "informal interactions" you refer to.
I think Adam and you have hit upon something worth pondering. When I think back to the breadth requirements I took, the main benefit wasn't the specific knowledge I got from the classes. It was the experience of meeting and working with (in study groups, class research projects, etc.) people outside of theory who I otherwise probably would have had minimal or no interaction with. It's the social network as much as (if not more) than the knowledge itself.
It still seems to me that classes are the best approach. But this gives context to the reasonable complaints about breadth requirements, which I think Adam highlighted. Just requiring classes isn't enough; the classes should be designed to bring people together and allow these connections to be built.
Well said. Although I still believe in superiority of pizza over courses in this regard.
Cheers ;)
Piotr
--> Requiring a student to take a class is not an insult to dignity. It's called training...
There actually are institutions that make you repeat your undergraduate education and prescribe fixed breadth courses regardless of your background. This I find insulting. It may be training, but it has a very low return on time investment. I hope Harvard doesn't turn into one of those institutions.
Again, I'm not against breadth in CS education. I'd just prefer a more laissez-faire approach.
Another idea (due to Greg, I guess) was to make the CS Colloquium talks mandatory for G-1s. Though, I think you should use more carrots than sticks there. Last time, the thing with the attendance sheet didn't quite work out, as one guy fell asleep on it, and then nobody was able to sign it. So, maybe if you give out brownie points that can be used to replace a required breadth course, then people would have more incentive to attend the talks :)
...I must stop posting here and get back to my CS-223 assignment.
Sounds like the real problem is that most student's undergraduate education does not include enough breadth. In my case, I can definitely say that my undergrad institution was overly focused on systems and offered very little theory. In addition, the few theory courses available were not mandatory, whereas every system course imaginiable was required to graduate.
Another point I haven't heard in this discussion is the GRE. Isn't that supposed to test our breadth? I remember having to study everything from AI to architecture to complexity theory just for that exam (made me wish I was taught these things in my undergrad classes).
I happen to think that the GRE is a terrible exam and I realize that many schools do not require it. But the point is that, as students, I believe we are made to jump through one too many hoops in the name of breadth.
To be clear, I agree with the many commenters that have said that a breadth requirement that says, "Take course X", without an escape clause for someone who has already taken X or has a course very like X in the past, is not well-designed.
However, that is different than the broader question of whether there should be a breadth requirement. I don't think it's too difficult to imagine a breadth requirement that avoids this implementation problem. (And we'll definitely try to avoid it at Harvard.)
While acknowledging good points, I should also acknowledge Adam's point that breadth should be incorporated where possible in every class, rather than just have breadth classes. I find that even just giving examples of where an algorithm is used in real life/in non-theory research is very useful to many students when presenting the algorithm; similarly, as a student, I appreciated when theoretical ideas came up in systems classes.
When you are on the job market (for either academia or industry) you are going to need breadth outside of theory in order to communicate with the majority of the people who will make the decisions about whether to hire you.
As a grad student it may be even more important to take advantage of the opportunity to learn about what is going on at the cutting edge of other research areas by talking research with other grad students and attending seminars and colloquia. Now getting something out of those seminars may very well require the background of a breadth course or two...
Another point I haven't heard in this discussion is the GRE. Isn't that supposed to test our breadth?
Not really. It is primarily focused on sophomore-junior level material. It tests people in the fall of their senior year before they have finished most of their senior-level courses so it is useless for real breadth.
For breadth, beyond just theory vs. systems, the requirement I whined about most **before** starting to fill it was Berkeley's "outside minor." As Michael probably recalls, this requirement forces students to take 8 credits worth (2-3 classes) of classes that are not in the computer science department. They are supposed to be related to your dissertation research and be graduate classes, as well.
In any case, I just started filling it this semester. I'm taking a class on "Applied Statistics" that covers observational studies, linear and probit regression, and other tools of the social/economic science trade. What makes this fun is that the professor is someone who's been around for years and knows where all the "bodies are buried" - we regularly critique real papers from social, political, and economic authors as part of the class and examine exactly what assumptions they make.
These tools are not common in computer science, but they have widespread use in "general life." Even if that were not the case, I am starting to see more areas in in computer security that rely on observational data, such as drawing conclusions from data breaches or trying to take a quantitative approach to bug-finding in software. While these areas also involve plenty of theory, especially cryptography, these other tools are showing up as well. I'd never have known how to deal with them without being "forced" into this class.
Post a Comment