FML (Failure: My Learning)

I read a book recently: How to Fail at Almost Everything and Still Win Big by Scott Adams.  It’s a good book and has made me think about things I do and has led to some behavioral changes already.

One of the things it made me think about was how I learn.  There’s a common saying when discussing different teaching methods that people learn in different ways.  They say some learn by hearing, some by reading, and some by doing.  In my particular case, I learn by doing.  But more importantly, I learn by failing.

For a very common personal example, when I am learning programming, it’s not enough for me to duplicate an example from a book and see it in action.  I will usually make the example my own – renaming variables, eliminating some pieces I feel are extraneous, and so on.  If it doesn’t work, great!  If it still works, I keep tweaking it until it breaks.  Then I begin the process of understanding why it doesn’t work.

To me, the how isn’t as important as the why.  I have the need to understand what the important parts are, so when I am creating my own version, I know what is flexible and what is not.  Or when I am looking at other’s broken code, I can focus on the important parts.  I think this is an important part of understanding.  I say many times that if something works perfectly the first time, you haven’t learned anything from the exercise.  Failing is a very important part of my learning process.

This sort of means I am suited to do more creative work.  I mean, I would be a pretty poor doctor (even though I am a great troubleshooter).  More like Dr. House, I would have to nearly kill each patient until I figured out what the proper solution was.  It also means I’m pretty damn poor at math.  My approach to solving a math problem is to start with a formula with known working inputs and output, then test it with many different inputs and verify that the output is as I want.  This is why I don’t do game programming.

Comments are closed.