Background

My 12-student class in the fall had only one student with programming experience. Similarly, the course was demographically not a stereotypical programming course, by which I mean that, like most of the courses I teach, white men were a distinct minority.The students almost universally said that they chose the course because it seemed interesting and they needed some kind of writing course for their major. The plurality were pre-med/bio.¹

The JavaScripting English Major, as the title suggests, is already aimed at a “non-traditional” computer science audience: humanities undergraduates. Nevertheless, in teaching the course, I quickly understood that I was falling into some anti-inclusive traps. And getting rid of those traps, that are both pedagogical and technical, underscore how this project is to continue.

Inclusivity

As mentioned above, the whole point of The JavaScripting English Major is to be more inclusive than the JavaScript textbooks that I considered using. Programming books, in my experience, are written for CS students, meaning they highlight concepts that are obscure or irrelevant to humanities students who want to learn JavaScript. The books can be great, but their audience is wrong.

That CS has an inclusivity problem is no surprise. Nevertheless, a lot of the suggestions someone like Ashe Dryden can make to Stanford’s CS department demonstrate potential means by which programming can be made more inclusive even to non-CS majors. A lot of the tips Dryden gives I was already using in the design of this course, but some I had overlooked.

Things to change: Pedagogy edition

1. No ninja programming: Edge cases are great, but I should not be asking students to explain to me why, in their second homework assignment, 0.1 + 0.2 returns 0.30000000000000004. The instructor should know the answer, of course, but asking students to figure it out is precisely the sort of arrogant, exclusionary type of assignment to scare away students. None of my students got this problem correct, and one even suggested that it’s because “computers are more precise,” which is precisely the opposite take-home message of such an assignment.

   In fact, in trying to explain this problem in class, I went down a massive rabbit hole once it was clear that my students (or so they claimed) had never been taught how to calculate in binary. It was fun for me to teach, and it was maybe fun for the students, but it certainly didn’t make any of them feel like they understood JavaScript better.

   “No ninja programming” is also an encouragement to use clunky, over-literal syntax as well. Define variables and then assign them separately, for example.

2. Use Atom in class: I’ve already made this change for this semester. I don’t use Atom in my day-to-day, but I also think it’s great for students, because it has a ton of great features built-in and a (comparably) flat learning curve. Hence, this course is designed, in part, around it. Nevertheless, when I was leading discussion of homework in class, I would be doing all my coding on the projected screen in Vim. Students noticed the difference, and one even suggested she felt like I was patronizing by teaching the “toy” Atom program instead of the “real” program I use.

   More importantly, students had far more technical trouble with Atom than I imagined they would. I’ve already addressed this in part by starting an Atom Help page that tackles the most common stumbling blocks my students encounter. But the fact that they couldn’t see me use Atom in class makes the software even more obscure, I suspect. Seeing my clicks, etc., provides visual cues for how Atom works that they can rely on later.

3. Have a weekly lab where students bring their laptops: My students recommended this one to me. They asked for more class! I generally don’t let my students use their laptops in class, but they were also having serious technical issues I could not predict. As a result, they had to rely on being free during my office hours or free for a few minutes before and after class to ask for specific, technical help. That, in my opinion, is bad pedagogy.

   If a student has an internship/job/busy schedule and can only do the homework at midnight, and all of a sudden Atom is doing weird things, they’ll probably get frustrated and resent the class/professor for requiring such a dumb piece of software. And they have no recourse. Assuming they’re like me—and that they’d just go to Stack Overflow—is anti-inclusionary and, again, bad pedagogy.

   This semester, I had all the students install Atom and make their first commits to our shared GitHub blog in class, at the same time. And wow. I had not anticipated the myriad ways they would find what I thought were crystal clear instructions rather opaque. This was a great experience.

   It makes perfect sense, then, to have students work on homework together in a weekly lab, leaving “regular” class for discussion of the readings, etc. At the lab, I can reiterate concepts from regular class, find new hiccups that I haven’t anticipated, and catch students who are slipping behind. Speaking of…

4. Mentor better and monitor students’ progress better: My approach to the homework assignments in The JavaScripting English Major didn’t work right. I had students put in a good faith effort at each problem set and push it to their own repository. I’d look those over before class and, in class, I’d ask if students had questions and go over the problems in class, with extra attention paid to where students ran into trouble in their posted homework. That was insufficient, because it relied on the unearned assumption that all of the students were caught up and doing the homework in the first place…

   Dealing with non- and under-performing students is a particular concern of mine, because “under-performing” is a brilliant description of me as a student. I liked that professors kept their nose out of my business, but I also resented them for not reaching out to me to help me when I was particularly adrift. As a teacher, I’m in a similar position now, where part of me takes the “they’re adults” line, but I’m starting to think that’s not the right approach. That is, if it breaks my heart to fail a student, then the solution shouldn’t be “well, some students fail.” The solution should be “make it so students don’t fail.”

   I should be more attuned to how alienating programming work can be to humanities students, meaning I should not simply dump all of the responsibility of trying to get caught up on the student. If I know a student is woefully behind in their homework—and in this course, the homework is cumulative and falling behind is a recipe for disaster—then I should be far more concerned at catching them up than I have been.² Given the marked correlation between students’ keeping up with the homework and their grades on their final projects (to say nothing of their final grades), a weekly lab should also help here with improving outcomes.

5. Require journaling: This may grow in importance as I think more and more in terms of self-evaluation and “ungrading,” but having the students reflect on their difficulties and feel open to critiquing how things are going during the course of the semester would be a good move. My students’ suggestions at the end of the semester were great—but I could have “easily” implemented some of them at midterm and some students’ performance would’ve improved alongside.

Things to change: Technology edition

1. Provide more materials: By this I mean documents like my JavaScript cheat sheet. In teaching JavaScript, I settled into some mantras (“what do all objects have?” “properties!”), but this cheat sheet was maybe too little, too late.

2. Use the console less: Students are learning JavaScript to learn how to (mostly) make webpages. I should get them out of the console as quickly as possible, then. This could even mean flipping the order of some chapters, like teaching students how to have elements appear on the page before they have used JS as a calculator.

3. Use the console more: On the other hand, my students were helpless at doing their own troubleshooting, and they didn’t know to use the console to help solve their various problems. The chapter on errors is meant to be a bit of a midterm break for the students, but that’s probably wrong. This could be its own help page.

4. Solve the variable definition problem: Throughout, I encourage students to define their variables first and only later assign them. This works fine with var and let, but it does not work with const. Nevertheless, the consensus seems to be growing that we should be using const as our “default” variable definer, especially considering that variables defined with const maintain their mutability, something I assumed not to be the case.

   I can get away with only using let, but if I introduce const, then I must also introduce let, which might be unnecessarily complex.

5. Get rid of jQuery: As they say, now, more than ever, you might not need jQuery. What to me appear as obvious wins in terms of readability might not be as clear to students. document.querySelectorAll() is “more verbose” than $(), but at least it explains itself. This would also go into thinking about a chapter about the DOM.

6. Move students into an html sandbox: I already do this for my Simple JavaScript Mapping workshop, where students send return values straight to their html pages instead of using the console in between. Using try and catch may even help with error checking.

7. Be less thorough: I realized that there are things I teach in this course that I, a person who spends hours a week writing JavaScript, never use. Namely, I never loop unless I am iterating over an array or something like that. Hence, why should I be teaching while loops and friends? Modulo operator? Seriously? No Ninja Programming!