As this semester draws to a close, I thought it would be appropriate to share some of the notes, some written and others floating around in wetware, that I have accumulated over the course of the semester concerning my first experience with formal Computer Science classes. These classes included an Introduction to Comp. Sci., an overview of C/C++, and a course on Discrete Math. Most of my thoughts concern the latter two. This post will be part I of these notes, where I will discuss my experience in the Program Development (CSCI 241) C++ programming class. Please bear with me as I brainstorm out loud.

[Begin lengthy intro. Feel free to skip if you're interested in the bullet points.]

The background to this unofficial series starts with an admission that towards the beginning of the semester, being a fairly self-motivated programmer accustomed to reading books, articles, documentation, and other self-help resources, I had a fair bit of consternation over whether forking over such a high dollar amount required for accumulating technical skills would yield a sensible ROI; technical skills that, frankly, I have pursued independently up until this point. Along with this, sometimes I wonder what advantages a graduated “white-collar” Comp. Sci. graduate has over a self-trained, so-called “blue-collar” programmer, but that’s an topic for another time.  (Please understand, I’m talking about practical skills and not arguing over the necessity of a diploma here.)

Parenthetically, it must be mentioned that this decision to delay my CS classes until my Junior year was not by choice but rather because I attended a Community College during the first two years with a scarce curriculum in Comp. Sci. Having been encouraged by a former professor, mentor, and good friend to make the most of my education by recording my experience so far, this post will serve as a sort of journal entry, marking the beginning of a two-year journey towards finishing my Bachelor’s in Computer Science, where I will record a few observations that I may end up retracting later on. Disclaimer over.

[End lengthy intro.]

I mentioned in the last post that I’m reading a book called Coders at Work by Peter Seibel. Sunday evening I read chapter 8, in which Mr. Seibel interviews Peter Norvig, the Director of Research at Google. I particularly enjoyed this article because in it, Norvig and Seibel discuss the interview process used by Google and what the company looks for when hiring new programmers. One of the questions that came up is what the purpose of using infamous trick questions (a practice that Google is known while interviewing candidates). I am paraphrasing Mr. Norvig’s response to Seibel (in reference to the paragraph at the bottom of page 320), but he essentially makes the point that it’s not as important that you know how to solve every type of problem, but rather that you have a well-developed approach to solving the problem. To put it a different way, it’s not necessarily the breadth of your knowledge, but rather the maturity of your thinking process that is of value here. Knowing the “tricks” helps, but that likely won’t be of aid when you need to apply a more broad problem-solving approach to a similar, but sufficiently different problem.

With this maxim in mind, I’d like to evaluate CSCI 241 at my institution and mention a few ideas that came up during those long hours of class.

My first grievance is with contrived examples. These are indeed useful for getting a novice programmer’s feet off the ground, but they are not what hold our interest nor motivate us to stay involved in the material. I want to know, how does this teach me to write code that matters? Do I really care about implementing a set of Dog/Mammal classes to (re)learn inheritence? After all, I dare say what drew most of us to computer science in the first place was developing a solution to a problem that was of personal interest.

So how can we fix this?

Or, how do we design a computer science curriculum in a way such that classes which teach programming languages present a greater advantage than, say, students picking up a few books and teaching themselves? An abstract solution is to teach “meta-programming” concepts in which things such as

• the importance of writing efficient, but readable code,
• the importance of reading others’ code,
• the importance of code ownership and responsibility, and
• the important skill of being able to find and use resources to further one’s own education on the job.

I am firmly convinced that none of these are possible unless there is personal interest on the part of the student in the applications that the he or she is writing. So, perhaps some more concrete possible solutions include:

• Have each individual in the class checkout the source code of an open-source project of their choice, examine, debug, modify, and do whatever it takes to understand its overall working.
• For a final project assignment, have each student write technical documentation based upon their understanding of a module or two in the open-source project.
• Is the student already involved in an open-source project? Why not, as a professor, support it?
• Provide homework assignments of tiered difficulty so that students of all levels can be challenged to expand their knowledge of the language. How can you optimize the code in the assignment? Do you understand the concepts of a LinkedList? Great, rewrite it using templates (and so on).
• While we’re at it, let’s leave the PowerPoint slides and their near-useless pseudo-code at home and crack open Visual Studio in class.

One final point to make. If all students, no matter their prior skill level, are going to be required to jump through the hoops and take all the introductory classes to get a degree, then an effort should be made to adapt the assignments so that every student is challenged by the right degree.

After all, we should be teaching a mindset, not a language. Old languages go out of date, and new ones are invented, but the process of learning them does not change.