Below are some thoughts about how to improve this website and the underlying course. I don’t expect this to be a completed document, and I will add to it as I prepare the upgrade (probably this summer), but I also think it may be of use to others.
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.1
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
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.2returns
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.
“No ninja programming” is also an encouragement to use clunky, over-literal syntax as well. Define variables and then assign them separately, for example.
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.
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…
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.2 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.
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
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.
Solve the variable definition problem: Throughout, I encourage students to define their variables first and only later assign them. This works fine with
let, but it does not work with
const. Nevertheless, the consensus seems to be growing that we should be using
constas our “default” variable definer, especially considering that variables defined with
constmaintain 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.
I had only one English major in my class and one first-year who was planning on becoming an English major. This was surprising, considering that the course was listed exclusively as an English course. This, of course, adds to my skepticism regarding how eager English majors are to take courses with a digital component—at least at NYU! Throughout my time at NYU, my self-designed courses have all fallen within the “Digital Literary Studies” rubric. Until this course, however, they fulfilled the English major’s “theory” requirement. I would typically have classes full of students saying that they chose the course because it was the least bad-looking course that fulfilled that requirement. I find it notable, then, that (given n = 3) though this was the most popular DLS course I taught, in terms of enrollment, it was also the least subscribed by majors in the home department. ↩
Mind, it’s not like I ignored students. But this requires more than the standard courses of action related to emailing the students and their advisors. My students are not accustomed to this kind of work, so I can’t use the practices I learned in “regular” English courses in trying to mentor and monitor them. ↩