CS Education: The Deep End of the Pool

The Software Engineering part is done badly because the slope is too abrupt and ends too quickly. The Java-based curriculum invariably ends up teaching OOP concepts within weeks (if not to start with) to someone with no concept of program flow, variables and functions. From my experience as a TA, I'd say 90% of students who haven't programmed before end up utterly confused about the order of execution of the various bits of code in a simple Java program with 3-4 classes.

The few people who survive this abrupt slope with an intact desire to learn more CompSci find that the slope ends too quickly. There is no further discussion of issues that are crucial for industrial Software Engineering: debugging techniques, version control, code repositories. Instead, the sophomore abruptly has to choose between a rock and a hard place: either a course in C, leading to an honours thesis in Systems; or some math-y courses leading to Theory.

The C course is a frustrating experience, requiring the student to un-learn a lot of the concepts learned in the Java intro courses and to learn instead to tread carefully on a landscape suddenly filled with inexplicable bugs. But this is actually the more accessible course, as the theory courses require a mathematical ability that the majority of potential CS majors simply don't have (or even had any inkling that it was required).

I think any intro course should begin with an explanation of very simple architecture concepts (program counter, memory, hard disk) and spend a good amount of time drilling the basic concepts (variables, loops, function parameters, function return values) and basic debugging techniques. In the second half of the semester, while the students work on a large project to practice these skills, spend the lectures to give them a broad survey of the major: architecture, algorithms, programming languages, OS, theory of computation.

College is also set up for majors to be chosen without any understanding of those particular areas of study in high-school.

So, yes, your intro class should be for kids with no former compsci exposure, just like every other major your college offers. You then allow AP compsci students to waive some of the intro classes.

Of course, the real question is why should the kid pay money to hear this guy when, if the kid already has an interest and some knowledge of CS, learn with MIT open courseware and iTunes University?

Do you think CS professors are the best at presenting/explaining the material? I believe it depends on the professor.

Music is much more difficult than compsci. In addition to the mental, you have to hear/listen, and possess excellent muscle coordination.

1. The commenters seem to imply that java is probably not the most appropriate language for cs1, where syntax considerations often overpower practical concerns.

2. Bright students that 'get it' are not the baseline, they're the exception. It's the other, intro level students that the class/recitation/curriculum should be catered towards.

3. Many (if not all) fields of study 'get hard' in college (i.e. physics, pure math, etc). The problem in this case is one of students being improperly tracked (i.e. curriculum failure).

4. Intro CS courses vary wildly in expectations and ideology. This set of courses seems to focus on 'practical' considerations that are probably better suited to a separate 'software design' course. It's possible that this 'survey' is actually too broad and not focused enough.

5. The music analogy is cute, but fails to consider that intro cs courses typically only succeed (and attempt) in getting students expressive (i.e. jibbering toddler) rather than elegantly fluent. This is why many post-cs1 students generally can solve problems using their new toolkit, but often solve them naively (it's like a toddler that says the wackiest things)

6. Confusing "programming ability" with "computer science" is problematic overall, i don't know that anyone would want to spend four semesters "programming" but i've know a bunch of people that enjoy the theory=>pracitce :: state machines => regular expression 1-2 punch. You can do quite a bit of fascinating cs in a logic/philosophy class as well as in a complexity theory class without ever touching a computer. I know, heresy, but it's true.

I think finally, the issue here is confusing "computer science" with "software engineering." I think java's a great language for software engineering, it's got all the stuff builtin to teach those concepts, but as a language for sketching, i'd probably use python.

People often make this mistake in teaching javascript because built in is the ability to manipulate the dom which, while eminently useful, is also basically a whole separate language/paradigm mess than 'javascript neat.'

And this is a hard question to be confronted with in any case: what are you teaching and why are you teaching it? Neither of those seem to be fully addressed in the author's description of cs1/2.

To get competent in programming seems to take about two years. To teach computer science/software engineering concepts in any form of depth (besides a simple, 'yo, here's X, here are 5 datapoints about X for the test', requires knowing something about programming. That means that to seriously teach data structures, algorithms, software engineering, computer organization/architecture, programming languages, all carries with it the pre-req of years of work. So students have massive issues!

I believe that it is indubitable that the best way forward is to have an optional programming track added to high school education. But we've all heard the high school programing-teacher horror stories. Add to that the idiocies perpetrated in the name of 'students must know computers' (Oh, look, Little Bobby Can Use Word). So that's probably not realistic.

What might be realistic is sketching out a college curriculum that uses a step function in terms of winnowing out students. E.g., the spring courses are hard, the fall courses are easy. That would help move things along better. Yet, the fundamental issue is that a 4-year college degree seems to be insufficient to prepare students from knowing zilch to being hireable, without some pretty heavy investment on the student's part.

Outside of software and music, I have never heard of this scenario for any college degree. I hope that I am wrong, that these two majors are not unusual.

CS 2 should not be dealing with inheritance, polymorphism, or object-oriented design. These subjects are advanced not because they are difficult, but because they are useful abstractions that help solve large-scale organizational problems that students have never faced. They are important aspects of programming discipline but are useless if you don't understand the underlying tools to begin with.

Instead of trying to teach design and high-level abstractions in CS 2, the focus should be on how systems actually work. You should be removing layers of abstraction rather than adding them. Programmers make computers work using compilers(and interpreters), operating systems, and networks. So begin teaching students the fundamental knowledge needed to use those tools effectively.

Students need to understand syntax. Teach regular expressions and context-free grammars. There is no need to go as deep as theory of computation or languages or compiler design, but students should be able to recognize how a language's specification matches their own code, so they can correct errors from principle rather than by trial-and-error.)

Students need to understand how to use libraries. They should understand how they can obtain and use new ones in their own code.

Students need to understand how to use the interpreters and compilers that translate their programs into machine code. They should know how to build and configure several different development environments given a standard windows, linux, or mac box.

Students should know the basics of memory and IO. There doesn't need to be a dogmatic focus on optimizing for performance (there will be plenty of that later I am sure), but the constraints need to be as clear as possible.

Consider teaching OSI layers or the HTTP protocol rather than inheritance.

Data structures and basic functional abstractions are important fundamentals, too. If they aren't covered in CS 1, it makes sense to prioritize them in CS 2.

A programmer who doesn't know object-oriented design and polymorphism might write ugly code. A programmer who doesn't understand his target environment is going to write broken code. A programmer who doesn't know how to use his compiler isn't going to write any code. If the goal is preparing a student to be an effective computer scientist, the first step is imparting fundamental tools of the trade.

I was a TA for CS 101 and 102 for a couple of years. I think I taught almost no one to program. The result (in terms of actual programming) would've been the same, had I just given everyone software and books and said, "have at it!"

As it was, I was just putting people through the motions of being in a college course.

I'd like to suggest that maybe we should consider two completely different things. Just as there is a huge different between someone who can play a musical instrument, and someone who is well versed in musical theory, there is also a huge difference between a _programmer_ and a _computer_ _scientist_.

You can learn how paging in a virtual memory system works, and how a garbage collector works, without necessarily being able to code up a program that plays "twenty questions". And similarly, someone be able to code up all sorts of interesting programs, without necessarily understanding "big O" notation. Their programs might not be the most efficient in the world, but it's certainly possible to do all sort of programming without being exposed to the formalism that comes from taking CS classes --- that's what most high school students who taught themselves how to write Basic, or Pascal or C programs generally have done.

If you decouple the two, then you could imagine having a series of classes which are "programming labs", for which you could test out of the first 1 or 2, and which would be mostly about the skill of programming, and different series of classes that are about _computer_ _science_, and which don't necessarily require that much programming expertise.

In addition, at my university I feel like the majority of students who are in the upper level classes with me (CS majors past their second year) got credit for the intro courses in high school. The way I interpret this is, it is a lot more likely for students to continue study CS past the first year if they take high school CS, which is a longer slower moving intro CS course.

I think the intro courses need to be much easier. They are discouraging too many smart students!

Now we get to the part where I sound like an asshole:

I'm not convinced that there is a good argument for teaching the "normal" students. In math, we don't go out of our way to attract people that don't like or aren't good at math. In fact, they usually come to us and say "I'm terrible at math" or "I hate math" and we politely help them with the calculus they need to pass to graduate and send them on their way. Math seems to have accepted its position as a "higher discipline" and while there are those that lament its inaccessibility to the layman, they don't lament that there are so few laymen in class---they just want to be able to show pretty girls at the bar pictures of the beautiful structures they play with all day.

So why can't CS just accept that some people just "don't get" the discipline? It is really hard, you have have a really amazingly large amount of domain knowledge, going all the way up from the metal to the OS and libraries, plus you have to know all this discrete math, understand algorithms of many flavors from many sub-disciplines, and recall it all at once so you can make tradeoffs. A good deal of the theory comes damn close to the math people are so open about being terrible at.

The way computer science works, you get students that love the math and can handle the programming, that stick with it long enough to excel with the programming too, and do great. Then, you get students that love the programming and can handle the math, same thing happens. But right now, you also get the students that hate the math and admit it, and hate the programming but don't feel like they can admit it, so they stick with it until they either drop to Information Science or something, or they graduate and become another one of those programmers that recruiters are always implicitly complaining about when they say "it's so hard to find good programmers".

In math, students who aren't excellent and passionate generally don't even try, or don't continue. That's because all they can do with a bachelor's in math is go to grad school, where they have to be good. In CS, it seems like we think we can send off crappy graduates and, well, if they can't go to grad school, at least they can get jobs programming. Well, wake up. Industry doesn't want them either. Better to help these kids realize they don't like the field and find something they do like, than let them continue busting their asses believing they'll get their dream job just for graduating.

This doesn't mean we should turn people away after the first semester. I like this model: let the kids that are really good skip the intro class(es), and make the intro classes intro classes. This means taking care to think about just how little background you can assume (in particular, assume no math skills, because otherwise they'd probably be math majors). Let this sequence take a year or so if necessary. Redesign the upper-division curriculum to both leave time for this extra intro stuff, and to take advantage of it: don't waste space with "upper-division" classes that are really just there for the crappy students to take so they can have something to do, because you won't have those students anymore. That way, you still be able to serve the average students, but they'll be nurtured at the right pace, making up for the lack of education in high school, until they're ready (or realize it's not for them), which seems to me like a much better model than "sink-or-swim CS 1".

Julliard can afford to be as competitive as it is because the input-output function is a strong bottleneck: You don't need many graduates (for every open violin position in European orchestras, there are roughly 800 graduates), there are plenty of kids who've been playing since the age of 6, so entry is competitive and standards are very high.

Programming? Very different situation. The market demands large numbers of CS grads, and (what the author so condescendingly calls) "natural programmers" are fairly rare. So standards suffer.

The right question is, what's the proper place to start?

First, set the bar high enough in universities/colleges that only people who have that magical natural programmer aptitude and lots of spare time programming experience can make it. Limit investing the precious university resources to that level and above only. This prevents academic CS education from being dragged down and dumbed down because they have to shovel nearly anyone who got accepted through the system.

Then, supplement those who wish to become the CS students but who lack the necessary mind and experience with training courses that begin from zero. These can be private courses or public education available in some other, non-academic institution. If it turns out that, given some experience, some of the trainees actually have the right aptitude then they can collect more experience and eventually apply to the university/college like the rest of the hackers.

http://software-carpentry.org/about/three-minute-pitch/

If their pitch is to be believed, passing this course should provide enough programming competence to begin a CS curriculum.

This worked wonders for me, Python, I mean. I was one of those students who had no programming language knowledge prior to my CS1 class, which was based on the C programming language. I was not that bad at things like maths or physics, but I couldn't for the life of me understand how could one write "i++;" or "for(i=0;i < n; i++)", they didn't make any sense to me. I barely, barely passed CS1, but CS2 I failed like a pro. I didn't even try to pass it for a couple of semesters, until I learned Python (by myself) and then everything was smooth and easy. The professor actually congratulated me for my A grade.

I think some of the comments about simpler syntax (moving from Java to Python, for example) are in the right direction, but not far enough down the path. I think the fundamental problem is that of generalization. Someone may intuitively understand how to do a specific task themselves, but how do you take that idea and make it generic enough to be useful?

Programming is communication about how to solve a problem. So let’s skip the whole computer language implementation detail. Don’t start with computers. Start with problem solving. Make the implementation language a list of steps to be performed. Split off people into pairs – have them write down descriptions of how to solve some problem, and then have their partner act it out. You get to talk through parse/compiler errors instead of having to translate something that only really makes sense when you’ve seen it a couple hundred times.

Once people are comfortable with taking a problem and producing steps to solve it, picking up a syntax to say the things they’re already comfortable talking about seems like a much smaller step.

Long term, we’ve got to start doing this earlier. Grade school. Hell, preschool. Why should analytic problem solving be something you’ve got to wait to learn?

-----

Other thoughts while I'm here:

We need to get over the math obsession. Yes, it's important. Yes, deep computer science has lots of math. But you don't teach someone to love music by first trying to get them to understand music theory. Let's cut out the parts that aren't essential. Let's take a lesson from unit testing culture - start with the smallest thing that will work. Big O isn't one of those things. Once people can come up with simple algorithms on their own (remember how great those first little wins felt?), it's a great opportunity to lead into complexity theory. But if you do it too early you'll just scare them off.

Maybe I'm in the minority, but I think everyone has the ability to learn basic programming and the analytic skills that go with it. It doesn't have to be hard. But we've got to start with baby steps.

By the end of your freshman year, you had taken:

CS1005 (which was basically learning C)

CS2005 (Object-oriented programming)

CS2135 (Scheme)

CS2137 (Prolog)

More importantly, when you were taking 2137, you had pretty much forgotten everything you learned in 2135 (as you're basically just perpetually cramming).

Perhaps there could be a special program in which a student spent 1 year intensively studying programming between high school and college. That might be able to bring motivated students into readiness.

I don't think there's any reason you can't teach an interested third grader to program.

The first is the "number of requirements" problem. At most colleges, there is some limit as to how many courses can be required for the major—a practical limit if not an explicit formally-imposed one. A lot has been forced downward into the standard two-course intro sequence,[0] and this has "worked" because some of the students are either brilliant or have had good preparation in high school, where that "two-semester sequence" can be spread out over multiple years, and in many cases is preceded by one or more years of "pre-AP" computer science courses. But the downward migration of material has meant that what we now consider to be a standard computer science degree includes a lot of material, and if we add some sort of college equivalent to the pre-AP courses, we can either add them as explicit major requirements (that some students can place out of), which means removing material from the other end of the major, or leave them as bypassable prerequisites, implicit requirements that mostly serve to discourage students without a high school CS background from taking CS.

The second big problem is the staffing issue. As a practical matter, every course that might get added at the pre-CS1 level will be viewed as an "extra" that has to be staffed, and either takes away from staffing that could be provided to upper-level courses—earning the ire of at least some in the department—or else requires additional hires and thus administration approval. If it is played as "we need this as an additional prerequisite to CS1", it will find an administrative reaction of, "how did you get by for the last few decades, then?" If it is played as "we need this to get some students up to speed before taking CS1", it will find an administrative reaction of, "why are you proposing to teach remedial courses at the college level?" There is also likely to be an uphill battle to even fill the course, especially if you can't get the college to let it fulfill some general education requirement, and then you have the added problem of trying to justify offering a course that is chronically underenrolled.

Adding to the campus-politics tangle of the whole thing, CS is often viewed as too mathy and/or vocational training and therefore viewed with distrust by members of some other departments, making it even more difficult (in some cases) to argue for needed changes.

So, it's a hard problem. Good analysis, though.

[0] Which isn't actually anything like standard, actually, but we still talk about it as if it is. It's at least the case that formerly-advanced topics are now widely present in the first few courses.

Both my local university and junior college use C++ as the introductory language, which I believe makes the high learning curve even worse. (I cheated my way through the introductory course by teaching myself C and arguing that the programs compiled and ran in a C++ compiler, and taught myself C++ later when I was better grounded in the fundamentals.) If it were up to me, the introductory class would be half in Python to teach the fundamental concepts of 'if' and 'while', and half in straight C to teach the low-level concepts of compilation, data structures, and memory management, and the fact that you can implement the same algorithm in different languages. I would wait until a second course to introduce C++ and its inheritance, templates, and operator overloading.