10,000 hours.
I’m not a big fan of Malcolm Gladwell’s books, but one of the things I read about after seeing a review of his book Outliers got me thinking about my own students.
His book Anders Ericsson in which he studies the commonalities of “experts” and how they came to be that way. The upshot of which is that it is all about “practice”. Notionally, the book suggests that you become an expert at something by fulfilling a regimen of practice for “10,000 hours”. You can read the research yourself to see how far Gladwell has stretched that notion. The thing is, 10,000 hours works out to rougly 3.5 years of full time 8 hours-a-day work!
To give you a bit of background, I teach part-time at a University in the UK and one of my classes involves a module called Advanced Games Technology in which we ask students to produce a full game for themselves over a two semester period. We don’t really specify much in terms of constraints other than “it has to be 3D” and “it has to use some middleware”. Ultimately it is meant to be a portfolio peice for them, so they can throw all of what they’ve learnt into the game and produce something really polished.
Now I’ve been teaching this module for a few years now, so I’ve started seeing some patterns in terms of student response to this relatively simple and open brief. Can you guess what it is?
Yep, it’s paralysis. Literally, for some reason the sheer concept of starting a project from scratch on this scale seems to throw most of the students into a cartwheel of indecision. My thinking is that this is because up until that point, they have largely worked off fairly strict briefs and fairly regimented development schedules with specialized classes and teaching to support them. But then they are faced with “do whatever you really want to do” it seems what they really want to do is nothing!
Only, it’s not strictly that simple. Because this isn’t just common garden student laziness (anyone who has taught knows what that looks like). This is something else and I feel like it has some relationship to the experitise issue. Which is that they simply have never practiced actually thinking of making a project from scratch for themselves. Or rather, they haven’t practiced often enough for it to be second nature that you have a hundred ideas you want to create and never have enough time for them. Almost everyone I know in the games industry has both done more than 10,000 hours worth of work in their respective roles and has also gotten hundreds of ideas for games they would like to make.
Analysis paralysis
The other issue I think, is that many of them fail to start because they are stuck in the limbo of indecision trying to choose which technologies to build and which middleware to use. I’ve seen this issue happening with indie projects as well. Literally never starting on something because the perfect technology is not quite there, even if one is “close enough”. The main factor is that if you find that there is always a barrier to you starting a particular project (be it a new peice of technology, a new art peice, or a new feature for a game) then you should maybe start thinking that practice in terms of just producing something is a good idea. I used to get that kind of feeling a lot when I was doing my own indie games using Torque. I always found myself waiting for the garagegames.com guys to develop some new technology they’d been talking about so I could then work on using it for my game. That whole notion of waiting for someone else to develop core technology simply wasn’t something I ever had when I was working in commercial development, where we would rather work on our own solutions and not use someone else’s. But the end result was that I had an excuse not to simply practice and make progress even if ultimately I would end up using their solution further down the line.
How to fix the problem?
This is basically a mental blockage as much as anything else. But the ideal solution is to “practice” these things until they become almost like muscle memory. One great way I think to approach this, is to take part in a short term development competitions like Ludum Dare or any of the game jams. At the very least you will not feel like you are the only one to have the blockage. But if you practice throwing together project code and “getting things done” you will eventually get over that hump of not being able to figure out where to start.
Here area few other ideas for practice for programmers:
- Make yourself create small project files from scratch, including setting up all build settings. Create your own libraries from scratch and use them as both static and dynamic libraries.
- Make yourself a testbed project and integrate new technology middleware into it often, write code so that you can “wrap” each middleware so that you can implement new ones in an opaque manner
- Take on a new aspect of technology, in an area you are not familiar with (animation, graphics, networking, physics, engine design etc)
- Practice 2D and 3D, make prototypes that work with similar code across both (thinking in components is good here)
- Work on math skills, practice things like orientations and simple but useful tools like easing. Do plenty of work involving different coordinate frames and transformations.
- Work on interfaces and API designs. Time them and profile them. Look at how memory changes and how different sizes of allocations change the profiles.
- Find a new aspect of the language and implement something new with it. Look at delegates, smart pointers and any new C++ standards features. Study new features in boost and other open source frameworks (POCO for instance).
- Learn a new language, implement a completely unrelated type of project with it than you normally work with (i.e. a database, a tool of some sort etc).
I do think that many companies would actually be wise to give their devs time to practice starting smaller games from scratch too, although it seems fairly rare. But the idea of making quick prototypes and generally not sweating the details of choices or designs or architectures I think is a useful practice as it stretches you to not be concerned with details and instead by productive and experimental. Of course the details matter, but then you can practice those issues seperately. As the Ericsson research shows, the best experts actually use a well thought out practice regime. It isn’t that you simply practice for its own sake, but that you practice in order to learn something new, or to commit to memory some process or practice that you can build on incrementally. In a way you are trying to find flaws in your own process and then factoring in corrections into the overall practice regime.
I’ve recently been teaching myself 3D art skills and one of the things I’ve learnt is that simply practicing things like sculpting (for faces) helps to improve my eye for proportion and anatomy and helps me understand what makes a “good” image. So doing regular sculpting, even if I’m still fairly tragic at it all is good. As I learn the tools and the forms I slowly begin to appreciate the underlying structure and process.
I think we can see code in similar terms. So doing quick and dirty prototypes will begin to show you the underlying patterns we need to commonly use in more complex works. Or will show us some aspect of design we aren’t fully aware of until we actually try and develop in that area.
So my questions to you, the readers of this entry. Have you done your 10,000 hours? How do you approach practice and what do you do to work on your skills and to expand your working process? Have you tackled anything new recently? How did you learn the new area and how can you apply those learning processes to new areas next time?