Slashdot Mirror
Improving CS Education?
"I've been reading through the ACM SIGCSE proceedings and there are some studies I'd like to do in order to give myself some research training (we don't get much of that in our regular curriculum). We're also trying to organize peer mentoring and code clinics (but that brings up interesting ethical questions). What are other things students can do to improve the quality of their CS education?
My university's already doing some pretty cool things. One of my professors sneaked some patterns into an introductory course. The teachers are super-approachable. But it's just that I look at our curriculum and classes and teachers and I realize that there's so much more that can be done.
I want to know this:
Lots of people have probably already tried this before - improving the way CS is taught/learned. I want to know how it turned out or how it's turning out. Do you have any advice? Notes? Ideas? Know anyone I should talk to? I'm an insanely motivated geek here and I want to make sure I get the best CS education with the (rather limited) resources available. If it incidentally helps other people, then that would be a Really Good Thing. =)"
I am currently a TA for the 3rd year OS courses. Nobody, and I mean nobody comes to discuss the material until
This sort of thing only increases the apathy felt by both the students and profs towards each other. The reason for this can mostly be attributed to the mass influx of people taking CS over the last few years. Whenever a huge amount of people start taking something that is "in demand" in the world, you get many people who just want to coast through and get that piece of paper. They have no interest in learning - they just want the degree to go make some money.
Woz
I find this is a great way to learn. There's so much more to CS than what comes from a book or a tenured academic. It also can expose you to fields you never thought about before; for example, I took a coop that wound me up writing code for the huge servers that control your cable TV.
Being at a school where everyone is supposed to be doing the coop program makes it easy because the classes are scheduled around different majors' coop cycles and you don't have to wrry about your course sequences getting messed up because you were out working when the one class you needed was being offered.
But since most universities haven't caught on to this, I would suggest going out and trying to get a summer internship.
There's simply no substitute for real life experience.
Now, as for the academic side, I would give students the opportunity to wrk at their own pace whenever possible. Let them test out of classes if they're learning fine on their own. My school starts students our with a term of HTML, javascript, and "computing fundamentals", which was a complete waste of time for me. But they forced EVERYONE to take it. Luckily the next term was intro to C++ and you had the option of placing out of it and into Data Structures. Yummy stacks, tasty queues, delicious doubly-linked lists!.
Karma: Bored. (Thinking about resurrecting the "Anyone else is an imposter" joke.)
It was all theory. I once embarassed the faculty by pointing out publicly that it was possible to graduate with an AI specialization without ever seeing an AI program run, let alone writing one. Programming instruction was basically "here's the manual". I took a comparative programming languages course, which covered everything from COBOL to Prolog. It didn't actually involve writing and running programs. I got a good grounding in formal methods, though.
I did most of my programming on a Xerox Alto, chosen because few wanted to learn Mesa and use the obsolete things, so they were always available. (The Alto is the original GUI machine from Xerox PARC. Page-sized monochrome screen, mouse, Ethernet, file servers, laser printers, all built with 1970s technology.) Most students used the time-shared DEC-20 machines, accessed through dumb terminals. PCs really hadn't made an impact yet. There were a few original Macs around (no hard drives yet), and they were fun, but curiosities.
At times it was wierd. Exam questions like "does a rock have intentions?" (The classic "Why are manhole covers round" was from the 1974 Stanford Comprehensive Examination on Computer Science). I took "Dr. John's Mystery Hour" (McCarthy's AI seminar), and had good arguments. Met all the big names in '80s AI. But there was an "emperor has no clothes" feeling about the whole thing, because expert systems just didn't do much, and the whole field was stuck.
About a year after I finished, Stanford put CS under the engineering department. The expert systems crowd was pushed off to the side, and the curriculum became much more practical.
The best aspects of my school's CS department had formerly been its focus on the fundamentals of CS ...
Agreed! The languages I learned were helpful, yes, but it's what I learned how to do in those languages that ended up being far more important for me.
Fundamental classes like "Data Structures", "Algorithms" (both the coding of them and being able to assess their performance), and "Assembly" gave me key insights into the CONCEPTS of what I could bring to bear on any given problem.
Macros, subroutines, functions, pointers, queues and stacks and lists, are a means to an end. My success in programming has depended not so much on what FACTS I'd learned (e.g. arcane language syntax) but on how I could organize my thoughts and conceive appropriate levels of abstractions of the problem space.
Slightly OT, but I just remembered Donald Knuth's series of books on the Fundamentals of Computer Programming. There were some truly great things in those books, but I was forever getting distracted by his "MIX" programming language. (And I was reading it well before I could even conceive of writing my own interpreter.) My hangup was that I couldn't type in a program and PLAY WITH IT, to see what it REALLY did. Would that he had written his code in C or some other mainstream language! Do any /.'ers know if Knuth (or anyone else) ever translated his examples into another programming language?
One are where I think CS schools are really short-changing students is testing and debugging. While there are quite a few schools who educate their students well in design, coding, algorithm analysis, and math, I've yet to even hear of a CS curriculum that prepares any student in the areas of testing and debugging.
This is a shame because as we all know, a large portion of any software engineer's time is spent testing and debugging code.
I'm not talking about teaching how to use the specific features of debugger XYZ. I'm talking about the basic sleuthing skills needed to track down defects in your software. How to use basic concepts such as breakpoints, single-stepping through code, data watches, etc. - things that are common to all debuggers. How to systematically use deduction to narrow down where the defect is ocurring. How to do unit testing, and why you should do it. General approaches for dealing with bugs in multithreaded/multiprocessed programs. Learning to write code that supports your debugging efforts and going beyond just using printf() for tracking down defects.
Most CS schools tend to just throw students to the wolves when it comes to testing and debugging - if they teach anything, they may teach how to use a specific debugger's interface. They usually just assume the students will learn various debugging techniques on their own. Some of them do. A lot of them don't.
The ones who don't learn a large array of debugging techniques, when to use them, and why the should be used enter the workforce unprepared. They end up learning on the job, which can cause a lot of stress for them and their employers.
This is pure speculation, but this may be a factor leading to the high number of defects in software programs today. A lot of ink-fresh-on-their-degrees CS students just don't know how to test and debug their software! While I don't think its the only factor, it's something that is rarely discussed.
-vince
I took undergraduate classes from CS departments at two different universities over a period of twelve years (1980-92). (I kept getting jobs and stuff, okay? :-) I've also hired and managed dozens of programmers since then.
First I'll address this question as a student, then as an employer.
Unviersity "A" had a much lower ranking, and did not emphasize research. University "B" was much larger, much better funded, and was rated in the top ten state university CS programs.
I think that undergraduate programs in research-intensive fields such as computer science suffer tremendously when the priority is on research and not on teaching. The poster talks about approachability: this is WHY YOU ARE AT A UNIVERSITY, is so you can interact 1:1 with people who have made studying CS their lives. Spending time with someone whose research is a notch less exciting is infinitely preferable to spending NO TIME with someone whose fascinating research you might as well have just read a book about.
No big surprise, I learned a lot more stuff, both useful and interesting, at University "A" than at University "B". It was also a much more satisfying experience.
I wish that I hadn't been such a slacker in High School, as I hear great things about some of the very, very top programs, that combine the best of both worlds.
So: hire faculty who actually want to teach undergraduates, who will spend 1:1 (or 1:N for small values of N) time with them, and who are good communicators.
As an employer, I really like the increased attention in a number of universities to group projects and methodology. Not that what they teach is necessarily any good (same for theory & algorithms) but because it at least provides some underpinnings and may persuade students that thinking about these things is important.
It's extremely helpful to someone I'm interviewing if, upon graduation, they can sit down and demo a significant piece of software that they worked on with a team.
So: make sure your CS graduates have at least some meaningful group-based project where they create something they can show peopple.
Granted, this is just one school, but I think it's something you'll find in most universities. My students just did NOT want to learn the material. They would skip class and not visit me during office hours, and then complain that they didn't get enough help for the projects (I'm serious!). None of them showed any natural aptitude or curiosity whatsoever.
I was one of those students who generally knew more than the teaching assistants, since I had already been programming for ten years by the time I was a freshman (I miss my TRS-80 :-)). But when it was my turn to teach, I was amazed at the laziness and ineptitude I saw. I know my classmates back in college were never this bad, so I can only assume one of two things:
- I'm a really, really bad teacher and somehow I convinced the students they'd be better off not doing any work.
- My students really were less competent.
Reason #2 makes a lot more sense to me.So before you go trying to improve the CS curriculum, take a look and see if your classmates are worth it. You might be better off finding a good professor and volunteering to work with him on projects.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Someone else has mentioned it already, but I will reiterate: Java does not make a good language to start learning with in a Computer Science program.
I am less than a month away from finishing a four year Honours Computer Science program at the University of Western Ontario. When I started in 1997, we were taught Pascal for the first year course(s) and C for the second year, with C++, Java and others (including Scheme for a course) in third and fourth year, depending on the courses you took. After my first year, they switched to teaching Java off the bat and leaving C out of it (even for second year).
The first thing that profs noticed was how much more difficult it was to get students to understand basic algorithms and simple CompSci concepts (trees, linked lists, etc). The OO stuff just got in the way. Everyone was hung up on trying to figure out how to simple things because of the object stuff like members, function declaration, etc. was just confusing to wade through for students not familiar with the concepts. What ended up happening was profs had to start explaining OO in some minor way, which only confused them further.
Now, some of this can be attributed to growing pains associated with changing a program curriculum. However, I am also currently a teaching assistant (TA) for the third-year operating systems course and the caliber of student I am seeing from a programming perspective is quite lacklustre. The OS course is required, so there are a lot of people taking it and I get to mark about a third of the assignments handed in. I will tell you now that I am, generally, not impressed with what I see. The students are beating themselves up trying to grasp the concepts of C when coming from a world of Java (recall, these third-year students never had C) since Java hides so much from them.
What I'm getting at is that a good language to start with is not OO. Why? Because the concept of OO makes much more sense after you've been introduced to iterative/functional programming. The natural way to solve a problem is not with objects and obfuscation (i.e., good design), but to work out a solution and step through it a la iterative/functional programming. (more on this in a sec)
You want to avoid Java because it hides too much. Java is good after you have an understanding of what is happening in the machine. In fact, Java is a nice language after the fundamentals are known to you.
Now, about the above point of iterative/functional making more sense, naturally. Firstly, think about how you tend to solve problems: come up with an idea, walk through the steps to get it to work. Note that there is nothing about objects in there. A pseudo-code algorithm translates a lot easier to a C program than it does a Java program. Pseudo-code is what a lot of first/second year students see and it should not be a chore to implement it. Functional languages are natural for some (like me) and follow the principle of "when I'm done with this, I'll give it to you", which is also not too tough to grasp once introduced to it.
Bear in mind - I am not anti-OO. I just think it's a more advanced concept that should be saved for later. I design everything around the OO philosophy now in my programs (no matter what language). It is good. It is just not for students starting out.
What your definition of 'CS' is? I ask this in all seriousness. Computing science/Computer Science varies greatly. In some schools, the program is about programming and technical details, in others, it's more about algorithms and theory. One is about science, the other is more about engineering. Which is it you want?
Sysadmin/Web design/administrative programming or banging out simple apps is not computing science...
This presupposes that object-oriented is the be-all and end-all of programming. Which it's not.
...
My college (which has a CS program I'm pretty happy with, all in all) teaches all the first- and second-year courses in Java now. When I went through, it was C++, which really meant "C with a bit of object stuff thrown in." Now, I've noticed that a lot of the newer students do have a kind of gut-level grasp of OO concepts and practices that I had to struggle to attain
... but the fact is that the very first "real program" I wrote at my job was in C. Not C++, not Object C, damn sure not Java: straight C. And if I'd only been trained in Java at that point, I'd have been fucked. I've been in classes with people -- smart people, well-trained people -- who spend most of the semester trying to figure out what a pointer is, because Java hides those kinds of details; or it drives them nuts that they have to write this thing called "main" that's not in a class; or the concept of memory allocation and cleanup to prevent memory leaks is completely foreign. So they get to the junior level in CS and they think they know how to program, and they _do_, but there's a lot missing.
I like Java. I think it's a great language and I hope it continues to be used more widely. But neither Java itself nor OO programming in general is What Computer Science Is All About. There needs to be a mix of the high-level and low-level stuff. Evangelists for one or the other really annoy me.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
I can only describe the result as an unmitigated disaster. The best aspects of my school's CS department had formerly been its focus on the fundamentals of CS; lacking a huge, monied department, we were taught how things work rather than how the latest database software interfaced (and this had produced generations of very successful graduates.) This curriculum had evolved over a period of years; naturally, there were newer classes, and we weren't still coding in Fortran, but the curriculum had been tested and slowly improved over time. The spate of sudden 'improvements' wrought by these changes have irrevocably changed the nature of our department. Aside from the fact that we have a generation of majors who don't know what a pointer is, much more effort is expended teaching the latest software or OS, to the detriment of the fundamental cross-language, cross-OS education that I enjoyed. So the point of all of this is that sudden, untested changes in a CS cirriculum can cause as much harm as good.