(Programming Induced) Fear and Loathing in Lost Students

Matthew Joseph Leineweber, Biomedical Engineering, San Jose State University

(Programming-Induced) Fear and Loathing in Lost Students
As an undergraduate student in mechanical engineering, I developed a theory: as a general rule, mechanical engineers all hate programming and are terrible at it. Albeit this theory was based on a relatively small sample size of approximately 30-40 mechanical engineering students, all in the same class at the same university, but intensity of their loathing seemed to count for more. While we recognized the importance of programming and computation, and saw how it drove calculators, modeling tools, and test equipment we used in other courses, we considered the programming itself something best left to the electrical engineers and computer scientists. Eventually graduate school proved there are many exceptions to my theory (although many computer scientists may still argue that engineers cannot really program worth beans). I came to appreciate the role and importance of programming and computation in engineering, and my dislike of the subject abated, even if my own skills only improved a modest amount.

Now, as an instructor, I hear my original theory echoed by the students in my Numerical Methods in Biomedical Engineering class, only it is twisted to apply to themselves, rather than mechanical engineers. Biomedical engineers hate programming, and it is best left to computer scientists. As with me and my classmates before them, this hatred is rooted in an underlying frustration associated with repeated code failures and error messages that ultimately leads to anxiety and even fear of programming, especially when faced with timed programming assignments, looming deadlines, and open-ended questions for which there is no single "true" approach reach a solution.

This frustration, anxiety, and even fear of programming exhibited by students leads to a the challenges of how to assess their work in such a way that we (instructors):

Can distinguish between students' comfort with programming syntax and structure versus their understanding of the underlying computational methods.
Design assessments to account for and alleviate the frustration and anxiety associated with programming.

For the past two years, I have played with different attempts to address these challenges in my Numerical Methods course, and have learned more ways not to evaluate computational skills than I have had successes. Initially, being new to teaching programming-based courses, I naively thought to simply include a separate "MATLAB portion" of the midterm exams where students would be asked to write a MATLAB script to perform a set of tasks to answer an engineering-related problem. However, students consistently reported this format as being extremely stressful, in large part due to the time crunch. They tended not to perform well on these exams, and having to grade individual scripts with multiple procedural parts proved to be a nightmare.

In the next iteration of the class, I replaced the programming exams with a series of shorter quizzes where students answered multiple choice questions pertaining to the MATLAB syntax, and the implementation of MATLAB commands and command structures. I also included non-programming conceptual questions aimed at probing their understanding of the underlying methodology and theory. Two examples of questions are shown in Figure 1. The question on the left is aimed at assessing students' understanding of loops and flow control, while the question on the right requires students to use a root-finding method to solve for the location of the extrema of y(t). All of these questions were open-book, open-note, and open-MATLAB, so students could actually try test the code to answer the questions, at the cost of time. Students who understood the underlying theory could answer these questions without relying on MATLAB itself. While scores were significantly higher for these quizzes than with the previous students' exams, they still reported high levels of anxiety due to the time constraints, and many students skipped the more coding-focused questions.

As with any challenging task, a little encouragement can go a long way. This philosophy is particularly true with learning programming and computational skills, which requires students to learn a mindset/way of thinking about problems as much as it requires them to learn a new language with its own set of rules. I try to remind them they're this learning process is not easy, and that it will take lots of trial and error. Since they often get frustrated with the red-text error messages when code is not working, I often remind them that the messages have useful information meant to help them by directing them to the exact cause of the error. In fact, many times the only reason that I am faster at debugging than they are is that I've already seen almost every error message that can be given. Making mistakes is part of the process!

Downloadable version of this essay

Short Essay on Computation Assessment (Acrobat (PDF) 309kB Aug23 19)