Here is the second installment from Head First JavaScript author Michael Morrison. Enjoy!
When my brother and I were kids, we liked to race our bicycles around the outside of our house. Being over five years older than me, my brother had a bad habit of showboating and taunting as he inevitably beat me time and time again. One day my Dad decided to teach my brother a lesson, and closed the gate we were riding through, knowing that my brother would be too busy looking over his shoulder taunting to notice the gate. My brother crashed into the gate and had quite a wipeout. My Dad had tired of warning him verbally, and eventually decided that real pain might send the message a little clearer.
And it did. The incident is interesting to me now because it touches on the notion of "engineered failure." Since we all tend to learn through failure, to what degree should the learning process involve the deliberate engineering of failure? My brother learned that day to quit taunting his little brother, at least if my Dad is around. The experience of crashing taught him something that he wasn't going to learn any other way. But what does this have to do with Head First? A lot, as it turns out...
One of the things that surprised me when I first became immersed in the Head First philosophy is how the series truly does engineer failure. And there is a very good reason for it. There is something about human nature that causes us to learn and grow primarily through adversity. Maybe it's the reflection we go through as we assess what went wrong in a situation. Or maybe it's the stubborn desire to not screw up again. Or in my brother's case, maybe it's pure and simple pain avoidance. Regardless of the "why," Head First embraces the learning-through-failure idea and makes a deliberate effort to create pitfalls that the reader will experience and learn from. What's important, however, is that the pitfalls are carefully controlled, which is why I call it engineered failure. If my brother had broken his arm in the bicycle wreck, my Dad's plan wouldn't have had the desired effect. Similarly, if a broken piece of code in a Head First JavaScript scenario is so broken that the learner gets frustrated, the effect will be lost. So one of the challenges to us as we create Head First learning opportunities is to set up situations where the learner will skin their knee but hopefully not limp away bleeding and dejected. It's also quite motivational because there is something sweeter about accomplishment when you've had to take a few lumps to achieve it.
The really cool thing about engineered failure is that you can use it in everyday life, especially if you deal with kids on a regular basis. There is a personal finance radio talk show host based in Nashville, TN (where I live) who tells a story about taking his kids to a carnival, and his daughter became obsessed with winning a stuffed animal at a carnival game. He warned her several times that it was very difficult to win in those kinds of games, but she persisted. He was tempted to stop her after a couple of dollars to keep her from losing all her money, but he saw the situation as a learning opportunity. So he let her blow the $10 she had saved and go down in flames playing the game. It equated to engineered failure because by not interfering, he allowed her to suffer in a situation that was ultimately controlled. And in the end, he reasoned that the the pain she felt over losing $10 now might leave an impression that will keep her from losing thousands of dollars as an adult later in life. We can't promise to save you from financial pain in Head First, but we are all about using engineered failure as a learning tool. It works.







By 










Leave a comment