Here’s a write up of another activity I’ve been working on as part of my sabbatical.

In college, I remember a dean telling us the joke about the student who was challenged by their professor to measure the height of a building using a barometer, and all the ingenious ways in which the student came up with complete the task: tying a piece of string to the barometer and lowering it from the side of the building to measure the heigh, dropping the barometer off the top of the building and measuring the time it takes to hit the ground, offering the barometer as a gift to the building superintendent in exchange for the height of the building, and more.

Inspired in part by this joke, I decided to see if we might be able to use a BBC micro:bit to measure the length of a piece of string. First, I want to give a serious shout out to the micro:bit as a pretty amazing tool for exploring computing. They are small (2in x 1in) integrated circuit computers that include an array of sensors (light, temperature, accelerometer, compass), a 5×5 LED display, 2 physical buttons, 25 pin outs, and bluetooth wireless connectivity. They’re also cheap (\$15) and very easy to program in a block based javascript, or text based python. The platform has a ton of accessories and curricular materials, and seems to be in pretty wide use across the UK and Norway, and probably many other places as well. Microbit is the easiest microcontroller platform I’ve ever worked with, and I think they would be an ideal platform for any middle of high school STEM class looking to add some embedded systems programming to their work.

When I first started playing with micro:bit, it took me about 10 minutes to follow these instructions about Live data logging with Python and Mu (a great beginning python editor for programming micro:bit), and suddenly I had an accelerometer that could wirelessly transmit its readings to a second micro:bit serving as a receiver connected to my computer. This got me thinking, could I use the micro:bit as a pendulum?

Here’s a description of what I did, with some ideas for how to turn this into an actual activity for students in physics class.

## Measuring the length of a piece of string with a microbit

The microbit is just about the perfect size to serve as pendulum bob, and it’s easy to attach a battery pack and string through one of the pre-drilled connection holes.

The first thing I needed to do was modify the program from the live data logging example to calculate the magnitude of the acceleration, rather than logging the 3 components for the x, y, and z axes. Thanks to the great documentation of the platform, and the built in tooltips of the mu editor, I was pretty easily able to come up with this program for the accelerometer:

from microbit import *
import math

while True:
sleep(20)
a_x = accelerometer.get_x()
a_y = accelerometer.get_y()
a_z = accelerometer.get_z()
a_mag = math.sqrt(a_x2+a_y2+a_z**2)

and the receiver program was unchanged:

from microbit import *

while True:
sleep(20)
print(message)

The beauty of the mu-editor is that it will automatically graph any data that is displayed using the print function with its built in plotter. (To take advantage of this feature, the data you print must be sent as a tuple, a single data value followed by a comma, and the radio.send function requires the transmission of a string, so this is the reason for the slightly strange notation of the radio.send argument in the transmitter).

Unfortunately, the mu-plotter is very limited in terms of what it can do—you can’t rescale the axis or do anything to manipulate the data. But mu-python also automatically saves each data run as a .csv file inside the “data_capture” folder within “mu_code”, which you can import into a spreadsheet. Once you’ve imported the data into the spreadheet, you can add a column of time measurements (this program takes readings every 20 milliseconds), and then graph and fit that data.

Since Geogebra is heavily used in Norwegian high school, I decided to try my hand at it for fitting sinusoid data. After pasting the data into the spreadsheet, you need to create a list of points, using the toolbar as follows:

You can then use the FitSin function to fit the list of points:

Knowing that the angular acceleration of the pendulum can be written in general as

$\theta(t)=A\sin\left(\omega t -\phi\right)+C$

The angular frequency for this pendulum must be 11.32 rad/s.

For a simple pendulum,

$\omega^2 = \frac{g}{L}$

which we can rearrange and solve for L:

$L = \frac{g}{\omega^2}=\frac{\unit[9.8]{N/kg}}{\left(\unit[11.32]{rad/s}\right)^2}=$

Hmm—something here isn’t right. It’s calculating a pendulum that is 0.07 m long.

Update: I realized the problem seems to be in the code—the sleep(20) statements in the both the pendululum and the receiver seem to combine to making the actual time between data points 0.04 seconds, rather than 0.02 seconds. Taking this into account would make the angular frequency of the pendulum 5.66 rad/s, giving a much more reasonable value for the lenght of the pendulum as 0.30m.

Note 2 (May 28): I think I’ve fixed the bug, but if you encounter an error loading the site, I’d greatly appreciate you reaching out via twitter, this blog, or email.

Note: it seems like the site has a bug I missed and isn’t loading in production. I’m traveling now, but will try to take a look at it tonight and fix it.

When I announced Physics Coach a couple of months ago, I thought I was just a few edits from being done. Of course, I’d totally forgotten the lessons I’d learned from reading The Mythical Man Month back in college. But with two more months of tweaking, I’m ready to share a beta version of Physics Coach complete with a few new features. Also, I again have to send big thanks to my former students, Holly, Yousaf, and Leo who were amazing pair programming companions for much of the development, and tremendous earth shattering thanks to Jason, a totally random reader of my blog who offered to help with the project, implemented a bunch of features and guided me through countless challenges.

New Features:

• Support for multiple courses: it’s now possible for teachers and students to be enrolled in multiple courses. Practices completed for a course also only appear in that course.
• Streamlined interface: Rather than ask three different questions at the end of each practice, Physics Coach just asks students to rate how well they accomplished their goal, notes on their practice, and write a question they thought of during their work.
• More data: Practice cards now show show more information, including the practice time, and emojis to indicate how well you accomplished your goal (🔥🔥 = accomplished much more than your goal). The question mark icon in the corner also indicates whether you have an open question associated with this practice (red= open question, green = closed question).
• Open and Closed Questions: after each practice, practice coach asks you to write a question that you still have. By default, this question is considered unanswered or open, until you go into the practice card and mark it is answered, which will change the color of the outline of the textbook, and the question icon on the practice card.

• Push Protocol: Back when I assigned homework consisting of a number of problems for students to solve, it often happened that students would come in the next day talking about how they struggled on a particular problem and spent an hour or more without making any progress. This sort of frustrated practice is a major detriment to student learning—it causes great frustration, decreases student self confidence, and can quickly lead to the student hating physics. To prevent this, I took some inspiration from Cal Newport, and asked students to recognize when they hadn’t made progress on a problem for 5 minutes, and in these moments, to write everything they’d tried to solve the problem, a question that would help them to get unstuck, share this with their teacher and then to move on completely from physics and start working on something else.I’ve created something similar in Physics Coach—once 5 minutes passes, the “I’m stuck” button becomes active, and if a student finds that they can’t make any progress on a problem for 5 minutes, they should press this button and will be asked to document their work, and write a question that would help them to make progress again.

Possible future directions:

• Creating summary page: this might show your recent practices, or a graph of your feeling of accomplishment over your most recent practices.
• Push protocol alerts: I’d like to create setting where the teacher would get sent an email when a student submits a push protocol practice, so that the teacher could respond with help.
• A question tracker page: I’m thinking it might be helpful to pull all of the questions from practices into their own page so that students might be able to browse and review those questions.
• Practice sharing: It might be useful for students to be able share their practices, especially push protocol practices, with other students in their class so that they can get feedback from their peers.

At this point, I really need some feedback from users to decide where to go with this app, so I think I’m ready to turn it over for beta testing. You can begin using the app right away. Here’s how:

2. To experience the student side of the app, enroll in the test course by following this link, and clicking the request to join button.
3. To get set up as a teacher, please complete this short beta test request form, and I’ll convert your account to a teacher, which will then let you create your own course, and enroll students by sending them the link to your course.

That’s it. I’m a bit bummed I wasn’t able to get this app out earlier in the spring so that we might be able to get some real student testing. But I appreciate any testing and feedback you might be willing to share over the summer.

While on sabbatical, I’ve had much more time to devote to working out. Back in it was warmer, I developed a decent slow running habit which I tracked in Strava, and once it got colder, moved to gym workouts which are tracked by an app built by my gym.

One of the things I’ve noticed is how helpful these apps have been for motivating me to workout—seeing a graph of how many times I’ve worked out this week is usually a good nudge to push me out the door when I’m not feeling fully in the mood to going to the gym, and Strava gives me a wealth of tools for analyzing my runs, even showing me all the super fit Norwegians in my neighbohood and how much faster they run around the local park than I do.

All of this got me thinking, what would an app to track physics workouts look like?

Last year, I implemented Casey Rutherford’s excellent homework policy that abandons traditional “assigned” homework (“do problems 1-33 odd for tonight”), and replaces it with asking students spend a certain amount of time practicing physics in a way that will increase their understanding and then document that practice. In my first year physics classes, this worked out to asking students to practice physics for 3 hours outside of class each week, and giving them a weekly menu of options focusing building skills, problem solving and extensions. Here’s an sample of a what a weekly practice menu looks like.

Overall, this turned out to be an awesome way to do homework. It was very easy for me to engage students in deep discussions of physics by adding comments to their work. Students were able to find meaningful work that they could custom tailor to their needs. Students also quickly saw how well practice correlates with improved understanding on assessments. For the most part, students were also very responsible about doing practice, even though it wasn’t graded at all (I only wrote feedback. Interestingly, I also think students felt more guilty about not doing physics practice than they would have felt for a more traditional homework assignments.

Most of the downsides came down to the requirement to document. Getting photos into Google docs and typing up what you did in a table became tedious for many students, and they struggled to see any benefit, especially when they didn’t engage my feedback and just chose to work on a new thing every night, and for some students this became a major roadblock to their progress.

### Introducing Physics Coach

All of this got me thinking that there should be a way to make this easier. After seeing how easy it is to log a run or workout in Strave or at the gym, I stated to think “There outta be an app for that…” and I set out to build physics coach.

I spent quite a bit of time this year learning React, Redux and Firebase, and by far the greatest motivator for learning this has been setting a goal of writing this app, rather than just trying to “learn React.” Also, so much of the progress I’ve made with this app and as a software developer has been due to regular pair programming sessions I’ve had with three former students, Holley, Yousaf, and Leo and one amazing student at the University of Illinois, Jason, who reached out on my blog. I’ve now got a decent working prototype that I would like to explain here and invite your feedback.

This web app supports Google authentication, and after students login and are assigned to a class, they will see a screen that looks like this.

When the student opens a new worksheet session, they see a screen that looks like this, prompting them to enter a goal for this practice session. (Right now the timer defaults to 1 minute for testing purposes, but can be set to anything).

Once you press start session, a simple Pomodoro-style timer comes up like this:

When the session concludes, the student is brought to a screen asking them to do a bit of reflecting on their session:

And they are then given the option to upload photos of their work, including by capturing photos from the webcam.

Once you save your practice, you can go back and view previous practices:

And examine one practice in detail:

And if you click on an image, you bring up a lightbox element that lets you zoom in on the photo.

All of this is working seemingly nicely at the moment, and I’m working on adding a few other features:

• Courses & Roles: putting students into courses, and setting up a “teacher” role so that a teacher can see all of the students in their class.
• Push protocol: I’d like to add a button for students to press when they’re stuck. If they’ve worked on something for 5 minutes, and haven’t made any progress at all, I want them to press this “push protocol” button, and it would ask them to document their work with a photo, explain why they are stuck, and then create a record of this practice. I’m thinking about possibly creating a way to share those “push protocol” practices with the class, so that other students in the class could offer feedback and suggestions.
• Image annotations: I’m thinking it might be nice to be able to specifically annotate images of student work.
• Tagging: I’d like to add tagging support, so you might be able to tag things like about your practice process “listening to music”, or “studying in library” or content/action tags, like “kinematics” or “reviewing for test”.
• Simple analytics: Similar to my gym all I’d like to show a student how many times they’ve practiced recently, and perhaps give them a tool to see how their and level of focus varied over time and with various factors like time of day.

### I want your feedback and would love some beta testers

I do have lots of questions:

• Does this seem like something that might be useful for your classes?
• Do you think students would be willing to use this app to log their practice sessions?
• Am I asking the right metacognitive questions at the end of each practice?
• What other features might you want to see in an app like this?

If you’re interested in seeing physics coach in action, you can try out a slightly older version than the one pictured above at https://physics-coach.firebaseapp.com/ (you’ll need to authenticate with your Google account). You can also check out the code at my github repo.

I would really love to find a couple of teachers interested in beta testing this with their students. If you might be interested, please leave a comment here, and we can talk about how to set this up for your class.

For the past few Fridays, I have been teaching my first ever lessonsto a class of Norwegian students, and I wanted to write about the experience here.

This class was a class of 30 or so Norwegian students in Mathematics 1T, which covers the the topics of precalculus and differential calculus. The students in this course had just finished studying functions, and function notation.

I asked students about their previous programming experience—many students had done some programming in scratch, one had done some work in HTML, and none had any experience in Python.

Here is initial throught thought about how to structure a series of lessons for incorporating programming into math class. Students are already quite comfortable with calculators like Desmos and Geogebra, and readily see their utility in mathematics. Why not introduce Python as a sort of “build your own calculator,” emphasizing their ability to program their own functions that will be useful for future work?

Ideally, I could imagine that students in an Algebra 2 or Precalc class build a file of functions that would be useful for their own work in mathematics—functions to find the x-intercept of a line, the roots of a quadratic, or even the slope of a fuction at a point. Once students learn to master a procedure, they then develop that procedure into a function in Python, and later, are free to use that function on future assignments.

For this type of introduction, I decided to start students off in the Repl.it web programming environment. If you have internet connectivity in your classroom, Repl.it is a great environment to work with because there’s nothing to install or configure, and yet you get the exact same Python interface you would get from installing IDLE or Anaconda (without having to wait half an hour for Anaconda to download).

The other choice I made  was to start by working directly with the Python interpreter, rather than writing actual Python scripts. This requires students to enter commands where into the interpreter one at a time. After most commands, the interpreter gives you some feedback. So if you enter “3+7”, you’ll see 10 appear below the prompt. If you try to enter a command that requires multiple lines, like a function definition, the interpreter prompt switches to an ellipses “…” allowing you to enter each line of of the command. And if your line happens to include mismatching parentheses, you’ll be able to tell because Python won’t return to a normal prompt until the braces are matched. Finally, if you have any syntax errors in the line you wrote, you’ll get immediate feedback in the form of an error message right under the line.

I think there are a number of advantages to first working with the Python interpreter. In normal Python programming, where you are running a script, your errors appear in a separate window, and I’ve found it very hard for students to connect and interpret these error messages as having important feedback about their code. If you want to check the value of a variable, you simply need to type the variable name on its own line, and Python will print the contents of that variable. Working in the interpreter also gives you an opportunity to predict the output of each line of code before running it, which is also a valuable activity when first learning to program. And finally, for the exercise of building your own calculator, working in the interpreter feels much more like how a calculator actually operates.

## Lesson Plan

Every student brings up the a Python environment using repl.it on their laptop.

We start by entering some simple addition problems into the interpreter—”4+6″, and I ask them if they can figure out and check the other mathematical operations—subtraction, multiplication and division, and they quickly find “-“,”*” and ,”/”.

I then show them the “%” operator, and ask them to spend some time exploring what it does. I start by giving them some examples.

5%3 --> 2

6%3 –> 0

10%3 --> 1

I ask the students to spend some time exploring this operation. What are the possible outputs for this operation? What exactly is this operator doing?

Students make some interesting discoveries—the output is at most 1 less than the second number in the operator. When we get more systematic, exploring 1%3, 2%3, 3%3, etc, they see the output follow a cyclic patten. Eventually, students are able to predict the pattern from a few examples, and then with a bit more nudging, and some cross cultural discussion about the differences in division notation between Norway and the US (did you know that the US division sign functions as the minus sign in Norwegian? And long division on Norway looks completely different from how I was taught), they recognize the modulus operator that gives you the integer remainer from division.

At this point, I give them a cheat sheet of various python commands I pasted together from the internet and ask them to spend a few minutes exploring some of the examples in the cheat sheat. When we report back, students have discovered all sorts of neat things like

print(“Hello” * 2)

>”HelloHello”

### Defining functions

Since students had just studied function notion, and my ultimate aim was to help them build a library of useful functions for mathematics, I decided to introduce them to defining functions in Python.

Students see that function definitions in Python can look remarkably like mathematical function definitions. We start with a simple linear function.

def f(x):
return 2x+3

Python also makes it pretty easy to create piecewise functions, like this

def f(x):
if x >= 0:
return 2x+3
else:
return 3

Next, we talked about the difference between a variable and a parameter, and how in the code below, the x in the function is not the same as the variable x—this tends to be a very confusing concept for students who are just starting out with programming.

x = 3
def f(x):
if x >= 0:
return 2x+3
else:
return 3

This was pretty much the end of the first day of programming and 90 or so minutes of work. A week later, I came back with a Desmos activity I had created to help them test their ability to read code and understand basic Python operations. The first screen was a matching exercise where students matched 4 small 2 line programs with their output.

Then students took a crack at reading and predicting the output of a small program:

Thanks to the awesome computation layer, I was able to create a follow up screen that showed students what they wrote as the output and ask them to resolve any differences between their prediction and the output of the program.

Lastly, I created a simple slider for students to state how they felt about our work thus far:

Once we discussed their work on this Desmos activity, I wanted students to see how we can use Python to define functions that aren’t “mathematical” and so worked together to develop a function that would take an (x,y) pair as an input, and return the Quadrant that contains that point, I, II, III or IV.

We began this process by developing a small flow chart to help us think through the logic:

From this, I tried to do some interactive live coding where students would tell me what to write, and eventually, we put together a function that looked something like this.

if x < 0:

if y > 0:

return "I"

else:

return "IV"

else:

if y > 0:

return "II"

else:

return "III"

It was super helpful to have the flow diagram to go back to be able to show at various points in the coding how much of the function we had written. But as students were trying to follow along to write this program themselves, things went a bit off the rails. It was a bit of a jump to go writing code that had nested commands three levels deep, and I again found myself running around helping students make sense of all the various syntax errors they were being. Not good.

Sadly, class was just ending, so I had to leave with a lot of students feeling frustrated.

On the third day, I came back with another exercise to follow up on our work on the quadrant function. This time, I’d rewritten the code we discussed last time, adding a syntax error and a error in the algorithm, and asked students to spend the first bit of class debugging. This turned out be great. Students did a great job of finding the syntax error, and they were having productive discussions to try to figure out the bug in the program that was producing incorrect output. Many of them saw that debugging is way harder (and more interesting) than just finding syntax errors, and a few that finished early started to walk around the room to help out their peers.

Once we had a working Quadrant function, we started to create our own functions, lke this,

def f(x):
return x**2 + 4

to see how our function nicely predicts points along an whole variety of functions. We really started to have fun when the teacher suggested looking at the sine function, which I imported, and we could quickly see how our function’s predictions perfectly matched the graph of sin(x) in Desmos.

### Reflection

By the end of the third session, some students were really beginning to enjoy programming and thinking through the execution of a program. A few were still finding it pretty frustrating and wondering why programming must be so hard. This is something I really want to work on in the future in my own teaching. Much more than my experience teaching physics, students who begin to program seem to quickly separate themselves into people who develop a quick love for it and people who think it’s not for them. Often, I think this is tied deeply to a student’s previous experience with programming and programming adjacent activities, like taking things apart, working with simple machines, etc, and I would love for a way to help students who think programming is not for them because they aren’t getting it as quickly as their peers to see that often, their peers have had much more previous experience that forms much of the basis of their seeming “intuition.”

I also think there’s a real need to develop many small formative assessments for students who are programming, and to center most of these activities and assessments around reading code and making small modifications to scaffolded code. Too often, I think we ask students to write code from scratch, and not only is this something that rarely happens in the real world of programming, it is deeply challenging for students to work on translating their ideas for a program into an algorithm and then master all the tiny syntactic details necessary to get a working program. There are lots of strategies to help with this, like writing pseudocode, running your program often to find errors, but I think for some students, this still isn’t enough, and a few minutes trying to find your error in the 20 lines of code you just wrote in one sitting is a nearly impossible task.

Finally, I wonder if these assignments are dreadfully boring. It turns out that the Norwegian math curriculum barely addresses the notion of Quadrants, and I’m not sure that students are excited to build a library of functions they could use as their own custom built calculator as I would be. Certainly there are contexts, like working with vectors, calculating cross products and unit normal vectors where this idea might really help students to see just how powerful a Python driven calculator could be, but if we really want students to see the power of programming as a tool to explore mathematical thinking, I think we need to keep working to find better topics to explore.

Recently, I saw Aatish Bhatia share this excellent TEDxCalgary talk from Marie-Claire Shananhan and Pratim Sengupta about coding in public spaces.

My favorite quote from the video was, “Learning to code isn’t about acquiring a thing or a skill. It’s about participating in rich and meaningful conversations together.”

I’ve seen this quote in action in many ways this year, in conversation with colleagues at UiO and across the world, on twitter, via Skype and more. But I think the most powerful way in which I’ve seen coding as a conversation has been with two former advisees, H and Y, both of whom are now juniors in college studying computer science.

H and Y were extraordinary advisees, and somehow we ended up keeping in touch once they went to college, scheduling Skype/Google hangouts a few times every semester. Both of them have given me great insights into what college-level STEM courses are looking like these days and many ideas for how we can improve our teaching and student life at my school. We’ve talked about finding summer internships, ethics in computer science, cool class projects they’re working on and much more.<

Recently, I’ve been working to learn React and Firebase to build an app I’ve wanted to create—Physics Coach (blog post forthcoming). For a good part of the fall, I spent a lot of time reading books on React, watching videos, and honestly, not making a ton of progress. It doesn’t help that it seems like the React/Javascript/web development ecosystem is evolving at such a fast rate that notation seems to be changing on a monthly basis.

Earlier this fall, I had the the bright idea to reach out to H and Y for some advice and invite them take a look at some of the code I’d written. Thanks to Zoom and Visual Studio Code Live Share (ZOMG—VS Code is the most amazing code editor ever), it was super easy to set up a pair programming session.

After six or so pair programming sessions with H and Y, I’ve made tremendous progress in developing Physics Coach, and in my understanding of React and Javascript. I think I’ve also given them some good practice for coding interviews as they’ve answered some of my questions and helped to troubleshoot code. We always start our sessions with me setting out a small goal, like setting Firebase up to write the homework sessions into its database or incorporating Google’s awesome material-ui into a login dialog. In all of these sessions, I feel like I’m 10x more productive when pair programming then when I am working on my own—this comes from being forced to explain my thinking and voice the things I’m uncertain of, and having someone else who able to ask questions, share different perspectives and help me talk through the logic of a particular coding challenge.

I think H and Y would say these sessions have been equally valuable for their learning, but I’ll let them speak for themselves in the comments. I also am thinking about how I might be able to bring something like this to my computer science classes. Might it be useful to pull students into a pair programming session with the teacher from time to time? I could see many ways to make this work—from live coding sessions where the student is the driver and the teacher and student are working together to implement a program that is just beyond the student’s current understanding, to having the student as the co-pilot on a more challenging project where the teacher serves as the driver, giving the student an opportunity to see how larger software projects are developed. I also think pair programming sessions with the teacher might help students to understand the value of pair programming better—something I’ve found that beginning students tend to discount when they think the programming challenges are easy and they can solve them themselves.

In the meantime, I think pair programming can be a way to grow the computer science teachers community, especially the <a TeachersCoding movement that Evan Weinberg has written about that seeks to help teachers understand how code can be a powerful tool to help their teaching. So if you’re ever interested in doing a bit of programming, usually after 10 pm Central European Time, hit me up!

As I’ve mentioned previously, most of the focus of my sabbatical in Norway is working with faculty at the University of Oslo to help prepare middle and high school teachers for a National curriculum revision in Norway that will require math teachers to incorporate programming into the math curriculum at all levels in grades 1-13. As part of that work, I’ve now gotten to visit a number of Norwegian schools and see some of the early efforts at incorporating programming into the maths curriculum.

Overall, I’m deeply impressed by what I’ve been seeing. The government of Norway is making a serious commitment to funding professional development for teachers, and the effort to bring about this change in the curriculum is strongly focused on giving students another tool to explore and think mathematics rather than just “preparing students for future careers.” The Norwegian teachers I’ve met are also very enthusiastic about the possibilities and opportunities to improve the Norwegian math curriculum to incorporate more problem solving and inquiry based learning.

I’ve also see that Norwegian classes and schools are quite varied. The Norwegian educational system is founded on national commitment to equitable school funding that would be unheard of in the States, it even goes so far as to provide additional funding for schools that have large populations of at-risk students, and as a result every school I’ve been visited is beautiful and fully stocked with all the furnishings, equipment and resources one could imagine needing to teach a great physics or math class. At the same time, I’ve sat in on math class ranging in size from 7 students to 39, and I’ve been thinking a lot lately about how you teach programming to students in such varied environments.

Here’s something I seen in my own teaching of computer science that I find to be particularly challenging—namely how to manage large classes when students are working individually or in small groups and each student/group is in need of assistance from the teacher. Teaching programming in a math class seems to exacerbate this, since students aren’t seeing programming every day, and students are likely to have a wide range of programming backgrounds—some are quite experienced and can often race through an assignment that a novice will struggle with. What often results is every student getting stuck on their own individual problem, and needing the attention of the teacher to help debug. The bugs students encounter, particularly when they are typing their own code from scratch, run the gamut, and I’ve found most beginning students are unable or very reluctant to interpret the error messages or do much troubleshooting on their own. So what happens is you as a teacher are faced with a 20 or so students, intermittently calling for help with problems that you have to diagnose and help solve on the spot, and while your attention is focused on one student or group, the other students who are waiting are steadily growing more frustrated.

I want to think for a moment about similar spaces and classes where this doesn’t happen. The first thing I think of is many of the math classes at my school that focus on Exeter-style problem solving. Here, students are working in groups of 3 or 4 every day on challenging problems that are often beyond their individual reach. It’s not uncommon for students to be working on problems at the whiteboard in these small groups for nearly the entire class, with the teacher just walking around and checking in on each group throughout the class. Students still get stuck here, but it’s rare to see moments where an entire group can’t make progress and is calling for the teacher to intervene.

I’m curious about this difference. I think it’s true that problem solving in math and programming often provide equal levels of challenge to students, but in my experience, students I’ve taught have a much better sense of WDYDWYDKWTD (What Do You Do When You Don’t Know What To Do) when they are problem solving math class as opposed to programming. I think there are lots of reasons for this, and I’m sure the fact that problem solving sits at the hear of our math curriculum, and teachers spend a lot of time helping students to develop these WDYDWYDKWTD skills, and it’s clear those skills don’t transfer to programming when you’re faced with some sort of seemingly indecipherable error message.

This makes me think that even if programming is an topic that is occasionally interwoven into a math class, it would be helpful to spend some time explicitly teaching students many of the skills that are helpful for debugging—running your program often, interpreting error messages, learning to add print statements and comment out blocks of code to localize bugs, and all the other things we teach in computer science classes that help students to become more comfortable with debugging their own code. Of course this takes time and practice—students often don’t pick up these habits until they’ve really struggled to get a program or two working, and I’m not sure how you fit all this into a math class that already has a lot of content to cover.

But my experiences thus far make me worried for the teacher of 30+ students in a math class who is trying to get their students to do some sort of programming activity that asks for students to work independently in class. What sort of structures or activities could a teacher put in place that don’t consume too much time but could help students be better at troubleshooting their own code?

I need to write a much longer post detailing my work in Norway and all the things I’ve learned, but I first want to publish this very small example of some of of the things I’m working on.

Here’s a little bit of background. The Ministry of Education of Norway has decided to make programming part of the 1-13 mathematics curriculum for all students in Norway. This requirement will be part of an overhaul of the entire curriculum in all subjects launching in 2020.

In addition, the Norwegian government has allocated a significant amount of funding to support training and professional development for teachers. Since most math teachers have very little previous exposure to programming, this is going to be a very big undertaking.

I’m working with some faculty at the Center for Computing in Science Education at the University of Oslo to help develop training and lessons for teachers in Norway. At the moment, we are developing training for a cohort of year 8-10 math teachers in the Oslo Kommune, which will consist of a single day workshop followed by 3 half day workshops later this year.

Our goal is to train these teachers in the fundamentals of python programming, and also to help them find ways opportunities for where programming and computational thinking can extend and enhance mathematics education. I’ve been re-reading Paper’s Mindstorms lately, and again am taken with Papert’s description of how the computer can create an environment where students are free to explore and test their mathematical ideas. There is another blog post I need to write about re-reading Papert—it’s amazing to me how relevant this book is to educational technology and computing 20 years after he wrote it.

All of this has put me on a quest to find interesting problems in mathematics that might be fun to explore with computing, and this is where I want to share the example of the locker problem.

I can clearly remember when I saw this problem in my 8th grade Algebera class. Newly (over)confident that I was proficient in solving any equation involving x, I was completely thrown by this problem because there didn’t seem to be any equation I could write. My 30 year old memory is hazy beyond that, but I mostly just remember wanting to know the answer, and not really having any tools to explore it. Were I teaching this problem today, I’d love to send my students off with whiteboards, and have them make sketches trying to find patterns for the first few students.

There’s so much you can do to think through this problem with pen and paper, but now, I also got to thinking it is a great problem to also explore with a bit of computing.

I’ve created this Juypter Notebook for my first draft of an activity that explores the Locker problem with computing. Here’s a version that is viewable on the web.

In creating this activity, I decided to take a scaffolded code approach. I wanted to provide students with some code that they could use for their own explorations, and assume they have only a very basic understanding of python loops and arrays. I created a Locker class that held the number of the locker, the current status of the locker (open or closed), the number of times the status has been changed, and the list of students who “touched” the locker, along with functions to “flip” and print the status of the locker.

From this, students can create an array of lockers, and then go about flipping various lockers to explore the problem. One goal of the assignment is to get them to see how they could simulate the problem and then look for patterns to generalize.

From here, I’m hoping students can do a bit of noticing and wondering about the patterns they see in this set of lockers, or possibly see what the patterns look like when they do the same action on 100 lockers.

I’ve never taught middle school before, but, my thought is that if students were comfortable with the basics of programming and the Juypter environment, they could walk through this notebook and use it to test and expand the initial work they did to think about the problem on paper or a whiteboard.

At this point, I’d love some feedback. Does being able to quickly simulate all 100 or 200 lockers give students more insight into the problem? Does it allow students more room to explore their own ideas, perhaps seeing what happens if you skip a student in this process? There definitely seem like plenty of ways for students who are comfortable with programming to extend this code—perhaps printing a list of all of the open lockers, or a function that will print the number of times a locker was touched.