Learn to Fail — and — Fail to Learn
On the other day, one of my friend — he just started off with web programming — asked me: “How do I learn all these shining new stuff happening in the front end world”.
I didn’t have a clear answer to that question. In fact, I am also in the same state as him; Amazed ( and confused at the same time ) by the whole new front end frameworks and patterns. Hence, instead of answering the original question, I explained him the way I usually learn something new.
I told him:
“Learn to Fail and Fail to Learn”
I saw him more baffled; but, let me explain. First, I’ll divide the above sentence and explain what I meant by those.
Note: Throughout this article I am going to use the word “thing” for what you’re going to learn. Pardon me, as I didn’t get another better word.
Learn to Fail
This is not about the real failure. This is all about self-assessing how much you know about the “thing” you’re going to learn.
First, create a list of items. Every item in the list should start with the sentence “Will I succeed” and we’ll call it as a failure points checklist. For example, if you’re going to learn the new AngularJS 2, your list might start with these:
- Will I succeed to set-up a simple Angular 2 project?
- Will I succeed to make it work with all set-up?
- Will I succeed to create a simple component?
- Will I succeed to create a route?
- …etc
If you observe, these are the items came out of your mind based on your existing knowledge about the “thing” you’re going to learn. The more you know about the “thing”, you can see more items in the list.
You can also ask yourself these question: “Can I do this in this way”? or “Can I change this in another way”? If you’re not sure about the answer to these questions, it’s a new failure point in your list.
When you’ve one or more item in your failure list, let’s do it and fail.
Fail to Learn
From here onwards, you’re learning the “thing”. Let’s take the first item from your list, and try to make it work. As expected, you’ll fail ( That’s why it is there in the failure list ).
Your goal is to get the item removed from your failure list. Learn as much as possible to get this done. Use books, articles, stackoverflow, forums and whatever materials available. While trying to fix the failure, you can also see a new pattern emerges: There will be new failures which you didn’t expect at the initial time. Just add them as a sub-list to your list entry, and try to fix them also.
From this, you’ll understand that there will be two types of failures: Expected and unexpected. Both are good, as they’ll be the path to new knowledge.
As this process goes on — finding failure points, and fixing them — you’ll be learning more and more about the “thing”. You can also observe that your failure points increases as when you gain more knowledge. You’ll also start seeking for more as your previous failure points are obsolete ( since you fixed them ).
As an inventor, Thomas Alva Edison made 1,000 unsuccessful attempts at inventing the light bulb. When a reporter asked, “How did it feel to fail 1,000 times?” Edison replied, “I didn’t fail 1,000 times. The light bulb was an invention with 1,000 steps.
Similarly, take your each failure as just a step to increase your knowledge.
How different is from reading a book?
I’m not saying that you have to avoid books. Once you start fixing your failures, you need to seek for more knowledge. Books and other resources are the places you look for information. Our methods are not to replace books, instead, replace the way of using them.
Let’s analyse a real situation: If I’m going to learn the new Angular2 framework or the Redux flux pattern, I could go ahead and read the books about them. However, the problem with the book is, you started learning something which you don’t know where to apply.
That’s the clear difference between a failure list and chapters in the book. In a book, you go chapter by chapter wise; But when you go by failure list, you’re looking for a solution to a particular problem. Your mind will give more attention when you try to seek a solution.
Conclusion
This pattern is similar to TDD ( Test driven development ). In TDD, we make a failing test and start implementing the feature to make the test pass. Here, we do the same; Instead of writing it as a test we’re just noting it as a failure point.
In comparison:
Test ==> failure pointPass ==> Learning how to fix the failure point.
Before wrapping up, I would like to tell that, this pattern applies in real life too. For example, I am trying to apply the same in my cooking sessions. Yes, I know how to make a tea now! :)
Accept the truth: Failure is the only way to learn something. Failures are the steps towards Success.
Let me know your feedbacks!
