During the Marshmallow Challenge, our group was applying a self-regulated learning cycle (though maybe not intentionally). We initially had big plans of making a multi-tiered triangular prism structure, but realized midway that we would not have enough time to do so. We revised our plan and focused on making a single-tier structure with a spaghetti roof that the marshmallow could sit on. Again, in realizing that we were running out of time, we revised our plan and brought the vertical sides of the triangular prism together to form a point that we stuck the marshmallow onto. In our case, having multiple perspectives allowed us to see our own blind spots and quickly pivot to what would be a simpler idea.
During the EarSketch project, I applied the self-regulated learning cycle on a small scale, but could have been more strategic thinking about the big picture. Being familiar with programming, I dove into looking through sounds and quickly moving them into lines of code. After creating a sequence I was happy with I tried repeating a section to make the song longer. I ran into a problem with overlapping tracks here, and edited the code to fix that bug. I was applying a self-regulated learning cycle specific to coding that has become very intuitive to me, where I plan what code I want to write and expect that I'll be able to find the source of bugs when they occur. I think I could have been more intentional in developing a plan for the project in general, and maybe could have anticipated some of the problems that arose when I duplicated sections.
Thinking about the self-regulated learning cycle, I am reminded of a group final project from last semester. The project was intended to take several weeks and included both a hands-on component and a research-based component. There were a few additional assignments spaced out over the course of the project; these were intended to keep us on track for the final deadline. One of these assignments was a project roadmap, which encouraged us to break down the large project into smaller actionable items. My group was attempting to perform proof-of-concept security exploits, a concept largely unfamiliar and intimidating to us, and our roadmap was fairly vague as a result of this uncertainty. As we researched, we narrowed our topic (deciding to focus on Meltdown attacks) and developed a plan that seemed manageable. However, after completing a large portion of our hands-on component, one of the group members informed us that she had talked with our professor, who thought our scope was too narrow. We had run out of time to meaningfully expand our hands-on component and opted to expand our research instead.
Looking back, there were several problems with our approach that could have been solved by applying the self-regulated learning cycle and through more effective communication between group members and with our professor. After narrowing our focus, we should have revised our roadmap and consulted with our professor. We also could have foreseen some the time constraints that affected us close to the final deadline (there were additional unforeseen circumstances as well, but had we created a more well-developed plan we could have managed these easier). The project was a lesson in developing, revising, and communicating a plan, which the self-regulated learning cycle encourages.