Citizen Schools
Citizen Schools is a national non-profit organization working towards educational equity. They work to provide hands-on learning experiences to students who otherwise might not have access to them. Students are enrolled in apprenticeships, led by career mentors who are experts in their fields. Mentors come to a Pitch Day, in September, and travel from class to class to pitch their apprenticeships to students. Students then choose their favorites, and The apprenticeships meet once a week, from 4:00-5:45pm, and extended from mid-September to end of December. The apprenticeship ends with a WOW! event, where students present their final projects to their classmates, families, and school staff.
I taught the apprenticeship, “Pencil Code”, which aimed to give students an introduction into programming. I worked at the Renaissance School of the Arts, located in East Harlem, alongside a Citizen Schools employee, Sean, who was embedded in the school. All the kids were comfortable with Sean, and he was largely responsible for keeping the kids focused on the tasks at hand. As a volunteer teacher, my role was to teach the material and plan out lessons and assignments for the apprenticeship. I was given a syllabus to follow, as well as several labs and exercises the students could complete during each session. However, I was also encouraged to tailor the syllabus to how I saw fit. As I reviewed the syllabus, I saw that the first half the semester covered the core programming concepts, and the second half of the semester was spent building a website. Each student works on building their own website and that ultimately becomes their final project for the WOW!. While web development is certainly important and useful, I worried that the kids wouldn’t have enough time to focus on building a solid foundation with the core programming concepts (conditionals, loops, etc). Much of the web development curriculum in Pencil Code was around CSS styling and adding HTML elements. As such, I decided to create my own curriculum for the second half of the semester. I drew inspiration from my time as a teaching assistant for CS15 as well as my time in industry, and decided the kids would build a game together. This would allow them to have a really complex final project, something they would hopefully be really proud of.
Goals
Develop a solid foundation in core programming principles
Ultimately, I wanted students to be comfortable with concepts like if statements, for loops, and variables. Students should be able to identify how and when to use these concepts. I also wanted students to understand how flow of control worked, and be able to explain what every line in their program does.
Bring the tech industry into the classroom
I wanted to show students that programming is extremely versatile and a career in the tech industry could mean many things. I also wanted to see if industry practices could be applied to the classroom to encourage collaboration and engagement.
Developing a Solid Foundation
While planning out the course, I leaned heavily on the existing syllabus for the first half of the semester. Pencil Code is a block-based programming language, based on JavaScript. I really appreciated that Pencil Code offered students the ability to toggle between the block view and the JavaScript view. This would help students be able to connect the dots between how the blocks work (significantly less intimidating) and how that translates into real code. Pencil Code also produced some videos that featured celebrities explaining programming concepts. I used these in class to get students interested in the new material for the day, and to break up the amount of time I talked during lecture.
The existing Pencil Code syllabus adopted a “challenge card” style format during lecture. After being introduced to the new concepts, students were given a series of challenge cards that walked them through how to use the new concepts. Each challenge became progressively more difficult, until the student was coding entirely on their own with no guidance. I liked the fact that students could work at their own pace- if they really understood the concepts, they could fly through the first few challenge cards and work on more complicated problems. If they were struggling, they could stick with the beginning cards and work at their own pace.
I did make some modifications to these first 5 weeks of lesson plans. For example, the lesson plans for the first week suggested playing a game called “Robot”. In Robot, the teacher is attempting to complete some task (i.e. laying on the ground and getting up) and the students must break down the steps and direct the teacher on how to stand up. The goal is make the students realize how much they assume another person knows how to do. In programming, everything must be broken down to the simplest of steps. This exercise is meant to show them the gap in what they think and what the computer does. Rather than have all the students direct the teacher, I decided to change this activity to something they could do in small groups. I drew upon my experience as a teaching assistant in college, and used an activity that went over well with my students there. Each group had 2 “programmers” and one “robot”. The programmers were given a gesture (i.e. “applauding” or “saluting”) and a set of blocks (printed out on paper). They then had to use the paper blocks to build a program that the “robot” then executed. The robot had to guess what gesture they were trying to act out. The kids were highly engaged and enjoyed trying to act out the steps.
Given the success of “Human Coding”, I made sure to incorporate similar exercises into my lessons where it made sense. In the “loops” lectures, I had the students act out a song by clapping, snapping, and stomping their feet. We then translated their actions into code that used loops. These techniques were also used in the conditionals and debugging lectures.
By the end of the 5 weeks, students were able to recognize and roughly explain the main concepts taught in the course- loops, user input, functions, conditionals, and animation. The next 5 weeks would be spent developing a game, which would allow students more practice in using these concepts.
The lesson plan summary for all 10 weeks of the apprenticeship
An example of a challenge students had to complete.
Blocks for “Human Coding”
Bringing industry into class
I tried to expose students to the various careers in technology from the very start. During Pitch Day, I spoke about how computers can be used to simulate walking cycles (and how that’s harder than the students might imagine). I drew upon my own introduction in computer science and spoke about animation, computer vision, and graphics as avenues they could pursue. Considering my school has a heavy focus on arts, I figured that would be a great way to inspire kids to take my apprenticeship. I continued to give examples of various careers in tech throughout the semester (including having some of my friends who worked at Google, Flatiron Health, and BlueSky Animation Studios come talk), but I also wanted to give the kids an idea of what it might look like to work for a tech company. This desire, coupled with the abrupt switch in course content in the suggested syllabus, prompted me to build my own syllabus for the second half of the semester.
I knew I wanted to have the kids drill down on the concepts they learned in the first half of the semester and I thought that the best way to keep their interest was to have them build a game. I was intrigued by the idea of turning my class into a mini game studio. I liked the idea of students becoming experts in their “field” and having to teach their classmates what they learned. For me, I always learn best by teaching others- there’s something about having to force what’s in my mind into words spoken aloud that makes me understand the concept better. I also wanted to have the kids work together in groups, so they could build on top of each other’s knowledge. On a logistical side, it was also much easier for me to help my students, since their tasks were bucketed (rather than each kid trying to build their own project). However, launching a class-wide group project would require a significant amount of planning ahead of time.
Planning the WOW!
The class-wide group project would ultimately end up being the students’ presentation during the WOW!. It would serve to be the culmination of all that they have learned in the class. As such, I needed to organize the project in such a way that there was a “minimum viable product” version that could be completed, even if we were running behind. My experience as a Head TA had shown me that it was best to expect that by the end of semester, we would be behind by at least a week or so. Somewhat amusingly, organizing this project felt reminiscent of feature development at my job. There would be a proof of concept (a version of the project I implemented to make sure it was feasible), a minimum functionality version, and then a “bells and whistles” version. If the students could finish the basic functionality of the game ahead of time, then we could collaborate and come up with realistic add-ons for them to implement in the time given.
Collaboration is really important to me, and I wanted the students to feel like they had a choice in their education. As such, I decided to come up with several different project options that students could pick from. The options were a modified version of DoodleJump (a platform jumping game), Tennis, Tic Tac Toe, Hangman, and Swarm. I presented each of the projects to the students, and then they filled out a worksheet. To get them in the “product thinking” mindset, part of the worksheet asked them to pick 2 games and identify ways they could make it better. This would help them later on in the project, when they would critique and build upon the game. Ultimately, they chose DoodleJump.
Students were also asked to pick what they would be most interested in working on. Based on my class size, I decided there would be 4 teams- 1 team for art design, 2 for game logic, and 1 for sound design. All of these teams would have tasks that would make use of the concepts they learned in the first half of the semester.
Breaking Into Teams
Once the game was settled and my students had indicated their interests, it was time to split them into teams. The two game logic teams were split into physics/animation (getting the character to jump and fall) and random generation (randomly generating platforms to populate the screen). The art team acted like designers- they were responsible for coming up with a theme for the game and designing characters/props to fit that theme. The sound team was responsible for crafting sound effects and background music for the app. I designed packets that outlined the goals of each group and led them through each task they had to work on.
The packets can be seen in their entirety here: Art Team | Logic 1 | Logic 2 | Music
Building the Game
As the kids worked through their packets, my job was largely to help them through any questions and start combining their components. The design team discussed and decided the game would be restaurant-themed and worked hard to create different props and characters that could be used. The physics team learned about gravity, and were able to play with making the character fall faster or slower, and make the character bounce higher. The randomization team focused on randomizing platform generation, and were able to create different levels of difficulty (based on how far apart the platforms are). The music team focused on building songs and instructions that would help onboard our players. After about 2-3 weeks of work, there was enough of a game that we could begin to have weekly critiques. This lightly modeled my experience with Agile programming and having “sprints”. While at work, sprints were formalized 3 week deadlines where each developer would have a completed task or feature to demo. Here, it was less about the specific timeframe, and more about giving the students the spotlight. Each team would have to talk about what they worked on and as a group, we would talk about any bugs we saw as we played through and come up with ideas for what could be fun to add. My students loved seeing the game together, and it helped motivate them through the rest of the their tasks.
Ultimately, the students were able to go above and beyond the “minimum functionality” that I had planned for. During our critiques, they suggested making the game a 2 player game and having monsters that the characters had to avoid. The randomization team worked on making the game 2 player, the art team designed the monsters, and the physics team handled the game logic for “losing” if the character intersected with the monster. Much like a real game studio, the teams were responsible for different parts of the same feature and were able to work together to create a polished final project. The fact that we were able to incorporate these ideas added to the student excitement as the end of the semester drew nearer. The final game can be found here.
Reflections
Looking Back
Overall, I believe the class was successful. The kids were somewhat comfortable with the concepts they learned, but often needed some prodding to recognize when certain concepts should be utilized. The most successful part of the class was building the game together as a class. The students within the teams had to work together, make choices, build “features” and then explain their work to the rest of the class. I found that these “teach-backs” were most effective in confirming the students’ understanding of the material and they felt proud to be considered an expert amongst their peers. The students were thrilled to have a complex game built by the end of the class, with many indicating that they would continue to learn programming.
Moving Forward
There are certainly ways I could improve my teaching of this apprenticeship. The first half of the semester relied a lot on drawing shapes and lines with a sprite. In the second half of the semester, a lot of the kids were not working on strictly graphical programming. As such, they struggled to pinpoint when to use concepts like if statements and for loops, outside of that “drawing” context. While the group WOW! presentation was successful, I feel that more work could be done to make the process smoother. I felt like I had to guide the students a lot through the tasks they needed to complete, and I wonder if having each individual child build a simpler game would result in more independence on their end. That being said, I think the kids did enjoy working in teams and building something together. I’d be curious to see if this could be replicated in other classrooms and if other industry practices could be useful in the classroom to motivate kids.