The Spring 2025 Semester Kicks Off

This week marks the official start of the Spring 2025 semester, which for me will hopefully be the semester in which I become ABD¹. I spent a good chunk of this week working on the slide deck for that defense and I'm feeling pretty good about it. However, the most notable thing that happened this week was the number of students who came by my office to ask for help with their work. I should note that this is not some random occurrence, but rather the result of my position in the department as the methods TA--the designated person to help graduate and undergraduate students with any research and methods-related questions they might have.

Part of the attendance I got came about due to my class introductions where I dropped by most methods-related courses to introduce myself and let students know that I'm available to help them with their work. Most of the students I got to help were graduate students, though, most of whom came by to pick up on conversations we had had last semester. It makes me happy to see students coming by to utilize the resources available to them, and I'm glad attendance has already picked up faster than it did last semester.

One of the greatest pleasures I get from helping these students comes from how their questions make me think about my own work and what I've learned. I find that it's easy to take certain bits of information for granted, whether that be due to the implicit assumptions one makes or the fact that it's near-impossible to adequately question every element of a given topic. However, when I get these students in my office, I find that their questions often force me to think about statistics or programming in a different way or to fundamentally questions why I do something in some way--even if I know that way is correct.

A good example of this came yesterday when I had a student ask me about some code I had helped him write. It was a chunk of R code that took a data frame, did some minor cleaning operations, generated some descriptive statistics, and ultimately displayed the result as a kable in R. For tasks such as that, I'll usually begin with the data frame object and pipe through the requisite steps before displaying the table, with a major reason for that being my desire to avoid intermediate object assignment. However, the student asked me what the %>% operator was and how it worked. Now, ignoring any debates one might encounter from R programmers or the tidyverse, I've often found that students who are new to R or programming in general have a hard time with the pipe operator--at least if the instructor didn't begin with it when teaching the language. And, thinking back to my experience learning R, I can't say I was any different; I remember more or less understanding what the pipe did without really having the intuition to use it in my own code.

So, I took a moment to explain the pipe operator to the student, showing him how you can use it to pass the object as an argument to subsequent functions. I also showed him the alternative to the pipe operator, which involves plenty of intermediate assignment and, in my view, makes the code harder to read. I think he understood what I was talking about, but the experience made me reflect on how I should model programming practices to students that come by. I don't think it's as helpful to help students write code (say, for a descriptive statistics table or data cleaning operation) if I'm going to do so by adding to the conceptual load they're already carrying. For instance, if students are already struggling with cleaning a variable in their data frame, the goal here is that they learn how to do so, not necessarily to teach them the way that I do it. By including the pipe operator, or any other element of the tidyverse, for that matter, I'm making their lives harder if their instructor didn't begin with the intention to teach them this side of R programming.

One of the most repeated lessons I've gotten when going through teaching training had to do with the importance of scaffolding in the classroom. In other words, an effective pedagogical approach begins with first principles and iteratively builds upon them until the student can be expected to grasp the more complex concept that makes up the course's end goal. If, then, the students I'm encountering aren't exposed to the tidyverse view of the world--which I have on good authority is the case--then I should be careful not to complicate matters by introducing them to something to which they've had no exposure. The alternative is to force them to learn something that they don't need to know at the moment, which can frustrate them and ultimately lead to a greater attrition rate in the course.

As a tutor, I have an obligation to help students learn the material in an effective manner. This means that I should avoid laziness in my approach; I should make sure that I'm not just giving them the answer that is the most readily available to me or the easiest to explain. I should consider what they know, to what point they've been scaffolded, and what they need to know to get to the next level. With that information in mind, I can then help them learn the material in a more effective manner, thereby minimizing the frustration they might feel and increasing the likelihood that they'll come back for more help in the future. In the end, what's the use of a tutor who gives the right answer if the student doesn't understand it or can't replicate it on their own?