Home Math Teaching About Me

Thoughts on teaching PIC 10A

Date Written: December 21, 2023; Last Modified: December 21, 2023

My first quarter of teaching has just ended, and I have some distribution of thoughts about how the quarter went. I guess teaching came with a lot of surprises, some good and some bad.

If you are a former student or the instructor of the course, please do not take any of these comments personally — this is primarily a place for me to share my thoughts in a place I can come back to. I would like to look back at these comments to guide my own teaching in the future.

Did the students learn how to code?

I think to some extent, yes, the students did learn how to produce rudimentary code. However, I think the course put a disproportionate amount of emphasis on certain elements of code that aren’t relevant to the students in the class, most (maybe all?) of whom do not study computer science! As such, I honestly don’t think their grade reflects their ability to code in a non-sterile out-of-the-classroom setting (e.g. performing data analysis for psychology research or creating weather simulations).

In fact, I don’t think this is necessarily true for the coding class I happened to take. As someone who has taken AP Computer Science, has taken collegiate CS courses, and has tutored for such courses as well, I think this is a broad problem with how coding courses are administered in general.

Here are some specific things I take issue with:

• Timed coding exams do not reflect coding ability.
  While asking students to predict output, catch errors, and interpret compiler messages are all good ways to test for understanding and knowledge, asking students to produce code in real-time does not at all involve skills that are necessary to produce “actual” code. The problems are often so simple that there’s no large-scale algorithmic thinking that takes place, and there’s no opportunity to display good design choices. Even stronger students make mistakes, and being able to understand the errors in your code and iteratively improve it are unavoidable in practise. How could timed exams measure those abilities?
• Homework assignments are sometimes difficult for the wrong reasons.
  These are assignments with disturbingly long and complicated specifications, yet end up being somewhat simple once everything has been parsed. The majority of the difficulty arises from how tedious the output and the sheer number of different scenarios the program must handle, while the logic and design remain straightforward (albeit tedious). We had one such assignment this quarter, and less than 10% of the entire class (~80 students) successfully completed it. It’s so easy to make a small logical error or minor misunderstanding of the specs, and the convoluted nature of these assignments make debugging horribly difficult.
• Documentation and formatting were ignored.
  Some people do enforce formatting guidelines when they teach coding, but this was not one such class. A small minority of students actually documented their code; often, indentation was inconsistent and naming conventions were abhorrent. I saw one-letter variable names, mixed snake case and camel case, and 150-character-plus lines of code. It’s very frustrating for me when I explain to my students that descriptive (yet concise) names are important, only for the instructor to provide starter code (for a homework assignment) that goes against all reasonable naming conventions.

I think the first and third are the most important, as it’s precisely those (missing) skills that we should be emphasising. These students want to learn code to pad their resumes apply those skills to their own fields of study, where they’ll encounter situations that demand good design principles, large-scale algorithmic thinking and code organisation, and maintainable coding habits! I feel awful in that this course missed all of those points, in my opinion.

I’m not sure if/when I’ll be teaching anything coding-related in the future. If I do, I’m hoping I’ll have more control over the class, and I’d like to address the above points. To be totally fair to the people already teaching code, these are difficult elements to address, and I don’t know if I have a good solution. Here is an idea I had, which I shall shamelessly espouse

Emphasise debugging and design in project/assignments! An idea I had was to assign a normal project, full with expected outputs and whatnot, but instead of asking students to write their own code, one could provide the students with buggy, poorly designed, and poorly documented code. The assignment would then be to clean up the code and make it work, which may involve refactoring, debugging, etc. The intention is to eliminate the “tedious” elements of implementing something while forcing students to think about design choices and the underlying logic.

Anyways, that’s the primary pedagogical problem plaguing prospective programmers.

The Students

To those students that are reading this, you were very great this quarter! Thank you all for the kind words and feedback throughout the quarter. I have some good things and some bad things (uhh…constructive criticism) to say about you, all of which came as a surprise to me.

Let’s start with some good things:

• Attendance
  So many people showed up to discussion sections throughout the quarter! This is a huge surprise to me, since I attended my own discussions very sparsely as a student at UCLA.
• Effort outside the classroom
  It’s good to see some regular faces in office hours! Most of all, though, it’s really nice to see people ask questions about the additional practise material I put out. I think a vast minority of students attempted them, and those that did definitely surprised me.

Oh yeah, you guys have good hygeine too. Thank you for showering consistently (as far as I could tell). Now for some less good things:

• Read the syllabus, please. And course announcements.
  I’ve had to deal with an impressive number of you guys asking me about things that are in the syllabus or stated in announcements on the course website! As an (almost) emotionally mature human being, I am able to suppress the bubbling rage and answer your question anyways. I hope you know full well that the wheel of karmic retribution spares nobody.

Oh, I guess that’s the only less good thing. There’s some stuff that sits in the middle, which are simultaneously understandable from a student’s perspective but still frustrating from an instructor’s perspective.

• Attending lecture
  This one’s tough because I also habitually skipped classes that I didn’t like. On one hand, I think a lot of students had good reasons for skipping lecture — the professor’s lecture style may be difficult for some (to put it lightly), and the content may seem meaningless or uninteresting to others. On the other hand, many students complained about course difficulty and expressed their frustrations with certain elements of how the course was administered. Some of this was very fair and justified, but sometimes the fix was just…go to lecture.
• Debugging
  This ties into what I mentioned in the first section of this post. With the last (and by far the most difficult) homework assignment, a significant number of students showed up to office hours or reached out over email to ask for help with debugging. This is perfectly fair; after all, they’re shelling out thousands of dollars, and this is a part of my job description. On the other hand, being given a few hundred lines of code alongside the email body “Can you help me figure out what’s wrong?” makes an excruciating task. This is made worse by inconsistent formatting, strange naming conventions, and limited documentation. This is ultimately a failure on our part, and I can’t blame the students for not understanding how difficult this process is. But damn, that was easily the worst part of TA’ing.

Bureaucracy and the Chain of Command

There were a lot of disagreeable administrative policies enacted throughout the course. These could have been changed very, very easily, but there were a lot of bureaucratic and systemic roadblocks, alongside the professor’s unwillingness to make certain changes.

• Choice of IDE
  The course specifies that everybody must use VSCode to complete the homework assignments. The course recommended that Mac users use XCode; students were expected to use the university computer lab to ensure their code compiled and ran properly in VSCode. This is terrible because it’s very difficult for any TA to be familiar with both VSCode and XCode — how many people have experience developing code in both IDEs? Moreover, I use Linux, and neither IDE is available to me. Why are we doing all of this instead of using a cross-platform IDE and compiler to ensure consistency across operating systems?
• The Midterm
  The midterm consisted of 18 multiple choice questions. You got 4 points for a correct answer, 0 points for a blank answer, and -1 point for an incorrect answer. What? This heavily punishes students that are already struggling, and it punishes students for making minor mistakes more than it punishes students for not knowing the answer to begin with. There was no coding on that exam either, so a lot of classtime which was spent on problem-solving and code-writing was irrelevant for this exam. The TAs couldn’t do anything about this since we didn’t even know the format of the exam until they were being handed out.
• The Final
  Oh, you thought the midterm was bad. The final was a 30-page booklet of 18 problems. Students scored an average of about 20%. This was due to a mix of unrealistic length and difficulty, limited practise with the types of problems asked, and very limited partial credit. Moreover, the partial credit was awarded rather randomly, and some perfectly reasonable answers got 0 points because they didn’t match the professor’s expectations. The professor did not accept revisions to the grading scheme.
• Departmental Intervention
  Near the beginning of the quarter, certain administrative concerns were brought to the department. They handled it very well, and some of the more problematic issues were promptly remedied. However, I was told that historically, bad professors went unpunished, and even with the egregious isuses brought up at first, they could not force the professors to change the way they taught their class. I’m glad that things (partially) worked out this quarter, but it’s worrying that there’s so little I can do about certain things.
• Attitude
  I have to remark that the professor had a somewhat peculiar attitude towards his students. While we were grading exams, he expressed the feeling that the students were lazy and unmotivated, citing how several exam problems were covered extensively in lecture (in which there was low attendance) while another was an exact copy of a homework problem (many students got that one wrong). Moreover, he said that the students had “never seen a hard exam”. Perhaps this is more a reflection of his teaching more than a reflection of the students.

Final Remarks and Further Reading

At the end of the day, the biggest thing that’s on my mind is: success and failure in this course aren’t anywhere close to indicating ability with C++. I think this is centrally an issue of how the course content was structured and the administrative decisions around grading.

But beyond just this class, it appears I’m not alone in this sentiment. Philip Greenspun, a computer scientist and educator (among other things), described several similar issues with undergraduate CS. Although he provides a perspective on computer science majors and their courses, which are geared towards industries like software engineering, a core point is reinforced: these classes focus all too much on a small subset of necessary skills that are needed in practise. Another article reiterates the mismatch between what’s taught in classes and what’s necessary in an actual job.

In addition, there some supply-and-demand effects that influence the quality of educator that some less motivated students (which are quite common in programming, I feel) receive. I’m not sure how qualified this quarter’s instructor was — his GitHub page (intentionally not linked) has very little C++ code on it, and half of it was written by ChatGPT. The other half had questionable naming conventions and limited documentation. Make of that what you will. But anyways, there’s a whole rabbit hole on CS education and teaching programming that I don’t want to jump into.

Not all programming teachers are awful! I have heard great things about several PIC professors at an anecdotal level. In any case, I do think this quarter has revealed some seemingly prevalent problems that many instructors don’t consider.