The best part about the new version of CSP is that in each unit the “Make” tasks require students to code on their own. This Lesson reminds me of the previous version of CSP where students don’t code from the ground up. I think it is especially challenging in this instance when there are different possible approaches and the students have to essentially think like the person who wrote this code instead of think about how they would approach it themselves. I honestly think this lesson would make more sense if it was set up the same way as the other Make tasks and as a class we could discuss opportunities for functions, parameters, and returns. Why was this lesson set up so differently than the others?
Hi @dmaletta,
This project was originally written as you are describing and was tested in that format during the pilot. For some classes it worked great, but for a majority it turned out to be too much to get done. Some students had a hard time conceptually and needed scaffolding, others could have done it but would have needed more time than a one-day lesson would accommodate. Based on that feedback the project was revised with the intent of still engaging students in the design process, but with some pre-existing code in order to keep classes on track and to make sure students were focused on the parameters/returns portion of the app.
I think that this is good feedback to have. I also agree that it was a little too scaffolded in my class. In order to push students a little further, I required that they do an extension (of their own design) which includes writing a parameterized function. Maybe adding some addition like that could bridge the two styles with an outcome of something a little more like the other Makes?
Thanks for the idea. I will add in a requirement for students to create a parameterized function to compare the overall scores of player and computer!
After having taught this, I don’t think this particular approach was the most effective for students to learn parameterized functions… since the function calls inside updateScreen were all using names of variables for the arguments, I think it was not at all intuitive to students… I wonder if one or two of the parameterized functions was setup and then students had to figure out the updateScreen function, then it would be easier for them… I dunno… I just felt like this lesson was a loss today and now we are moving to libraries…
Part of the problem for me was that I didn’t feel prepared at all to lead the discussion on it. I think code.org does an phenomenal job of balancing college board requirements with content that teachers who are not necessarily programmers can deliver. The forum really helped a lot but I still felt there was a lot of room for improvement on my part.
Disclaimer: I have yet to experience this lesson with my class.
7.3 is when we ask the kids to switch from a procedural paradigm to a functional paradigm. That is a big change for them. 7.4 expects them to have made the paradigm shift, well almost.
I think that could be why it seems like a lot.
1 Like
I don’t know that I ever read this message last spring Don, but I agree with your assessment! I hadn’t thought about it in those terms, but that makes total sense.
1 Like