Reflect on Learning from Failure (Framework)
(Difference between revisions)
| Line 1: | Line 1: | ||
| − | Idea: | + | |
| + | == Idea: == | ||
| + | |||
Describe framework and then use a concrete activity to apply our ideas for reflection on learning from failure, probably version control and issue tracking activities, which are already defined, and extending them for our perspective. | Describe framework and then use a concrete activity to apply our ideas for reflection on learning from failure, probably version control and issue tracking activities, which are already defined, and extending them for our perspective. | ||
| − | |||
| − | Students will get critiqued in the world they'll enter into. They need to learn how to deal with that in a constructive way. | + | == Rationale for our framework: == |
| − | Go look at someone else's code - can you understand it? If yes, students will start feeling more confident. Also, it reinforces how important code documentation is. | + | |
| − | Model behavior for students in the classroom and have students suggest what to put in there, then discuss them. How can that be scaffolded? | + | |
| − | Here’s some code that’s not working, do a quick quiz in class and let them find out why. Then put up “this is what most people think why it doesn’t work. Now go try fix it.” | + | * Students will get critiqued in the world they'll enter into. They need to learn how to deal with that in a constructive way. |
| + | * Go look at someone else's code - can you understand it? If yes, students will start feeling more confident. Also, it reinforces how important code documentation is. | ||
| + | * Model behavior for students in the classroom and have students suggest what to put in there, then discuss them. How can that be scaffolded? | ||
| + | * Here’s some code that’s not working, do a quick quiz in class and let them find out why. Then put up “this is what most people think why it doesn’t work. Now go try fix it.” | ||
| + | |||
| + | |||
| + | == Outcomes / deliverables (students’): == | ||
| + | |||
| + | * Micro-reflections (throughout an activity; in class) | ||
| + | ** Can be done at regular interval (e.g. every 30 minutes in class) | ||
| + | ** Commit messages where students state their current stage of thought/problem-solving process, snapshot of where they’re at. | ||
| + | ** If collecting them in a different place is preferred, a shared doc is an option. | ||
| + | ** Index card / Post-its if computers aren’t in use (and public, can optionally be categorized), but would have to be written up / redistributed / photographed if they are supposed to be available to the students for macro reflections. | ||
| + | ** There is a social aspect to sharing them as tangible artifacts help students to relate and see the social skills for a moment instead of the technology. Color coded notes/notecards could be used for various categories (technical, communication, big picture, etc.) | ||
| + | * Mini-reflections (weekly; outside of class): | ||
| + | ** Blog | ||
| + | ** Wiki | ||
| + | ** Prompt a different category every week: soft skills, technical aspect, communication, organization | ||
| + | * Final/macro/meta Reflections (1-3 at milestones/checkpoints; outside of class): | ||
| + | ** Milestones: start of the semester (survey), middle of semester (survey), end of semester (survey and essay) | ||
| + | ** Surveys: use existing FOSS surveys and maybe add a couple of questions | ||
| + | ** Short essay with reflection at the end (using their micro reflections) and the prompt to reflect on how they learned from failure. | ||
| + | * Progress visualization over an academic term... | ||
| + | ** How can we (help students) visualize progress? Charting on the following fronts: | ||
| + | ** Let students set a goal - may be unrealistic but they engage more if they can contribute creatively | ||
| + | ** Level of frustration, just for giggles, hoping it goes down over the semester ;) | ||
| + | ** Learning goals / objectives (for the course, as determined by instructor) | ||
| + | ** Data collection via Moodle/BlackBoard/whatever your course is already using | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | == Background: == | ||
| − | |||
| − | |||
Readings: | Readings: | ||
| − | Roger Von Oech - A Whack on the Side of the Head: How You Can Be More Creative - http://courses.washington.edu/art166sp/documents/Spring2012/readings/week_3/AWhackOnTheSideOfTheHead.pdf | + | * Roger Von Oech - A Whack on the Side of the Head: How You Can Be More Creative - http://courses.washington.edu/art166sp/documents/Spring2012/readings/week_3/AWhackOnTheSideOfTheHead.pdf |
Revision as of 16:56, 19 November 2016
Contents |
Idea:
Describe framework and then use a concrete activity to apply our ideas for reflection on learning from failure, probably version control and issue tracking activities, which are already defined, and extending them for our perspective.
Rationale for our framework:
- Students will get critiqued in the world they'll enter into. They need to learn how to deal with that in a constructive way.
- Go look at someone else's code - can you understand it? If yes, students will start feeling more confident. Also, it reinforces how important code documentation is.
- Model behavior for students in the classroom and have students suggest what to put in there, then discuss them. How can that be scaffolded?
- Here’s some code that’s not working, do a quick quiz in class and let them find out why. Then put up “this is what most people think why it doesn’t work. Now go try fix it.”
Outcomes / deliverables (students’):
- Micro-reflections (throughout an activity; in class)
- Can be done at regular interval (e.g. every 30 minutes in class)
- Commit messages where students state their current stage of thought/problem-solving process, snapshot of where they’re at.
- If collecting them in a different place is preferred, a shared doc is an option.
- Index card / Post-its if computers aren’t in use (and public, can optionally be categorized), but would have to be written up / redistributed / photographed if they are supposed to be available to the students for macro reflections.
- There is a social aspect to sharing them as tangible artifacts help students to relate and see the social skills for a moment instead of the technology. Color coded notes/notecards could be used for various categories (technical, communication, big picture, etc.)
- Mini-reflections (weekly; outside of class):
- Blog
- Wiki
- Prompt a different category every week: soft skills, technical aspect, communication, organization
- Final/macro/meta Reflections (1-3 at milestones/checkpoints; outside of class):
- Milestones: start of the semester (survey), middle of semester (survey), end of semester (survey and essay)
- Surveys: use existing FOSS surveys and maybe add a couple of questions
- Short essay with reflection at the end (using their micro reflections) and the prompt to reflect on how they learned from failure.
- Progress visualization over an academic term...
- How can we (help students) visualize progress? Charting on the following fronts:
- Let students set a goal - may be unrealistic but they engage more if they can contribute creatively
- Level of frustration, just for giggles, hoping it goes down over the semester ;)
- Learning goals / objectives (for the course, as determined by instructor)
- Data collection via Moodle/BlackBoard/whatever your course is already using
Background:
Readings:
- Roger Von Oech - A Whack on the Side of the Head: How You Can Be More Creative - http://courses.washington.edu/art166sp/documents/Spring2012/readings/week_3/AWhackOnTheSideOfTheHead.pdf
