🤔Project Mode Philosophy
This philosophy is mirrored in our Interactive Web and ICM curriculums.
Project mode can be incredibly powerful, but only when it's treated with the care and attention it deserves. We’ve centered this course around these beliefs:
The strongest student learning happens during project mode.
This course is designed to allocate almost the entire school year to working on individual, partner, or group projects. It assumes students enter the course with much of the content they already need, and while it may be tempting to slow down and reteach content from lessons or years past to the whole class, teachers of this course are encouraged to sprinkle the weeks of Project Mode with optional teaching moments to only small groups of students who need it most.
There is a profound difference between a teacher insisting that we should all type a line of code during a lesson, and a student struggling to solve a problem in an effort to implement a feature that they came up with all on their own. We know that motivation impacts learning, and project mode allows for student ownership in a way that a convergent assignment does not.
However, project mode isn't this powerful by default. It is essential that a teacher give students enough choice, agency, and planning time to get truly excited about what they plan to build - this may mean modifying or being flexible about the assigned prompt. Do not let students begin projects until every single group is at least somewhat excited about what they plan to build.
Student buy-in happens during project mode.
Creating student buy-in on their specific project paves the way for student buy-in to the entire content area.
A student without a strong interest in computer science may still take this class to get a specific credit, or to be with their best friend, or even without intending to, because it was the only class that fit in their schedule. Taught excellently, there will be moments of joy and discovery in the lessons along the way, but those moments pale in comparison to a well-run Project Mode.
An excellent experience in Project Mode can be path-altering. It can reveal to a lukewarm student that computer science will open doors for them in any industry.
Team projects are more powerful than independent projects.
Teachers are strongly encouraged to run all the projects of this course in small groups of 2-4, rather than as individual projects. Group project mode outshines independent project mode for a number of reasons:
They present a much closer parallel to real-world programming work.
They leverage students' varied skill sets and reaffirm the idea that everyone has something to contribute.
They facilitate some low-stakes, organic peer tutoring.
They lower the project-to-teacher ratio, allowing a teacher to spend more time supporting each group.
They fold in additional real-world skills, like division of labor, team communication, prioritization, and compromise.
These are features of a well-run project mode, and require more support than a simple "work in groups" direction. Refer to the Project Launch Protocols for tips on implementation.
Note: While we emphasize the power and importance of team projects, we also acknowledge that a full year of team projects may be overwhelming for some students. In these instances, know your students, and if needed, some independent project work may be valuable and necessary. We recommend a student work independently for only one or two of the three projects at the beginning of the year, and with a team for the Final Project. Additionally, varying the groups themselves will also play an important role in keeping Project Mode engaging and fun for students and preventing unproductive partnerships - we provide more guidance for creating groups in the Project Launch Protocols.
Real projects are varied, and that's a good thing.
Students need to be allowed to work at a pace that keeps them squarely in their zone of proximal development for the duration of project mode. This necessarily means that your most advanced students will create a project that demonstrates far more mastery of content than your students who are still grappling with the essentials.
This is a feature, not a bug. In order to encourage students to focus on their actual project goals instead of shoehorning in specific features to best fit a rubric, your project requirements will have to be either flexible or minimal.
Refer to the Grading Best Practices for more specific tips.
Planning and punting are the best ways to sustain student momentum.
One of the most common challenges in any sustained project work is the temptation for a student to say "I'm done" as soon as they've created anything at all.
This can indicate that a student really has a fully realized vision, but more often indicates that a student simply isn't that interested in what they're doing, and would like your permission to stop working on it.
This can be addressed in part with an explicit expectation that students "work the whole time," but that places the onus on a teacher to decide what additional features a group should add to their project, and thus the vision is no longer the student's, and the motivation has shifted back to compliance.
Have your students spend a significant amount of time planning to ensure that they are fully invested in the project, and have them generate artifacts along the way. Pointing back to wireframes, mockups, and feature roadmaps can ensure that students are always executing on their vision, and not simply complying with a directive to keep working.
This is addressed more deeply in the Design Journal, Learning Plans, and Project Launch Protocols.
*Project Mode Modifications
A teacher is free to change the topic of any of the projects described in the unit guides. Be cognizant of doing so in a way that will allow all students to find something that excites them. We’ve purposely chosen broad themes for each of the first three projects (web application, data focus, entertainment / creative) with the hope that students will be able to find something that is meaningful to them within each theme.
This course also advises re-starting project mode from scratch for each of the fist three projects. That is a strong recommendation, as it allows for students to learn from past mistakes and start fresh, working with new partners, and without dealing with legacy code or code debt incurred in the previous project mode.
However, if a teacher is prepared to deal with those challenges, this course can also be run where students revisit project groups for the (optional) Midpoint and Final Project, iterating on a single idea at each new project sprint, adding new functionality and features each time.
Teachers of this course are also welcome to explore the middle ground, where students are allowed to decide whether they want to start from scratch or iterate.
Last updated