Any time I go to a conference and see the word 'learning' in a session title, I get excited. Even better when games are involved. So I was already positioned to enjoy Elizabeth Hunter's talk on teaching literature with interactivity. Bonus that she herself is getting a PhD in theatre and knows how to present!
Elizabeth told us about her interesting game project called Something Wicked. The project aims to answer the question of whether playing a true-to-the-text video game adaptation of a famous work of literature help people better understand the work.
In the demo version of the game, the player participates in a battle with the king of Norway. In the book, the battle is described for 70 lines by a bloody military man, but you don't get to see it; it's not engaging for modern students. But you need to understand the nuances in the monologue or else you don't really understand the play.
Elizabeth previously found in her research that taking Shakespeare into unusual settings, using the full environment, helped people enjoy it more. They felt inside the story, and they cared more, which allowed them to think more deeply about the text.
While live theatre does not scale, video games do. It's worth noting that video games are not a replacement of live theatre. However, we can use games to capture some of the benefits we get from live theatre, like boosting affinity, critical thinking, and comprehension. Unfortunately, a lot of literature video games are nothing more than a jazzed-up book, a little too true to text rather than just inspired by a work of literature.
Something Wicked was built according to the rules governed by the world in the book. The game mechanics reward making decisions that Macbeth would have made, rather than "playing well." If you don't play violently enough you have to start again. You have to behave with bloodlust and sneakiness.
So far the game seems to be succeeding in its goals. One cool thing, for example, is that older players end up being excited to analyze Shakespeare's text to figure out why the game was designed the way it was (and even to argue about those decisions).
Learn more about Something Wicked and sign up to playtest on the project's website.
Monday, November 6, 2017
Friday, October 13, 2017
GHC17 / Changing of the Guard: Welcome to the New ABI President and CEO
At the opening keynote of this year's Grace Hopper Celebration, eighteen thousand technical women got to meet AnitaB.org's new President and CEO, Brenda Darden Wilkerson. She introduced herself as a warm, eloquent, and passionate lady. She and outgoing CEO Telle Whitney made a touching video in which Telle passes the proverbial torch to Brenda, heralding an exciting new era for the organization.
***
I have had the great pleasure of getting to know Telle over the last number of years. A talented computer scientist, she took on the commitment of heading up the then-called Institute for Women and Technology in 2002 when her dear friend Anita Borg fell ill. Though CEO might not have been a role she expected to have, Telle embraced the challenge and lead the institute through incredible growth and impact.
I first met Telle when I was assigned as a Hopper volunteer for an ABI advisory board meeting during Grace Hopper in 2010. I was then invited to be part of the board and got to know Telle more over the years. Some of my fondest memories of her are on the dance floor, where she was always ready to bust a move with me like we were the best of friends.
***
I had the chance to meet Brenda Tuesday night before GHC started. The ABI advisory board no longer exists, but I had the chance to attend the Systers leadership dinner with the Anita|Bees committee. Brenda addressed our relatively small group with such warmth that I couldn't help but immediately like her. That she has such an impressive background, and founded the original 'computer science for all' initiative, just makes it all the better.
I'm also tickled that we had a bonding moment over breastfeeding. I was nursing my six-month-old Henry when she was going to introduce herself. After noticing what I was doing, she told me about her own experiences with her babies. I love connecting with folks on a personal level like that, no matter how "high-up" they are.
***
I think everyone can agree that great things lie ahead for AnitaB.org. I hope that Telle enjoys her well-earned retirement, and I hope that I'll have a chance to dance with Brenda someday as well.
If you'd like to learn more about Brenda, check out her interview on the AnitaB.org website.
***
I have had the great pleasure of getting to know Telle over the last number of years. A talented computer scientist, she took on the commitment of heading up the then-called Institute for Women and Technology in 2002 when her dear friend Anita Borg fell ill. Though CEO might not have been a role she expected to have, Telle embraced the challenge and lead the institute through incredible growth and impact.
I first met Telle when I was assigned as a Hopper volunteer for an ABI advisory board meeting during Grace Hopper in 2010. I was then invited to be part of the board and got to know Telle more over the years. Some of my fondest memories of her are on the dance floor, where she was always ready to bust a move with me like we were the best of friends.
***
I had the chance to meet Brenda Tuesday night before GHC started. The ABI advisory board no longer exists, but I had the chance to attend the Systers leadership dinner with the Anita|Bees committee. Brenda addressed our relatively small group with such warmth that I couldn't help but immediately like her. That she has such an impressive background, and founded the original 'computer science for all' initiative, just makes it all the better.
I'm also tickled that we had a bonding moment over breastfeeding. I was nursing my six-month-old Henry when she was going to introduce herself. After noticing what I was doing, she told me about her own experiences with her babies. I love connecting with folks on a personal level like that, no matter how "high-up" they are.
***
I think everyone can agree that great things lie ahead for AnitaB.org. I hope that Telle enjoys her well-earned retirement, and I hope that I'll have a chance to dance with Brenda someday as well.
If you'd like to learn more about Brenda, check out her interview on the AnitaB.org website.
Wednesday, July 5, 2017
How We Learn: A Book that Understands the Research and Brings it to the Masses
There's a lot of research out there on the theory of learning, so you'd think we'd all know the tricks by now. Unfortunately, due to the relative inaccessibility of academic research by the general public, this isn't the case. Academic writing, when you can find it without needing to shell out a lot of money, isn't exactly designed for consumption by the everyday person (and I say this having been an academic).
Luckily for us, Benedict Carey, a long-time science journalist, has done the work of distilling key learnings (pun intended) about learning science (etc) from the literature. He shares some very practical results in How We Learn: The Surprising Truth About When, Where, and Why It Happens. Even better, he does it in a way we can all understand.
The book climbs the ladder of abstraction of the mind. It begins with some basic neuroscience theory, explaining how the brain works. It then goes through some of the best techniques to remember things, shares ideas behind effective problem solving, and finally discusses how learning happens away from the conscious mind.
There are a few themes that are threaded throughout the book. For example, some level of difficulty is desired, such as forcing yourself to struggle to remember things through self-testing. Another theme is the power and importance of forgetting:
Carey walks through all of these ideas by telling the stories of the researchers who discovered the various principles, and how their ideas can be put into practical use by us today. If you're looking for just the quick and dirty list of what to do to improve your learning, this probably isn't the book for you. Such a list is there at the end, but you might find reading the whole book inefficient. On the other hand, if you like to have ideas reinforced several times and enjoy hearing about the history behind them in an engaging way, I highly recommend this book!
Luckily for us, Benedict Carey, a long-time science journalist, has done the work of distilling key learnings (pun intended) about learning science (etc) from the literature. He shares some very practical results in How We Learn: The Surprising Truth About When, Where, and Why It Happens. Even better, he does it in a way we can all understand.
The book climbs the ladder of abstraction of the mind. It begins with some basic neuroscience theory, explaining how the brain works. It then goes through some of the best techniques to remember things, shares ideas behind effective problem solving, and finally discusses how learning happens away from the conscious mind.
There are a few themes that are threaded throughout the book. For example, some level of difficulty is desired, such as forcing yourself to struggle to remember things through self-testing. Another theme is the power and importance of forgetting:
“Compared to some kind of system in which out-of-date memories were to be overwritten or erased,” Bjork writes, “having such memories become inaccessible but remain in storage has important advantages. Because those memories are inaccessible, they don’t interfere with current information and procedures. But because they remain in memory they—at least under certain circumstances—be relearned.”
Thus, forgetting is critical to the learning of new skills and to the preservation and reacquisition of old ones.Other important ideas include the role of context in learning (it's best to switch it up!), why testing is much more important than just for assigning grades, and how to know when to stop working on something for a while to let it percolate.
Carey walks through all of these ideas by telling the stories of the researchers who discovered the various principles, and how their ideas can be put into practical use by us today. If you're looking for just the quick and dirty list of what to do to improve your learning, this probably isn't the book for you. Such a list is there at the end, but you might find reading the whole book inefficient. On the other hand, if you like to have ideas reinforced several times and enjoy hearing about the history behind them in an engaging way, I highly recommend this book!
Monday, May 29, 2017
When Feedback Makes You Cry a Little
Feedback really is a gift. But feedback can also be hard, both to give and to get. I moved into a leadership role a little over a year ago, and got my first hard-hitting feedback at the end of 2016.
The fall was a stressful time for our entire team. We were launching something completely new with fewer people than we needed and inherently inflexible deadlines. I was pulled in multiple directions as I tried to build what our team would do more broadly, champion this one huge project, and do a fair bit of individual-contributor work that really did have to be done by me in the circumstances. Everyone else was faced with wearing too many hats, too. We managed to maintain a very high quality through the fall but we were all worried about what was looming in the new year.
Late fall, my lead initiated a feedback process for me that included everyone on our team and a bunch of folks that worked with us. I also did a self evaluation. It's a standardized process used with all folks in leadership roles. I got a report back with a summary of scores on the various questions and the written responses, but of course none of the names to go with them.
When I first got the report, my heart just sank. How poorly I had calibrated my self-evaluation is what struck me first - most scores given to me seemed really low. Then I started to read the written stuff and my heart sank even lower.
Nothing written was mean, and in fact, none of it was unfair. It took a day or two of reflection, but the feedback was absolutely right.
I wonder if there are known stages of absorbing feedback, like the stages of grieving. At first I felt shock, then I felt a little upset, and then I felt horrible about how I had made the team's lives harder in some ways. It was difficult to realize how much less self-aware I was in some areas than I imagined.
After reading the report I had a session with one of our internal coaches. I definitely cried a little in that session. We worked through the feedback, me talking through what likely caused it and how I missed realizing what I was doing. It was extremely valuable and I highly recommend doing something similar if you can.
The coach gave me some suggestions for how to address the feedback with my team. At our next standup I brought it up using her advice and cried a little again. The team was so wonderful. It became really clear that the feedback came from a place of us all caring about each other very much. It was a difficult but very important experience.
I was able to put some of the plan for addressing the feedback into action before leaving to have a baby a couple of months later. My biggest takeaway, besides the specifics of the feedback, is that I need to give and ask for feedback more often. It's not always easy, and it might make you cry a little, but it is so so worth it.
The fall was a stressful time for our entire team. We were launching something completely new with fewer people than we needed and inherently inflexible deadlines. I was pulled in multiple directions as I tried to build what our team would do more broadly, champion this one huge project, and do a fair bit of individual-contributor work that really did have to be done by me in the circumstances. Everyone else was faced with wearing too many hats, too. We managed to maintain a very high quality through the fall but we were all worried about what was looming in the new year.
Late fall, my lead initiated a feedback process for me that included everyone on our team and a bunch of folks that worked with us. I also did a self evaluation. It's a standardized process used with all folks in leadership roles. I got a report back with a summary of scores on the various questions and the written responses, but of course none of the names to go with them.
When I first got the report, my heart just sank. How poorly I had calibrated my self-evaluation is what struck me first - most scores given to me seemed really low. Then I started to read the written stuff and my heart sank even lower.
Nothing written was mean, and in fact, none of it was unfair. It took a day or two of reflection, but the feedback was absolutely right.
I wonder if there are known stages of absorbing feedback, like the stages of grieving. At first I felt shock, then I felt a little upset, and then I felt horrible about how I had made the team's lives harder in some ways. It was difficult to realize how much less self-aware I was in some areas than I imagined.
After reading the report I had a session with one of our internal coaches. I definitely cried a little in that session. We worked through the feedback, me talking through what likely caused it and how I missed realizing what I was doing. It was extremely valuable and I highly recommend doing something similar if you can.
The coach gave me some suggestions for how to address the feedback with my team. At our next standup I brought it up using her advice and cried a little again. The team was so wonderful. It became really clear that the feedback came from a place of us all caring about each other very much. It was a difficult but very important experience.
I was able to put some of the plan for addressing the feedback into action before leaving to have a baby a couple of months later. My biggest takeaway, besides the specifics of the feedback, is that I need to give and ask for feedback more often. It's not always easy, and it might make you cry a little, but it is so so worth it.
Friday, March 24, 2017
Review / Invent to Learn: Making, Tinkering, and Engineering in the Classroom
While visiting a branch of our city's library system we don't often find ourselves at, I browsed the tiny section on education. I found Invent to Learn by chance, and though the title's font left me a bit skeptical, I decided to give it a try. I'm glad I did.
The premise of the book is that adopting principles of making into formal and informal education is both feasible and worthwhile. The focus is on maker projects oriented around fabrication, physical computing, and computer programming. The book starts with solid learning theory and goes all the way to how to actually teach with open-ended maker projects.
I'm admittedly an education nerd, so I was delighted to see the book start with some relevant education history, learning theory, and discussion on "thinking about thinking." Seymour Papert, creator of Logo among many other things, is a central figure threaded throughout.
Papert coined the term constructionism, which builds on a previously established theory of learning, constructivism. As defined in the book, constructivism is:
The rest of the text covers what makes a good project, what 'making' means today, the three game-changers in making (the aforementioned fabrication, physical computing, and programming), the practical stuff of actually teaching through maker projects, and how to convince others that the maker approach is a good idea.
Many concrete resources and materials are described throughout the book. It was published in 2013, though, so a lot of the specifics are likely to be out of date. Nonetheless, the suggestions should serve as a good starting point. (As a side note, the book's website, inventtolearn.com, appears to have been hacked, so best not to visit it at the moment.)
Overall, if you are curious about having your students learn by making things (real or virtual), and want to get a taste of the theory behind why it might work as well as the practical suggestions on how to do it, it's worth checking this book out.
The premise of the book is that adopting principles of making into formal and informal education is both feasible and worthwhile. The focus is on maker projects oriented around fabrication, physical computing, and computer programming. The book starts with solid learning theory and goes all the way to how to actually teach with open-ended maker projects.
I'm admittedly an education nerd, so I was delighted to see the book start with some relevant education history, learning theory, and discussion on "thinking about thinking." Seymour Papert, creator of Logo among many other things, is a central figure threaded throughout.
Papert coined the term constructionism, which builds on a previously established theory of learning, constructivism. As defined in the book, constructivism is:
...a well-established theory of learning indicating that people actively construct new knowledge by combining their experiences with what they already know. Constructivism suggests that knowledge is not delivered to the learner, but constructed inside the learner's head.On constructionism:
Papert's constructionism takes constructivist theory a step further towards action. Although the learning happens inside the learner's head, this happens most reliably when the learner is engaged in a personally meaningful activity outside of their head that makes the learning real and shareable. This shareable construction may take the form of a robot, musical composition, paper mâché volcano, poem, conversation, or new hypothesis.The authors claim that constructionism is the learning theory that resonates most with the maker movement, and build the rest of the book on this idea.
The rest of the text covers what makes a good project, what 'making' means today, the three game-changers in making (the aforementioned fabrication, physical computing, and programming), the practical stuff of actually teaching through maker projects, and how to convince others that the maker approach is a good idea.
Many concrete resources and materials are described throughout the book. It was published in 2013, though, so a lot of the specifics are likely to be out of date. Nonetheless, the suggestions should serve as a good starting point. (As a side note, the book's website, inventtolearn.com, appears to have been hacked, so best not to visit it at the moment.)
Overall, if you are curious about having your students learn by making things (real or virtual), and want to get a taste of the theory behind why it might work as well as the practical suggestions on how to do it, it's worth checking this book out.
Thursday, March 2, 2017
Why I Prefer Processing as a First Language to Teach
Once upon a time, almost 5 years ago, I wrote a post about Python vs Processing as a first language to learn. It became my only post to appear on Hacker News and still gets plenty of hits. The reflections in that post were quite early on in my use of either language for teaching, though. Now that I've used both in several teaching contexts, I'd like to explain why Processing still holds top spot for me when teaching beginners about computer science and programming.
Before I begin, I'd like to say that just because I like Processing best doesn't mean that other options aren't also good. Python, for example, is still a good first language in my view; I even use it in some of my course designs and workshops, especially if someone is in a field that will likely only ever use Python. For younger audiences, Scratch is still my go-to. There are many other languages and tools I probably haven't even seen yet that have great promise, too. But for workshops and courses to introduce beginners in high school, post-secondary, and beyond, Processing remains my go-to.
Without further ado, here are some of the reasons why I love Processing...
Processing is easy to download, install, and run. When you open it, it looks clean and simple. You can ask learners to write in one line of code, press play, and see a drawing pop up. This matters, especially when you are aiming to reduce intimidation of learning to program among less traditional groups. I'm always looking to remove any barrier possible that might make a beginner "nope out" of computing.
The fact that Processing's main purpose is to create visual output is also a huge bonus. You need very little code to create something that is meaningful enough to show others. Running home to show your family that your code spits out a number on a console just isn't the same as showing a (usually interactive) visual program. On the console, it's harder to understand that the code does something interesting and that it took effort to do it.
A further advantage of visual output is the ability for learners to see more of what their own code is doing. When you perform a computation with a single result at the end, the code can feel a bit like a black box. If the answer is wrong, which part of the code caused the issue? At least when all your code contributes to what's on screen, you have some more ability to reason about which code is causing the output to be wrong.
Pedagogically, I have a strong preference for introducing as few individual concepts at a time. I don't like the approach of most textbooks and courses I see, where all the fundamentals (variables, branching, iteration, functions, etc) are introduced quickly up front with toy examples before finally getting to the more interesting projects/demos. At the same time, starting with something too complex right away is intimidating and would likely lead to cognitive overload (*cough* Pygame).
I find that Processing allows me to design demos of just the right complexity. Each new demo only needs max a few new concepts (be it a programming concept or something Processing-specific like adding images). I can show the demo, and start working on creating it, introducing concepts just-in-time. It's also possible to design lots of interesting exercises with the same minimal number of new concepts, allowing learners to focus on mastering a small number of things at a time. I find this more difficult to achieve with other languages, even if there is a visual component (for example, I found Python Turtle too restrictive to achieve this for anything longer than a short workshop, while Pygame is way too complicated up front).
As an example, here is a summary of my CS1 course design in terms of the demos I cover for each module and the concepts that are introduced (more detail, including slides and code):
(from a demo in my CS1 course using Processing)
Before I begin, I'd like to say that just because I like Processing best doesn't mean that other options aren't also good. Python, for example, is still a good first language in my view; I even use it in some of my course designs and workshops, especially if someone is in a field that will likely only ever use Python. For younger audiences, Scratch is still my go-to. There are many other languages and tools I probably haven't even seen yet that have great promise, too. But for workshops and courses to introduce beginners in high school, post-secondary, and beyond, Processing remains my go-to.
Without further ado, here are some of the reasons why I love Processing...
Processing is easy to download, install, and run. When you open it, it looks clean and simple. You can ask learners to write in one line of code, press play, and see a drawing pop up. This matters, especially when you are aiming to reduce intimidation of learning to program among less traditional groups. I'm always looking to remove any barrier possible that might make a beginner "nope out" of computing.
The fact that Processing's main purpose is to create visual output is also a huge bonus. You need very little code to create something that is meaningful enough to show others. Running home to show your family that your code spits out a number on a console just isn't the same as showing a (usually interactive) visual program. On the console, it's harder to understand that the code does something interesting and that it took effort to do it.
A further advantage of visual output is the ability for learners to see more of what their own code is doing. When you perform a computation with a single result at the end, the code can feel a bit like a black box. If the answer is wrong, which part of the code caused the issue? At least when all your code contributes to what's on screen, you have some more ability to reason about which code is causing the output to be wrong.
Pedagogically, I have a strong preference for introducing as few individual concepts at a time. I don't like the approach of most textbooks and courses I see, where all the fundamentals (variables, branching, iteration, functions, etc) are introduced quickly up front with toy examples before finally getting to the more interesting projects/demos. At the same time, starting with something too complex right away is intimidating and would likely lead to cognitive overload (*cough* Pygame).
I find that Processing allows me to design demos of just the right complexity. Each new demo only needs max a few new concepts (be it a programming concept or something Processing-specific like adding images). I can show the demo, and start working on creating it, introducing concepts just-in-time. It's also possible to design lots of interesting exercises with the same minimal number of new concepts, allowing learners to focus on mastering a small number of things at a time. I find this more difficult to achieve with other languages, even if there is a visual component (for example, I found Python Turtle too restrictive to achieve this for anything longer than a short workshop, while Pygame is way too complicated up front).
As an example, here is a summary of my CS1 course design in terms of the demos I cover for each module and the concepts that are introduced (more detail, including slides and code):
- Drawing pictures with Processing – a static image with several semi-complex entities (basic drawing, variables)
- Interactive painting with Processing – an interactive painting program that allows you to change colours (active mode/interactions, basic functions, switch statement)
- Jukebox – a music player with three buttons to start and stop songs (functions as abstractions, Boolean expressions, if statements)
- Sheep AI – pet sheep that wanders toward your mouse, drinks tea when it reaches it, and emanates coloured rings when clicked; pictured above (state machines, while loops, arrays)
- Foreign student data visualization – visualization of sortable data available on Canada's Open Government website (Strings, algorithms, state-only objects, constructors)
- Social media set cover problem – contextualized example and visualization of the set cover problem for a small set of data (shared data and references, for loops)
For beginners I prefer teaching languages that are statically typed and generally more 'rigid' for lack of a better term. The more the compiler or interpreter can tell you about what you're doing wrong, the better. I've seen so much frustration from my students working in Python because they do weird things that are syntactically correct, but make no sense semantically. Of course this point doesn't limit the choice to Processing, but it's an added plus for me.
It can also be useful that Processing is Java, but with the tricky parts abstracted away in the IDE. Starting this way is great because you don't have to say things like "don't worry about what public static void means, I promise it'll make sense later." Yet students are actually learning Java syntax when they learn Processing, and can even start pulling in more advanced features of Java later on if desired. When a follow-up course is done in Java (as the CS2 course I designed is required to be), the transition is smooth. Even better, you can still use the Processing library in a 'regular' Java project (example), so you can incorporate it into those later courses if you want. For instance, in CS2, I do so to get students using a third-party library and to learn about MVC and event-driven programming (see more).
I could probably go on about how useful I've found Processing in teaching beginners, but I think this is a pretty good list for now. I'd love to hear about how you've used Processing in your own teaching!
Friday, January 20, 2017
A Growth Mindset Workshop
I recently gave a workshop on the growth mindset with first year computer science students working as part of this amazing program. It went well, so it seems worth sharing. What follows is the workshop plan.
Take the following quiz and share results: http://mindsetonline.com/testyourmindset/step1.php
Share definition of growth and fixed mindset (read quote, put key parts on a slide):
Share printout with the following quotes from Mindset and have them read them individually. While reading, think about times in your studies (especially in the fall!) where you might have approached something with a fixed mindset, and other times you have used the growth mindset.
Take the following quiz and share results: http://mindsetonline.com/testyourmindset/step1.php
Share definition of growth and fixed mindset (read quote, put key parts on a slide):
“When we ask people to tell us what the growth mindset is, we often get lots of different answers, such as working hard, having high expectations, being resilient, or more general ideas like being open or flexible. But a growth mindset is none of those things. It is the belief that qualities can change and that we can develop our intelligence and abilities.
The opposite of having a growth mindset is having a fixed mindset, which is the belief that intelligence and abilities cannot be developed. The reason that this definition of growth mindset is important is that research has shown that this specific belief leads people to take on challenges, work harder and more effectively, and persevere in the face of struggle, all of which makes people more successful learners.
It is hard to directly change these behaviors without also working to change the underlying understanding of the nature of abilities.” (source)Watch TEDx talk by Carol Dweck. Have students write down everything they found interesting, surprising, or useful. Pair up, pick the top three points of interest, share them.
Share printout with the following quotes from Mindset and have them read them individually. While reading, think about times in your studies (especially in the fall!) where you might have approached something with a fixed mindset, and other times you have used the growth mindset.
I [Carol Dweck], on the other hand, thought human qualities were carved in stone. You were smart or you weren’t, and failure meant you weren’t. It was that simple. If you could arrange successes and avoid failures (at all costs), you could stay smart. Struggles, mistakes, perseverance, were just not part of this picture.
...children with the fixed mindset want to make sure they succeed. Smart people should always succeed. But for children with the growth mindset, success is about stretching themselves. It’s about becoming smarter.
Why is effort so terrifying? There are two reasons. One is that in the fixed mindset, great geniuses are not supposed to need it. So just needing it casts a shadow on your ability. The second is that … it robs you of all your excuses. Without effort, you can always say, “I could have been [fill in the blank].” But once you try, you can’t say that anymore.
In this course [in our research study], everyone studied. But there are different ways to study. Many students study like this: They read the textbook and their class notes. If the material is really hard, they read them again. Or they might try to memorize everything they can, like a vacuum cleaner. That’s how the students with fixed mindset studied. If they did poorly on the test, they concluded that chemistry was not their subject. After all, “I did everything possible, didn’t I?”
…
The students with the growth mindset completely took charge of their learning and motivation. Instead of plunging into unthinking memorization of the course material, they said: “I looked for themes and underlying principles across lectures,” and “I went over mistakes until I was certain I understood them.” They were studying to learn, not just to ace the test. And, actually, this was why they got higher grades – not because they were smarter or had a better background in science.
[Benjamin Bloom, eminent educational researcher, says:] “After forty years of intensive research on school learning in the United States as well as abroad, my major conclusion is: What any person in the world can learn, almost all persons can learn, if provided appropriate prior and current conditions of learning.”
Just because some people can do something with little or no training, it doesn’t mean that others can’t do it (and sometimes do it even better) with training. This is so important, because many, many people with the fixed mindset think that someone’s early performance tells you all they need to know about their talent and their future.
[Story from one particular student, Tony:] In high school I was able to get top grades with minimal studying and sleeping. I came to believe that it would always be so because I was naturally gifted with a superior understanding and memory. However, after about a year of sleep deprivation my understanding and memory began to not be so superior anymore. When my natural talents, which I had come to depend on almost entirely for my self-esteem (as opposed to my ability to focus, my determination or my ability to work hard), came into question, I went through a personal crisis that lasted until a few weeks ago when you discussed the different mindsets in class. Understanding that a lot of my problems were the result of my preoccupation with proving myself to be “smart” and avoiding failures has really helped me get out of the self-destructive pattern I was living in.After the exercise, have students pair up and discuss the consequences of using the fixed or growth mindset in different scenarios. Share one or two stories with the group.