This article is about an assessment called "group quizzes." I titled this article "The Assessment That Changed How I Teach" because the advent of group quizzes is the most definitive and material change that has taken place in my classroom since I've noticed a substantial shift in my teaching. That shift is one in the direction of student-centered discussion, engagement in learning and self-reflection. I know that correlation does not imply causation and I've also been teaching for nearly a decade, so I'm sure this "change" can't solely be attributed to the success of an assessment strategy, no matter how fantastic it may be. Perhaps the strategy is really a catalyst for what was already set in motion by both years of experience and other events outside of my control. But I will offer this: if you are a teacher and you are even interested in shifting the focus of your classroom to center on your students and especially if you are willing or have already tried some new techniques to that end, I would say you are in precisely the position I was in when I discovered an assessment that was everything I was looking for.
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:
I have a very observant daughter. Sometimes, she's sorta like Navi in The Legend of Zelda, Ocarina of Time.* Even if the only word she can say is "Hey!", her attention to a certain, nearby objective is often so relentless that it begs to be addressed before continuing onward. For example, one time while she was riding in the stroller and Kay was in the backpack, a grey mitten fell off Kay and landed in the street as we crossed. Rae began to cry and point but didn't yet have the words to explain what she had seen. Because the color of the mitten had darkened from the water it absorbed, I couldn't even make it out against the asphalt. Still, Rae persisted. It wasn't until I conceding to walking back across the street that I finally recovered what had been lost, and it was all thanks to Rae.
A similar event happened not too long ago. I had picked Rae up from day care and we were taking a new route home, but the holiday window dressings on this route were a sizable distraction for Rae and we were making very slow progress. As we walked by the park, my thoughts began to drift to dinner and what I would be preparing. It was getting late. To compensate for lost time, I made the executive decision to pick up Rae and carry her the rest of the way home. Rae began to fuss, which I attributed to her not wanting to be carried, but I had already made my decision. We were going home now.
Her fussiness only grew. We were a block from home at this point, then half a block. She only got louder. She was saying something, but I wasn't sure if it was words or just noise. I set her down on her feet and looked her in the eyes.
"Rae, Daddy wants to help you but you aren't using your words, sweetie. I need you to stop crying and really try to tell Daddy what you want."
In rather cinematic fashion, a single tear fell from her eye. She shook her head, as if to say "I don't have the words" or perhaps "I've been telling you this whole time, you just don't understand me." The only actually word she said was, "Please."
I had no idea what she wanted, but I understood one thing. Whatever it was, it was of dear importance to her. I picked her up and we began to walk back.
One block. I set her down.
"Is it here?"
Rae pointed back farther. I picked her up and we walked another black. I set her down again.
"Is it here?"
Rae shook her head and pointed back farther.
"Can you show Daddy?"
She began walking back on her own now. I was following her. Rae carefully examined each building. It was very near. Yes, this is it. Rae pointed.
"Star." She declared.
Indeed. It was a start mounted in some custom framing shop. Rae had only wanted to stop to admire the Christmas star.
We took a picture to show Mama.
That's some two-year-old.
*Navi is a fairy side kick that is animated as a pink or white glow in the video game. She isn't always very articulate but helps you out with the most important stuff, especially when you are lost. (I have to explain these things for my mom.)
Before I began drafting the game design project, I spoke to a few people about how team projects are done in the professional world. One guy told me plainly, "If you aren't using Git, you're doing it wrong."
I knew I needed to learn how to use Git, but I couldn't figure out where to begin. I understood it was version management software that enabled multiple people to collaborate on a single project, but every tutorial I found made immediate assumptions about words I didn't understand. What was the difference between "Push" and "Commit"? Between "Pull" and "Fetch"? "Repository" and "Branch"? I was able to follow the tutorials, but the tutorials didn't give me an understanding of Git that made me feel comfortable teaching students, let alone debugging issues as they arose. What I needed was an all-in-one tutorial that explained Git like I was a ninth-grader.
I can't say I've yet mastered Git, but I have learned a whole lot - to the point where I think I could write a tutorial for a ninth-grader. I am sure my technical depth of understanding is limited, but if I can't paint an accurate picture of all of its inner workings, I can at least paint a functional one. That is to say: please forgive me (and kindly correct me) if there is an error in my explanation.
Consider this a starter's manual for using Github in the classroom. There is a lot of information on this page, so I've separated it with headers. The information is intended the read like a tutorial, not a reference, but if you are already familiar with Github, you might just skip to the end.
What is Github?
Git is version management software. Github is a website that freely hosts public Git projects (private projects can be hosted for a fee.) Eclipse is an Integrated Development Environment ("IDE", which is essentially a program for programming) that includes integration with Github. Eclipse + Github is how I interact with Git. It doesn't have to be that way, (you can actually use Git independently of both Github and an IDE) but it's what I know. So while the principles of Git remain constant across any configuration, I don't have the practical experience to use Git on its own. Git does not have a user interface, it is run through the command line.
As version management software, what Git does is organize changes that are made to a file system and the contents of its files. Git can manage changes made by hundreds of collaborators, so to do this, Git has to be very smart. The foundation of this organization is called a repository. A repository is a designated location for all of the files associated with a project.
Before we continue, something else must be understood about repositories. The people who work on that project are sharing their work over the Internet, so naturally, the repository is stored on a server. This would be fine, except if that was the case, every collaborator would be required to have an Internet connection in order to work on the project. Sometimes, having a constant Internet connection isn't an issue, but when it is, it is nice to have a copy of the server's repository on your own machine. Such a copy is called a local repository. Periodically, it is necessary to "update" the local repository. When this happens, it is called "fetching". You 'fetch' changes made to a repository.
As was previously stated, a repository is a designated location for all of the files in the project. One repository is online (on Github, usually) and a copy is kept in your machine. Let's suppose three people collaborate on such a repository, Arianna, Brian and Conner – conveniently abbreviated A, B and C. These three are working on a home screen for a Web app. At this point in the project, it fulfills basic functional requirements, but Conner wants to give it a little extra. Let's say he wants to add an up-to-date weather panel. He needs to code this function from the ground up, and he's worried that if he updates the current version, during the debugging process, the basic version will be rendered non-functional. What Conner really needs is a "draft" version so he can make adjustments to without the risk of ruining the original version. In Git, this is called a new branch. Branches are different versions of the same repository. Typically, the working, published branch is given the name "master". So when Conner makes a new branch, he calls it "c-weather". So now, ABC's repository had two branches: a "master" branch that contains a version of the fully-functioning program and a "c-weather" branch that contains everything from the master branch, plus some changes made by Conner that may or may not work. By switching between branches, one can view the entire file system according to the updates made within that branch. Just like there's a local repository, there is also a local branch. As Conner continues to work, the changes are made on the local branch. When he is ready to share his work with the rest of his team, he will move his work from the local branch to the branch on the server, a process we will describe shortly.
Now, Derek, Eric and Fatima (DEF) come along and admire ABC's open-source project. They say "Hey, what you have is really nice, we'd like to do something similar. Can we work with you?" But ABC are a little protective of their work and they don't think it's wise to give collaborative privileges to a group of strangers. They want a way to let DEF make a new "branch" without actually letting their "branch" be a part of the original repository. So what DEF are given is the ability to "fork" the repository. Forking means creating an independent copy of another repository. By forking ABC's repository, DEF can see all the branches and add, change and delete without bothering ABC.
So if Conner has his own branch, theoretically Arianna could have also have her own "a-sports" branch and Brian could have his own "b-business" branch. With all of these different branches, what does team ABC do when they want to combine each branch and make an updated master version? The short answer is the have to merge their branches back into the master branch. When Git merges changes from one branch into another branch, it compares the differences between the two branches and marks anything that might be a conflict. Therefore, the process of merging sometimes involves carefully reviewing and resolving the merge conflicts. It can be rather complicated. So at this point, you might be wondering, "Which is the best method for my class? Branching or Forking?" Answer: neither should be used when you are first learning Git. Now that you know about branching and forking, let's plan on not overwhelming our students. At the beginning of the year, I simplify this whole process by giving each student their own repository with one master branch and I teach Git in such a way that merge conflicts are often avoided.
Okay, so we have student Arianna who now has her own repository because she followed the steps on her teacher's class website (and you can too.) Note that Arianna did this herself. It is not necessary that the teacher set up each student's repository. After learning the difference between her Github repository and her local repository, Arianna is now interested in how Github is used. She knows that she will be using the Eclipse IDE to edit code. The files in the Eclipse IDE are a reflection of her local repository. The question, then, is how do you link the local repository to the Github repository? This link is called a remote. Remotes are assigned a name (useful for when you want to connect to multiple repositories) but my students will only ever use one remote. The name of that remote is, by convention, "origin". The remote sends changes from her local branch to her Github repository in a process called pushing and receives changes from the Github branch to her local branch in a process called pulling.
While Arianna works on Eclipse, she can save changes the old fashioned way as often as she pleases. Occasionally, however, she might want to "dog-ear" a particular change in her program. That is to say, she may want to mark a change so that she can return back to it or maybe she wants to consider updating the repository with the change. Such a change is called a commit. Updating the repository with the change is called pushing a commit. While you can commit without pushing, you would only do so for the same reason you dog ear a page of a book - to return to it later. Going from a local repository to the server is often called "pushing upstream". The remote is the instrument that handles the push. Technically, (but in no particular order)it verifies the commit (all commits must have a message to describe the change,) checks that there are no commits upstream that the user hasn't already integrated into his or her local branch, verifies the user's credentials (password), then updates the correct branch with the new commit. Configuring the remote for pushing is as simple as specifying which local branch get pushed to which server branch. Because Arianna only has one branch, this is a no-brainer: master → master.
Let's suppose Arianna is at a computer in the library. The library doesn't have Eclipse on its computers, but it has a browser. Arianna can actually log in to her Github account and edit her code through the browser. This is, in fact, even easier because since Github is operating on the server, no remote is necessary, she's already on the server repository!
So, let's suppose the next day, Arianna come into class and attempts to push her code again. She's going to run into a problem. If Arianna made commits from the library, the remote will see there are upstream commits that aren't already integrated into her local branch. It's going to give an error with the label "non-fast-forward," meaning in order to push the new commits, they must incorporate all prior commits. Incorporating upstream commits into your local branch is called pulling. Not the difference between fetching and pulling: Fetching updates your local repository to reflect the server's repository. Pulling pulls those updates into your local branch – the branch where you are doing your work. Fetching isn't very useful if you only have one branch. You might fetch if you wanted to checkout (look at) two different branches and compare them before deciding which one to pull.
Arianna pulls her code from the library and now that her local branch is up-to-date, there will be no problems the next time she attempts to push.
PROBLEMS THAT OFTEN ARISE IN CLASS
The most common problem with pushing occurs when there are upstream commits that need to first be pulled. Occasionally, those upstream commits conflict with what you've done in your local branch. When that happens, those conflicts are annotated with marks that signify a merge conflict. The marks separate two groups of code: one group that reflects the changes upstream, another group that reflects the local branch, or "HEAD". The user must resolve these conflicts by deleting irrelevant code. Once the merge conflict has been resolved, the commit can be safely pushed.
Sometimes, in the worst of cases, a merge conflict may be too problematic to resolve. When this happens, it might be easier to force push. To force push means to deliberately override any and all upstream commits. The option to force push appears as a check box in a dialog box that appears when you select the option to Push with options ("Push..." as opposed to simply, "Push".)
Sometimes (but usually only when directions were not properly followed) a student really, really messes things up. Eclipse might deny any attempts to push, providing an unknown error message. There have been times when I can't tell what the student did and the student also cannot remember what he or she did to stop absolutely anything from working at all. When this happens, I often delete the Git repository (right click on the repository in the Git Repository view and select "Delete repository") and all associated working trees and directories. It is then possible to import the project from Github and start fresh. (Instructions for importing are also on this website.)
Now I'd finally like to address the title of this post, "How Github Makes Everything About Teaching CS Better." Let me start by saying this is my first year using Github from the very first week of school. Last year I only used it for the final project at the end of year. Wow. What a difference it makes to get students accustomed to Git from Day One. Here are all of the reasons why using Github is the best thing I ever did for my instruction, as well as a few additional tips:
Like my students, I use the Eclipse IDE when I write code in class. The computer is hooked up to a projector and students can follow along, copying the code and comments as I write. Git provides an added resource for students however: at the end of the day, by simply pushing my code, everything I have done in class gets updated to my online repository. With a link to my repository, every student (even those who are absent) can view my original code. This is helpful for students who have difficulty keeping up on their own machines or for students who are out that day.
2. Reliable Back Ups
Before I started using Git, students were bringing in their own flash drives to back up their code and bring it from school to their home computers. Not only is this cumbersome, but the teacher desk in the computer room currently stows about twelve flash drives that have been accidentally left behind. With Github, students have their repository on the server, a local repository at school, and a local repository at home. Flash drives are obsolete and the back up system is almost fool proof. Even if the student could some how corrupt both their repository at home AND the repository on the server, when the student comes into class, I can help him or her restore everything by force pushing from his or her repository at school.
Github allows you to edit your repository through the browser. Occasionally, I get a student who is having trouble setting up Eclipse at home. He or she says it is preventing them from doing their homework. But when I show my students that, using Github, they can even do their homework on their phones, excuses go out the window.
4. Presenting Code and Grading
At the beginning of the year, I have all of my students fill out a Google form to provide their Github URIs. Google then generates a spreadsheet that organizes all of that information. Throughout the year, if I ever want to see what a student has been doing, no matter where I am, I can either pull his or her repository into Eclipse or view it online through Github. That means I can grade whenever, wherever and if the student has to present in front of the class, it only takes about 30 seconds to import all of his or her code onto my machine. It's astonishing to think I actually used to have my students copy, paste and email their source code.
5. Working in Groups
I recently had students complete a project, working in groups of four. At the end of the year, they will complete a project as a whole class. Between now and then, I will teach them how to use branches, but until them, I have simplified the procedures for setting up and collaborating on a Git repository. One student acts as the administrator. This student creates a repository on his or her own Github account. The student must manually add the user names of the other member of the group to the repository's list of collaborators, which can be found in Settings. The admin is solely responsible for the Main class (the class that contains the 'main' method.) All of the other members of the group create and maintain their own class files. As long as every student only makes edits to their own class file and the admin is the only one who makes edits to the Main class, merge conflicts are completely avoided. The students must be taught that they cannot push their own code until after they have pulled commits by the other members of their team. With these norms in place, working together is easy. Not only is it easy, but it provides information that is not available any other way. In Eclipse (and on Github) you can view the history of commits on a given branch. This history shows every commit by every student and the time of the commit. A teacher can see if a student is not pulling his or her own weight or if a student appears to be procrastinating. Furthermore, using the history, a teacher can checkout the project at any time in its history. For example, I assigned a project that was due Friday at 2:00pm. It took nearly a week for all of the groups to present, but the group that presented last had no advantage over the group that presented first: I only checked out commits that had been made before the deadline!
I've only touched the surface of what Git can do. I would encourage you to learn more about how you can use Git by learning more about multiple branches, which is really a necessity if you are planning on assigning a major project that might go through multiple versions. Some thing else you might try doing is looking at real world, open source projects via Github. One could even fork such projects and customize them in class! While the learning curve may seem a bit intimidating in the beginning, I am sure your students will enjoy the possibilities that become available to them once managing a repository becomes routine.
My first love was theatre. As a freshman in high school, I found it to be a welcoming and fun after school club. I auditioned for all of the shows, enrolled in the elective every year and participated in every event. Even while I began to discover my love for math through AP Calculus during my senior year, I was simultaneously absorbed with competing in the state monologue competition and auditioning for colleges. When Willamette University offered me an acting scholarship, the only reason I decided to double major in mathematics was because my grandparents asked me to consider a back-up plan. I was actually hoping to go into education anyway, so during a time when funding for the arts was constantly being cut, it sounded wise to keep my options open.
The acting scholarship made demands on my time that overshadowed anything the math department asked of me. I had to take on a responsibility in each of four shows every year and even my work study was in the theatre's set building shop. Nevertheless, the joy of mathematics continued to grow in me all the while. The math major required a semester of computer science, which I begrudgingly took during my junior year. While I am sure there must have been an exam in that course, I don't remember taking any; I remember working on several projects. I enjoyed it far more than I expected. That was also the same year when, for the fist time, I questioned whether I might prefer to teach math over theatre. The day I found Math for America's ad in the math magazine in the department lobby was a day of fate. "If I can land that fellowship in NYC," I told myself, "I will teach math instead of theatre."
Well, all of that happened. Six years later I found myself well into my career teaching math (and sometimes physics.) One day, I realized if I could revitalize those old programming skills, I could use them to automate routine tasks, saving both time and frustration.
Programming to simplify my work became an addiction. As soon as I realized the ability to automate something simple, I wanted to expand into more complex tasks. I spent hundreds of hours studying programming and integrating it into my day-to-day work. I also began meeting professions and learning what it was like to have a career in computer science. This is how, with no more than a semester of formal course study, I had the nerve to volunteer to teach AP Computer Science.
Unlike what I could say about the coursework I did in earning my credentials to teach mathematics, I cannot remember ever having to prepare for an exam in computer science. The lens through which I understand and experience C.S. isn't like mathematics at all. I would say computer science is a tool – a source of empowerment (or something) – but whatever it is that I find useful about C.S. could easily be said about mathematics. The difference is, what I've learned about math, I've learned through years of studying for exams. I hate to say it, but examinations are the one, consistent trend in every course I've ever taken. In turn, while I prepare my students for an exam year after year in my own math class, I justify it, thinking I myself have witnessed how these exams, however arbitrary, are a means to a greater end. But I cannot say the same thing in a computer science course. To me, computer science is more like theatre.
There is one advantage about studying theatre that is easily missed. Recall: I participated in every production in high school and was required to participate in every production in college. That amounts to twenty four productions over the course of my education. Each of those productions required me to play a varying role in a much greater, artistic vision. Each required that I reach achievable goals –whether it be memorizing lines or building a set - before an inevitable deadline. Each required me to work with a team, respect a chain of command, and rely on others when the pressure was on. Each required me improvise when something outside of my control went amiss – whether it be a costume malfunction or a missed line. By comparison, I wrote essays in English, I wrote lab reports in science, I took exams in math. In my own education, I can think of no other discipline that has provided more than twenty four opportunities to practice such a diversity of real life, professional skills.
So when I started teaching AP Computer Science, I began by asking myself, how could I make computer science for my students what theatre was for me? I began talking to the friends I had made in the industry and asking how they worked on a project. I learned how to use the tools they used to communicate and collaborate and I began to write an outline for a game design project that could be completed by students using the same tools. I wrote all of this into my course syllabus and, after two revisions, it was approved by the college board.
I just completed my first year of teaching AP Computer Science and - while everything I've said up until now paints it much rosier than real life, it was still a wonderful year. If you're curious about what I actually did, you can find everything I gave my students here and here, and I will continue to update these resources throughout my second year. I'm planning on writing more in my next post about how I've actually implemented such a project in addition to preparing students for the AP exam. Until then, I'd like to leave you with a question or two. In STEM classrooms, would you consider exams as commonplace as I do and if so, is there good reason for this? And if – like me – you don't think there is a good reason for this, is there a way to instruct students in what is really important that deemphasizes any required exam without being a detriment to it?
This year, I used my Math for America flex funds to buy a 3D printer for my geometry class. My goal is to desgn unique models to support the Common Core Standards in Mathematics. If you are aware of any other resources where one can find similar .stl files, please let me know in the comments and I will post the links here.
What Defines a Good Board Game
A good board game is one that is suited to your tastes and the dynamic of your gaming group. The best board game, then, is not the most popular board game necessarily, but the one that fits your own personal niche in a way no other board game can. The games that are most popular (Agricola, Twilight Struggle, Dominion, Pandemic) are really just the gateway to finding a more perfect game. This is my to ten list, which is to say, ten games that have had the most success at my table. Are they the best games of all time? For me, they definitely are, but they aren't all conventionally popular, and that's okay. If you want to know if these games are right for you, then understand the criteria that - for me - make a great board game:
- I like a game with mechanics that serve the theme. A great game with a "pasted on" theme is no theme at all.
- I like a game that plays at a pace that keeps my interest. Both fast games and thoughtful games accomplish this in their own respective ways, but a game with too many decisions and resulting "analysis paralysis" is to be avoided.
- A good game relies primarily on strategy, very little on luck. Not only do I appreciate a game that rewards strategic thinking, but when a game contains components of luck, a good game is liable to be ruined by a horribly unlikely card draw or roll of the die.
- A good game fits the occasion. Often, I prefer a heavy, two- to three-hour game, but sometimes, with the right audience and the right time, I just want to have a blast for 20 to 30 minutes. When the occasion is right, I'm willing so sacrifice in any of the other criteria.
- A good game enables you to spend more time playing than teaching. I love Eclipse and Mage Knight, but I don't want to own a game I get tired of explaining.
- Finally, variety is important. No matter how good two games can be, if they both have the same theme or mechanics, on a list of top ten, one must displace the other. A more unique game will win over a timeless classic, especially when so many people already own the classics. Ultimately, it's nice to have a collection that let's you bring something new to the table.
You can read my individual reviews by clicking on the thumbnails underneath the table.
|Game||Players||Duration||Theme||Strategy||Fun||Learning Curve||Pacing||Distinguishing Characteristics|
|Myrmes||2-4||1-2 hours||10||10||8||8||8||Best Strategy Game|
|Concordia||2-5||2-3 hours||7||10||9||9||9||Best Civilization Game|
|Food Chain Magnate||2-5||2-4 hours||10||9||8||8||9||Best Deck Builder Game|
|Splendor||2-4||25 - 50 minutes||1||5||8||10||9||Best "Dessert" Game|
|Imperial||2-6||3-5 hours||8||10||7||7||5||Best War Game|
|Avalon||5-10||15 - 45 minutes||5||7||10||10||9||Best Concealed Identity Game|
|Isle of Skye||2-4||1 hour||4||8||7||9||8||Best tile placement and Bidding Game|
|Legends of Andor||1-4||1 - 3 hours||8||8||9||10||8||Best Cooperative Game|
|Codenames||2-10||10-20 minutes||1||7||10||10||10||Best Party Game|