In my post on "How What I Learned in Theatre Influences How I Teach Computer Science," I ended with the question, "is there a way to instruct students in what is really important that deemphasizes any required exam without being a detriment to it?" At the heart of this question is a confession that, while I hate standardized exams, I recognize they exist and I am still accountable to them. If you are a teacher, this is most likely your reality as well. The rest of "How What I Learned..." post described what I think is truly motivating and most important to glean from a good education. In my post, "How Github Makes Everything About Teaching CS Better", I explained what Github is, how I introduce it to students, and how my students use it on a day-to-day basis to collaborate. With this introduction of the theory and the tools aside, I'd like to finally write about what I do in my classroom to actualize my teaching philosophy. This post assumes a basic understanding of Github.
Let me begin by saying the most important thing my students should learn in my class is how to work as a team to produce an engaging product. I didn't take that from the AP Computer Science course description, this is what I want students to learn. After surveying students during the 2015-16 school year, I learned that a role-playing game was of greatest interest, so I designed a whole process that would bring that ambition to fruition.
The project would start from a template for a graphical user interface that we would code together in class. We called this our "game engine". The students would then self select a team (the Battles team, the Towns team, the Maps team, the Menus team...) and within each team students would envision what they would like the game to look like and present their concept designs to the class. The class would then vote on one of the presented designs to be the theme of the game. With this goal in mind, students would then assign roles within their teams. (In the Towns team, one student might be responsible for programming the Shops, another responsible for programming interactions with the non-playable characters (NPCs,) another person responsible for saving the game at the Inn, etc) They would then design a hierarchy for the classes that would embody this function and any interfaces that would be required for members of other teams to implement in order to eventually merge the teams into a cohesive whole. (The Shops programmer in the Towns team designed a 'Sellable' interface that another member from the Items team would have to implement in order to sell Items in Shops.) This was presented in the "Hierarchy Design Presentations." Finally, the teams would set to coding. Each team would work independently from the others. Therefore, the Shops programmer would have to program a SampleItem just to debug his or her code before integrating with the actual Items team. After all the programming was done, teams would present their demos. In practice, this meant the Towns team would present a "game" that consisted only of exploring a Town. In the last phase, students would integrate their code with the other teams. (As a result, the Shop no longer only sold SampleItems as was the case in the demo, but actual Items programmed by the Items team.)
My entire year was structured with end in mind. If it sounds ambitious, I can tell you: it felt ambitious, at times even daunting, but it also felt important. There are a few essential practices that enabled me to pull this all together. Ultimately, these practices compromise my "guide" to preparing students for an exam while deemphasizing its importance.
1. Vision. On day one, I told my students that our goal is to prepare for a career in programming. For some students, that meant they would have exposure to what real world programming even before college, to others, it meant a more informed decision of whether programming was something they would continue to pursue. To everyone, it set a clear expectation: they would not impress me or even do well if they could perform well on my exams, I would be most impressed and reward excellent products.
2. Motivation. It's contradictory to say you can prepare students for an exam you don't care about. You have to care, at least a little. So while I tell my students our sights are set on fostering innovation and collaboration, I also tell them the AP Exam is a means to that end. In fact, even while we code the game engine, I continually highlight the aspects of the engine that exemplify the AP's expectations. I actually tell them that, because our aim is career skills, the AP Exam will be simple. It isn't that we shouldn't care about the AP Exam, it's that the AP Exam won't be a reach for us. I go one step further in trivializing the exam by saying that there are a few "seemingly arbitrary and abstract skills" that the exam emphasizes to see if you can "think like a computer." I say (and I truly feel) these skills are "technical to an extreme that is hardly practical" but I assure them that we will take time to master these "tricks" by spending six weeks prior to the exam to study it in depth. So while the first seven months under-emphasize the exam, during those final six weeks, they would learn the exam so completely they would be dreaming about it. Finally, I point out that even these six weeks of exam-focus are in line with our career-focused curriculum because, as is the case with any job, there are some aspects of the job that aren't as enjoyable but are nevertheless rewarding.
3. Exam Expectations. You may retake every exam as many times as you want. When I say this, I don't mean there are multiple versions of the same exam. You may take a free response exam, have it passed back to you, review the solution and the rubric, and – assuming there is evidence that you tried your best the first time – take the same exam again. It sounds pointless, but it accomplishes so much. First, despite the advantage to taking an exam a second time, students prefer not to. They will study and take an exam seriously even in the first attempt, they understand that excelling on the first attempt is a stronger indicator of success in the AP Exam at the end of the year. Furthermore, there is a stronger sense of accomplishment when the exam is completed on the first try: not only does it earn a high mark, they also saved valuable time. Additionally, allowing multiple attempts enables students who are struggling to work towards an achievable goal. They can see their poor scores, understand the rubric, and have a concrete idea of what needs to improve in order to earn a higher score. Finally, it sends a powerful message: this exam is not so serious, or rather, is only as serious as the people who use it as a means of evaluation. There are some students who like exams because they consider themselves "good" at taking exams. But for students who have testing anxiety, struggle with exam skills, or are constantly asking "How can we use this in real life?" A policy of retaking exams says "It's okay, it's just an exam, you will get it with practice. We don't have to make our course revolve around it."
We did all of this during the 2015-16 school year (and are still doing it now.) Altogether, the game design project took about two months. Before we started the project, there were five free response exams. In the middle of the project, we set everything aside and spent six weeks preparing for the AP exam, during which we completed and scored three complete exams from previous years. After the AP exam date in May, we resumed with the integration phase of the game design project. By the end of the year, each team had integrated with at least one other team; some had integrated with two other teams. The game, as a whole, did not fully come together in the amount of time we had left after the AP Exam, but students reportedly learned a lot about the production process and real-world collaboration. Of course, what anyone really wants to know is: was it successful in terms of the AP exam results? Here are the results, as compared with the rest of the school:
(includes my class)
(excludes my class)
Exam results are released during the summer, so I was unable to ask the class as a whole to reflect on their success, but when one of my alums who returned for a visit, I was able to ask him. He attributed his earned AP score of '5' to the work done during the six-week intensive, citing that it was during that time when he really learned what the exam was actually "testing": the peculiarities of specific questions that consistently appeared on the exam, the expected pitfalls and how to think in order to avoid them.
Of interest is the fact that the student did not include his game design experience as a major factor in helping him earn his score. He didn't exclude it because he held it at no value, in fact, he reported that one of the most important things he learned was how to collaborate with others and communicate within a team. Rather, it was that the student distinguished between the two purposes of the course. The six weeks of exam prep served one purpose, while approximately 30 other weeks of learning to work collaboratively on projects served a whole other purpose. What makes me happy is that I got to spend most of the year teaching what I think is truly valuable and that had a lasting impact on my students. While the exam was deemphasized, it was not to any detriment.
If you are interested in a more detailed picture of how I assessed and scaffolding this assignment, you can review the 2015-16 assignment website here. Currently I am in the midst of the game design unit for 2016-17 and I've made sizable improvements by scaffolding the project with three assignments to serve as a precursor to what will soon be the final project. Each of those assignments is described in detail below: