Trying Out PRIMM with Javascript

At some point over the last few weeks, I stumbled upon the PRIMM structure to teaching programming from the King’s College London. The gist of it is described in the image below:


Poking around the King’s College website, it seems like this is a relatively new framework for introducing new code snippets and programming concepts to students – there’s a pretty awesome table on the blog link above that gives more info about each of the steps, how to apply them, and why to apply them. It was immediately appealing to me since it checked some pedagogical boxes I was already familiar with – like asking for a low-stakes prediction as the entry point to a new concept – while also adding some structure that I hadn’t codified on my own. I also liked it as an alternative to the typical ‘code along’ strategies I see most places but have their own issues that Kaitie O’Bryan does a pretty good job of documenting in a longer post about the challenges of teaching coding in a high school classroom.

So, I decided to give it a shot. I’m currently teaching a Javascript course with Upperline and had a section of a lesson where I thought this strategy might work pretty well. Without giving too much away about the lesson & curriculum itself, the gist is: students had already written HTML and CSS, but no Javascript yet. By the end of the lesson, I needed students to basically be able to add an event listener to an HTML object and, when that object is clicked, toggle a certain class on or off. In other words, they needed to understand these 5 brand new pieces of syntax within the next hour:


In delivering the lesson, students are already given a website with the HTML and CSS pre-loaded – all that’s left is to learn the Javascript. The website itself also has only 3 objects on the screen to interact with – but, the fact that it’s exactly 3 things is one of the things that inspired me to try PRIMM with this lesson (more on that below). Also in delivering this lesson, students are already setup in a shared Slack channel where I can send out messages and code snippets as need be. This was another vital component of the lesson that made me want to try PRIMM.

We started with a blank Javascript file, so the first line we added was console.log("Script Loaded"). This was actually pretty straightforward – I could’ve asked for predictions and made comments and things like that, but I opted to move faster through this part. Once I made sure everyone had a statement in the console, we moved on so I could introduce variables and querySelector() at the same time.

At this point, I had students turn off their monitors and only follow along with me on the board as I added this line of code:


Then I asked them to chat with their neighbor and (1) list anything that looked similar to something they had already done (hoping they’d pick up on the similar CSS syntax) and (2) say what they think this line of code is doing (Predict). After 30 seconds, I don’t have them share out but instead add this to the screen:

let taco1 = document.querySelector("#taco1")

Then I repeat the same questions: anything look familiar, and predict what they think is happening. Again after 30 seconds, I add this:

let taco1 = document.querySelector("#taco1")

Again talk, but this time I circulate and listen in. My hope is that, by writing the code in steps, students figure out that there are multiple pieces interacting together. I’m also hoping that by writing the code out of order (ie: not left-to-right) they realize that sometimes the first piece of code we actually think about isn’t the first piece of code that gets written on the line – sometimes that code is on the other side of an assignment operator or its inside the argument for a function.

As a sidenote – everything before now feels very different from how I would previously try to do this with a ‘code-along’ style. In that framework, students would be typing along with me and I would be trying to explain each line of code as we type it – we’d be creating the code together. This usually means I’m typing and speaking at the same time, which means students are typing and listening and looking (so they can see what I type) at the same time. I’m also usually forced to type from left-to-right, since trying to give instructions to add something at different places in the line is a pain and a recipe for typos and students getting lost in the explanation. Now that I’m reflecting on this process, I really appreciate how this process focuses students on the things I want them to understand at this point – attaching meaning to syntax – instead of being distracted by typing speed and multiple sensory stimuli. Without these distractions, I think I can ask more cognitive work from my students as they try to understand the code.

Back to the lesson. After a minute, I Run the code and show what happens (spoiler alert: the HTML for the taco1 div element appears in the console). After watching this happen, we finally share out and I ask students to share what they think is happening and compare that to their predictions. In today’s class, students pretty solidly intuited what querySelector() does, had a novice’s idea for what a variable was which I could shape into something more rigorous, and still had no idea why the code needed to say “document” in front (which I could clear up).  As we Investigated the code in-depth and I added academic language to their comments (‘we call this a variable’), I was happy that the explanation seemed more evenly split between student-talk and teacher-talk, even if my teacher-talk was very purposeful. In retrospect, as I write this post, I wish I would’ve thought of a way to ask questions connecting incorrect predictions to what’s actually happening to help emphasize that even though there is a ‘right’ answer to what’s happening, those initial predictions are still valued even if they’re incorrect. Gotta think about that one some more.

At this point, I took the code snippet I had written and sent it to the students on Slack with the following instructions:

  1. Copy and Paste my code into your program. TEST that it works. It should work exactly like we saw in the front of the room.
  2. Copy and Paste my code to another area of your program, then Modify the code so now you’re selecting the second object on the screen. TEST that it works.
  3. Make the code from scratch (typos and all) to select the third object. TEST that it works.


Walking around the room, I was happy with the scaffolding this provided to students and the opportunities to isolate mistakes for debugging (ie: intense spelling mistakes were mostly relegated to the final Make part of the process). I also like that it challenged students to understand which aspects of the code were static and inherent in the code (like let or querySelector) versus which things needed to be changed to fit the situation. Lastly, to Kaitie’s point above, it significantly reduced initial typing issues if I had asked students to follow along. Instead, students could feel ownership over their code from the Modify step before possibly being bogged down with typos and other novice mistakes. Oh, and I also got to touch on iterating your code since I was asking students to test frequently as they edited their code.

As the lesson continued, I repeated the process with this snippet of code:

taco1.addEventListener("click", e => {
console.log("Clicked Taco 1")

Again, we Predicted in steps, Ran the code, Investigated the pieces (which was much more teacher-centered as I explained what the arrow function did and what the e stands for), then I sent the snippet to them where they Modified the code for the next object and finally Made their own code for the last one. To my surprise, there were very few typos as they went through this piece even though the syntax is complex. Maybe it’s because in the Modify step students are only focusing on what things need to change in order to get the code to work, which means in the Make step they can focus entirely on just spelling things correctly and getting the syntax right. Without splitting these up, students are trying to process both the syntax and what pieces of the puzzle they’re responsible for changing, which can be overwhelming. Separating those into the Modify and Make steps might help ease some of that mental work. I think I realized that as I was writing this paragraph. That’s cool.

Lastly, I added in the final Javascript with the .classList.toggle() command, again asking them to predict what would happen. I guess I should say, before each of these sections, I was also letting students know the motivation behind each snippet – we want to make sure the javascript is linked correctly, then we want to grab our HTML element, then we want something to happen when we click it, and finally we want to flip one of the classes. I think this whole endeavor would be less valuable if I was skipping those steps and students were only writing code without me telling them why we’re writing the code.

At the end of this segment, I grouped together the new lines of code we had written (as seen in the picture at the very top), added the underlines and the numbers, then asked students to describe to each other what each piece did. I could’ve added more structure to this, but I just let them talk and then checked in with them to see if they had any questions – most students were fine. After going through this, they were given an additional assignment to practice these skills in a different context. That’s about it.

Reflecting more generally on this process, I definitely felt like I could ask better questions and get more student engagement using this methodology rather than a traditional code-along. I was also worried how well students would have ownership over the coding, since I’m writing most of the code and they’re mostly copy-and-pasting it, but I was pleasantly surprised with how much they seemed to understand the code itself and its pieces rather than seeing it as larger arbitrary chunks. That may be a credit to the scaffolding involved with how the code is presented and that extra Modify step where students have to pick out the pieces from the larger syntax. I was also worried about timing – I thought this would take longer since there are these extra steps before students are actually writing code – but I think it all evened out in the end and took about the same amount of time as if we had coded most of it together. I think the gains happen when students are modifying & making their code – in a code-along, when I would send them off to write their own other snippets, there were usually lots of debugging questions or concept questions, so it would take longer to address all of those. With this process, students stayed mostly at the same pace and we could regroup easier – I didn’t feel like I ever had to say “even if you’re not quite done, we’re going to move on…” which is always a crappy announcement.

Lastly, I think I want to bring this process back to my classroom, and a key piece of that is using GitHub and Slack to disseminate code (either wholesale in Github or in snippets on Slack) directly to students. I think that’s been the missing piece of the puzzle in my own high school classroom (Google Classroom is terrible with code) and a key part of this process – the ease with which students can obtain my code and modify it. This even shows up in the PRIMM guidelines on that website way back at the top – the importance of starting with a working piece of code, then gradually transferring ownership by modifying and making. I’m already thinking of ways I can use GitHub in my class with their Classroom features, but now I’m also wondering about using Slack with my students too as a way to quickly share code mid-lesson. Gotta look into that one a bit more.

One thought on “Trying Out PRIMM with Javascript

Add yours

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: