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.