Subtitle: Attrition, Attribution, Self Efficacy, and Feedback
So, for those familiar with the work I am pursuing for my thesis, it should be no surprise that I believe that feedback is an important part of any educational environment. The type of feedback we choose can have profound effects on student learning, but I am also convinced that it can impact their motivation as well. This is a post inspired by a recent WSJ article that was also picked up in the NYT as well.
There are many research hypothesis that have made their way into my “folder”. I keep a folder in my desk where I jot down notes based on other works, or just ideas for research studies I’d like to conduct if I have the time. I believe that this folder will become useful if I ever want to make a change in my general research direction, or if I eventually have students who are looking for a project but not sure where to start. Each idea contains references to the presentations or works that inspired the thought and I would let my students look through for something that interested them and then have them read the work so that we could talk about their take on whatever principle applies to CS (or Math or EdTech) education. There is a very large subsection of that folder that belongs specifically to self efficacy and its impact on learning, performance, retention, engagement, and perseverance.
Computer science is an interesting discipline. Most scientific disciplines have a level that you reach where the problems you are trying to solve are not prescriptive and take a number of attempts or false starts before you are on a path to success. For complex math proofs, it is often the case that you try several different methodologies before hitting on the one that works. For natural sciences, there is a reason why its called an “experiment” - what you try does not always work the first time when you are doing lab research. CS obviously has these problems as well - but whats interesting is that at the novice level, the first course even, we are often already into that state. Students are asked to complete a programming assignment that may have an abstract connection to what was done in class, but is rarely a direct translation of the lecture. Also, the feedback is much more immediate (in the form of a compiler and test cases) than the other disciplines where you might get a problem set back the next week with a marked grade.
Therefore, in CS, a novice’s experiences are comprised primarily of something telling you that you are “wrong”. Even when you fix one problem, the tools that we use when teaching do not celebrate the fix, but present the next bug. This has to have a negative impact on student self-efficacy and in turn their belief that they are being successful in this course of study. At some point I want to study this, and what we can do to the messaging that our pedagogical environments give our students in order to help them understand that there is more work to do in order to successfully complete the program, but also to celebrate the small victories in the problem solving process early on.
Because I know a number of teachers read this blog, I’d like to include here some of the untested things I’ve used in my classroom in the past to scaffold students, and would like to evaluate rigorously in the future.
First, when introducing a new concept give small, short programs that are very similar to the lecture. Or have students code with you in class. Whether you choose to “grade” these at the same level as other assignments or not (ie. 5 point practice programs vs. 100 pt. larger projects) the quick-fix of putting together a short successful program can front load the SE of the student. Give them some early successes to build confidence before tossing the larger, more rigorous assignment at them. I often did this in a embedded way. Using Bloom’s Taxonomy I would have three graded levels for each assignment. A passing grade would involve implementing what I called a one-step. The program would be one step further than the lecture. They could type in the notes (any code I posted online would be in .gif form so they could not just copy/paste but actually had to type), and make one change. Step two would be a little harder and involve some application of other knowledge or integration of other concepts. This would earn them either a B+ or A-. In order to get an A they had to “impress me”. The last points were open ended and require that students then create some application of the program. A great example is when I taught students to use buttons and click events. The lecture would show how to create one button and have a single text box pop up when the button was pressed. The one-step was to create a program with two buttons and two messages. The next level involved maintaining a state across button presses - counting how many times each button was pressed. The last level was up to them and I got everything from touch-screen type McDonald’s ordering menus, to games, to a four function calculator.
A second way I scaffolded students within each assignment was the use of unit testing. In addition to helping me out by providing automated grading, students could see how many tests they passed and failed, and rather than just seeing the next error many interfaces will show you all tests - with passed tests in green. Watching the number of green tests increase over time is a good way to feel like you are making progress, even if there are still errors to correct.
Overall, I think SE is an important measure of just how well we are creating content and pedagogy that has the chance of engaging students and reinforcing learning.