Episode 22- Fail Faster

Today I had a great time playing around in Houdini. I opened up a tutorial and started learning about dynamics in vellum, specifically relating to grains and sand simulations. I made it maybe halfway through the tutorial when I just turned it off, turned on some music, and started tinkering with it. While I didn’t learn any specific skills I can definitively put my finger on, it was a really constructive session of self-learning.

On paper- I messed up a render like 3 times, had Houdini crash once, had the power go out, and still ended up creating a really fun little simulation. 

Looks like this (It’s still rendering, but these are some stills):

So play is what I want to talk about today. 

Play is something SUPER overlooked when it comes to learning a new skill, but it’s SO important. With classes in most schools that I’ve been in trying to cram was much info into their courses as possible, they can be stressful affairs. You’re trying to force a way of learning and while that may work for some, many people don’t retain information that way. For me, in order to understand something, especially programs, I need to “break them”. What I mean is, I need to mess around with them. See what happens when I do what I intuitively want to do vs. the recommended way to do things. Sure, you often lose project files. Sure, you frequently get error messages. But once you get used to this regular failure, you can fail faster and find the boundaries of what you can and can’t do. 

Take Adobe After Effects for example, an animation tool for 2D animation that I use almost everyday for work. I took a class or two in college on 2D animation using it, and while the knowledge-base I picked up there was valuable, just sitting in a coffeeshop and experimenting without pressure or deadlines was an equally effective learning tool. The program knowledge you gain from following along to an instructor is great, don’t get me wrong. It’s just that when you learn in that setting, you’re typically taught one way to achieve a task. This is great if the next time you open up the program, that’s the specific effect or animation you’re trying to create. You know all the steps to achieving it from someone who knows their stuff. But what if the next time you open up the program, you need to do something similar, but that requires a different animation setup? In classes they understandably try to keep you from failing, so they teach that best way to do something. When you learn through experimentation and failure, you might not know exactly every step to achieving a specific task, but you learn what will happen if you do weird stuff. What I mean is, you learn how to learn. Because of the nature of animation, there is almost without fail ALWAYS more that one way to get to the same end output. So knowing 10 different ways to do something is often far more valuable than knowing 1 really good way to do something in a controlled environment. 

TLDR: Fast failure = Fast learning.

Fail more, friends. You might surprise yourself with how much you learn while you do. 

Jake-out