Sympathizing with Students

I've had two very different conversations in the past few weeks with two different colleagues, both of which relate to working with students. One of these conversations was very sympathetic to students, in a "how can we help them succeed and thrive?" sort of way. The other was...a bit less sympathetic...the sort of commiserating conversation with more of a "how do we hold students accountable to actually do the work?' sort of feeling.

I feel both of these things sometimes, as an instructor. 

But I'm coming down right now on the side of sympathizing with students. Perhaps it's because I'm taking a computer programming course on audit right now, and feeling some of the same pressures. I am an achiever, and I want to do well, and represent myself well, and really learn the things I need to be successful! Though, to be clear, auditing a course is different--as much as I want to say I sympathize with my fellow learners, I'm in a bit of a different category. I'm taking this course just for the learning, with no grade attached, and no high stakes (e.g., scholarships) riding on a grade. Also, the professor teaching the course is a friend, and is very supportive and encouraging of me taking the course. And while she is equally supportive of the other learners in the class, there is a different kind of power dynamic, I think, since I am a peer, and the students in the class really are not.

But while all of this is true, I do feel a sense of the pressures the students taking the course do. There are times when I have to re-read the text multiple times to really understand it. There are times when I am really not sure how to start coding a program that I've been assigned, and I start to trial-and-error it. (Which never seems to work out well.) My wife could tell you how she knows when I'm struggling, because I mutter under my breath and sigh a lot. The work is challenging, and it's stretching me. And I feel a very real sense of accomplishment when I solve a programming problem that has been a bugaboo for me.

But one experience in particular had me sympathizing with students. We use an online platform as part of our homework for the course. I really like this! We get immediate feedback on the snippets of code we write, and we can redo things as many times as needed to get things right. I find that this is helping me check my understanding in a step-by-step kind of way, and deepening my understanding through repeated practice when I get things wrong. Sometimes I get things right the first go. More often, it takes me two or three attempts, but I figure this is actually a good thing, because it causes me to slow down and rethink my approach, and check my understanding of the syntax of the language I'm learning.

But there are limitations to this platform, and sometimes this has me running into dead ends, because my code isn't exactly right according to the specifications of the platform. I had this experience last week with a programming problem. I wrote a piece of code that I thought would solve the problem...but no joy. So I took the error messages, and used them to try and pinpoint where things went awry. No joy. I revised, and revised, and eventually started over from scratch. No joy, no joy, no joy. I tried over 30 different submissions on this project! (I was definitely muttering under my breath about it.) I'm stubborn enough to keep working away at it, because I really want to learn this stuff for myself! But there came a point where I felt like I was banging my head against the wall.

And so...in my frustration and defeat...I turned to Google.

I found a solution, of course. And my code was about 95% correct, but I had missed a crucial step. It felt so obvious when I saw it. I fixed my code, and submitted the project. All done.

But I also felt some guilt about needing to look up help online to solve the problem. 

In this course, which I'm taking just for fun and for my own learning, I have the luxury of not caring about a grade. Did I have to find a solution for this problem? No. But I wanted to--perhaps out of wanting to represent myself well, to actually complete the assignment, do it correctly, and get 100% on this assignment. Was it cheating? In this case, no, because my professor-colleague encourages us to use our resources to help us learn, including looking things up online. But there was still some guilt there for me.

And this is where I'm feeling sympathetic with my students. They often have higher stakes attached to grades, after all. So perhaps it's no wonder that they seek out help when they run into roadblocks. And perhaps that "seeking out help" isn't always on the up-and-up. But in a moment of frustration, or uncertainty, or need to just-get-it-done-and-move-on-to-the-next-thing-because-there-is-always-more-homework, they might seek out illicit homework help.

So all of this has me thinking about what our philosophy ought to be for encouraging students to actually, deeply learn the material? Yes, I want my students to be accountable for doing the work. And, yes, I want to encourage and support my students so they will be able to be successful in learning. Both of these are true at the same time. Are they in opposition to each other? 

All of this to say, placing myself in the students' seat has been a good exercise in understanding at least some of the pressures they are experiencing. 

Image by Chris Ried via Unsplash

Computational Thinking and Solving Problems

In my last post I shared how I am taking a programming class. We're a couple weeks in now, and it's all going well enough. (So far, so good!) 

Yesterday I wrote a fun little program to help with planning a hot dog roast. (Why do hot dogs come in packages of 10, and buns in packages of 8???) It's not the most elegant code ever, I'm sure, but I tested it with a dozen or so inputs, and the math checks out. It's a functional program. I'm feeling proud of myself, even though it's a relatively small thing.

Here's the output for the program I wrote. Fun, right?

I'm learning the syntax of Python, the "grammar" of the language. And I'm learning strategies to build code that is readable by both the computer (obviously) but also humans who might need to understand the code as well. And I'm learning about software development environments, and just how many places Python is used today. (It's a lot--a really useful language!)

But as interesting as it is for me to think through what I'm learning...it's even more interesting to me to reflect on how I'm learning.

I've taken programming before, and I'm finding myself calling back to the last time I took a course that involved hacking code, over 25 years ago now. The language is obviously different. But I'm thinking about the habits of mind I'm re-encountering as I'm taking this course. There is quite a bit of discourse in STEM education today about teaching what is called "computational thinking." This is the idea that we can break down problems into "computable" steps--algorithms, heuristics, and patterns that can help us solve the problem. 

I'm finding that more than learning coding in a particular language, I'm (re)learning some computational thinking strategies by taking this course. 

We're at a point in the semester where we are learning techniques for branching and iteration--"if-else" statements, and "while" loops--and the logic of understanding how the computer will process our code. This has me thinking about how I break the problem down, and how I attack the specific aspects of the problem to find a workable result.

My professor is fantastic at helping us think through "pseudocode" in class, where we take a problem, and collectively analyze the steps we might need to take to solve the problem, and sort of code it out as a series of algorithms, without actually writing all of the code in Python. Then we can work through the specifics of turning that pseudocode into the actual grammar of the language. It's a really effective teaching technique! And then, the practice: we use an online platform to practice writing small snippets of code and get immediate feedback. Because I get immediate feedback on whether my code "worked" or not, I can either move on to another exercise, or rework it, or if I really get stuck, it even offers some hints to get me thinking in a different direction. It's a pretty smart approach. This is really helping me to sharpen up my skills at attacking smaller scale problems that I can then bring to bear on the bigger coding problems that we do, like the hot dog cookout program I shared above.

When it comes to the exercises for homework, it's amazing to me how often find this pseudocode approach working--and it's also amazing to me how frustrated I get when I don't slow down and think computationally. There have been a few times where I read the problem in our online coding platform, immediately make an intuitive leap to how I think the code should function, hack out a solution to the exercise, and hit submit. And sometimes this works great! But other times...well, let's just say I hit "submit" 23 times for one exercise the other night, tweaking the code just a bit each time before hitting the button again. Ooof. I was getting a little frustrated, but when I finally got the right answer, I laughed...because I realized that I had been banging my head against the wall because I had missed a step in the initial framing of the problem, and in my rush to start hacking code, I didn't slow down to think through the steps.

And that, to me, is the most important thing I'm learning: I am often quick to make snap judgments, and I think this course has already been opening my eyes to the importance of slowing down and understanding the real situation of the problem before I just barrel on to a solution.

It's a lesson that I am going to need to keep relearning, I think. 

But I'll celebrate the small steps that I'm taking in this (re)learning process. And if you are planning a hot dog roast, I have a piece of code that might help you in the planning process.

My Latest Adventure in Learning

 I am a learner at heart. 

Having taken the StrengthsFinder assessment a couple of times now, it's been confirmed for me: "learner" is one of my top five strengths. I didn't really need the assessment to tell me this. I love to learn new things, and even re-learn things I've learned before.

Perhaps that's part of the appeal of academia for me: there is always something more for me to learn. And sometimes, it's the teaching that actually leads to more learning.

That's the case for me this semester. I'm teaching a new course--new to me, but also brand new to our institution: Robotics for K-12 Education. I'm right on the edge of my comfort zone for teaching this one. Honestly, I'm just a little anxious about it. I love robotics as a way of bringing the STEM disciplines (science, technology, engineering, and mathematics) together. But I also recognize that I have some learning to do.

I've taught math. I've taught science. I've taught technology applications. I've read books on design thinking, and problem-based learning, and I love projects as a way of building understanding. But I recognize the limitations of my current experience with actually building and programming robots.

It's not that I have no training or experience with building and programming robots. I've taught science and engineering principles at the middle school level with Lego robotics kits. I've used block-based coding tools to build Android apps. I've played around with Arduino micro-controllers. At a conference a couple years ago, I participated in a substantial workshop related to teaching computational thinking that involved programming simple robots. All of this helps.

But I realized the other day that it is 27 years ago since I took a true programming class, way back when I was a computer science major in my first year of college. Ooof.

And so...with the recognition that my students taking this Educational Robotics course have had programming MUCH more recently than I have (and it's actually a pre-requisite for this course!)...I've decided that I should retake Programming I, just to brush up on my own skills.

So here's to learning a new language (Python), and revisiting computer science principles I've likely forgotten in the intervening decades, and updating my skillset to be better equipped to serve my students! I'm hoping to document my ongoing learning here as part of my reflective practice--both in taking the programming course, as well as in the first go at teaching the robotics course.

Hooray for adventures in learning!

I'm ready for it...bring on the Python!

Gender Bias: Girls Who Code

It's summer camp week, and we have 300+ middle schoolers who have joined us for Dordt Discovery Days. It's an "academic camp"--designed to give kids a taste of college life, living in the dorms, eating in the dining hall, taking a couple of exploratory courses, playing all-campus games and activities, and meeting kids from across North America who have come to spend some time with us on campus. I'm co-directing, again, which I love, because it means I get to visit all the classes kids are taking, and talk with them about what they are doing and learning.

It's amazing, honestly. Every time I step into a classroom, I have kids shouting at me...

"Dave! Come see this cartoon character I created!"

"Dave! We're dissecting sharks! Come see what we found in the intestines!"

"Dave! Can you stay for a minute? Our a'cappella group is working on an arrangement of 'Africa,' and we want you to hear it!"

"Dave! Check out the pillow I made! I sewed it myself!"

"Dave! My group has been creating this awesome marble roller coaster--come try it!"

"Dave! We're playing improv games--come join in!"

"Dave! ..."

Computers Programming Kids?

For a reading for one of the classes I'm taking this semester, we read part of Seymour Papert's classic book Mindstorms: Children, Computers, and Powerful Ideas. If you are Lego fan and have every worked with their robotics kits--also named "Mindstorms"--you are working with materials developed in collaboration with Papert. And, if you are of a certain age, you perhaps remember Apple LOGO (the "turtle" you could command around the screen?) which was developed by Papert as a way of teaching young children how to program computers.

I don't think I understood it this way when I was playing with LOGO as a kid. I was just messing around...though Papert would probably say that is the point. His philosophy is an off-shoot of constructivism called "constructionism" that involves creating (constructing) physical objects to represent complex ideas. This comes through pretty clearly when you think about the Lego robotics kits, doesn't it?

A functioning model of the Curiosity Rover, created using Lego Mindstorms NXT
Image by Erre [CC BY-SA 2.0]