comp sci students’ rage against the machine

One of the biggest things computer programmers like to complain about is that the code our colleagues write is all too often barely usable rubbish that runs only after a sacrifice to the compiler gods. Just check out a little group therapy session on the subject from a somewhat popular programmer blog to get an idea of how new programmers to a team can be deemed guilty of incompetence until begrudgingly proven innocent through a somewhat convoluted ring of tests which include coding exercises during interviews. Those are not fun since you face the prospect of being in the same room with someone who won’t give you a minute to think, jumping around with his own solutions to the point of almost literally bouncing off the wall, but you can understand why they would be popular with some companies. After all, they want to know if you’re any good with code, and it’s also very well known that computer science is a notoriously hard subject to teach. In fact, thanks to the above- linked programmer blog, Coding Horror, I’ve learned that there’s even an academic effort to predict who will actually be successful in a computer science curriculum, and what it shows is interesting to say the least.

First, a little background. Most academic programs are designed like curves. As you learn, you steadily gather steam and accelerate towards the acquisition of all the knowledge you need to function in the field. Comp sci programs are more like ladders where every new topic represents a new level of complexity and your goal is not so much to climb the curve, but to stay on the ladder as you’re yanked upwards. You start with simple and easy to follow assignment operations. Then you’re introduced to conditionals. Now you have to navigate logic and validate results. Then loops come in. Now you’ll have timing, cycles, and all sorts of wonderful errors that come as a result of placing the right operation into the wrong scope or being off by one, or bad conditionals in charge of running the loop’s logic. Then you have recursion, concurrency, and all sorts of other fun stuff which you have to wield to make a pile of circuits do your bidding. It can be done, but the semi-official estimates that get thrown around say that 30% to 60% of all students who take introductory comp sci courses either fail them or drop them. I’ve seen it myself. People who don’t have the patience and don’t understand just how dumb the machine in front of them is, get frustrated and overwhelmed when their programs don’t work.

Part of this is a lack of experience with the cryptic compiler errors and not being able to follow the paths within their programs, but a bigger part may be the students not being logically consistent. That consistency is what the aforementioned predictive test for computer science success tries to measure by asking students to get a sense for what the code is doing and by which rules the machine works both before a class began, and then three weeks into the class. About 44% of the students developed a consistent mental model of assignments in programming languages (giving values to variables) and it’s those students who tended to be much more successful with a 78% pass rate, vs. their logically inconsistent classmates’ 48%. The implication is that one has to have a certain mindset to even start working with programming and at the core of it is the ability to find, define, and follow very consistent rules. It’s fine if that first attempt at rule definition is wrong, that could easily be fixed with more instruction and practice. The most important thing is that the students understand that the rules exist and that they will not change from one program to another. Should they fail to do that, they won’t be able to follow their own code and figure out what went wrong when a bug pops up.

Now, considering that there’s a problem with getting students past their tentative steps into introductory comp sci classes, here’s another thought which involves CMU’s decision to bizarrely mutate their curriculum. The programmers and computer scientists cheering the changes on the academics’ blog explaining the decision numbered plenty of those who complained that teaching object-oriented languages like C++ and Java to first year students was too hard and forces these students to also start thinking about object and system design, something I mentioned in my original post on the subject. So what if, and this is just speculation borne out of my less than trusting nature, the decision to make object-oriented languages optional at CMU had more to do with teaching students assignments, sequences, concurrency, and recursion, and trying to ever so slightly let the bar slip lower while cloaking the effort in language pooh-poohing the OO paradigm and its recently minted hybrid implementations as being too clunky for the modern computer scientist? If that’s really the case, this is an even greater disservice to students than exasperated me across two posts, depriving them of very relevant skills, setting them up for professional failure and pushing them into a rather bleak future. Hopefully, this is not the case and I’m just overreaching because I would really, really hate to be right about this…