I have been home from the fantastic Eyeo Festival for a full day and thought I should write up a few notes that I neglected to mention during my talk. I had intended to say this stuff out loud but as I ran out of time and since I had switched over to showing iPad content, I never went back to my presentation where I had a few extra notes and takeaways ready to go. So here they are.
Iterate
Your first attempt at anything is likely going to suck. Let’s face it, most of us are not phenoms. In fact, I cannot think of a single person I have met in my 38+ years who was able to excel at something shortly after trying it for the first time. We all need practice, and lots of it, for everything we try. From learning to talk and walk, to learning to play an instrument, to learning to drive, to learning how to be a social creature… it all takes practice.
Want to know how to get better at something? Do it over and over. And over and over and over.
However, it cannot just be mindless repetition. There are two additional factors that need to come into play. You need to also do the following.
1) Correct. You should work on fixing the things that didn’t go right with the previous iteration. Make a list of the things you want to address. Tackle the big items when you have a clear head and a nice block of time. Otherwise, pick off the smaller ones. However, don’t get overzealous with your corrections. If you happen to mutate your project into something interesting but unintended, save this mutation so you don’t overwrite it. I have lost some nice bug-made oddities because I was too concerned with fixing errors.
2) Improve. You should research the field to try and learn things to add to future iterations. This means looking at what people have already done and also what people are trying to do. Staying on top of advancements in your field of interest is definitely worth the effort. Unfortunately, this may mean you find yourself looking over SIGGRAPH white papers or University theses that are over your head. This is fine. Don’t get too caught up with not understanding what is written. Just look at the pictures if that is all you can manage. The important thing is to continually expose yourself to information about your interests.
Collaborate
I don’t know how many of you played D&D as a kid (or as an adult… no judgement here) but I will speak now as if all of you have. When you roll up a new character, unless you cheat it is highly unlikely you will create a demigod. You might have a 18 here or a 16 there, but you will never ever roll up a character with an 18 for every attribute. Ideally you will have one high attribute, perhaps an 18 strength. With an 18 strength, you would make a fantastic fighter. So off into battle you go.
But life, fantasy or not, is never easy. Your first run-in with a couple filthy thieves results in a gash across your chest and you drop half your hit points and suddenly you start to suffer the reality of the situation. You need healing abilities. So what do you do? Well, you don’t go running to the library to start a multi-year process to learn how to cast a healing spell. Instead, you find a cleric who has an 18 wisdom but happens to suck at fighting and you join forces. Now, you are much more powerful than the sum of your respective skills.
And the beauty of this setup is that nobody feels like they are being taken for granted. The fighter has an intense appreciation for the healing abilities of his new cleric friend, and the cleric is thrilled to have found someone that can fight off the horrible monsters that lurk out in the wilds. So if you are a fighter, find yourself a cleric friend. If you are a cleric, track down some muscle for hire. Because if you don’t, you will live a limited life and never get to see what is on the other side of the dark forests at the base of Mount Craggyspire. Or whatever.
I have spent much of my coding career learning how to manipulate particles and figuring out how to make OpenGL make things pretty. But I suck at many other aspects of coding. Which is why the projects involving collaboration ended up being the most successful. The visualizers I have made with Andrew Bell, and the Planetary iPad app which I am currently developing with Bloom… those projects have meant the most to me and I am damn certain I would not have been able to make them on my own.
Baby Steps
I went through a talk I gave in 2004 and saw a slide that, though a bit harsh, still represents the best advice I can give to young idealistic coders. It said, in bright red on white, TAKE TINY STEPS OR FAIL!!! and the FAIL!!! bit was flashing on and off for emphasis.
A problem I suffer (and hopefully it isn’t just me) is that I see something awesome someone else made and it gets my mind churning and I start thinking “I can totally do a 3D terrain simulation with physics, CLoD implementation, and realtime weather effects” so I dive right into XCode and start making my Globe class and the Weather class and on and on and before you know it, I feel extremely overwhelmed which usually has me running for the remote so I can watch science documentaries in an attempt to distract my bruised ego. Knowing exactly what you want to make can often be the largest barrier in your creative journey.
My advice in this situation is to take some time to break the problem up into bite size pieces. Work on little prototypes. Explore each tiny concept and eventually, start to put them together. If you are too focused on the gap between what you envision and what you currently have, you will likely lose faith.
Plus, if you have a bunch of well-understood bite size pieces, it will make it much easier to combine them into bigger projects. But if you start in with building a big project, it is much more difficult to pull out the pieces you want to repurpose later.
Take a walk or a shower
This may not work for everyone but it has been very useful to me. If I am stuck, either creatively or programmatically, I go for a walk. Or if it is late in the evening, I will take a hot shower. Something about those two activities really helps me clear away the mental fog and helps me to focus on the issues at hand. I have cleared many a hurdle just by putting on my headphones, slipping on some shoes, and going for a walk through the neighborhoods of San Francisco. This doesn’t mean walking over to the neighborhood bar for a drink. Walk while mulling over the problem at hand and head home when you have an idea of what to try next.
I realize what I am writing here is nothing new. We have all heard these points made by many. They have reached rockstar cliché status. But this doesn’t mean it isn’t worthwhile to be reminded every now and again.
Ira Glass on creativity: http://www.youtube.com/watch?v=BI23U7U2aUY
Frequently asked Questions
Should I learn Processing, OpenFrameworks, or Cinder?
Depends. On many things. Your skill level, your dedication, and your interests. It is important to say that it is not a matter of which framework you choose. It is much more about how much effort you are willing to put into it. Learning something new can be hard and I sometimes worry that when I am asked this question, what I am really being asked is “Which is easiest?” Unfortunately, coding is difficult. And as I mentioned above, there is no substitute for practice.
That being said, I usually answer Processing. Not because Processing is easy, though it is definitely easier than trying to learn C++. I answer Processing because Ben and Casey have made it part of their mission to create a framework that would make it as easy as possible for those with a less technical background to enter the world of creative coding. The first thing you learn in C++ is usually something like how to write text into the console. The first thing you learn in Processing is how to draw a circle. Coming from a visual arts background, I was far more interested in drawing circles. I still am.
This doesn’t mean learning Processing over a C++ framework will limit your work. This is especially true if you plan on doing a lot of graphics work with OpenGL. Generally speaking, OpenGL is OpenGL regardless of whether you are getting there through Java or C++. And with all the advancements that are happening to Processing (look for Processing 2.0 soon) it is definitely a fantastic tool to become familiar with. So when I started to look for an alternative to using Flash for my code experimentation, the answer was a resounding Processing. But if you are a bit more computer-minded are are willing to put in the long hours reading C++ books and searching Stack Overflow for obscure Xcode error messages and trying to wrap your head around the difference between pointers and references and the reasons to use one over the other, something like OpenFrameworks or Cinder might be right for you.
What is the difference between OF and Cinder?
Honestly, that is not something I can speak to as I have only used OF a couple times. It was shortly after the Mac version came out and it was alpha and unstable. It has come a very long way since those early days. However, I am definitely a Cinder person and would be happy to talk about all the ways in which Cinder is awesome. I just can’t fairly speak to how it compares.
How should I get started?
The first half of the Hello, Cinder tutorial covers the creation of a simple particle engine and shows how to use it to do algorithmic stippling. The second half turns the particle engine into a flocking simulation. It does so using a three-rule system first described by Craig Reynolds here. During my Eyeo talk, I forgot to mention Craig Reynolds seminal contribution to the field of flocking simulation and only referenced Ian Couzin’s work (discussed here at a Radiolab webcast).
Also, take a peek at a post I wrote last year. Much of what is mentioned there is still relevant.
Hope this helps!
