Thanks for the questions!  Actually, the free-play group in general completed more levels of the game.  We also have some initial evidence that the free-play students progressed more in debugging, which isn't what we were expecting!  We are still doing more detailed analysis around the differences between the groups.  The goals the goal-oriented group set were chosen by the students and often involved "getting to the next strawberry" because the character collects them.

Hi Robin! Thanks for your valuable feedback. 

We had six game sessions and students switched their play groups after the third session. Based on analysis of our data so far, there are some indications that students who played the game without explaining (freely-play group) in first three sessions performed better on debugging than students who were forced to explain while playing (goal-based, explained play group). Further, students who played the game without explaining completed more levels. 

For goal-based explain group, students set their own goals after we asked them "Where would you like to go?". Once pairs created code, we encouraged students to explain how their program helps them for reaching the goal. 

Hope this helps. 

That's really interesting. I wonder about the best use of student explanations in all math classes. You said there was some evidence that the free play group did better on debugging. That's definitely not to say explanations weren't valuable, but I wonder if explanations need to be timed so that they don't interfere with the flow of problem solving. 

That's a really good point.  It was often hard to get groups to stop and tell us what they were planning to do; whereas, when the game wouldn't let them progress until they used certain programming pieces, they had to slow down and often communicated more.  We'll be playing around with having students do some explaining before playing this year.  We also thinking about ways to continue supporting their talking to each other without interfering with their problem solving (but supporting their problem solving).

Yes!  It would be great for students to be able to learn without feeling like everything is high-stakes and to take a game-like approach to other areas of learning.  At the same time, we want them to learn from their trial and error so that they don't continue to make the same mistakes over and over.  We'd love suggestions on other tasks we could give to look at whether they use similar trial and error practices in mathematics.  We used a tangram task (where students use different shapes to fill in a puzzle in the shape of a fox), and many used a trial and error approach, but we did not follow up with another puzzle to see if they got any better.  

We cannot argue that only one group of students (either freely-play or goal-based explain play) commented in a certain condition (when code won't work, explaining how code works, describing what just happened). Both groups of students were more likely to comment in all these conditions. The main point is that all students in goal-based explain play group commented to explain code how it works because we forced them to explain. However, we cannot say all students in freely-play group commented code to explain how it works because some of them explained code when interacting each other although we did not forced them to explain. 

We are exploring what influenced students' interactions and explanations. Once finalized our analysis, we will have some factors that influenced students' interactions and explanations. Then, we would have stronger suggestions about teacher strategies to support students. Further, next year, we can evaluate whether our suggestions would be helpful for students' interactions and explanations.

Thanks for your comments and questions. 

I get lost all the time - sometimes intentionally. But I find it more fun to 'debug' my route by moving forward instead of backtracking. I learn a lot about a neighborhood that way, and am less likely to get lost there again.

Then there are times I 'debug' recipes in the kitchen. Hopefully successfully. Hopefully not requiring a complete trashing and restart (though that is an interesting question: how many of your students felt like 'debugging' required them to throw out everything and start again? How many could backtrack partway? How many could debug by just adding to the existing code?)

Then there is personal relationship debugging: where a comment falls differently than I expected and I have to figure out what went wrong and try to fix it.

Fun examples!  The recipe one is interesting...sometimes you can fix a recipe by adding more of every ingredient (if you accidentally added a little too much of something) but there are some cases where it's not salvageable.  There were times students did get rid of all of their code and start again.  My intuition is that this happened more after they tried to tweak things a few times but still had bugs, but we'll have to see after more detailed analysis.

Hi, Beth,

Just chime in after Laura. We also thought about the transfer to mathematical reasoning. On the pretest and posttest, we asked students some counting and debugging problems in math. After students played the programming game for six sessions, we expected them to get a sense of debugging and practice enough the reasoning for “why” and “how.” We found that students’ gestures revealed they could understand where went wrong. They just didn’t say the reasoning out loud.

Thanks for explaining. 

We had a range of interactions in the different gender pairs.  Some female groups were very silly and tried "crazy" programs that were hard to debug and some male pairs who were the same.  Regardless of gender we had some groups where one group member took the lead and the partner was a helper.  We had some groups where the partners traded off being in control.  It will be interesting to look at the progress of these different types of groups.

Michelle,

Thanks for your questions!

Your study is about URM students including female students. I’m curious about what you think of some strategies in encouraging girls to participate in math-related activities.

I was thrilled to see how this video set the stage for equality. I believe math and science are not gender based but have become stereotyped by society. By setting the task early for both male and female students and pairing them as equal with no gender colors/bias then students gravitate towards their interest and their skills develop naturally. The game was also challenging and provided enough positive feedback students felt free to explore. Which is critical for young minds and I believe will help offset previous society views of where women should and can work. 

Thank you, Michelle, for your comments. One of our goals was to help students understand the role of programming in STEM professions and explore their attitudes change after the intervention. 

Thank you, Michelle! You are perfectly right! The woman brain is not less functional than man brain so it can do programming, can do science, can do the math. The women are as good thinkers as man and the stigma of that stereotype hopefully in the near future will be forgotten.

Thanks, Amy!  Yeah, we thought that was interesting, as originally we were hoping students would get better at avoiding bugs.  Yet, it seems like purposefully exploiting a known bug could be helpful sometimes as this student discovered.  I think this gets at the complexity of programming and dealing with "real world" situations.

Hi, Leslie,

Exactly. The kids in pairs put coding pieces together, warned partners of potential malfunctioning codes, commented on and discussed how to make programs. We also find that some kids always took the lead while the other kids were always (passively) cooperating unless we told them to work together. This is not how two professional programmers work together. Professionals explicitly know what roles and responsibilities they take. So we’re thinking that next year we may assign kids different roles.

 That’s a really really good piece of sharing. Laura will likely have some things to add, but I’ll respond to what you said above.

Some friends of mine work in analytics companies and do cool coding stuff. Sometimes they told me they finished a small block of programming and then passed it on to next one and another one would collect all small blocks and put them together to make a huge workable program. What I said in the previous post might cause some confusion. I totally resonate with you that pair programming is fluid and flexible in terms of the roles and responsibilities. In our study, a student might start with a piece of code and the other helped finish the program; or a student might put all pieces together and the other debugged the program through comments.

I’m excited about the idea of having more training programs. Last year in the Goal group, we asked students to set a goal and explain their programs; in the coming fall, we might try out using worked examples as a form of training. So you as a software designer, science researcher, and engineering educator, must have rich experience in teaching programming. We’d like to hear your thoughts about the training of elementary students’ programming when the training does not interfere too much students’ own development of thinking.