Guiding Students to Success

Inquiry and Project Based learning are key concepts in modern pedagogy. As a Computer Science teacher, I believe it is especially important that I align my assessments as closely as I can to the experience that most students will have if they become Software Engineers.

This isn’t just important because it helps prepare them for future jobs, it also helps to learn the programming languages better. As we discussed in my previous post, most exercises created for CS courses are very small. On average, they only require the students to write 10-15 lines of code. They also go out of their way to isolate the concept being targeted.

While this is great for the early stages of learning a programming language, most students can grow beyond the level where this is helpful very quickly with a bit of practice. Therefore, all of my classes other than AP CSA are structured so that 70-90% of the grade in that class is earned via projects - ideally projects spanning 4-6 weeks

Challenges with Projects

Larger projects come with their own challenges though, particularly projects where students are not expected to progress through the steps in lockstep (or possibly even not in the same order). It is not uncommon for students to become stuck at different points in a project, putting that student out of sync with the rest of the class. At the same time, it isn’t uncommon for students to procrastinate on large projects, leaving themselves without enough time to turn in what the teacher is expecting.

Another issue with larger projects in the classroom is student awareness of their own work. Estimating is an important skill when it comes to project management and few school projects are structured to help develop this skill. Without this, students will not be able to accurately judge the scale of the projects they are undertaking.

A final challenge with projects is that they can easily devolve into a mere box-ticking exercise. For example, consider the AP CS Principles Create Task. The Create Task is, theoretically, a project based learning experience where students create an application with “real world application”. Unfortunately, my experience of seeing students do this project suggest that actually doing a project with “real world application” means you’ll probably struggle to earn all of the points. The easiest way to earn the points is instead to create a variable that holds a list, as the user a question, then loop over the list with an if statement until you find a match to the user’s response and output a. That may sound challenging if you have no programming experience, but in reality that is only about 10 lines of code (plus however many items you decide to put into the list). See again my points on the length of real programming projects. Students prioritizing the project over the rubric will receive a lower grade than those who simply tick all the boxes on the rubric. But a student who actually completes a real project has learned far more about programming that someone who merely ticked all the boxes.

The Guide to Success approach to projects aims to develop student meta cognition about their work, improve teacher tracking of student progress, and move the box-ticking component of the project as far away from the grading as possible. It has also had the fortunate side-effect of functionally eliminating arguments with students over final project grades.

Guiding Students to Success

The Guide to Success could be applied to any project structure, but I have found it works best when used inside the structure I’ve outlined in this series. Students are given the project and rubric at the beginning of the project and students are expected to make steady progress on the project for the entire length of the unit rather than lumping all the work up at the end. The Weekly Check-in process as part of the Guide to Success is a key part of that. Without regular check-ins, the Guide to Success will not work. I have found weekly to be the right balance allowing students time to make real progress and catching students starting to fall behind, but it depends on the length of your projects. I would recommend a minimum of 2 check-ins during a project.

The Guide to Success

The Guide to success is broken into 4 sections: Task Requirements, Qualitative Criteria, Self Reflection, and Teacher Guidance. Each of these form a key component of the framework.

Task Requirements

Task Requirements represent the minimum a student can do and consider themselves “finished”. This section should have all quantitative measurements for the project (the box-ticking component of the project). Students who cannot check all the boxes in this section at the end of the project should receive an incomplete.

It is important that these checkboxes represent true minima. If there is something here which you would allow a student to omit in a submission, it does not belong here. For example, if you would accept an essay that did not cite any sources, you should not include citations in your Task Requirements. Instead, it should be part of the next section. The things here should be what a student would have to do in order to attempt mastery of the standards and content.

When completing this document for a check-in, the students should check the boxes based on their progress through the task and the teacher should verify that they have, in fact, completed the tasks.

Qualitative Criteria

Qualitative Criteria represent the things which you are actually grading on the assignment. This can be any scale you want, I found 4 to be too small. As you can see, I am currently using 6 but I will try 10 for the next iteration. It is best if this is an even number as it does not allow an “exactly in the middle” rating.

You will notice that I did not include any descriptors in my qualitative criteria. Instead, I have asked the students for their reasoning. As with the task requirements, the student should mark their grade (I have mine highlight the grade they think they have earned) and then write their reasoning below. I encourage mine to write this as bullet points and to provide links to external evidence (such as specific line numbers in their project for my programming projects). The teacher should also grade the project, quickly during the conference for a check-in and in detail during the final project grading.

Self-Reflection

The whole objective of this process is to draw out student reflection on their progress and understanding of the topic and requirements. The Self-Reflection section should be considered mandatory even on the final submission. It is the time when the students actually learn what they have learned on the project. It is broken into 4 sections.

1. What’s going well. This is a space for students to brag about their work and reflect on their successes.
2. What need work. This is a space for students to analyze the work they’ve already done and consider where their existing work needs improvement. This is not for describing new work.
3. What to do next. This is a space for students to reflect on next steps and new things to add to their project.
4. Questions for the Teacher. This is for students to ask clarifying questions. This is the only space where I allow perfunctory responses like “None”.

Each section contains some example questions or prompts, but they can ignore those and answer independently. I encourage students to write 1-2 bullets or sentences for each one. The teacher reads these together with the student during conferences and uses the responses to springboard the conversation.

Teacher Feedback

This is space for the teacher to provide feedback to the student. Frequently, I will have the student write this on their own during the conference rather than writing it myself. That tends to give them deeper understanding and ownership of the feedback.

Creating Qualitative Criteria

My goal for each qualitative criteria is that it is a question centered on an adjective related to how well they have either used the programming construct or built their project. For my projects, most of the assessment is actually connected to project quality rather than the use of specific programming constructs. I require them to a for loop in the Task Requirements. Then I assess them on their explanation of why they used that for loop in their actual grade. This shifts the emphasis from “I have to have a for loop” to “I have to have a useful for loop.”

This is essential to writing good programs because good programs are not about the programming constructs they are made of, they are about the user experience. This is why the emphasis needs to be on the user experience. This means that on paper, I heavily assess just a few of the CSTA standards (3A-AP-19, 3A-AP-21, 3A-AP-23, and 3A-IC-25). The other standards are assessed, but many of them are assessed as Task Requirements rather than qualitatively.